pith. sign in

arxiv: 1907.08367 · v1 · pith:AIRJ4QZQnew · submitted 2019-07-19 · 💻 cs.DC

Optimizing Validation Phase of Hyperledger Fabric

Haris Javaid , Chengchen Hu , Gordon Brebner This is my paper

Pith reviewed 2026-05-24 19:14 UTC · model grok-4.3

classification 💻 cs.DC
keywords Hyperledger Fabricvalidation phaseperformance optimizationCouchDBLevelDBchaincode cacheparallel database accessblockchain throughput
0
0 comments X

The pith

Re-architecting Fabric's validation phase with caching and parallel database operations yields up to 2x throughput gains for CouchDB.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The paper breaks down latency in the validation phase of Hyperledger Fabric and targets sequential database accesses and repeated chaincode execution as the main slowdowns. It introduces a chaincode cache that reuses results across transactions, starts state database reads while validation is underway, and performs ledger and database writes concurrently. These changes produce measured gains of 2x with CouchDB and 1.3x with LevelDB on the tested workloads. A reader would care because permissioned blockchains handle enterprise transaction volumes where higher validation speed directly lowers latency and hardware requirements. The modifications are presented as backward-compatible additions that a future Fabric release could adopt.

Core claim

The authors re-architect the validation phase of Hyperledger Fabric based on a fine-grained latency breakdown. The new design adds a chaincode cache during transaction validation, initiates state database reads in parallel with validation, and writes to the ledger and databases in parallel. Experiments show these steps deliver performance improvements of 2x for CouchDB and 1.3x for LevelDB.

What carries the argument

Chaincode cache during validation combined with parallel state-database reads and parallel ledger/database writes.

If this is right

  • Transaction validation becomes the faster stage in Fabric's commit pipeline for both CouchDB and LevelDB backends.
  • Overall system throughput rises without any change to the Fabric consensus or endorsement protocols.
  • Enterprises running Fabric on CouchDB receive larger relative gains than those on LevelDB.
  • The same parallel and caching patterns could be applied to other phases of the Fabric transaction flow.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • Other permissioned blockchain platforms with similar validation loops could apply the same latency-driven restructuring.
  • Cache size and eviction policy become new tuning knobs that affect realized speedup under varying transaction patterns.
  • If parallel writes reduce contention on the ledger, overall block commit time may drop beyond the validation-phase gains alone.

Load-bearing premise

The fine-grained latency breakdown correctly identifies the dominant bottlenecks and the proposed parallel and caching changes introduce no new overheads that would reduce the measured gains under production workloads.

What would settle it

Measure end-to-end validation latency on a production-scale workload with realistic cache hit rates and compare against the reported 2x and 1.3x speedups.

Figures

Figures reproduced from arXiv: 1907.08367 by Chengchen Hu, Gordon Brebner, Haris Javaid.

Figure 1
Figure 1. Figure 1: Transaction Flow in Hyperledger Fabric. An endorsing peer both executes/endorses transactions and validates/commits blocks to the ledger. A non-endorsing peer only validates/commits blocks to the ledger. Execution of transactions is enabled by smart contracts or chaincodes, which represent the business logic and are instantiated on the endorsing peers. The ordering sevice consists of orderers which use a c… view at source ↗
Figure 2
Figure 2. Figure 2: Original validation phase: LevelDB vs. vscc threads. [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗
Figure 3
Figure 3. Figure 3: Original validation phase: LevelDB vs. block size. [PITH_FULL_IMAGE:figures/full_fig_p003_3.png] view at source ↗
Figure 5
Figure 5. Figure 5: E. Optimized Validation Phase The observations from our analysis can be summarized into two main points: (1) Only the vscc operation benefits [PITH_FULL_IMAGE:figures/full_fig_p003_5.png] view at source ↗
Figure 4
Figure 4. Figure 4: Original validation phase: CouchDB vs. vscc threads. [PITH_FULL_IMAGE:figures/full_fig_p004_4.png] view at source ↗
Figure 5
Figure 5. Figure 5: Original validation phase: CouchDB vs. block size. [PITH_FULL_IMAGE:figures/full_fig_p004_5.png] view at source ↗
Figure 7
Figure 7. Figure 7: Optimized validation phase: LevelDB vs. vscc threads. [PITH_FULL_IMAGE:figures/full_fig_p005_7.png] view at source ↗
Figure 8
Figure 8. Figure 8: Optimized validation phase: LevelDB vs. block size. [PITH_FULL_IMAGE:figures/full_fig_p005_8.png] view at source ↗
Figure 4
Figure 4. Figure 4: On the block commit operations, the ledger write la￾tency is completely hidden by the statedb write latency. The ledger write latency in this case also includes the time taken to write to the history database, and hence is more than the ledger write latency in [PITH_FULL_IMAGE:figures/full_fig_p005_4.png] view at source ↗
Figure 9
Figure 9. Figure 9: Optimized validation phase: CouchDB vs. vscc threads. [PITH_FULL_IMAGE:figures/full_fig_p006_9.png] view at source ↗
Figure 10
Figure 10. Figure 10: Optimized validation phase: CouchDB vs. block size. [PITH_FULL_IMAGE:figures/full_fig_p006_10.png] view at source ↗
read the original abstract

Blockchain technologies are on the rise, and Hyperledger Fabric is one of the most popular permissioned blockchain platforms. In this paper, we re-architect the validation phase of Fabric based on our analysis from fine-grained breakdown of the validation phase's latency. Our optimized validation phase uses a chaincode cache during validation of transactions, initiates state database reads in parallel with validation of transactions, and writes to the ledger and databases in parallel. Our experiments reveal performance improvements of 2x for CouchDB and 1.3x for LevelDB. Notably, our optimizations can be adopted in a future release of Hyperledger Fabric.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

1 major / 0 minor

Summary. The paper analyzes the validation phase of Hyperledger Fabric via a fine-grained latency breakdown. It proposes three optimizations—a chaincode cache during transaction validation, parallel state database reads concurrent with validation, and parallel writes to the ledger and databases—and reports measured speedups of 2x for CouchDB and 1.3x for LevelDB, claiming these changes can be adopted in a future Fabric release.

Significance. If the speedups hold under scrutiny, the work supplies practical, targeted performance engineering for a widely deployed permissioned blockchain platform. The latency-breakdown methodology is a clear strength for identifying bottlenecks, and the claim of adoptability indicates the changes preserve compatibility with the existing codebase.

major comments (1)
  1. [Experimental results section] Experimental results section: the central claims rest on the reported 2x/1.3x speedups, yet the manuscript supplies no workload descriptions, hardware configuration, baseline implementation details, number of runs, or error bars. This prevents verification that the three changes correctly target the dominant bottlenecks and introduce no offsetting overheads under realistic conditions.

Simulated Author's Rebuttal

1 responses · 0 unresolved

We thank the referee for the constructive feedback on our manuscript. We address the single major comment below and will incorporate the requested information in a revised version.

read point-by-point responses

  1. Referee: [Experimental results section] Experimental results section: the central claims rest on the reported 2x/1.3x speedups, yet the manuscript supplies no workload descriptions, hardware configuration, baseline implementation details, number of runs, or error bars. This prevents verification that the three changes correctly target the dominant bottlenecks and introduce no offsetting overheads under realistic conditions.

    Authors: We agree that additional experimental details are required for independent verification. In the revised manuscript we will expand the experimental results section to describe the workloads, hardware configuration, baseline implementation, number of runs, and error bars. These additions will allow readers to confirm that the reported speedups arise from the targeted optimizations without offsetting overheads. revision: yes

Circularity Check

0 steps flagged

No significant circularity; purely empirical engineering study

full rationale

The paper contains no equations, derivations, fitted parameters, or predictive claims. It reports a latency breakdown of the Fabric validation phase followed by three concrete code changes (chaincode cache, parallel state-DB reads, parallel ledger/DB writes) whose speedups are measured directly on CouchDB and LevelDB. No self-citation is used to justify uniqueness or to close a logical loop; the central results are externally falsifiable benchmark numbers. The work is therefore self-contained with no reduction of outputs to inputs by construction.

Axiom & Free-Parameter Ledger

0 free parameters · 0 axioms · 0 invented entities

No mathematical model, free parameters, axioms, or new entities are introduced; the contribution is an engineering re-architecture of an existing system.

pith-pipeline@v0.9.0 · 5623 in / 935 out tokens · 17060 ms · 2026-05-24T19:14:41.753306+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

24 extracted references · 24 canonical work pages · 3 internal anchors

  1. [1]

    http://couchdb.apache.org/

    Apache CouchDB. http://couchdb.apache.org/

    work page

  2. [2]

    http://kafka.apache.org/

    Apache Kafka. http://kafka.apache.org/

    work page

  3. [3]

    https://bitcoin.org/en/

    Bitcoin. https://bitcoin.org/en/

    work page

  4. [4]

    https://www.corda.net

    Corda. https://www.corda.net

    work page

  5. [5]

    https://ethereum.org

    Ethereum. https://ethereum.org

    work page

  6. [6]

    https://www.hyperledger.org/projects/caliper

    Hyperledger Caliper. https://www.hyperledger.org/projects/caliper

    work page

  7. [7]

    https://www.hyperledger.org/projects/fabric

    Hyperledger Fabric. https://www.hyperledger.org/projects/fabric

    work page

  8. [8]

    https://github.com/syndtr/goleveldb/

    LevelDB in Go. https://github.com/syndtr/goleveldb/

    work page

  9. [9]

    https://www.jpmorgan.com/global/Quorum

    Quorum. https://www.jpmorgan.com/global/Quorum

    work page

  10. [10]

    Hyperledger Fabric: A Distributed Operating System for Permissioned Blockchains

    Elli Androulaki, Artem Barger, Vita Bortnikov, Christian Cachin, Kon- stantinos Christidis, Angelo De Caro, David Enyeart, Christopher Ferris, Gennady Laventman, Yacov Manevich, Srinivasan Muralidharan, Chet Murthy, Binh Nguyen, Manish Sethi, Gari Singh, Keith Smith, Alessan- dro Sorniotti, Chrysoula Stathakopoulou, Marko Vukoli ´c, Sharon Weed Cocco, and...

    work page 2018

  11. [11]

    Performance Characterization of Hyperledger Fabric

    Arati Baliga, Nitesh Solanki, Shubham Verekar, Amol Pednekar, Pan- durang Kamat, and Siddhartha Chatterjee. Performance Characterization of Hyperledger Fabric. In Crypto Valley Conference on Blockchain Technology (CVCBT), 2018

    work page 2018

  12. [12]

    Consensus in the Age of Blockchains

    Shehar Bano, Alberto Sonnino, Mustafa Al-Bassam, Sarah Azouvi, Patrick McCorry, Sarah Meiklejohn, and George Danezis. Consensus in the Age of Blockchains. In CoRR, arXiv:1711.03936, 2017

    work page internal anchor Pith review Pith/arXiv arXiv 2017

  13. [13]

    Forbes Blockchain 50: Half of the biggest companies deploying blockchain use Hyperledger

    Hyperledger Blog. Forbes Blockchain 50: Half of the biggest companies deploying blockchain use Hyperledger. https://www.hyperledger.org/blog/2019/04/18/ trashed, 2019

    work page 2019

  14. [14]

    BLOCKBENCH: A Framework for Analyzing Private Blockchains

    Tien Tuan Anh Dinh, Ji Wang, Gang Chen, Rui Liu, Beng Chin Ooi, and Kian-Lee Tan. BLOCKBENCH: A Framework for Analyzing Private Blockchains. In Proceedings of the 2017 ACM International Conference on Management of Data (SIGMOD) , 2017

    work page 2017

  15. [15]

    Christian Gorenflo, Stephen Lee, Lukasz Golab, and S. Keshav. Fast- Fabric: Scaling Hyperledger Fabric to 20,000 Transactions per Second. In CoRR, arXiv:1901.00910, 2019

    work page internal anchor Pith review Pith/arXiv arXiv 1901

  16. [16]

    FAB-103 Cache of the World State for Improved Performance

    Hyperledger Fabric JIRA. FAB-103 Cache of the World State for Improved Performance. https://jira.hyperledger.org/browse/FAB-103

    work page

  17. [17]

    FAB-12221 Validator/Committer Refactor

    Hyperledger Fabric JIRA. FAB-12221 Validator/Committer Refactor. https://jira.hyperledger.org/browse/FAB-12221?filter=12526

    work page

  18. [18]

    Qasse, Manar Abu Talib, and Ali Bou Nassif

    Qassim Nasir, Ilham A. Qasse, Manar Abu Talib, and Ali Bou Nassif. Performance analysis of hyperledger fabric platforms. Security and Communication Networks, 2018

    work page 2018

  19. [19]

    Failure and Recovery of StateDB in Hyperledger Fabric v1.1

    Senthil Nathan. Failure and Recovery of StateDB in Hyperledger Fabric v1.1. https://blockchain-fabric.blogspot.com/2018/05/failure-and- recovery-of-statedb-in.html, 2018

    work page 2018

  20. [20]

    In Search of an Understandable Consensus Algorithm

    Diego Ongaro and John Ousterhout. In Search of an Understandable Consensus Algorithm. In Proceedings of the 2014 USENIX Conference on USENIX Annual Technical Conference (ATC), pages 305–320, 2014

    work page 2014

  21. [21]

    Performance Analysis of Private Blockchain Platforms in Varying Workloads

    Suporn Pongnumkul, Chaiyaphum Siripanpornchana, and Suttipong Thajchayapong. Performance Analysis of Private Blockchain Platforms in Varying Workloads. In International Conference on Computer Communication and Networks (ICCCN) , 2017

    work page 2017

  22. [22]

    How to Databasify a Blockchain: the Case of Hyperledger Fabric

    Ankur Sharma, Felix Martin Schuhknecht, Divya Agrawal, and Jens Dittrich. How to Databasify a Blockchain: the Case of Hyperledger Fabric. In CoRR, arXiv:1810.13177, 2018

    work page internal anchor Pith review Pith/arXiv arXiv 2018

  23. [23]

    Performance Benchmarking and Optimizing Hyperledger Fabric Blockchain Platform

    Parth Thakkar, Senthil Nathan, and Balaji Vishwanathan. Performance Benchmarking and Optimizing Hyperledger Fabric Blockchain Platform. In 26th IEEE International Symposium on the Modeling, Analysis, and Simulation of Computer and Telecommunication Systems (MASCOTS) , 2018

    work page 2018

  24. [24]

    The quest for scalable blockchain fabric: Proof-of- work vs

    Marko Vukoli ´c. The quest for scalable blockchain fabric: Proof-of- work vs. BFT replication. Lecture Notes in Computer Science (including subseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics), 2016

    work page 2016