本稿について
本稿は、Tendermintホワイトペーパーの詳細版ともいえるTendermint現CTOであるEthan Buchman氏の執筆論文をもとにTendermintについて見ていくシリーズです。冒頭に筆者による「簡単まとめ」を入れ、その後にもととなった部分の日本語訳を載せるという順番で書いていきます。
論文「Tendermint： Byzantine Fault Tolerance in Age of Blockchain」の原文はこちら。
今回の対象範囲は第6章「Governance」のうち序文、6.1「Governmint」、6.2「Validator set Change」で、これを読むと、Tendermintの「Governmint」とバリデータ集合の変更方法についてやや詳しい内容が分かります。
スポンサードサーチ
要点をまとめてみる
- Tendermintのガバナンスアプリケーションを「Governmint」という。
- グループ内で投票したり、バリデータ集合を変更したり、Governmintアプリケーションの更新を行ったりすることができる。
- Governmintの投票メカニズムとして、QVには大いに関心を抱いている。
- バリデータ集合の変更に関して、TendermintがRaftと似通ったアプローチをとる。
- EndBlockメッセージを利用したTMSPインタフェースを通じて変更のやりとりを行う。このやりとりは、AppendTxメッセージ終了後からCommit前の間に実行される。
- アプリケーションは、バリデータの公開鍵並びにEndBlockメッセージに対する新たな投票パワーを明確化することで、更新するバリデータの一覧を返す。バリデータの投票パワーを0にセットすればバリデータを除外できる。
- ブロック高Hで行われた更新はブロック高H + 1で反映されるが、ブロック高H + 1のLastCommitはブロック高Hの署名を含むことからブロック高Hのバリデータの集合も必要である。
- 除外したバリデータが次の提案者だったという事態を防ぐため、ラウンドロビン方式を利用する。
以下、今回取り扱った箇所の日本語訳なので詳細を知りたければどうぞ。
Chapter6. Governance
これまでのところ、本論文ではTendermintコンセンサスプロトコルとアプリケーション環境の基本的な要素について見てきた。バリデータ集合の変更や危機状況下からの復旧等の現実世界におけるシステム操作の重要な要素についてはまだ論じていない。
このチャプターではこれらの問題に対し、コンセンサスシステム内のガバナンスの役割を定式化するアプローチを提案する。バリデータの集合はより非中央集権的なエージェントの集合を内包するようになるので、ネットワーク維持のための十分なガバナンスシステムがネットワークの成功にいっそう重要である。
6.1 Governmint
ガバナンスの基本的な機能は、典型的には投票の形式でアクションに関する提案をフィルタリングすることである。ソフトウェアとしてのガバナンスの最も基礎的な実装は、ユーザが提案し、投票し、票数を集計できるモジュールである。提案がプログラミングされたものであれば正常な投票に従って自動的に実行されるだろうし、プログラミングされたものでなければ手動で実行することになる。
バリデータ集合の変更やソフトウェアのアップグレードなど、Tendermintにおいて一定のアクションができるようにするために、Governmintと呼ばれるガバナンスモジュールが実装された。Governmintはエンティティからなる複数グループのサポートを兼ね備えた実用最小限のガバナンスアプリケーションで、各グループは内部的に提案に投票でき、一部のグループはバリデータ集合の変更やGovernmint自体の更新（例えば新しい提案の型や投票メカニズムを導入するなど）のようなプログラムによるアクションを実行することになるだろう。
このシステムでは投票者の認証にデジタル署名を利用しており、また様々な投票をスキームを用いる可能性がある。とりわけ関心を持っているのはクアドラティック投票（筆者注：QV, quadratic vote, Steven LalleyとGlen Weyl氏が提唱した投票の概念で、単に賛否を表明するのではなく、どれだけ強く賛成か反対かを重みを付けて表明できるようにすることでマジョリティの独裁を回避する意思決定手法）で、ここでは投票にかかるコストは投票の重みの二乗なので、投票者の選好を満たすのに優れた能力を持っている。
6.2 バリデータ集合の変更
バリデータ集合の変更は現実世界のコンセンサスアルゴリズムの非常に重要な構成要素で、過去の多くのアプローチは仕様化の失敗に終わったか、あるいは黒魔術的なものとして取り残された。Raftはバリデータ集合の変更に関する妥当なプロトコルを詳細に説明するのに苦労し、変更をコンセンサスを介してやり取りする必要があって、新しいメッセージタイプを使うことになった。Tendermintも同様のアプローチを用いる。ただし、Tendermintの場合はEndBlockメッセージを使うTMSPインタフェースを通じて標準化されており、これは全てのAppendTxメッセージが終了した後かつCommitの前に実行される。トランザクションまたはトランザクションの集合がバリデータ集合の更新を意図した効果とともにブロックに含まれると、アプリケーションは更新するバリデータの公開鍵並びにEndBlockメッセージの応答としての新たな投票パワーを明確化することで、更新するバリデータの一覧を返すことができる。バリデータの投票パワーをゼロに設定することでそのバリデータを除外することができる。これにより、トランザクションタイプを条件として規定することなくアプリケーションがバリデータの集合を更新するジェネリックな方法を提供できる。
ブロック高Hでブロックが更新済みのバリデータ集合を返すならば、ブロック高H + 1のブロックはその更新が反映される。しかし、ブロックH + 1のLastCommitは更新で取り除かれたバリデータからの署名を含んでいる可能性があることから、ブロック高Hのバリデータの集合を利用しなければならない点には注意しておきたい。
投票パワーの変更はH + 1から適用されるので、次の提案者はその更新の影響を受ける。特に、ややもすると次の提案者になったかもしれないバリデータが除外されてしまう可能性がある。ラウンドロビンアルゴリズムはこの問題にうまく対処する可能性があり、単純に並び順の次の提案者に移る。同じブロックは少なくともバリデータの2/3でレプリケートされ、ラウンドロビンは決定論的であるので、バリデータは全員が同じ更新を行って同一の次なるブロック提案者を期待するだろう。
（EthanのTendermint論文11 ←← 前）｜（次 →→ EthanのTendermint論文13）
免責
邦訳には誤りがある場合がございます。予めご承知おき下さい。
確実な情報を知るためには冒頭に示した原文をご参照くださいますようお願いいたします。