[论文解读] 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

一句话总结

本文提出 Fabric++，即 Hyperledger Fabric 的增强版本，通过集成数据库领域的优化技术——事务重排序与提前终止——显著提升事务吞吐量。通过重排序事务以减少序列化冲突，并在流水线早期阶段终止无效事务，Fabric++ 相较于原生 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++ 的性能，与原生 Fabric 对比吞吐量与失败率。
• 采用可配置的基准测试设置，通过调整区块大小、读写比例及客户端/通道数量，评估可扩展性与优化效果。
• 通过受控实验，分别分析事务重排序与提前终止各自及联合使用时的贡献。

实验结果

研究问题

• RQ1 Hyperledger Fabric 与经典分布式数据库系统之间存在哪些概念上的相似性与差异？
• RQ2 成熟数据库技术在多大程度上可被应用于提升许可区块链系统（如 Fabric）的性能？
• RQ3 事务重排序与提前终止机制如何影响 Fabric 事务流水线的吞吐量与效率？
• RQ4 重排序与提前终止的联合效应如何？它们在实践中如何相互作用？
• RQ5 与原生 Fabric 相比，Fabric++ 在通道与客户端数量增加时的可扩展性如何？

主要发现

• 在最优配置下，Fabric++ 相较于原生 Fabric 实现了高达 3 倍的成功事务吞吐量提升。
• 仅启用事务重排序或提前终止中的任一机制，即可使吞吐量从约 100 提升至约 150 笔成功事务/秒。
• 同时启用两种优化时，峰值吞吐量可达约 220 笔成功事务/秒，表明存在协同增益效应。
• 提前终止与重排序的结合通过确保仅考虑具有实际成功可能的事务进行重排序，有效降低了流水线竞争。
• 跨多个通道扩展可将吞吐量提升至 4 个通道，超过此数量后资源竞争导致吞吐量下降与事务失败率上升。
• 增加每个通道的客户端数量会因资源竞争导致失败率上升与吞吐量下降，尤其在 Fabric++ 中，高客户端数量下的性能下降更为显著。