[论文解读] FastFabric: Scaling Hyperledger Fabric to 20,000 Transactions per Second

Christian Gorenflo, Stephen Lee+2 more|arXiv (Cornell University)|Jan 3, 2019

Blockchain Technology Applications and Security参考文献 15被引用 45

一句话总结

本文对 Hyperledger Fabric v1.2 进行了可插拔式重构，将元数据与数据分离、提升并行性、使用内存中的世界状态，并将提交者/背书节点的硬件分离，以在不显著降低区块延迟的情况下将吞吐量从约3k tx/s 提升到约20k tx/s。

ABSTRACT

Blockchain technologies are expected to make a significant impact on a variety of industries. However, one issue holding them back is their limited transaction throughput, especially compared to established solutions such as distributed database systems. In this paper, we re-architect a modern permissioned blockchain system, Hyperledger Fabric, to increase transaction throughput from 3,000 to 20,000 transactions per second. We focus on performance bottlenecks beyond the consensus mechanism, and we propose architectural changes that reduce computation and I/O overhead during transaction ordering and validation to greatly improve throughput. Notably, our optimizations are fully plug-and-play and do not require any interface changes to Hyperledger Fabric.

研究动机与目标

• 动机：需要高吞吐量的许可区块链，并评估 Hyperledger Fabric 1.2 中共识之外的吞吐瓶颈。
• 设计并实现可插拔的架构优化，以提高端到端交易吞吐量。
• 表明这些优化在保留 Fabric API 的前提下可与 Fabric 2.x 集成。
• 给出性能结果并讨论可扩展性方向，最高达 50k tx/s。

提出的方法

• 将交易元数据与有效载荷分离，以通过仅向排序服务发送交易ID来减少排序开销。
• 在排序服务中引入消息流水线和并行处理以提高吞吐量。
• 用内存中的哈希表替代世界状态数据库，以加速关键路径上的读写操作。
• 将区块存储与提交/背书解耦，实现专用的存储集群和背书节点池。
• 在不同硬件上分离承诺与背书角色，以降低竞争。
• 缓存未解码的 Protocol Buffers 块，以在验证期间避免重复解码。

实验结果

研究问题

• RQ1 Hyperledger Fabric 的吞吐量是否可以在不改变 API 的前提下通过重新设计排序与验证路径来显著提升？
• RQ2 在 Fabric 1.2 中，将元数据与数据分离、实现并行化、以及使用内存数据结构带来的性能提升如何？

主要发现

• 端到端吞吐量从 3,185±62 tx/s（Fabric 1.2）提升到 19,112±811 tx/s（FastFabric），用于 100k 个背书交易。
• 在有效载荷大小优化下，排序节点吞吐量提升至约 21,719–28,534 tx/s，取决于配置（Opt O-I 和 O-II）。
• 在实现所有对等节点优化后，点对点吞吐量从约 3,200 tx/s（Fabric 1.2）提升到超过 21,000 tx/s。
• 在峰值吞吐量下，区块延迟通过优化显著下降，达到原始延迟的约三分之一。
• 在调优并行性设置下，100 笔交易的区块大小可获得最优端到端吞吐量（约 21k tx/s）。
• 端到端实验显示在部署设置下相比 Fabric 1.2 的吞吐量提升了 6–7 倍。