[論文レビュー] Impact of network delays on Hyperledger Fabric

Thanh Son Lam Nguyen, Guillaume Jourjon+2 more|arXiv (Cornell University)|Mar 21, 2019

Blockchain Technology Applications and Security参考文献 6被引用数 7

ひとこと要約

この論文は、PBFT共識を採用する許可型ブロックチェーンであるHyperledger Fabricにおけるネットワーク遅延の影響を評価している。フランスとドイツの地理的に離れたクラウド環境にシステムを展開し、最大3.5秒までの制御された遅延を導入することで、ブロック伝搬遅延が深刻なレジストリ不整合を引き起こすことを実証した。100番目のブロックでは134秒のオフセットが生じ、銀行取引などの重要なアプリケーションに不適切であることが判明した。これは一貫性の保証が欠如しているためである。

ABSTRACT

Blockchain has become one of the most attractive technologies for applications, with a large range of deployments such as production, economy, or banking. Under the hood, Blockchain technology is a type of distributed database that supports untrusted parties. In this paper we focus Hyperledger Fabric, the first blockchain in the market tailored for a private environment, allowing businesses to create a permissioned network. Hyperledger Fabric implements a PBFT consensus in order to maintain a non forking blockchain at the application level. We deployed this framework over an area network between France and Germany in order to evaluate its performance when potentially large network delays are observed. Overall we found that when network delay increases significantly (i.e. up to 3.5 seconds at network layer between two clouds), we observed that the blocks added to our blockchain had up to 134 seconds offset after 100 th block from one cloud to another. Thus by delaying block propagation, we demonstrated that Hyperledger Fabric does not provide sufficient consistency guaranties to be deployed in critical environments. Our work, is the fist to evidence the negative impact of network delays on a PBFT-based blockchain.

研究の動機と目的

• PBFTベースの許可型ブロックチェーンであるHyperledger Fabricにおけるネットワーク遅延が一貫性およびパフォーマンスに与える影響を調査すること。
• 顕著な伝送遅延を伴う現実的なネットワーク環境下でも、Hyperledger Fabricが強力な一貫性保証を維持できるかを評価すること。
• 特にブロック伝搬および共識調整において、遅延が閾値を超えた際にアーキテクチャ上の障害ポイントが生じるかを同定すること。
• 特に長距離のクラウドリージョン間での展開において、高遅延環境下でのシステムの耐性を評価すること。
• 現在のHyperledger Fabricのバージョンが、低遅延・高一貫性を要する重要なアプリケーション（金融取引やリアルタイム決済システムなど）に適さないという実証的証拠を提供すること。

提案手法

• フランス（ソルボンヌ大学）とドイツ（ハイデルベルク大学）の2つのクラウド環境にHyperledger Fabricを展開し、長距離ネットワーク条件をシミュレートした。
• トラフィックコントロールツール（例：tc）を用いて、ノード間の伝送遅延を最大3.5秒まで制御的に導入した。
• 両地域のピア間でのブロックタイムスタンプの追跡により、ブロック伝搬時間とレジストリ同期オフセットを測定した。
• ネットワーク分析ツール（例：Wireshark）を用いて、遅延が増加する状況下でのシステム挙動を監視し、バッファオーバーフローおよびピアの切断イベントを確認した。
• 最大30,000件のトランザクションに達するトランザクション負荷を段階的に増加させ、高負荷下でのパフォーマンス劣化およびオフセット増大を評価した。
• オーダーとピア間の通信パターンを分析した。特に、ピアが次のブロック受信前に受信確認信号を送信するフィードバックループが、遅延を拡大させることを特定した。

実験結果

リサーチクエスチョン

• RQ1 ネットワーク遅延は、Hyperledger FabricのPBFTベース共識におけるブロック伝搬およびレジストリ同期にどのように影響するか？
• RQ2 Hyperledger Fabricが重大な不整合またはシステム障害を起こさない限界となるネットワーク遅延はどの程度か？
• RQ3 ネットワーク遅延が3.5秒を超えた場合、特にピアの切断および共識停止の観点から、システムの挙動にどのような変化が生じるか？
• RQ4 オーダーのバッファサイズが、高遅延環境下での伝搬遅延の蓄積にどの程度寄与しているか？
• RQ5 現実的なネットワーク遅延を伴う生産環境レベルの長距離展開において、Hyperledger Fabricは強力な一貫性保証を維持できるか？

主な発見

• 3.5秒のネットワーク遅延下で、100番目のブロックはフランスとドイツのピア間で134秒のオフセットを示し、深刻な不整合が生じた。
• 3.5秒の遅延下で、最初のブロックでは128秒のオフセット、100番目のブロックでは134秒のオフセットが生じ、遅延の指数関数的増大が確認された。
• ネットワーク遅延が3.5秒を超えた場合（例：3.58秒）、Dockerスワームによってソルボンヌノードが切断されたと検出され、システム全体が停止した。
• システム障害の原因はフィードバックメカニズムに起因していた。ピアはオーダーに受信確認信号を送信するが、これにより次のブロックの送信が同じ往復時間だけ遅延し、遅延が拡大した。
• 30,000件のトランザクションと3.5秒の遅延下で、オフセットは1時間10分以上にまで増大し、トランザクション量の増加が不整合を悪化させることを示した。
• オーダーのバッファサイズが遅延蓄積の主要因であることが特定された。バッファが満杯になると、オーダーは停止し、結果としてシステム全体が停止した。