Source-linked AI summary
FastFabric: Scaling Hyperledger Fabric to 20,000 Transactions per Second
Christian Gorenflo, Stephen Lee, Lukasz Golab, S. Keshav
TL;DR
Limited transaction throughput constrains blockchain practicality relative to database systems. FastFabric re-architects Hyperledger Fabric beyond consensus with changes to ordering and peer validation, reaching nearly 20,000 transactions per second while reducing peer latency.
Problem
Blockchain systems need transaction rates comparable to existing database management systems to be viable in practice.
Method
FastFabric re-architects Fabric beyond consensus using transaction-ID-only ordering, parallel validation, aggressive caching, and lightweight in-memory data structures.
Results
6-7× improvement over the Fabric 1.2 baseline was measured in end-to-end throughput experiments.
Takeaways & Limitations
FastFabric shows that independent I/O, caching, parallelism, and data-access optimizations can raise permissioned-blockchain throughput substantially.
Abstract
from arXiv · showhide
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.
I. INTRODUCTION
Permissioned blockchains can reduce consensus burdens, but Fabric still needs database-comparable transaction rates for practical deployment. FastFabric therefore re-architects Fabric beyond consensus, combining metadata separation, parallelism, caching, and faster data access to raise throughput.
- Blockchain viability requires transaction rates comparable to existing database management systems.
- The work targets permissioned blockchains, whose known participants allow consensus and validation to be delegated to selected nodes, while consensus remains a bottleneck.
- FastFabric improves Fabric 1.2 end-to-end throughput by almost 7×, from 3,000 to 20,000 transactions per second, while decreasing block latency.
- The redesign separates transaction IDs from payloads for ordering, parallelizes validation, caches unmarshaled blocks, and uses lightweight in-memory data structures for critical-path access.
- The proposed optimizations are presented as compatible with Fabric's existing workflow and interfaces, with future work identified toward 50,000 transactions per second.
A. Node types
Fabric divides transaction processing among clients, endorsers, peers, and orderers. Endorsers execute and certify proposals, orderers establish transaction order and blocks, and peers commit those blocks and update world state.
- Peers commit blocks locally and apply their changes to a state database, while some peers also perform endorsement.
- Clients send transaction proposals to endorsers, which execute them in a sandbox, compute read-write sets, and validate business rules.
- Fabric channels identify separate virtualized blockchain contexts, and all nodes must be known and registered through the membership service provider.
- Endorsers return signed responses, after which clients submit endorsed proposals to the ordering service.
- Orderers check client authorization, publish proposals to Kafka, establish channel-specific serial order, and assemble transactions into blocks.
2) Peer:
Peer processing verifies, validates, and commits ordered blocks, with sequential validation and storage on the critical path. FastFabric targets these stages while preserving module interfaces and allowing optimizations to be implemented independently.
- Peers first unmarshal and syntactically check block metadata, verify orderer signatures, and discard blocks that fail these tests.
- Blocks then pass sequentially through validation and commit stages, guaranteeing their addition to the blockchain.
- Validation checks transaction syntax and endorsements, then verifies read-write-set key versions so conflicting state changes invalidate transactions.
- The final commit writes the validated block to the filesystem, while world state and block indices use LevelDB or CouchDB.
- The redesign keeps module interfaces and responsibilities intact, remains compatible with existing implementations, and makes its improvements mutually orthogonal.
- FastFabric focuses beyond consensus because Fabric 1.2 uses Kafka ordering, while BFT consensus improvements are outside this work's scope.
B. Orderer improvement I: Separate transaction header from payload
FastFabric redesigns orderers and peers around concurrent processing, separating transaction IDs from payloads and reducing repeated computation and storage overhead. The peer design combines in-memory state, parallel validation, role separation, and cached unmarshaled blocks.
- Orderer: Orderers send only transaction IDs to Kafka because consensus needs transaction order rather than complete transaction payloads.
- Orderer: The orderer stores payloads separately, reassembles transactions when ordered IDs return, and then batches them into blocks.
- Orderer: Incoming transactions are processed concurrently through a pipelined ordering mechanism, including transactions from the same client and channel.
- Peer: Peer validation uses an in-memory hash table for world state and parallelizes validation of multiple blocks and transactions.
- Peer: The design separates endorsement from commitment, defers blockchain-log storage, and caches unmarshaled blocks to reduce critical-path work.
E. Peer improvement I: Replacing the world state database with a hash table
The paper replaces the peer’s disk-backed world state database with an in-memory hash table to accelerate sequential state updates, while pairing volatile memory with stable storage.
- Sequential world-state lookups and updates are critical because each transaction must preserve consistency across all peers.
- An in-memory hash table replaces LevelDB/CouchDB for relatively small world states, eliminating hard-drive access during updates.
- The hash table is susceptible to node failures because it uses volatile memory, so it must be augmented with stable storage.
- Immutable blocks can use append-only storage, and a distributed storage cluster is proposed for maximum scaling of blocks and world-state backups.
G. Peer improvement III: Separate commitment and endorsement
The design separates endorsement from commitment and parallelizes validation work, while caching unmarshaled blocks to reduce repeated computation in the validation pipeline.
- Separate commitment and endorsement: Separating endorsement and commitment avoids replicating expensive commitment work across every endorser node.
- Separate commitment and endorsement: A committer validates blocks and sends them to endorsers that only apply world-state changes without revalidating them.
- Parallelize validation: Block and transaction-header validation are highly parallelizable, so the design introduces a complete validation pipeline.
- Separate commitment and endorsement: The current implementation does not include the proposed storage system.
- Cache unmarshaled blocks: A temporary cyclic cache stores unmarshaled block data for reuse across validation goroutines and safely overwrites entries after commitment.
- Cache unmarshaled blocks: Memory allocation from unmarshaling remains the largest share of execution time, while gRPC management and cryptography are outside this work’s scope.
IV. RESULTS
The evaluation compares Fabric 1.2 with incremental orderer and peer improvements using controlled experiments and a full end-to-end setup. The reported results include sustainable gRPC throughput above 40,000 transactions/s and substantial orderer gains from sending only transaction IDs to Kafka.
- The evaluation uses fifteen local servers with 24 hardware threads and compares Fabric 1.2 against improvements added step by step.
- The experiments use valid, non-conflicting transactions, so every transaction undergoes all validation checks and state commitment, evaluating worst-case performance.
- More than 40,000 transactions/s is sustainable over gRPC for block sizes from 10 to 250 transactions, indicating network bandwidth is not the bottleneck in this environment.
- For 2 KB payloads, orderer throughput rises from 6,215 transactions/s in Fabric 1.2 to 21,719 transactions/s with both orderer optimizations.
- Publishing only transaction IDs to Kafka nearly triples average throughput at a 4096 KB payload, while adding proposal parallelism reaches 4× average throughput over Fabric 1.2.
C. Peer experiments
Peer experiments evaluate cumulative state-storage, validation, commitment, and unmarshaling-cache optimizations on isolated peers. Together, these changes reduce block latency and raise peer commit throughput substantially.
- The isolated-peer experiments send precomputed blocks to a peer that completely validates and commits them, with configurations incorporating improvements cumulatively.
- The configurations replace LevelDB with an in-memory hash table, parallelize validation and commitment, offload storage and endorsement, and cache unmarshaled data.
- Peer latency decreases to a third of its original value, although the reported latency is per block and excludes network delay.
- Using a hash table increases peer throughput from about 3200 to more than 7500 transactions/s, while parallelized validation adds roughly 2,000 transactions per second.
- All peer optimizations increase commit performance 7x, from about 3200 transactions/s to over 21,000 transactions/s.
2) Parameter sensitivity:
The study tunes peer-validation parallelism and examines how block size affects throughput. A 100-transaction block provides the best measured throughput, while nearby sizes perform similarly.
- Parallelism: Validation parallelism is controlled through separate go-routine pools for concurrent blocks and transaction validation.Semaphores regulate both pools, allowing independent control of block-header and transaction-validation parallelism.
- Parallelism: 56 go-routines maximize throughput for 100-transaction blocks: 25 validate transactions while 31 concurrently shepherd blocks.The total is the sum of the two independent axes; excessive threading causes a small management-overhead degradation.
- Block size: Block-size experiments use roughly 24 ± 2 transaction-validation go-routines and 30 ± 3 blocks in the pipeline.Each run splits 100,000 transactions across blocks and scans block sizes logarithmically.
- Block size: Just over 21,000 transactions per second is achieved at 100 transactions/block, the best-performing block size.Performance differences between block sizes 50 and 500 are minor, so the configuration fixes block size at 100.
D. End-to-end throughput
The end-to-end evaluation combines the ordering and peer optimizations and compares the result with unmodified Fabric 1.2. The benchmark reports a 6–7× throughput improvement, while prior work spans complementary optimizations and measurements.
- End-to-end evaluation: The combined Opt. O-II and Opt. P-III configuration is evaluated against unmodified Fabric 1.2.The experiment measures end-to-end throughput after combining the paper’s ordering and peer optimizations.
- End-to-end evaluation: 100,000 endorsed transactions are batched into blocks of 100 and delivered to a peer for throughput measurement.Throughput is estimated from the mean time between committed blocks over repeated runs.
- End-to-end results: 6–7× higher throughput is reported than in the baseline Fabric 1.2 benchmark.The benchmark uses one orderer, three ZooKeeper servers, three Kafka servers, one peer, and five endorsers.
- Prior work: Earlier Fabric work includes certificate caching, parallel policy verification, and batched state validation and commitment.These techniques address bottlenecks in endorsement-policy verification and commit processing.
- Prior work: Some prior approaches are complementary, while dropping conflicting transactions at orderers is incompatible with this solution.The incompatibility follows from deliberately withholding transaction read-write sets from orderers.
- Prior work: BFT-SMART-based ordering has reported throughput up to 30,000 transactions/second in a single datacenter.Other studies examine channels, lossy compression, and Fabric scaling without establishing the same quantitative benefits or general applicability.
VI. CONCLUSIONS
The paper re-engineers Hyperledger Fabric through independent optimizations in I/O, caching, parallelism, and data access. The resulting design supports nearly 20,000 transactions per second, with several future improvements identified.
- Conclusion: Nearly 20,000 transactions per second is achieved, almost 7× better than prior work.The conclusion presents this as the main contribution of re-engineering a permissioned blockchain framework.
- Conclusion: The design sends transaction IDs rather than full transactions to orderers and heavily parallelizes peer validation.It also uses aggressive caching and lightweight data structures for fast critical-path access.
- Future work: Future work includes incorporating efficient BFT consensus, accelerating transaction-ID extraction, and replacing the cryptographic library.These directions target ordering, cryptographic, and consensus overheads.
- Future work: Further parallelism could come from separate ordering and fast peer servers for each channel.The paper also proposes an efficient distributed data-analytics layer using Apache Spark.