Cited by 632Blockchain Technology Applications and SecurityBlockchain Technology in Education and LearningDistributed systems and fault tolerance

The DOI matches its Crossref record; 17 of the 17 references it cites were found in a registry or an index; none of the 10 sources its claims cite is checked for support yet.

Performance Benchmarking and Optimizing Hyperledger Fabric Blockchain Platform

Open access
Thakkar, Parth, Nathan, Senthil, Viswanathan, Balaji·2018·2018 IEEE 26th International Symposium on Modeling, Analysis, and Simulation of Computer and Telecommunication Systems (MASCOTS)

Abstract

The rise in popularity of permissioned blockchain platforms in recent time is significant. Hyperledger Fabric is one such permissioned blockchain platform and one of the Hyperledger projects hosted by the Linux Foundation. The Fabric comprises various components such as smart-contracts, endorsers, committers, validators, and orderers. As the performance of blockchain platform is a major concern for enterprise applications, in this work, we perform a comprehensive empirical study to characterize the performance of Hyperledger Fabric and identify potential performance bottlenecks to gain a better understanding of the system. We follow a two-phased approach. In the first phase, our goal is to understand the impact of various configuration parameters such as block size, endorsement policy, channels, resource allocation, state database choice on the transaction throughput & latency to provide various guidelines on configuring these parameters. In addition, we also aim to identify performance bottlenecks and hotspots. We observed that (1) endorsement policy verification, (2) sequential policy validation of transactions in a block, and (3) state validation and commit (with CouchDB) were the three major bottlenecks. In the second phase, we focus on optimizing Hyperledger Fabric v1.0 based on our observations. We introduced and studied various simple optimizations such as aggressive caching for endorsement policy verification in the cryptography component (3x improvement in the performance) and parallelizing endorsement policy verification (7x improvement). Further, we enhanced and measured the effect of an existing bulk read/write optimization for CouchDB during state validation & commit phase (2.5x improvement). By combining all three optimizations1, we improved the overall throughput by 16x (i.e., from 140 tps to 2250 tps).

Overview

AI snapshot

Written from the paper’s full text.

TL;DR

This paper empirically benchmarks Hyperledger Fabric v1.0 across block size, endorsement policy, channels, resource allocation, and state database choices, identifying three major bottlenecks. It then introduces MSP caching, parallel VSCC validation, and CouchDB bulk read/write optimizations, improving single-channel throughput from 140 tps to 2250 tps (16×).

Key findings

  • Fabric v1.0 saturated around 140 tps with GoLevelDB on a single channel; latency rose from hundreds of milliseconds to tens of seconds near saturation because VSCC validation ran serially on one vCPU.
  • GoLevelDB throughput was 3× greater than CouchDB (140 tps vs. 50 tps); with CouchDB, increasing writes dropped throughput from 50 tps to 18 tps, while GoLevelDB showed no such impact.
  • The three identified bottlenecks were endorsement policy verification, sequential policy validation of transactions in a block, and state validation/commit with CouchDB.
  • Optimizations: MSP cache gave 3× improvement, parallel endorsement policy verification gave 7×, and CouchDB bulk read/write gave 2.5×; combined, they improved single-channel throughput from 140 tps to 2250 tps (16×).

Methods

  • Empirical study of Hyperledger Fabric v1.0 using over 1000s of experiments, varying block size, endorsement policy, channels, resource allocation, and ledger database.
  • Test network: 4 organizations, each with 2 endorsing peers (8 peer nodes total), 1 orderer with Kafka-Zookeeper, on IBM SoftLayer VMs with 32 vCPUs and 3 Gbps network; load generated by three client machines with 56 vCPUs and 128 GB memory.
  • Custom benchmark modeled from 12 internal customer solutions, using write-only and read-write transactions; Fabric source was instrumented to collect fine-grained latencies such as VSCC, MVCC, and ledger update latency.

Limitations

  • Stated: the ordering service performance was not studied; network was assumed not to be a bottleneck; arrival rates did not follow a distribution model; scalability and fault tolerance are left for future work.
  • Stated: the study focuses on Fabric v1.0, though the authors note the optimizations were adopted in v1.1 and core functionality remains similar.
  • Evident: results are tied to a specific datacenter setup, hardware allocation, single orderer, and benchmark workloads derived from 12 internal customer solutions, so generalization to other topologies, WAN deployments, or production arrival distributions is not established.

Model-written summary. Check it against the paper before relying on it.

Integrity signals

Registry

Crossref · 10.1109/mascots.2018.00034

Cites

17 of 17 references verified0 citation errors · 0 not checkable

Statistics

Nothing to recompute.

Verification

Claims the paper makes

43 Own result · 28 No basis given · 27 Own interpretation · 8 Sources not found · 4 Own method

Show all 77 claims

  • It may state two separate claims as one. 26
  • Probably not a substantial claim. 9
  • The quote only partly states this claim. 1
33 of 33
  • The authors state this as an assumption.

    The study assumes a datacenter or high bandwidth network with very low latency.

    “While network characteristics are important, we assume a datacenter or high bandwidth network with very low latency for this study.”
  • The authors state this as an assumption.

    The orderer, gossip, and physical network were kept static and did not affect the experiments and observations.

    “we keep the Orderer, Gossip (physical network) etc. static so that it does not affect our experiments and observations.”
  • The paper relies on this without support.

    There is a lack of standard benchmarks for blockchain.

    “In the lack of standard benchmarks for Blockchain, we built our own benchmarks by surveying around 12 internal customer solutions built on Fabric for diverse use cases.”
  • The authors state this as an assumption.

    The network is not a bottleneck in the study (a datacenter or high-bandwidth, very-low-latency network is assumed).

    “In our study, we assumed that the network is not a bottleneck.”
    “While network characteristics are important, we assume a datacenter or high bandwidth network with very low latency for this study.”
4 of 4

Claims other papers make about this one

Each is checked against this paper’s own text: does it say what the citing paper says it does?

Self-check

Percentages, sums and reported differences re-computed from the paper’s own numbers.

Each contradiction between two passages listed here was confirmed by an independent check.

2 of 2

Citations

Cites

Show all 15 references

Research works printed but not linked: 20

  1. white, 0, Digitizing Global Trade with Maersk and IBM
  2. 0, e SDK for Fabric Client/Application
  3. 0, PostgreSQL as the State Database for Hyperledger Fabric
  4. 0, PostgreSQL Database Management System
  5. 0, The Linux Foundation Helps Hyperledger Build the Most Vibrant Open Source Ecosystem for Blockchain
  6. 0, Quorum an Ethereum-forked variant Blockchain
  7. 0, SecureKey Building Trusted Identity Networks
  8. nakamoto, 0, Bitcoin A Peer-to-Peer Electronic Cash System
  9. 0, CouchDB Document Revision Number
  10. 0, CouchDB Bulk API
  11. 0, Go SDK for Fabric Client/Application
  12. 0, Everledger - A Digital Global Ledger
  13. 0, Java SDK for Fabric Client/Application
  14. 0, GoLevelDB
  15. 0, CouchDB
  16. 0, Membership Service Providers (MSP)
  17. 0, Chaincodes
  18. detwiler, 0, One nations move to increase food safety with blockchain
  19. keller, 0, New collaboration on trade finance platform built on blockchain
  20. hearn, 0, Corda A distributed ledger

Cited by

Sorted by citations

Items 501–600 of 632

Metadata

Authors
Thakkar, P., Nathan, S., & Viswanathan, B.
Affiliations
  • National Institute of Technology Tiruchirappalli (IN)
  • IBM Research - India (IN)
Venue
2018 IEEE 26th International Symposium on Modeling, Analysis, and Simulation of Computer and Telecommunication Systems (MASCOTS)
Publisher
IEEE
Published
2018-09
Pages
264-276
ISSN
1526-7539 (ISSN-L)
OpenAlex
W2806281946
Cited by
632
References
15
Citations by year
2026: 45 · 2025: 49 · 2024: 49 · 2023: 79 · 2022: 97 · 2021: 118 · 2020: 107 · 2019: 84 · 2018: 4
FWCI
61.41
Type
conference paper
Language
en
Open access
Locations
  • Proceedings - International Symposium on Modeling, Analysis, and Simulation of Computer and Telecommunication Systems (publishedVersion)
  • arXiv (Cornell University) (submittedVersion)
  • arXiv (Cornell University)
Topics
  • Physical Sciences › Computer Science › Information Systems › Blockchain Technology Applications and Security
  • Physical Sciences › Computer Science › Information Systems › Blockchain Technology in Education and Learning
  • Physical Sciences › Computer Science › Computer Networks and Communications › Distributed systems and fault tolerance
Keywords
Hyperledger Fabric, permissioned blockchain, blockchain performance, performance bottlenecks, transaction throughput, latency, CouchDB, caching

About these checks

Registry, retraction, Cites and statistics results are computed, not judged, with one exception: a printed reference that no index lists is read once by a model before it counts as a citation error. Claims are extracted by a model and kept only when their quote appears verbatim in the text; each cited source is then checked, with a model’s help, for whether it says what the claim relies on. Those verdicts can be wrong — read the claim’s quote and the cited source before relying on one.

A language model drew the claims from the paper on 2026-11-10, under version 3 of the claim definition (model deepseek-v4.1-flash, prompt extract-v3).

A second model labelled each claim on 2026-11-10 (model jev-1.13-20260917, definition revision gold-guideline-v0.2).

Statistics and arithmetic are recomputed, not judged.

Confidence bands are shown only for fields calibrated on our annotated test set. None is calibrated yet, so no band is shown.

What counts as a claim ›How we measure confidence ›How we check this ›

Are you an author, or do you see a problem with this page? Request a review