FastFabric: Scaling Hyperledger Fabric to 20,000 Transactions per Second

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.

Optimizing Validation Phase of Hyperledger Fabric

“…Our work is closest to [15], [22], [23]. Thakkar et al [23] performed an extensive study of the Fabric v1.0, and found that the major bottlenecks are in repeated deserialization of indentities/certificates, sequential validation of transactions during vscc, and slow CouchDB accesses.…”

“…We implemented our optimizations in Fabric v1.1 (also valid for v1.4), and show that for CouchDB the throughput improves by 2× (from 575 to 1,196 transactions/second), while the improvement with LevelDB is 1.3× (from 2,178 to 2,835 transactions/second). Our optimizations are orthogonal to previous works [15], [23], and thus can be adopted in a future release of Fabric.…”

“…In a recent work [15], Gorenflo et al focused on rearchitecting both the orderer and peer in Fabric v1.2. For orderers, they proposed to use only the transaction ids instead of full transactions.…”

“…Like these works, we also propose architectural changes, however, our optimizations are focused on improving other operations (such as chaincode accesses, and database reads and writes in parallel) which have not been explored before, and can be combined with these existing works. For example, assume that the in-memory hash table from [15] acts as a caching layer for state database [16], then the parallel reads and writes from state database can be combined with [15] to further improve Fabric's performance.…”

“…Many previous performance studies have highlighted validation phase as one of the major bottlenecks [11], [15], [23], in addition to the bottlenecks in consensus mechanism [10]. For the validation phase, recent optimizations [15], [23] include validation of transactions in parallel, caching block and identity certificates, and bulk reading from slow CouchDB.…”