はじめに
本記事は、過去にコンセンサス・ベイスが主宰していたオンラインサロンの記事です。記事は2017年~2018年にかけて執筆されたため、一部は、既に古くなっている可能性があります。あらかじめご了承ください。
今回の内容
前回はProof of Workの問題、それを置き換えるProof of Stakeの設計思想、Ethereumで導入されるCasperの第一段階であるCasper FFGを解説しました。今回は、もうひとつのCasperであるCasper CBCの紹介をし、Casperが導入されることによってEthereumで何が解決されるのか、将来の展望を説明します。
ゴール
Casper CBCがどのようなものかを理解します。その後、Casperが何を解決するかを理解します。
ターゲット
Ethereumに興味がある方を対象としています。
前提知識
暗号通貨やブロックチェーン技術、合意形成アルゴリズム、グラフ構造、オラクル、Nothing at Stake問題についての知識があること。 並びに前回の記事を読んでいることを前提とします。
もう一つのCasper
Casperの仕様は2つ考えられています。Casper FFG(Friendly Finality Gadget)とCasper CBC(Correct By Construction)です。2018年2月現在はテストネット上でFFGの検証が進められています。 前回説明したCasper FFGと、もうひとつのCasperがCasper CBCです。コンセプト段階で概念実証の段階のものもあるので、実際の導入の際には仕様が大幅に変更となる可能性があります。
Casper CBC
Casper CBC(Correct-by-Construction：構造による正しさ)は、合意形成プロトコルを「導き出す」方法で、Vlad Zamfirによってプロトタイプとして研究されているものです。
Casper CBCを利用することで、下記のように従来の合意形成プロトコルに比べて様々なメリットを持つプロトコル群が作成されます。
- 合意形成の安全証明が比較的簡単に行える
- プロトコル内におけるファイナリティの限界値が存在しない。
- ネットワークのオーバーヘッドだけでなく、バリデーター数による「ファイナリティの遅延」をトレードオフする
- 特定の状況下でのネットワークの理論的オーバーヘッドの最適化
合意形成プロトコル
まず、合意形成とはどういうものかをおさらいします。
例えば読者が10台のノードの所有者であり、これらのノードを1から100の間の乱数で合意したいとします。
コンピュータの信頼性が低いため、一部のコンピュータが予期せずクラッシュしたりするかもしれませんが、残っているノードの値は引き続き一致します。
障害のないすべてのノードが、同じ値にどのように合意するかをどうすれば確認できるか、これが合意形成の基本的な問題です。
番号を決定する2つのノードが、同じ番号を決定することを確認したいとすると、1台のコンピュータが「11」を提案し、もう1台が「12」を提案したとすると、合意形成はできません。
この2つのノードが異なる決定を行えない場合に、合意形成プロトコルは正常であり、安全であるといえます。
前回説明したProof of Work(以下PoW)やProof of Stake(以下PoS)も合意形成プロトコルの一種です。
実際には予期せぬネットワークの遅延や、ノードがクラッシュする、誤動作をするなどの状況も考えられますが、その点は後ほど説明します。
Casper CBCの研究は、パブリックブロックチェーンのためのPoS合意形成プロトコルの調査として始まりましたが、調査を進めていくうちにより一般的な合意形成プロトコルの研究分野に発展しました。
執筆時の現時点で、Casper CBCには以下の6つの合意形成プロトコルが存在します。
- Casper the Friendly Binary Consensus Protocol：0または1に合意
- Casper the Friendly Ordinal Consensus Protocol：整数に合意
- Casper the Friendly List Ordering Protocol：リストの並び順に合意
- Casper the Friendly GHOST Protocol：ブロックチェーンに合意
- Casper the Friendly Concurrent Schedule Replication Protocol：同時スケジュールに合意
- Casper the Friendly Sharded Blockchain：分割されたブロックチェーンに合意
ファイナリティ
Casper FFGはPoWのブロックチェーン上に重ねる形で設計されていますが、Casper CBCのうちの一つ、ブロックチェーンへの合意形成プロトコルであるCasper TFGは、ブロックチェーンの合意形成を劇的に見直しており、既存のPoWを合意形成に使っているチェーンの上に重ねることはできません。
Casper FFGはチェックポイントのみ投票により決定をするのに対し、基本的にブロック全てが投票になる点で、FFGと異なります。
ですのでCasper FFGに存在する、チェックポイント間の概念もありません。
前の例に戻って、1から100の間の乱数で合意形成できるように試みる10台のコンピュータを考えてみます。
伝統的な合意形成アルゴリズムでは、そのプロトコルに従っているノードたちは、プロトコルの終わりで出力を決定します。しかしながら、現在存在するすべてのPoWブロックチェーンでは明示的な決定は行われません。
トランザクションが入ったブロックの後続ブロックが生成され、チェーンが伸びたところで確率的に決定がなされているだけで、51%攻撃などで覆る可能性があります。 Casper TFGにおけるPoSプロトコルは、ノードにブロックの決定を行えるようにしようとしています。さらにノード群が矛盾した決定を下すことは不可能とすることで安全性を保証します。
安全証明
Casper CBCの安全性を証明することは、従来の合意形成アルゴリズム、例えばPaxosのようなものに比べ、非常に簡単です。
- すべてのバリデーターは、受け取った一連のメッセージを保持しています。これをビュー、またはプロトコル状態と呼びます。
- バリデーターは、合意の現在の値についての見積もりを行うためにエスティメーター（見積もりを推測する機能）を使用することができます。エスティメーターは、現在のプロトコルの状態やバリデーターが受け取った見積値の集合に基づいています。例えば、バイナリ値の合意形成では、エスティメーターは「0」または「1」を返します。ブロックチェーンの合意形成の場合ですと、エスティメーターは「正しいブロックチェーンはxxxxというブロックで構成されています」と返します。
- また、見積もりの安全性を定義します。将来のプロトコル状態の見積もりになる可能性がある見積もりの場合、その見積もりはプロトコルの状態において安全といえます。例えばバイナリ値の合意形成では、とあるバリデーターが見積もりは「1」と表明し、将来において他のバリデーターから受け取ったメッセージとは関係なく、見積もりは「1」になるだろうと確証できる場合、見積もり1は安全性を持つといえます。
あるバリデーター1が、自身の見積もりは安全であると検証し、バリデーター2も自身の見積もりが安全であると検証した際、お互いの見積もりが競合しないようにする必要があります。
例えば、バイナリ値の合意形成では、他のバリデーターが「0」を安全であると検証しておきながら、他のバリデータが「1」を安全であると検証することは不可能であるべきです。
欠陥のあるバリデーター
上記の安全性証明では、欠陥のあるノードや不正なバリデーターについての説明を省きましたが、ノードがクラッシュしたり予期しない動作をしたりすることで、合意形成プロトコルの終了時に他のノードが決定を下すことを不可能にしたり、異なるノードが競合した決定を起こす可能性があります。
ブロックチェーンが動作し続けるためには、障害耐性を持つ必要があります。主要なタイプの障害として、
①ノードのクラッシュ ②無効な見積もりのメッセージ ③曖昧な状態が起きた際 の3点を例に挙げ、それらの状況下でCasper CBCではどのような振る舞いが起きるのかを説明します
①ノードのクラッシュ
1点目のノードのクラッシュについてです。
クラッシュ状態はノードがメッセージを作成しなくなった際に発生します。クラッシュノードは他のノードが意思決定を行うことを不可能にする可能性はありますが、他のノードが異なる決定を下すことを助長することはありません。
②無効な見積もりのメッセージ
2点目の無効なメッセージを生成しているノードの場合も、簡単に理解しやすい障害です。例えば、Casper CBCのバイナリ値の合意形成プロトコルを実行している場合、メッセージは必ず「0」か「1」になります。ノードが見積もりとして「2」をメッセージにするとします、これは明らかに無効な値です。
③曖昧な状態が起きた際
3点目の曖昧な状態は、一番気をつけないといけない状況でしょう。
とあるノードが同時に2つの合意形成プロトコルを実行している時、2つの合意形成プロトコルはお互いを認識していません。
たとえば、バリデーターが同時に2つのメッセージを作成した場合、1つは見積もりが「0」であり、もうひとつは「1」の状態があったとすると、ノードが値に合意したい状況にとって悪い影響を与えてしまいます。
このような、障害を処理するために、不正な見積もりメッセージや無効な見積もりメッセージの閾値を設けておき、それを超えたら有効な合意形成プロトコルではなくなるという条件を追加します。
これにより、閾値を超えない欠陥であれば、ノードは同じ決定を下すことが保証することが可能となります。この例でいえば、どちらかのメッセージを無視するようにする条件を決めておけば良いでしょう。
オラクル
上記の理由より、欠陥があるバリデーターがあったとしても、その他のバリデーターは安全な見積もりを決定することができます。あとは、バリデーターが各々の見積もりを安全なタイミングで検証する技術が必要になってきます。
これを実現するために、バリデーターが使用する安全なオラクルを使用します。
安全なオラクルは、プロトコルの状態といくつかの見積もりを入力として受け取り、そのプロトコル状態で見積もりが安全である場合は「true」を返し、そうでない場合は「false」を返します。
例えばリソースが制限されているデバイスや様々な環境に適応するため、複数のオラクルを用意します。現在はコードベースの概念実証として下記の3つのオラクルが存在しています。
敵対的なオラクル
敵対的なオラクルは、プロトコルと見積もりを与えられると、バリデーターをシミュレーションして見積もりを変更しようとします。変更に成功したら、見積もりが安全ではないと判断し「false」を返します。
派閥オラクル
バリデーターとその見積もりをグラフ構造で表現します。このグラフ構造の中で、どの見積もりを持つ派閥が最大であるかを探索します。最大の派閥が50%以上であればその見積もりにはある程度の安全性があると考えられます。
テュランオラクル
バリデータと見積もりをグラフ構造で表現する点で、上記の派閥オラクルと似ています。異なる点は、派閥オラクルが最大の派閥を探索したのに対して、テュランの定理を利用して、グラフ上に存在すべき最小の派閥のサイズを探索します。この作業により、見積もりが安全であるかを検証し、この見積もり必須である最小限の安全性を計算します。
図1：バイナリ値の合意形成プロトコル実行例
ノード上のラベルは、見積もりを表します。見積もりの安全性を達成した場合、その正当性を考慮して派閥オラクルに合致するメッセージが色づけされます。色が濃いほど誤った見積もりである可能性が高くなります。
Casperは何を解決するか
Casper CBCについての理解を深めた上で、あらためて、Casperは何を解決しようとしているのかを考えてみましょう。
非中央集権化
PoWでは、ハッシュパワーの高い者や集団ほどETHを手に入れやすく、富が集中化してしまう問題がありました。CasperではPoSを導入することで、その問題を緩和しています。
オリジナルのPoSには資産の溜め込みや流動性の低下の問題がありましたが、Casper FFGではデポジットしたETHのロック期間を設けており、さらに他のインセンティブを設計することで問題の解消をはかってくるでしょう。
電力消費の削減
ブロック生成にPoWのような巨大なハッシュパワーを必要としないので、大量の電力を消費することがなく、環境問題を解決することができます。
スケーラビリティ
Casperによって実現される明示的な決定とノードの負荷を下げることによって、ネットワークを構成するノードのサブセット（ノードの中の一部のノード群）のみを切り出して特定のトランザクションを処理する、またはラウンドロビンで処理を行う、といったことができるようになります。
これにより、Ethereumの処理性能を大幅に向上させることが期待されているシャーディングという技術を下支えする仕組みが実現できます。サブセットを構成するノードが減ることにより、51%攻撃がやりやすいなどのセキュリティ面での問題が出てきますが、その点もCasperの合意形成プロトコルでカバーしようとしています。
Proof of Stakeの問題
オリジナルのProof of StakeにはNothing at Stake問題があります。
ブロック生成コストが低いことに起因する問題ですが、CasperではSlasherの機能を導入することでネットワークに利益をもたらそうとしない者に罰則を与え、問題を解消しようと試みています。
Slasher外からの過去ブロックからのフォークに対しては、過去のブロックからはフォークができないような設計もなされており、ロングレンジ攻撃にも対策を取っています。
Casperのロードマップ
Casperの最終的な形式は、Casper FFGとCasper CBCの両方からの研究結果によって得られる可能性が高いと考えらています。
しかし、現状ではCasper FFGが第4段階目のハードフォークであるSerenityで、Casperの第一弾として導入される予定としか決定されていません。
また、メインネットに導入するには既存のEthereumネットワークの大きな変更が必要とされています。
まずは、第1段階目のCasper FFGでPoWとPoSのハイブリッド運用が安定したのち、バリデーターの数を増やし、PoWのマイニング報酬を段階的に減らしていくと考えられています。
Casper CBCについては具体的な予定は決定していませんが、2018年3月にフランスで開催されるEthereum Community Conferenceで、さらに詳細な情報が発表される可能性もあります。
まとめ
まだ研究段階で実装においては未決定のものが散見されるCasperですが、Ethereumが真の意味でアプリケーションプラットフォームとして成立するためには必須の技術要素となっています。
シャーディングへの布石として重要な技術であるCasperは、今後も動向を注目していくべき対象となるでしょう
