本稿について
本稿は、Tendermintホワイトペーパーの詳細版ともいえるTendermint現CTOであるEthan Buchman氏の執筆論文をもとにTendermintについて見ていくシリーズです。冒頭に筆者による「簡単まとめ」を入れ、その後にもととなった部分の日本語訳を載せるという順番で書いていきます。
論文「Tendermint： Byzantine Fault Tolerance in Age of Blockchain」の原文はこちら。
今回の対象範囲は第3章「Tendemint Consensus」のうち、3.2「Consensus」の3.2.1「Proposals」と3.2.2「Votes」で、これを読むとTendermintのコンセンサスの3つの構成要素のうち「提案」と「投票」についてやや詳しい内容が分かります。
原文はこちらになります。
スポンサードサーチ
要点をまとめてみる
- 提案者が提案するのは、厳密に言うとブロックを含む提案者の秘密鍵による署名付きProposalMsgである。
- ラウンドの有効な提案者は一人だけであり、全てのバリデータに正しい提案者が分かる。
- ラウンドロビン方式で順序付けられているため。
- 事前投票（pre-vote）は言うなればネットワークが次にとる行動の準備、事前コミット（pre-commit）はネットワークが次にとる行動の決定である。
- 2/3より多くの事前投票がブロックに対してある場合、ポルカができる。
- 2/3より多くの事前投票が空（nil）に対してある場合、空ポルカができる。
- ポルカは次に行う事前コミットに正当性を与えるものである。ポルカがない場合、空に事前コミットすることになる。
- ポルカがないのにブロックに対して事前コミットするのは、悪意ある行動とみなされる。
- 2/3より多くの事前コミットがブロックに対してある場合、ブロックはコミットされ、次のブロック高のラウンド0へと進む。
- 2/3より多くの事前コミットが空（nil）に対してある場合、ブロックはコミットされず、そのブロック高の次のラウンドへと進む。
- 事前投票⇒事前コミットと2段階の投票システムになっているのは、ビザンチンフォールトトレランス性を持たせる対応策の一環である。
以下、今回取り扱った箇所の日本語訳なので詳細を知りたければどうぞ。
Chapter3. Tendermintコンセンサス（続き）
3.2 コンセンサス（続き）
3.2.1 提案
各ラウンドは提案から始まる。所与のラウンドの提案者は、ローカルキャッシュ（Mempoolという。チャプター4参照）から直近受け取ったトランザクションのまとまりを取ってブロックを構成し、そのブロックを含む署名付きProposalMsgをブロードキャストする。もし提案者がビザンチンであれば、別の提案を別のバリデータにブロードキャストする可能性がある。
提案者はシンプルで決定論的なラウンドロビン方式で順序付けられているので、所与のラウンドで有効な提案者は一人のみであり、全てのバリデータに正しい提案者が分かる。提案がこれより前のラウンドで受け取られるか、不正な提案者からのものである場合、その提案は拒否される。
提案者の循環はビザンチントレランスのために必須である。例えばRaftでは、選出されたリーダーがビザンチンで他ノードとの強力なネットワーク接続を維持している場合、そのリーダーは完全にシステムを侵害してあらゆるセーフティとライブネスの保証を破壊することができる。Tendermintは投票とロックメカニズムでセーフティを守り、提案者の循環によりライブネスを維持するので、提案者がトランザクションを全く処理しなくても別の提案者の誰かがトランザクションをピックアップする。もっと面白いことに、もしかするとバリデータはガバナンスモジュール（チャプター6参照）を通じて投票を行ってビザンチンなバリデータを取り除いたり置き換えたりできるかもしれない。
3.2.2 投票
バリデータは完全な提案を受け取ると、その提案に対する事前投票に署名してネットワークにブロードキャストする。もしバリデータが正しい提案をProposalTimeout以内に受け取らなかった場合、提案の代わりに空（nil）に対する事前投票する。
ビザンチンなバリデータがいる非同期環境では、各バリデータが一票のみ投じる一段階の投票では十分にセーフティを確保できない。本質的に、バリデータは不正にふるまうことができるうえにメッセージの伝送時間に何らの保証もないので、悪質なバリデータは、一部のバリデータがある値にコミットする一方で、そのコミットを確認していない他のバリデータを次ラウンドへ進むよう調整できる。そして、次ラウンドに進んだバリデータらは異なる値にコミットしてしまう。
一段階の投票により、バリデータらは提案について知っていることを互いに伝えることができる。しかし、ビザンチン故障（故障している数、また本質的には、虚偽や詐欺、騙し等）に耐性を持つためには、バリデータらは、他のバリデータが提案に関して知っていると明言したことについて自身が知っていることも互いに伝え合わなければならない。換言すれば、第二段階は十分なバリデータが第一段階の結果を目撃したことを確約するのである。
ゆえに、ブロックに対する事前投票は、ネットワークがブロックをコミットする準備のための投票なのである。空に対する事前投票は、ネットワークが次のラウンドへ進む準備のための投票なのである。オンラインの提案者がいる理想的なラウンドでは、2/3より多くのバリデータが提案に事前投票するだろう。所与のラウンドにおける1つのブロックに対する2/3より多くの事前投票のまとまりをポルカ（polka）1という。空に対する2/3より多くの事前投票のまとまりは空ポルカ（nil-polka）である。
バリデータがポルカを受け取ると（1つのブロックに対する2/3より多くの事前投票を読むと）、ポルカはネットワークがブロックをコミットする準備が整ったというシグナルを受信し、バリデータがそのブロックに対する事前コミット投票に署名してブロードキャストすることの正当性を示すものとしての役割を果たす。時々、ネットワークの非同期性のせいでバリデータはポルカを受け取れなかったり、ポルカがない可能性がある。その場合、バリデータはそのブロックに対する事前コミットに署名することを正当化できないので、空に対する事前コミット投票に署名して公表することになる。つまり、ポルカからの正当性なく事前コミットに署名することは悪意ある行為とみなされる。
事前コミットは実際にブロックをコミットするための投票である。空に対する事前コミットは実際に次ラウンドに進むための投票である。もしバリデータが1つのブロックに対する2/3より多くの事前コミットを受け取ったなら、バリデータはそのブロックをコミットし、その結果のステートを計算し、次のブロック高のラウンド0へ移動する。もしバリデータが空に対する2/3より多くの事前コミットを受け取ったなら、バリデータは次のラウンドへ進む。
（脚注1）
使われる本来の用語はPoL、またはPoLCである。それぞれ、Proof-of-Lockか、Proof-of-Lock-Changeのことを指す。バリデータがpolkaを踊っていると解されることから、この用語はpolkaへと発展した。
（EthanのTendermint論文2 ←← 前）｜（次 →→ EthanのTendermint論文4）
免責
邦訳には誤りがある場合がございます。予めご承知おき下さい。
確実な情報を知るためには冒頭に示した原文をご参照くださいますようお願いいたします。