次世代のコンセンサスエンジン"Tendermint"の話をしました @blockchain.tokyo #8

こんにちは！メルペイの中村(@keita0q)です。
5月24日に開催されたblockchain.tokyo #8 にて次世代のコンセンサスエンジンとして期待されているTendermintについて登壇したので、その時の内容をまとめます。

blockchain-tokyo.connpass.com

発表内容

www.slideshare.net
上記が発表資料です。
スケーリング問題や、分散システムのコンセンサスにおける問題の解決策として提案されたTedndermintについて詳しく見ていきましょう。

スケーラビリティ問題

まずはブロックチェーンにおけるスケーラビリティ問題についておさらいしておきましょう。
BitcoinやEthereumなどの主要ブロックチェーンでは、参加者の増加に伴いトランザクションの数が増え続けることで検証や合意形成に時間がかかるなどの問題が発生しています。これがスケーラビリティ問題と呼ばれ、ブロックに含めることのできるトランザクション数の制限や、ブロック生成時間の制限などが理由として上げられます。今後パブリックなブロックチェーンが実用化されるためにはこの問題を解決することが必須となるでしょう。この問題の解決策として以下のものが挙げられます。

• Layer2
  • SideChain
    Plasmaなど
  • StateChannels
    Raiden, LightningNet など
• Layer1
  • Sharding
    Ethereum Sharding, Ziliqa など
  • Consensus
    Casper, Tendermint など

スケーラビリティ問題の解決策としてはルートチェーンの外でなるべく処理を行うLayer2の解決策と、ルートチェーン自体の処理速度を上げるLayer1での解決策に分けられます。Layer2 ではルートチェーンで行うトランザクションへの処理をサイドチェーンや外のステートマシンに任せることでスピードアップしようというもので昨今盛り上がりを見せているPlasmaなどがこれの一つです。
Layer1での解決策はこれとは異なり、ルートとなるブロックチェーン自体の処理速度を上げようというもので、シャーディングとコンセンサス(合意形成)自体のスピードアップによる解決などが挙げられます。今回紹介するTendermintはコンセンサスによるスケーラビリティ解決策の一つとして期待されています。

Tendermitとは？？

それでは本題のTendermintについて説明していきます。
TendermitはブロックチェーンにおけるコンセンサスアルゴリズムとP2Pネットワークをパケージングしたソフトウェアです。
これを使うことで容易かつ安全にブロックチェーンネットワークを構築することが可能です。主な構成要素としてはTendermint Coreと呼ばれる Tendermint コンセンサスエンジンとABCI(Application BlockChain Intereface)の２つです。それぞれの動き方を確認する前にTendermintの特徴を紹介します。

• PoSのコンセンサスのためトランザクションの処理速度が早い(数千TPSの処理速度)
• ブロック生成後すぐにファイナリティを得られる。
  ビットコインは6ブロック生成後までファイナリティを得られない
• フォークしない
• 1/3までのバリデーションノードが停止またはビザンチンな振る舞いをしても問題ない。ビザンチン将軍問題の一つの解となるアルゴリズムである。
• コンポーネント化された設計とABCIによって独自のアプリケーションレイヤーを持つブロックチェーンを容易に実装可能

このような特徴がどのように実現されているのか見ていきます。

ABCIについて

特徴として最後に述べた、独自ブロックチェーンを容易に構築するための仕組みであるABCIについて詳細に説明します。
ABCIとはコンセンサスエンジンとアプリケーションレイヤーのロジック間でメッセージングを行うことで動作します。
主要メッセージはスライドに示す三種類です。

2つのプロトコルが存在します。

メッセージプロトコル

スライドに示すように、ABCIでは必ずコンセンサスエンジンからアプリケーションロジックに対してリクエストを行い、そのレスポンスを返すようにルール付されています。つまり、コンセンサスエンジンがクライアントとなるのです。

ブロックチェーンプロトコル

３つの主要コネクションで構成されています。

• mempool コネクション

CheckTxメッセージを使い検証を依頼し、検証に成功したトランザクションをプール、成功しなかったものは捨てられます。

• consensus コネクション

コミットされたタイミングで、コンセンサスの取れた最新ブロックによるアプリケーションロジックの状態更新と次のブロック生成への準備を行うコネクションです。DeliverTxで含まれるトランザクションによる状態更新を要求し、Commitメッセージで状態更新後のステートルートを要求します。
BeginBlockリクエストはブロック更新前に現在の最新ブロックの状態や情報を元に初期化するためのリクエストです。これによってTendermintの最新状態からいつでもアプリケーションをリスタートできます。EndBlockリクエストはブロックコミットが行われたあとの事後処理を要求します。バリデータセットの更新などもこのタイミングで行われます。

• query コネクション

接続先のピア情報や、アプリケーションの設定など常にアプリケーションに対して紹介できるコネクション。Tendermint CoreからRPCでリクエストできます。

ABCI 実装例

ABCIを実際に用いた例として以下の２つが挙げられます。

• Ethermint
  コンセンサスをTendermintに任せてアプリケーション層にEVMを実装。
  web3や、solidityなどと言ったEthereumの周辺要素との互換性があります。

• Cosmos
  アルゴリズムの異なるブロックチェーン間でのトークン移動を可能にするプロジェクト。
  Tendermintをコンセンサスとして用い、それぞれのブロックチェーンに即した形でABCI
  を実装することでクロスチェーンテクノロジーを提供します。

Tendermint Consensus について

以下の前提を頭に入れてコンセンサスアルゴリズムのフローを見ていきましょう。

• プロトコル参加者をバリデータと呼ぶ
• バリデータは交代しながらブロックを提案
• 提案しないバリデータは投票者となる
• 2回の投票が行われ、2回とも2/3以上のバリデータによって認められればコミットされる
• 1回目の投票を pre-vote という
• 2回目の投票を pre-commit という

大きく分けて３つのフローに分けることができます。

1. Propose :
   ステーク量に応じて選出されたバリデータセットによってブロックの提案、投票が行われます。異なるバリデータによって交代交代で提案が行われるようにラウンドロビン方式で提案者が選ばれます。このラウンドロビン方式の選出は関数として実装されており、誰が提案者となるのかは決定論的に証明可能です。

2. Pre-Vote :
   提案されたブロックに対する一回目の投票ステップです。ここで言う投票とは実際にはブロードキャストで送られてきたブロックに対しての署名です。このステップでは2/3以上のバリデータからの投票が集まるまで待ち状態となります。2/3以上の投票が集まれば即座に次のステップに移行しますが、集まるまでは制限時間まで待ち続けます。この制限時間を設けていることが完全な非同期アルゴリズムではなく、弱い非同期(部分的非同期)となる理由です。また、この投票アルゴリズムにおいては1/3のクラッシュまたはビザンチンな振る舞いに対して対処可能です。

3. Pre-Commit :
   一回目の投票で2/3以上の投票が集まったブロックに対する二回目の投票ステップです。ここでさらに2/3以上のバリデータにより投票されればめでたくブロックチェーンに新規コミットされ、ABCIのConsensusコネクションが発生するわけです。
   二度目の投票で注目しなければいけないのが2/3以上の投票が集まらなかった場合です。この場合、2度目の投票であるpre-commitを対象ブロックに対して行ったバリデータはロックされます。バリデータはロックされたブロック、もしくは2/3以上の投票をpre-vote(1回目の投票)で得た新規のブロック以外には投票できなくなるのです。これによって各バリデータがpre-commitステップで投票できる対象ブロックは常に1つになります。この性質があるためブロックチェーンに対して新規コミットされるブロックは常にひとつ、つまりフォークしないのです。

それぞれのステップを見ることでTendermintはBFTな決定論的部分非同期コンセンサスプロトコルであることがわかります。

Tendermint vs X

Tendermintと他の分散システムとの比較をまとめました。

vs 分散ストレージ

zookeeper, etcd, consulなどの非BFTコンセンサスのKVSとの違い

• 分散ストレージにはRaftコンセンサスなど非常に実装しやすいアルゴリズムが使われています。
• 分散ストレージでは1/2までクラッシュは回避することができます。しかし、1つでもビザンチンな振る舞いをされるとシステム全体が破壊される可能性を持っており、ビザンチンな振る舞いは起きないと仮定できるときのみ使用できます。

vs Public Blockchain

Bitcoin, Ethereumなどパブリックなブロックチェーンにおけるコンセンサスとの違い

• Bitcoin, Ethereumではそれぞれのノードの動きは独立しており、非同期に動作しますが、コンセンサスは同期的に動きます。これはブロック生成時間がネットワーク全体を通して共通であり、この固定された時間ごとにコンセンサスが取られるという性質があるからです。
• これに対し、Tendermintはコンセンサスの説明でもわかる通り部分的非同期に動きます。
• 同期的なコンセンサスプロトコルでは同時にコミットが発生してしまう可能性があり、フォークは起きざるを得ません。

vs Permitted Blockchain

HyperLedger Fabric のような permittedなブロックチェーンにおけるコンセンサスとの違い

• 参加するバリデータに制限をかけることでBFTなコンセンサスを取ることができます。
• 制限をかける場合、そのプリケーションへの参加者は暗黙的に参加しているバリデータを信頼する必要が生まれます。
• 制限のかかったバリデータによるコンセンサスアルゴリズムとしてPBFTが挙げられ、スケール可能であるとも言われています。

Tendermint の課題

• 決定論的なPoSであるため、提案者や投票者を計算で把握することができます。これにより提案者、投票者に対してDDoSを仕掛けチェーン全体をストップさせることができてしまいます。
  → Tendermintでは Sentry Node Architecture と呼ばれるノードのIPアドレスを非公開にする仕組みを実装することでこれを防ごうとしています。(WIP)
• PoSのコンセンサスに共通して挙げられる問題として Nothing at Stake 問題もTendermintの課題の一つです。
  → これには現状、投票するのにトークンをデポジットしなければいけないといった形で防いでおり、引き出しに一定時間かかることなども一つの対策として挙げられます。
  

最後に

今回、次世代のスケール可能で安全なコンセンサスエンジンとして期待されるTendermintをご紹介しました。
Tendermintを使ったパブリックチェーンであるCosmosもまもなく公開予定で世界的な広がりも期待されています。
PoSならではの課題があるものの、アカデミアの世界でも認められ、実用的なアルゴリズムであるTendermint コンセンサスから今後も目が離せません！！

今後もブロックチェーンに関する情報発信を行っていく予定ですのでお楽しみに！！