本稿について
本稿は、Tendermintホワイトペーパーの詳細版ともいえるTendermint現CTOであるEthan Buchman氏の執筆論文をもとにTendermintについて見ていくシリーズです。冒頭に筆者による「簡単まとめ」を入れ、その後にもととなった部分の日本語訳を載せるという順番で書いていきます。
論文「Tendermint： Byzantine Fault Tolerance in Age of Blockchain」の原文はこちら。
今回の対象範囲は第3章「Tendemint Consensus」のうち3.6「Faults and Availability」と3.7「Conclusion」で、これを読むとTendermintの故障や可用性に対する考え方についてやや詳しい内容が分かります。
原文はこちらになります。
スポンサードサーチ
要点をまとめてみる
- TendermintはBFTコンセンサスアルゴリズムで、ビザンチンなバリデータが1/3未満であればセーフティやライブネスを維持できる。
- 非同期の場合でも事前投票と事前コミットフェーズに関して最適化が可能である。
- 最適化のためにローカルクロックに基づくタイムアウトを利用する。
- 1/3以上のバリデータがクラッシュした場合はネットワークは停止するが、ログ先行書き込みにより後から復帰したバリデータが偶然ルール違反を犯してしまうような心配はない。
- 1/3以上のバリデータがビザンチンである場合はセーフティを侵害されてしまうが、違反の証拠は明確かつ識別できる形で残る。
以下、今回取り扱った箇所の日本語訳なので詳細を知りたければどうぞ。
Chapter3. Tendermintコンセンサス（続き）
3.6 障害と可用性
BFTコンセンサスアルゴリズムとして、Tendermintは1/3未満のバリデータのビザンチン故障に対して耐性がある。これは、セーフティやライブネスを侵害することなく（ライブネスについて通常のFLPの注意で）ノードがクラッシュしたり、他のピアへ別の矛盾するメッセージを送信したり、メッセージのリレーを拒否したり、好き勝手にふるまったりする可能性があるということである。
プロトコルには、ローカルクロックに基づくタイムアウトを利用することで非同期性に関して最適化しうる箇所が2つある。単一のブロックや空に対するものを除く2/3以上の事前投票を受信した場合と、単一のブロックや空に対するものを除く2/3以上の事前コミットを受信した場合である。どちらのケースでも、一定時間スリープして低速だったり遅延していたりする投票が受け取ってもらえるチャンスを与えることができるので、ブロックのコミットなく次のラウンドに進んでしまう可能性を低減する。クロックはバリデータが2/3以上からの投票を観測するたびにリセットされるので、バリデータ間で同期している必要はない。
1/3以上のバリデータがクラッシュした場合、どのバリデータもバリデータの集合の2/3より多くからの連絡なく進むことができないので、ネットワークは停止する。ネットワークは読み取り用に利用できるが状態ではあるが、新しいコミットを行うことはできない。バリデータがオンライン状態に復帰すると、オフラインになったラウンドから続けることができる。コンセンサスステートマシンはログ先行書き込みを採用しているので、復帰したバリデータはクラッシュした時点のステップに速やかに戻り、たまたまルール違反を犯してしまうといったことは確実にない。
1/3以上のバリデータがビザンチンであるならば、様々な方法でセーフティを侵害できる。例えば、同一ラウンドで2ブロックを提案したり、コミットまでずっと両方のブロックに投票したり、ロックルールを破ることで同一ブロック高の異なるラウンドの2つのブロックに事前コミットしたりなどである。いずれの場合においても、一定のバリデータが不正なふるまいを行ったという明確で識別可能な証拠がある。最初の例であれば、同一ラウンドで2つの提案に署名しており、それは明確なルール違反である。2つめの例であれば、ラウンドR - 1にロックされているのにラウンドRの別のブロックに事前投票していたかもしれず、これはPrevote-the-Lockルールに違反している。
コンセンサス形成にインセンティブを与えて管理するために経済的な構成要素とガバナンスの構成要素を利用する場合、このような追加のアカウンタビリティ保証は非常に重要になる。
3.7 結論
Tendermintは弱い同期性を持ち、ビザンチンフォールトトレランス性があり、ステートマシンレプリケーションプロトコルで、BFTの前提に違反があった場合は最適なビザンチンフォールトトレランス性と追加的なアカウンタビリティ保証を有する。プロトコルは提案者に関してラウンドロビン方式を用いるとともに、ブロックのコミットに関しても同様の方法で提案者をスキップする。セーフティはシンプルなロックメカニズムを利用してラウンドを通してずっと維持される。
このチャプターにおけるプロトコルの表現は多くの重要な情報を書ききれていない。例えば、効率的なブロックのゴシッピングや、トランザクションのバッファ、バリデータの集合に対する変更、アプリケーションロジックのインタフェースなどは書かれていない。これらの重要なトピックは後のチャプターで取り上げる。
（EthanのTendermint論文7 ←← 前）｜（次 →→ EthanのTendermint論文9）
免責
邦訳には誤りがある場合がございます。予めご承知おき下さい。
確実な情報を知るためには冒頭に示した原文をご参照くださいますようお願いいたします。