Libra BFTコンセンサス・アルゴリズムの解説 #4

3.Libraブロックチェーンとのインテグレーションについて

3.1. コンセンサスプロトコルについて

我々は、LibraBFTはLibraブロックチェーンに以下のように使われることを想定している。

•Libraのバリデーターたちが、LibraBFTのコンセンサスプロトコルに参加する目的は、Libraブロックチェーンのステートをセキュアに複製するためである。各バリーデーターは、我々が、SMRと呼ぶモジュールを使って、LibraBFTのノードの運用環境を構築する。ここからは、LibraBFTへの参加者をバリーデーターノード、もしくは単純にノードと呼ぶ。

•SMRモジュールに送られるコマンドは、Libraにおける一連のトランザクションである。SMRモジュールの視点から見ると、コマンドと実行されたステートは、不透明なデータ構造である。SMRモジュールは、そのコマンドの実行をすべてLibraの実行モジュールにデリゲートする。そして、その実行されたステートからEpoch IDを読むのである。(epoch IDの変更がコミットされた際は、現在のepochを停止するリコールが実行される)

•重要なこととして、SMRモジュールは、与えられたEpochの投票権の実行を、残りのシステムにもデリゲートする。これは、先ほどあげたリコール方式と同じ方式で、Epochを管理している実行レイヤーに対してコールバックされる。よりベターな柔軟性と透明性を獲得するために、我々は、このロジックは、Libraの開発言語であるMoveで記述されることを期待している。

• コマンドが実行されるたびに、Moveによって記述されたスマートコントラクトに、実行するエンジンがタイムバリューを与える。このタイムバリューは、全てのSMRノードが同じコマンドを実行する一貫性が保証されている。

•SMRモジュールによって実行されたステートは、実際のブロックチェーンデータである必要性はない。実際には、このレポートで言う所の、”実行されたステート”は、ハッシュ値に代表される軽量化されたデータ構造である。そして、そのデータ構造は、バリーデーターのローカルストレージに実行された具体的なステートの記録として保存される。全てのコミットされたコマンドは、咲いて1回は、全てのバリーデーターに、ローカル環境で実行されなくてはならない。未来においては、LibraBFTは、バリーデーターが、別のバリデーターの最近の実行した類似のステートと同期を取るため、追加のメカニズムを加えるかもしれない。

3.2. リブラのクライアント環境

LibraBFTのデザインは、バリデーターノードが、Libraシステムのクライアント環境とどのようにインタラクトするかとはほぼ独立している。しかしながら、以下のことが言える:

• Libraのクライアントより送られてくるトランザクションは、Memppol プロトコルを利用して、まず第1にバリーデーターノードに共有される。そしてコンセンサスを取るリーダーが、ブロック更新の提案をする際に、そのmempoolからトランザクションを取り出すのである。

• Libraのクライアントに対して、ブロックチェーンのステートの正しさを証明するために、LibraBFTのノードは、特定の実行されたステートがコミットされたことを証明するためショートコミットメントに著名をする。この暗号学的なコミットの認証は、LibraBFTのコンセンサスプロトコルの詳細とは独立して証明が可能であるように設計されている。Libraのクライアントは、矛盾しないEpochのバリデーターキーのセットを提供されることで、この認証を取ることができる。このどのようにコミットメントがt繰られて、コンセンサスが得られるかについては、セクション4.1で説明している。

•上の前提条件によれば、現時点では、Libraのクライアントが、一つか複数の善意的なバリーデーターとのインタラクションによって、一連のバリーデーターキーを知ることができるようになっている。しかし、将来的には、ここにもセキュリティプロトコルを追加する予定である。

3.3. セキュリティについて

ブロックチェーン・アプリケーションは、同様に、追加のセキュリティ配慮を必要とする。

•ネットワワーク参加者は、一定規模の、CPU、メモリ、ストレージなどのコンピューティングリソースを確保できなければならない。これが保証できないと、ビンザンチン的な振る舞いが起きた際に、ネットワークの実践的な生存性を維持できない。次のセクション4では、我々のデータ・コミュニケーション・レイヤーが、どれぐらいのデータをバリデーターがコントロールすることになるか、そのレシーバー・コントロールについて、そのメカニズムの詳細について紹介する。より包括的な分析は、将来的にこのレポートで展開する予定である。

• 善意的なノードに対する経済的インセンティブは、SMRプロトコルのセキュリティとパフォーマンスに比例して提供されるべきものである。その報酬とペナルティについてのラフなアイデアについては、セクション9で説明している。

• リーダーは、サービス妨害攻撃について対応しなければならない。セクション7で説明しているペースメーカーモデルは、我々が考えるVRF(Verifialble Random Function)において、どうやって予測不可能な形でリーダーを選出するかについてそのラフなアイデアをまとめている。将来的には、より強力なリーダーを頻繁に選ぶために、我々はリーダーセレクションにおいても影響力を及ぼすかもしれない。システムレベルにおけるノードのプロテクションについては、このレポートではカバーしない。

ここで公平性についても述べておく。安全性と生存性に加えて、SMRシステムで、もう一つ考慮しているのは、公平性である。善意的なノードによって実行される全ての正当なコマンドは、結果的にコミットされるされるという伝統的な定義に関わっている話であるが、しかし、この伝統的な定義は、Libraのようなブロックチェーンアプリケーションのモデル、つまり、トランザクションが、共有化されたmempoolにまず行き、トランザクション手数料に応じてオークションにかけられるやり方の場合、あまり相関性がない。この点の公平性については、将来的な取り組みとして継続する考えである。


これ以降は、かなり技術的な説明になるため、翻訳は一旦ここまでにします。皆さんの参考になれば幸いです!

関連記事