tendermintの概要

1. ~ scalable blockchain consensus engine ~
@keita0q

2. • 中村奎太
• twitter @keita0q
• メルペイ / 分散台帳開発部

3. Scalability Problem

4. Scalability Problem
ブロックチェーンを実用化するためには
スケーラビリティ問題を解決する必要がある
transaction
info
Block
Hash
ネットワークへの参加者が増えるほど
トランザクションの検証、合意形成に時間がかかる
transaction
info
Block
Hash
transaction
info
Block
Hash

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

9. Tendermint
PoSのためトランザクション処理速度が早い（数千 TPSの処理速度
）
ブロック生成後すぐにファイナリティを得られる（一度承認された
トランザクションは覆らない）
フォークしない
参考資料
1/3までバリデーションノードは停止していても問題ない。
コンポーネント化された設計とABCIによって独自のアプリケーショ
ンレイヤーを持つブロックチェーンシステムを構築可能
主な利点

10. ABCI
Application BlockChain Interface

11. P2P Network
PoS Consensus
application layer
ABCI
ABCI
あらゆる言語でBFT対応した分散処理アプリケーションを
簡単に開発するためのインターフェース
アプリケーションレイヤーではコンセンサスについて考慮する必要がない

12. ABCI
アプリケーション
ロジック
コンセンサス
エンジン
ABCI
三種類のメッセージをABCI(インターフェース)を通して送り合うことで構成されている
• DeliverTx メッセージ : トランザクションの送信、検証、状態更新依頼
• CheckTx メッセージ : 検証依頼メッセージ 検証対象のTxを含む
• Commit メッセージ : 新たなブロックがコミットされたタイミングでアプリケーショ
ンに対して状態更新、次へのブロックヘッダのハッシュ値を要求する
トランザクション検証
ステート更新
バリデータに
正しいブロックが複製され
ていることを保証

13. message protocol
アプリケーション
ロジック
コンセンサス
エンジン
ABCI
request
response
メッセージはコンセンサスからのリクエスト、アプリケーションからのレスポンスで構成

14. blockchain protocol
３つの主要コネクションで構成されている
mempool connection
consensus connection
query connection

15. blockchain protocol
３つの主要コネクションで構成されている
mempool connection
consensus connection
query connection

16. mempool connection
アプリケーション
ロジック
ABCI
コミット前のトランザクションに対する検証をアプリケーションに依頼し、
検証に成功したTxをプールしておく
コンセンサスエンジン
コンセンサス
ロジック
Mempool
CheckTx
TxResult
検証済みトランザクションを保持
保持したTxがコミットされたらフラッシュする

17. blockchain protocol
３つの主要コネクションで構成されている
mempool connection
consensus connection
query connection

18. consensus connection
アプリケーション
ロジック
ABCI
コンセンサス
エンジン
TxResult
TxResult
…
StateRoot
BeginBlock
DeliverTx
DeliverTx
…
EndBlcok
Commit
合意形成され、新しいブロックがコミットされた際に起きるコネクション
コミットされたブロック情報をもとにトランザクションの検証、また状態遷移を行う
DeliverTxリクエストでTendermintによって合意形成されたTxに
よる状態更新を依頼
DeliverTx処理後にCommitリクエストを行う
DeliverTxリクエストの返り値としてTxResultが返ってく
る
Commit の返り値として状態更新後の state rootを返す(次
のブロックへのヘッダも含む)

19. blockchain protocol
３つの主要コネクションで構成されている
mempool connection
consensus connection
query connection

20. query connection
アプリケーション
ロジック
ABCI
Query
常にアプリケーションに対して照会できるコネクション
tendermint coreからRPCでいつでも可能
tendermint
core
RPC
例 : 接続ピアなどの検索

21. ABCI実装例
TendermintのABCIを用いた実装例
Ethermint
Cosmos
コンセンサスをTendermintに任せてアプリケーション層にEVMを実装している。
web3や、solidityなどと言ったEthereumとの互換性がある
アルゴリズムの異なるブロックチェーン間でのトークン移動を可能にするプロジェクト
Tendermintをコンセンサスとして用いそれぞれのブロックチェーンに即した形でABCI
を実装することでクロスチェーンテクノロジーを提供する

22. Tendermint
Consensus

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

26. Propose Step
ステーク量に応じて選出されたバリデー
タによって新しいブロックについてのコ
ンセンサスをとることになる
Txが一定時間内に溜まっているかつ、正
しいと認められる場合は提案として近隣
のノードにブロードキャストする
前回のラウンドでpre-commitされなかっ
た提案がある場合はそれを提案する
異なるバリデータによって交代交代で提案されるようにラウンドロビン方式で選出する。
決定論的

27. Pre-vote Step
提案されたブロックに対して一回目の投
票を行う(投票 = 署名)
2/3以上のバリデータによる投票が集まる
までPre-voteステップは一定時間続く
2/3以上の投票が集まれば即座に次のステ
ップへ遷移する
1/3のクラッシュやビザンチンな振る舞いに対
処可能
タイムアウトがあることで完全な非同期ではなく弱い非同期(部分的非同期)として動作する
BFTである

28. Pre-commit Step
2/3以上の投票が集まったブロックに対し
て2回目の投票を行う
2/3以上の投票が集まればそのブロックは
コミットされブロックチェーンに繋がれ
る
2/3以上の投票が集まらなかったブロック
は次のラウンドに回される
pre-commitを行うと新たなpre-voteで2/3以上の投票数を得たブロックが提案されるまで
投票することはできない。このことから、各バリデータがpre-commit できるブロックは1つのみ
フォークしない

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の持つ潜在的な問題にたいしては現在も研究が進められている