Tendermint
- 1. ~ scalable blockchain consensus engine ~ @keita0q
- 2. ? 中村奎太 ? twitter @keita0q ? メルペイ / 分散台帳開発部
- 5. Solutions Layer2 SideChains Plasma, Cosmos State Channels Raiden, Lightning Layer1 Sharding Ethereum Sharding, Ziliqa Consensusによる解決 Casper, Tendermint, …
- 6. solutions for scalability problem Layer2 SideChains Plasma, Cosmos State Channels Raiden, Lightning Layer1 Sharding Ethereum Sharding, Ziliqa Consensusによる解決 Casper, Tendermint, … とにかくメインチェーンで やること減らそう！ Tx処理スピードをあげよう！
- 7. Tendermint
- 8. Tendermint ブロックチェーンにおけるコンセンサスアルゴリズムとP2Pネットワーク を容易かつセキュアに構築することができるソフトウェア P2P Network PoS Consensus application layer ABCI Tendermint
- 11. P2P Network PoS Consensus application layer ABCI ABCI あらゆる言語でBFT対応した分散処理アプリケーションを 簡単に開発するためのインターフェース アプリケーションレイヤーではコンセンサスについて考慮する必要がない
- 12. ABCI アプリケーション ロジック コンセンサス エンジン ABCI 三種類のメッセージをABCI(インターフェース)を通して送り合うことで構成されている ? DeliverTx メッセージ : トランザクションの送信、検証、状態更新依頼 ? CheckTx メッセージ : 検証依頼メッセージ 検証対象のTxを含む ? Commit メッセージ : 新たなブロックがコミットされたタイミングでアプリケーショ ンに対して状態更新、次へのブロックヘッダのハッシュ値を要求する トランザクション検証 ステート更新 バリデータに 正しいブロックが複製され ていることを保証
- 14. blockchain protocol ３つの主要コネクションで構成されている mempool connection consensus connection query connection
- 15. blockchain protocol ３つの主要コネクションで構成されている mempool connection consensus connection query connection
- 17. blockchain protocol ３つの主要コネクションで構成されている mempool connection consensus connection query connection
- 19. blockchain protocol ３つの主要コネクションで構成されている mempool connection consensus connection query connection
- 20. query connection アプリケーション ロジック ABCI Query 常にアプリケーションに対して照会できるコネクション tendermint coreからRPCでいつでも可能 tendermint core RPC 例 : 接続ピアなどの検索
- 23. BFT-based PoS P2P Network PoS Consensus application layer ABCI BFTな決定論的であり、部分的非同期であるコンセンサスプロトコル
- 24. Consensus flow 前提事項 プロトコル参加者をバリデータと呼ぶ バリデータは交代しながらブロックを提案 提案しないバリデータは投票者となる 2回の投票が行われ、2回とも2/3以上のバリデータによって認 められればコミットされる 1回目の投票を pre-vote という 2回目の投票を pre-commit という
- 25. Consensus flow
- 27. Pre-vote Step 提案されたブロックに対して一回目の投 票を行う(投票 = 署名) 2/3以上のバリデータによる投票が集まる までPre-voteステップは一定時間続く 2/3以上の投票が集まれば即座に次のステ ップへ遷移する 1/3のクラッシュやビザンチンな振る舞いに対 処可能 タイムアウトがあることで完全な非同期ではなく弱い非同期(部分的非同期)として動作する BFTである
- 29. Tendermint vs X 分散ストレージ ブロックチェーン zookeeper, etcd, consulなどの 非BFTコンセンサス上に形成される分散KVS Bitcoin, Ethereumなどのパブリックな ブロックチェーンにおけるコンセンサス HyperLedger Fabricのような permitted なブ ロックチェーンのコンセンサス
- 30. Tendermint vs 分散ストレージ 分散ストレージ zookeeper, etcd, consulなどの 非BFTコンセンサス上に形成される分散KVS Raftコンセンサスなど非常に簡単なアルゴリズムを使用している 1/2までのクラッシュを許容できるが、１つでもビザンチンな振る舞い をされるとシステム全体を破壊する可能性を持つ BFTではないことが最大の違い
- 31. Tendermint vs Public Blockchain Bitcoin、Ethereumは同期的に動くコンセンサスモデル ブロック生成時間という固定された時間毎にコンセンサスを取るという同期性(この中で伝 播、検証、ナンスの発見を行う) Tendermintは部分的非同期 最低限のタイムアウトはあるもののバリデータの2/3以上が投票すればコンセンサスが取ら れるという意味で固定されていない 同期的なコンセンサスアルゴリズムではチェーンのフォークがおきつづ ける 固定値が存在するせいで同時に複数のコンセンサスが取られてしまう ブロックチェーン Bitcoin, Ethereumなどのパブリックな ブロックチェーンにおけるコンセンサス
- 32. Tendermint vs Permitted Blockchain 参加するバリデータに制限をかけるのも１つのBFTを達成する方法 制限をかけるとするとそのアプリケーションへの参加者は、バリデータ を暗黙的に信用する必要が生まれる。 BFTでスケールするアルゴリズムとしてPBFTが挙げられるが、 permitted なコンセンサスであることは大きな違い ブロックチェーン HyperLedger Fabricのような permitted なブ ロックチェーンのコンセンサス
- 33. The Problem of Tendermint ? 決定論的なPoSのためブロック提案者、投票者は常に計算 で導くことが可能であり、攻撃の対象となる。 ? 提案者へのDDoSによってチェーン全体を止めることがで きる Sentry Node Architectureで対応予定 Sentry Node Architecture : ノードのIPアドレスを非公開に ? Nothing at Stake 問題(PoS共通) 投票にデポジットした資金の引き出しに一定時間かかることで対処
- 34. Conclusion ? Layer1でのコンセンサスアルゴリズムによるスケーリング解決としてのTendermint を紹介 ? PoSだから処理速度が早い ? ABCIについて ? コンセンサスアルゴリズムとのインターフェースとなっていることで様々な言語 で独自のブロックチェーンアプリケーションを実装可能 ? Ethermint や cosmosなどが実装例 ? Tendermint Consensus について ? 決定論的に投票者を選出し、部分的非同期にコンセンサスを取る事により、 フォークのない即座にファイナリティを得られるようなビザンチン耐性のある アルゴリズムである. ? PoSの持つ潜在的な問題にたいしては現在も研究が進められている
Editor's Notes
- #5: ブロックの中に含めることのできるTxの制限やブロック生成の時間的な制約などから、ネットワークの参加者が増え、トランザクション数が増えるほどさばくことのできないトランザクションの量は増えてしまう。 ブロックチェーンはさばけるトランザクションの数を増やすためにスケール問題を解決しなければいけない
- #10: BFT ベースのPoSによるコンセンサスを行うことで1秒間数千のトランザクションさばくことができる POSという言葉は書く ブロック生成後即座にファイナリティが得られる これはビットコインの6個のブロック生成を待ってから得られるのと比較できる そして同期的な振る舞いをするbitcoinなどのコンセンサスアルゴリズムとは違い、部分的に同期的な振る舞いを行うよう設計されているため1/3以下の検証ノードに異常がある場合でも機能させることができ、合意を形成できる。 このため意見が別れることはなく常にファイナリィが得られる。 また同時にコミットされるブロックがないアルゴリズム設計のためフォークが起きない これから説明するABCIによって簡単にセキュアで高パフォーマンスな独自ブロックチェーンを構築することが可能です。
- #13: 幾つかのプロトコルで構成されています message protocol blockchain protocol
- #19: DeliverTxは非同期に動きますが順序は担保されるらしい - BeginBlockリクエスト ブロック更新前に現在の最新ブロックの状態や情報を元に初期化するためのリクエスト これによってTendermintの最新状態からいつでもApplicationをリスタートすることができる EndBlock リクエスト ブロックコミットが行われたあとの事後処理を要求する。 (このタイミングでバリデータの更新をおこなうこともできる)
- #25: ブロックコミットのフロー ステーク量に応じて選出されたバリデータは新しいブロックの提案を行う ブロックが正しいと検証できた場合、提案を行う 提案を行う際に提案するバリデータ自身のプライベートキーを用いて署名し、何らかの障害が起きたときに署名したバリデータが責任をおう 選出されなかったバリデータは提案にたいして投票を行い、自分の秘密鍵で署名
- #26: ブロックコミットのフロー ステーク量に応じて選出されたバリデータは新しいブロックの提案を行う ブロックが正しいと検証できた場合、提案を行う 提案を行う際に提案するバリデータ自身のプライベートキーを用いて署名し、何らかの障害が起きたときに署名したバリデータが責任をおう 選出されなかったバリデータは提案にたいして投票を行い、自分の秘密鍵で署名
- #27: ラウンドロビンのローテーションは决定论的に証明可能
- #28: 1/3までビザンチンを許容する理由 ビザンチン耐性がある
- #29: フォークしない理由
- #33: コンソーシアムやプライベート