[論文レビュー] FireLedger: A High Throughput Blockchain Consensus Protocol
FireLedger は、正しく動作するプロポーザーを楽観的に仮定することで通信オーバーヘッドを低減する高スループットブロックチェーンコンセンサスプロトコルであり、1回の通信ラウンドで1ブロックの決定が可能で、最小限のメッセージ送信で実現される:プロポーザーは自身の提案のみを送信し、他のノードはそれぞれ1ビットずつ送信する。10ノードの単一データセンター環境において、512バイトのトランザクションに対して最大16万 tps を達成し、HotStuff や BFT-SMaRt よりも構成に応じて20%~600%の性能向上を実現する。
Blockchains are distributed secure ledgers to which transactions are issued continuously and each block of transactions is tightly coupled to its predecessors. Permissioned blockchains place special emphasis on transactions throughput. In this paper we present FireLedger, which leverages the iterative nature of blockchains in order to improve their throughput in optimistic execution scenarios. FireLedger trades latency for throughput in the sense that in FireLedger the last f + 1 blocks of each node's blockchain are considered tentative, i.e., they may be rescinded in case one of the last f + 1 blocks proposers was Byzantine. Yet, when optimistic assumptions are met, a new block is decided in each communication step, which consists of a proposer that sends only its proposal and all other participants are sending a single bit each. Our performance study demonstrates that in a single Amazon data-center, FireLedger running on 10 mid-range Amazon nodes obtains a throughput of up to 160K transactions per second for (typical Bitcoin size) 512 bytes transactions. In a 10 nodes Amazon geo-distributed setting with 512 bytes transactions, FireLedger obtains a throughput of 30K tps. Moreover, on higher end Amazon machines, FireLedger obtains $20%-600%$ better throughput than state of the art protocols like HotStuff and BFT-SMaRt, depending on the exact configuration.
研究の動機と目的
- Byzantine 故障がまれな許可型環境において、ブロックチェーンの反復的性質を活用することで、ブロックチェーンのスループットを向上させること。
- 通常動作時の通信オーバーヘッドを低減するため、楽観的実行条件を仮定することで、コンセンサスプロトコルの通信量を最小限に抑えること。
- 高い性能を標準的で専用化されていないインフラ上で、強力な最終性を維持するプロトコルを設計すること。
- 実際の展開環境下で、HotStuff や BFT-SMaRt などの最先端コンセンサスプロトコルを上回るスループットと効率性を実現すること。
提案手法
- FireLedger は最後の f+1 ブロックを一時的(tentative)に保持することで、このウィンドウ内のプロポーザーの1つが Byzantine であっても回復可能であり、f+1 ラウンド後に最終性が保証される。
- 各ラウンドで1つの新しいブロックを決定するラウンドベースのコンセンサスモデルを採用し、プロポーザーは自身の提案のみを送信し、他のノードは合意を示すために1ビットずつ送信する。
- 暗号的認証を活用し、2段階の通信プロトコルを採用:まずブロックヘッダを広報し、次に障害回復が必要になった場合にのみ、取引データを送信する。
- 1ブロックあたりの取引をバッチ処理し、ブロックヘッダと取引データを分離することで、スケーラビリティの向上と帯域幅の圧迫を軽減する。
- 障害のあるプロポーザーが検出された場合にのみ回復メカニズムが発動するため、通常動作時におけるオーバーヘッドを最小限に抑える。
- バッチサイズ(β)、ワーカー数(ω)、ブロックサイズ(σ)などの構成パラメータを活用し、CPU効率の良い設計でパフォーマンスを最適化する。
実験結果
リサーチクエスチョン
- RQ1プロポーザーが正常であるという楽観的条件を仮定することで、ブロックチェーンコンセンサスプロトコルが著しく高いスループットを達成できるか。
- RQ2最終性やセキュリティを損なわずに、Byzantine 故障耐性コンセンサスにおける通信オーバーヘッドをどの程度まで低減できるか。
- RQ3楽観的コンセンサスプロトコルのパフォーマンスは、単一データセンターから広域ネットワークを含むグローバル分散環境まで、さまざまなネットワークトポロジでどのようにスケーリングするか。
- RQ4同じハードウェア環境と故障耐性要件下で、FireLedger は HotStuff や BFT-SMaRt といった先端プロトコルと比較して、スループットとレイテンシの点でどの程度優れているか。
主な発見
- 10台の中程度の性能を持つノードが1つの Amazon データセンターに配置された環境で、FireLedger は 512 バイトのトランザクションに対してピークで 16万 件/秒(tps)のスループットを達成した。
- 10ノードのグローバル分散環境でも、FireLedger は 3万 tps を達成し、広域ネットワークを介しても高いパフォーマンスを発揮した。
- さまざまな構成やクラスターサイズにおいて、FireLedger は HotStuff より 20%~300%、BFT-SMaRt より 40%~600% のスループットで優位性を示した。
- クラスターサイズの増加に伴い、f+1 の最終性のためレイテンシが上昇するが、n ≤ 30 ノードの範囲では Libra の10秒の最終性目標を達成する競争力のある性能を維持した。
- バッチサイズ(β)とノード数(n)の増加に伴い、CPU 利用率の向上とバッチ処理の恩恵により、特に大規模クラスタでスループットが向上した。
- 大容量のトランザクションでは、データ配布が通信オーバーヘッドの主要因となり、プロトコルレベルの利点が相対的に減少するため、FireLedger と HotStuff の性能差は縮小する。
より良い研究を、今すぐ始めましょう
論文の読解から最終レビューまで、研究時間を劇的に削減しましょう。
クレジットカード登録不要
このレビューはAIが作成し、人間の編集者が確認しました。