[論文レビュー] How to Databasify a Blockchain: the Case of Hyperledger Fabric

Ankur Sharma, Felix Schuhknecht+2 more|arXiv (Cornell University)|Oct 31, 2018

Distributed systems and fault tolerance参考文献 12被引用数 9

ひとこと要約

本稿では、トランザクション再順序付けと早期ロールバックというデータベース由来の最適化を統合した、Hyperledger Fabricの拡張版であるFabric++を提案する。トランザクションを再順序付けしてシリアル化競合を低減し、パイプラインの初期段階で無効なトランザクションを早期にロールバックすることで、vanilla Fabricと比較して成功トランザクションのスループットが最大3倍に向上する。スケーラビリティを損なわず、大幅な性能向上を達成している。

ABSTRACT

Within the last few years, a countless number of blockchain systems have emerged on the market, each one claiming to revolutionize the way of distributed transaction processing in one way or the other. Many blockchain features, such as byzantine fault tolerance (BFT), are indeed valuable additions in modern environments. However, despite all the hype around the technology, many of the challenges that blockchain systems have to face are fundamental transaction management problems. These are largely shared with traditional database systems, which have been around for decades already. These similarities become especially visible for systems, that blur the lines between blockchain systems and classical database systems. A great example of this is Hyperledger Fabric, an open-source permissioned blockchain system under development by IBM. By having a relaxed view on BFT, the transaction pipeline of Fabric highly resembles the workflow of classical distributed databases systems. This raises two questions: (1) Which conceptual similarities and differences do actually exist between a system such as Fabric and a classical distributed database system? (2) Is it possible to improve on the performance of Fabric by transitioning technology from the database world to blockchains and thus blurring the lines between these two types of systems even further? To tackle these questions, we first explore Fabric from the perspective of database research, where we observe weaknesses in the transaction pipeline. We then solve these issues by transitioning well-understood database concepts to Fabric, namely transaction reordering as well as early transaction abort. Our experimental evaluation shows that our improved version Fabric++ significantly increases the throughput of successful transactions over the vanilla version by up to a factor of 3x.

研究の動機と目的

• Hyperledger Fabricのようなブロックチェーンシステムと、古典的な分散データベースシステムとの間の概念的類似点と相違点を調査すること。
• トランザクションの順序が最適でないことや、ロールバックの判断が遅いことによって生じるFabricのトランザクションパイプラインにおけるパフォーマンスボトルネックを特定すること。
• 確立されたデータベース技術が、ブロックチェーンシステムのパフォーマンス向上に効果的に応用可能かどうかを検討すること。
• スループットと効率の向上を図るために、データベース由来の最適化を統合した改良版Fabric、すなわちFabric++の設計と評価を行うこと。

提案手法

• シリアル化競合を最小限に抑えるために、ブロック内のトランザクションを再順序付けする高度なトランザクション再順序付けメカニズムを導入する。これにより、有効なトランザクション数が増加する。
• トランザクションパイプラインの複数段階で早期ロールバックを実装し、リソースを消費する前に無効なトランザクションを検出し、破棄する。
• シミュレーション段階と順序付け段階を分離することで、トランザクションフローを最適化し、競合の早期検出とパイプラインの競合低減を実現する。
• 108種の異なるワークロードおよびシステム構成において、Fabric++のパフォーランスを評価し、vanilla Fabricと比較してスループットと障害率を測定する。
• ブロックサイズ、読み取り／書き込み比率、クライアント／チャネル数を変更可能なベンチマーク環境を構築し、スケーラビリティと最適化効果を評価する。
• 制御された実験を通じて、それぞれの最適化（再順序付けと早期ロールバック）の個別的および併用時の貢献度を分析する。

実験結果

リサーチクエスチョン

• RQ1 Hyperledger Fabricと古典的な分散データベースシステムとの間に、どのような概念的類似点と相違点が存在するか？
• RQ2 確立されたデータベース技術は、Fabricのような準拠ブロックチェーンシステムのパフォーマンス向上に、どの程度応用可能か？
• RQ3 トランザクション再順序付けと早期ロールバックメカニズムは、Fabricのトランザクションパイプラインのスループットと効率にどのように影響を与えるか？
• RQ4 再順序付けと早期ロールバックを併用した場合のトランザクションスループットへの統合的効果は何か？実際の動作ではそれらの機構はどのように相互作用するか？
• RQ5 vanilla Fabricと比較して、Fabric++はチャネル数やクライアント数の増加に伴い、どのようにスケーリングするか？

主な発見

• 最適な構成下では、Fabric++はvanilla Fabricと比較して、成功トランザクションのスループットが最大3倍に向上する。
• トランザクション再順序付けまたは早期ロールバックのいずれかを有効化するだけで、スループットが約100から約150件の成功トランザクション／秒に向上する。
• 両最適化を同時に有効化すると、ピークスループットは約220件の成功トランザクション／秒に達し、相乗効果によるパフォーマンス向上が確認される。
• 早期ロールバックと再順序付けの組み合わせにより、パイプラインの競合が低減され、成功の可能性があると見なせるトランザクションのみが再順序付けの対象となる。
• 複数のチャネルにわたるスケーリングにより、4つのチャネルまでスループットが向上するが、以降はリソース競合が原因でスループットが低下し、トランザクション障害率が上昇する。
• 1つのチャネルあたりのクライアント数を増加させると、リソース競合が顕著になり、障害率が上昇し、スループットが低下する。特に、Fabric++ではクライアント数が多い状況でのパフォーマンス低下が顕著に現れる。