ブロックチェーンとCAP定理

Yaron Goland氏は、マイクロソフトのプリンシパルアーキテクトであるが、ブロックチェーンのクライアントがその実装に基いてどのようにAPまたはCPとなるのかについて書いた記事を公開した。トランザクションのあとでそれが受け入れられるまでに来るブロック数の設定でこれは動作する。トランザクションのあとで発生するブロックの数が多くなればなるほど、システム全体の合意を持つ、一貫性のある状態になる可能性が高くなる。

ブロックチェーンはピアツーピアであり、分散データベースであり、事実の中心源はない。Goland氏はこれがビットコインのようなデジタル通貨でどれほど問題があるかを説明する。ユーザはビットコインを受け取ったと信じ、それを現実の通貨と交換し、それから後ほど財布を確認し、やがてビットコインがなくなったとわかる結果になる。

一方ブロックチェーンは一連の不変のブロックである。まだ各ピアが一連の異なるトランザクション履歴を作り上げることができる。この相違はフォークとして知られている。Golands氏の例での一貫性の問題の原因である。彼はブロックチェーンがこれを解決する方法は合意アルゴリズムを用いてであると説明する。そこでは最終的にどのフォークを捨てるべきであるかについて大多数の同意がある。

"これは結果整合性のとても伝統的な例です。2つの競合した値が書き込まれると、システムはそれについて話し、最後には競合の解決プロトコルが勝者を選択するために使われます。"

それはクライアントがAPまたはCPとなる結果整合のためにブロックチェーンを待つかどうかを選択しているとGoland氏は説明する。APとなるためにはクライアントはトランザクションがブロックチェーンに追加されるとすぐにそれを受け入れるべきである。この方法は、ピアの残りに何の依存性もなく、トランザクションを利用できるようにするが、残りのピアが一貫性を犠牲にしてトランザクションを拒否するリスクがある。CPとなるためには、クライアントはブロックチェーンが一度トランザクションについて合意を形成したならそれを受け入れるべきである。これは逆の影響がある。そこではデータは一貫しているが、もし合意を妨げるネットワーク分割があれば利用できなくなるリスクがある。

トランザクションへのシステム合意を待つ方法に関して、Goland氏は詳細な解説を公開した。彼はこのように要約している。"あらゆるものをそれが少なくともXブロックになるまで存在するものとして扱いません。" これが意味することはクライアントはトランザクションが受け入れられるまで、そのあとに起こるX以上のブロックを待つということだ。

Yanos氏はまたこの方法でクライアントを設定できることはCAP定理を壊さないと強調する。このタイプの設定は可用性と整合性のトレードオフだからだ。両方を同時に満たすことはできない。

"上記で私たちがしたことは、ビットコインがAPとCPの両方を持つことができない、ということを表しているのではありません。それは今完全に異なるCAPのトレードオフを持ちつつ完全に異なる2つのシステムをビットコインのすべての部分がクライアントを除いて同じままで構築できるということを表しています。"

要約すると、Goland氏はビットコインがピアツーピアモデルであるにもかかわらず、強固な整合性への要求を達成できることをデモストレーションした。これはビットコインのようなデジタル通貨ではとくに重要である。これはユーザがトランザクションを信頼できると意味するこのタイプのトレードオフだからだ。