ブロックチェーン連続講義 第5回 分散システムのリテラシー

分散システムのリテラシーブロックチェーン連続講義第 5 回

慶應義塾大学 SFC研究所上席所員斉藤賢爾

[email protected]

ブロックチェーン連続講義第 5 回「分散システムのリテラシー」— 2016-03-25 – p.1/31

今回のテーマ分散システムのリテラシー

ブロックチェーンの可能性と限界を考える上で基礎となる、分散システムの基本的性質についての解説です

FLP不可能性、CAP定理といった基本原理から、ビザンチン将軍問題、様々な障害モデル、CUP (未知の参加者とのコンセンサス)、そして P2P特有の問題であるオークション問題やエクリプス攻撃まで、分散システムではどのような条件のとき何ができて、何ができないのか、ブロックチェーンに関する安易なセールストークにも騙されないリテラシーを身につけます

ブロックチェーン連続講義第 5 回「分散システムのリテラシー」— 2016-03-25 – p.2/31

分散システムのリテラシー1. 分散システムの法則とブロックチェーン2. ブロックチェーンのチャレンジ3. 本当は怖い P2P

4. 課題の意味

ブロックチェーン連続講義第 5 回「分散システムのリテラシー」— 2016-03-25 – p.3/31

1. 分散システムの法則とブロックチェーン

ふたりの将軍問題FLP不可能性CAP定理ビザンチン将軍問題コンセンサス

ブロックチェーン連続講義第 5 回「分散システムのリテラシー」— 2016-03-25 – p.4/31

ふたりの将軍問題

将軍 A, Bは敵を攻める計画に合意したいしかし A-B間はメッセンジャー mを通してしか通信できない

メッセンジャーは敵に捕らえられる可能性があるAが発案した計画に Bが合意していると Aが知る手立ては？

そして Bの合意を Aが知っていると Bが知る手立ては？そして . . .

ブロックチェーン連続講義第 5 回「分散システムのリテラシー」— 2016-03-25 – p.5/31

絶望したみなさんへ分散システムの課題への取り組み方

1. 一般に X は不可能である2. X を事実上可能にする条件 C がある3. 条件 C を成立させる方法を考える

例えば1. 伝令を用いるふたりの将軍問題には解がない2. だが花火を打ち上げると事実上可能になる3. 花火を作る方法を考えるただし、この「花火」は reliable multicastのことであり、実現するには合意の問題を解かなければならない

ブロックチェーン連続講義第 5 回「分散システムのリテラシー」— 2016-03-25 – p.6/31

同期システム・非同期システム同期システム参加者の時計が同期されているシステム

非同期システム参加者の時計が同期されておらず、その進み方もまちまちなシステム

仮想的にでも同期システムが作れれば色んな問題を解決できる例 : イベントの順序づけ、タイムアウト後述するビザンチン将軍問題の解も同期システムを前提

ブロックチェーン連続講義第 5 回「分散システムのリテラシー」— 2016-03-25 – p.7/31

セイフティとライブネスセイフティ (safety)悪いことが決して起きない、という形式の性質

ライブネス (liveness)よいことがいつか起きる、という形式の性質

分散システムの要件はセイフティとライブネスの組み合わせで表される(それにより時相論理で証明したり議論したりすることが可能になる)

要件は不変項分散システムは要件を不変項として維持するシステム答えを出すのではなくて (答えを出す =計算を完了して止まる)

ブロックチェーン連続講義第 5 回「分散システムのリテラシー」— 2016-03-25 – p.8/31

障害の種類メッセージが届かない、ノードが停止する→ ビナイン/良性 (benign)

前提を置かない→ ビザンチン (Byzantine)

ビザンチン障害では、プロトコルから逸脱する任意の事象が起きる裏切りとか共謀とかただし、悪意によりプロトコルから逸脱するとは限らない「悪意のある (malicious)」より広い概念

ブロックチェーン連続講義第 5 回「分散システムのリテラシー」— 2016-03-25 – p.9/31

FLP不可能性完全なる非同期システムにおいては、いかなるコンセンサスプロトコルもただひとつのプロセスが予告なしに停止するというだけで合意を達成できなくなる

ちなみにメッセージの伝達自体は完璧という前提でただし遅延に上限を設けられない

Fischer, Lynch, Patersonが証明現実的にはタイムアウトにより障害検出の「見なし」を行う

ブロックチェーン連続講義第 5 回「分散システムのリテラシー」— 2016-03-25 – p.10/31

CAP定理Consistency (一貫性)

読み出しは直前の書き込みの内容を返す

Availability (可用性)

必ず有限時間内に応答する

Partition tolerance(分断耐性)

ネットワークが分断されても動作する

⇒ 3つは同時に満たせない止まらないブロックチェーンは Cを満たせないEventual consistency (結果整合性)を狙うわけだが . . .

ブロックチェーン連続講義第 5 回「分散システムのリテラシー」— 2016-03-25 – p.11/31

Consistency (一貫性)

Strong consistency (強い一貫性)更新が完了した後、すべてのアクセスは更新された値を返す (safety)

Eventual consistency (結果整合性)更なる更新が行われない限り、いずれすべてのアクセスは最後に更新された値を返す (liveness)

↑ 強化

Weak consistency (弱い一貫性)すべてのアクセスが更新された値を返すことは保証しない ←ブロックチェーンはココ (エクリプス状態を想定)

ブロックチェーン連続講義第 5 回「分散システムのリテラシー」— 2016-03-25 – p.12/31

ビザンチン将軍問題n人の将軍がそれぞれの軍隊を率いている攻めるか、撤退するか、合意しなければならない地理的に隔離されていて、メッセンジャーを通してしか通信できないメッセンジャー =伝令者

高々f 人の忠実でない将軍がいる

という前提で、以下を満たせ忠実な将軍は全員、同じ計画に合意する合意された計画は、忠実な将軍の誰かの発案と等しい (裏切り者にだまされない)

ブロックチェーン連続講義第 5 回「分散システムのリテラシー」— 2016-03-25 – p.13/31

ビザンチン将軍問題を解く

「司令、攻撃やめるってよ」副官 1から見てシナリオ 1, 2は区別できない

n ≤ 3f では解が存在しないブロックチェーン連続講義第 5 回「分散システムのリテラシー」— 2016-03-25 – p.14/31

コンセンサスCS1 : 提案された値だけが選択されるCS2 : ひとつの値だけが選択されるCS3 : 正しい参加者は選択された値だけを学ぶCL1 : 提案された値のどれかがいずれ選択されるCL2 : 値が選択されるなら、正しい参加者はいずれその値を学ぶ

ブロックチェーンはコンセンサスを実現しない提案 : ブロックのブロードキャスト選択 : 続くブロックのブロードキャスト各々がスコアが最大 (e.g. 最長のチェーンの末尾)と判断するブロックに続ける

ブロックチェーン連続講義第 5 回「分散システムのリテラシー」— 2016-03-25 – p.15/31

Paxos (1)

論文 : 「パートタイム議会 (The Part-Time Parliament)」エーゲ海にある Paxos島の物語

たまにしか出席しない議員たち (パートタイム議員)によって法案は成立させていけるか？議員↔サーバ市民↔クライアント現行法↔データベースの状態

議員たちは、たまにしか出席しないが、出席しているときは真面目に業務をこなす⇒ ビナインな障害に耐える

ブロックチェーン連続講義第 5 回「分散システムのリテラシー」— 2016-03-25 – p.16/31

Paxos (2)

コンセンサスを実現するための役割提案者 (proposers),承認者 (acceptors),学習者 (learners)

プロトコルの超概要1. 提案者は提案を複数の承認者に向けて送る提案は番号により順序づけされる提案をやり直すときは番号を大きくする

2. 承認者の過半数が承認したとき、提案は受け入れられたとする

多くのコンセンサスプロトコルは変形により Paxosと同型であることが示されているブロックチェーンは違う(コンセンサスを実現していないし)

ブロックチェーン連続講義第 5 回「分散システムのリテラシー」— 2016-03-25 – p.17/31

耐ビザンチン障害 Paxos

Paxosプロトコルにはビザンチン障害への耐性を持たせられる

2f + 1の正常な参加者により Paxosを実行することで最大 f の裏切り者に耐える、みたいな一般化された “byzantizing”手続き

Byzantine Paxosと呼ばれる

変形により PBFT (Practical ByzantineFault-Tolerance)と同型

ブロックチェーン連続講義第 5 回「分散システムのリテラシー」— 2016-03-25 – p.18/31

2. ブロックチェーンのチャレンジCUP (Consensus with Unknown Participants)

斉藤-山田不可能性 (仮)

ブロックチェーン連続講義第 5 回「分散システムのリテラシー」— 2016-03-25 – p.19/31

(B)FT-CUP (Consensus with Unknown Participants)

未知の参加者の間で耐障害性 (ビナイン/ビザンチン)を持つコンセンサスプロトコルは作れるか？

耐ビナイン障害 : FT (Fault-Tolerant)

耐ビザンチン障害 : BFT (Byzantine Fault-Tolerant)

アドホックネットワークや P2Pに適用される問題

ブロックチェーンもこの種の問題への取り組みと見なせる従来の提案では参加者数 nを探ってからFT/BFT プロトコルを適用する

完璧ではありえない

ブロックチェーン連続講義第 5 回「分散システムのリテラシー」— 2016-03-25 – p.20/31

斉藤-山田不可能性 (仮)

ノードの総数 nが定まらない状況下ではコンセンサスを満たすプロトコルは存在しない

(すでに他の人が証明していたら教えてください)

6月下旬に論文発表予定

p.6「絶望したみなさんへ」参照

ブロックチェーン連続講義第 5 回「分散システムのリテラシー」— 2016-03-25 – p.21/31

3. 本当は怖い P2PP2Pオークション問題シビル攻撃 -ブロックチェーンの場合は無問題エクリプス攻撃 -リアルな脅威

ブロックチェーン連続講義第 5 回「分散システムのリテラシー」— 2016-03-25 – p.22/31

本当は怖い P2P

例題: P2Pオークション問題隣接する 3つのノードに出品情報の転送を依頼〆切後、その 3つのノードからしか入札がなかったと判明競争相手を減らす戦略が採られた

参加者は利己的にプロトコルから逸脱しうる

ブロックチェーン連続講義第 5 回「分散システムのリテラシー」— 2016-03-25 – p.23/31

シビル攻撃とその無問題性シビル (Sybil)

16の異なる人格をもつ患者の記録のノンフィクションどうやら捏造らしい

転じて、ひとつの主体が複数の参加者になりすましてシステムに参加する攻撃を指す

ブロックチェーンでは一般に参加者の数ではなく資源量が問題となるそのためシビル攻撃自体に対する考慮は不要

ただし悪意をもつ主体による大量な参加者投入には要注意

ブロックチェーン連続講義第 5 回「分散システムのリテラシー」— 2016-03-25 – p.24/31

ビザンチン将軍問題を解く again

ランポートらによる解n > 3f であれば解ける通信路について条件がある

ブロックチェーンで解だと言われているもの全体の資源量を R、裏切り者の資源量を F としてR > 2F であれば解けている

⇒ 条件が議論されているように見えない無条件には解けないはず本当は暗黙に条件がある

ブロックチェーン連続講義第 5 回「分散システムのリテラシー」— 2016-03-25 – p.25/31

エクリプス攻撃

悪意の (または故障)ノードがネットワークを分断し、互いを見えなくする

ブロックチェーンの場合は、分岐が永続するf = 1で原理的に可能 ⇒ 資源の総和 Rは無関係

ブロックチェーン連続講義第 5 回「分散システムのリテラシー」— 2016-03-25 – p.26/31

4. 課題の意味課題の整理再訪ワンネスの罠再訪

ブロックチェーン連続講義第 5 回「分散システムのリテラシー」— 2016-03-25 – p.27/31

技術の整理と課題ブロックチェーンの技術は 3層に分けて考えられる

1. デジタル署名によるデータ構造誰もが制御を持て、自己充足構造で誰もが検証可能

⇒ 有益2. ダイジェストを格納するブロックの連鎖の構造相対時刻を定義する、証明の基盤

⇒ 想定されていたほど強固ではない3. コンセンサスのプロトコル

TXとしての確定に向けたトライアル· コンセンサスを厳密な意味では実現せず後追いでしか語れない

⇒ 現実と同期して動く上で問題がある

課題の解決と、課題が解決されたことを前提とする応用の探究を同時に進める必要がある

ブロックチェーン連続講義第 5 回「分散システムのリテラシー」— 2016-03-25 – p.28/31

スケールアウト問いいつも 10人並んでる ATMが 1台ありますここで新たに ATMを 1台足すと行列の人数はどうなるでしょう？

参考 : 山崎大輔さん「スケールアウト再考」http://www.slideshare.net/yamaz2/ss-58813038

サーバを追加することにより性能上の問題を解決可⇒ システムがスケールアウトする

ブロックチェーンは素のままではスケールアウトしない

KVSだと思えば改良は可能ブロックチェーン連続講義第 5 回「分散システムのリテラシー」— 2016-03-25 – p.29/31

望まれる諸性質 vs. ワンネス取引の増加に伴い、データ構造を維持するためのコストが直線的に上昇する

「世界がひとつ」でなければ動作しない大規模災害や政変などによりネットワークが分断されると正しく動作しない技術を進化させるガバナンスが利きにくい一部で違うことを試してうまくいったら全体で採用、ということができない

以上は分権できない構造による欠点逆に、分権できる分散コンセンサス基盤には大きな期待と可能性がある

ブロックチェーン連続講義第 5 回「分散システムのリテラシー」— 2016-03-25 – p.30/31

ご質問や議論を

ブロックチェーン連続講義第 5 回「分散システムのリテラシー」— 2016-03-25 – p.31/31