[Paper Review] 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 Security15 references45 citations

TL;DR

The paper re-architects Hyperledger Fabric v1.2 with plug-and-play changes that separate metadata from data, enhance parallelism, use in-memory world state, and separate committer/endoser hardware to boost throughput from ~3k to ~20k tx/s while reducing block latency.

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.

Motivation & Objective

• Motivate the need for high-throughput permissioned blockchains and evaluate throughput bottlenecks beyond consensus in Hyperledger Fabric 1.2.
• Design and implement plug-and-play architectural optimizations to increase end-to-end transaction throughput.
• Show that the optimizations preserve Fabric APIs and can be integrated with Fabric 2.x.
• Provide performance results and discuss scalability directions up to 50k tx/s.

Proposed method

• Separate transaction metadata from payload to reduce ordering overhead by sending only Transaction IDs to the ordering service.
• Introduce message pipelining and parallel processing in the ordering service to increase throughput.
• Replace the world state database with an in-memory hash table to speed read/write operations on the critical path.
• Decouple block storage from commit/endorsement, enabling a dedicated storage cluster and endorser pool.
• Separate commitment and endorsement roles across distinct hardware to reduce contention.
• Cache unmarshaled Protocol Buffers blocks to avoid repeated decoding during validation.

Experimental results

Research questions

• RQ1 Can Hyperledger Fabric throughput be significantly increased without API changes by re-architecting ordering and validation paths?
• RQ2 What are the performance gains from separating metadata from data, enabling parallelism, and using in-memory data structures in Fabric 1.2?
• RQ3 How do architectural separations (committers vs endorsers) and caching affect end-to-end throughput and latency?
• RQ4 What is the achievable end-to-end throughput of FastFabric under representative workloads compared to Fabric 1.2?

Key findings

• End-to-end throughput scales from 3,185±62 tx/s (Fabric 1.2) to 19,112±811 tx/s (FastFabric) for 100k endorsed transactions.
• Orderer throughput with payload-size optimizations increases to about 21,719–28,534 tx/s depending on configuration (Opt O-I and O-II).
• Peer throughput improves from ~3,200 tx/s (Fabric 1.2) to over 21,000 tx/s with all peer optimizations (Opt P-I, P-II, P-III).
• Block latency decreases significantly with optimizations, achieving roughly one-third of the original latency at peak throughput.
• A block size of 100 transactions yields optimal end-to-end throughput under tuned parallelism settings (≈21k tx/s).
• End-to-end experiments show a 6–7x throughput improvement over Fabric 1.2 in the deployed setup.