PaperlayerView exact revision on arXiv

Source-linked AI summary

Performance Benchmarking and Optimizing Hyperledger Fabric Blockchain Platform

Parth Thakkar, Senthil Nathan, Balaji Vishwanathan

arXiv:1805.11390v1cs.DC

TL;DR

The paper addresses concerns about whether permissioned blockchain platforms can handle high transaction volumes at low latency. It empirically benchmarks Hyperledger Fabric across configurable parameters, identifies bottlenecks, and evaluates optimizations that improve single-channel throughput 16×, from 140 tps to 2250 tps. The study also notes that its network assumptions leave geographically distributed deployments for future work.

  • Problem

    Permissioned blockchain platforms face concerns about handling huge transaction volumes at low latency, motivating evidence on Fabric’s performance and bottlenecks.

  • Method

    The authors conduct a comprehensive empirical study varying block size, endorsement policy, channels, resource allocation, and state database choice, then use instrumentation to guide optimizations.

  • Results

    16× single-channel throughput improvement, from 140 tps to 2250 tps, resulted from combining MSP cache, parallel VSCC validation, and bulk read/write optimizations.

  • Takeaways & Limitations

    The study provides six configuration guidelines and identifies three major bottlenecks for improving Fabric performance.

  • Takeaways & Limitations

    The study assumes the network is not a bottleneck and uses a datacenter or high-bandwidth, very-low-latency network setting.

Abstract

from arXiv · show

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).

I. INTRODUCTION

Permissioned blockchains target enterprise applications with authenticated participants, but their performance under high transaction volume and low latency is a concern. This study empirically evaluates Hyperledger Fabric’s configurable parameters, identifies bottlenecks, and tests optimizations.

  • Motivation: Permissioned networks authenticate participants and support access control for enterprise applications.They can also support smart contracts and integration among organizations.
  • Research Challenge: Performance concerns center on handling high transaction volumes at low latency in permissioned blockchain platforms.Hyperledger Fabric is the enterprise-grade permissioned platform examined in this work.
  • Research Challenge: Fabric’s components and processing phases expose configurable parameters whose values affect efficient network setup.The parameters include block size, endorsement policy, channels, and state database choice.
  • Approach and Contributions: The study varies five major parameters across thousands of experiments and provides six configuration guidelines.The evaluated dimensions include block size, endorsement policy, channels, resource allocation, and state database choice.
  • Approach and Contributions: The authors identify crypto operations, serial transaction validation, and multiple CouchDB REST API calls as major bottlenecks.They introduce three optimizations and report a 16× overall improvement, from 140 tps to 2250 tps, in a single-channel environment.

II. BACKGROUND: HYPERLEDGER FABRIC ARCHITECTURE & CONFIGURATION PARAMETERS

Hyperledger Fabric is a modular permissioned blockchain whose transaction path separates endorsement, ordering, validation, and commit. Its architecture uses channels, identities, endorsement policies, ordering services, and peer-maintained ledgers to process transactions.

  • Architecture: Fabric supports enterprise-oriented smart contracts, pluggable consensus, configurable trust models, and identities managed through organizational membership providers.Its network includes peers, ordering service nodes, and clients belonging to different organizations.
  • Architecture: Peers execute chaincode for endorsement and maintain the ledger and current state in a key-value StateDB.Peers may be endorsing or committing peers, but both maintain ledger state.
  • Architecture: Endorsement policies specify which organizational peers must simulate a transaction and digitally sign its execution results.Policies are Boolean expressions over network-principal identities.
  • Transaction Processing: Channels isolate communication, ledgers, and chaincodes, while ordering services create per-channel blocks and deliver them to peers.Consensus is applied per channel, and the ordering service supports a pluggable consensus mechanism.
  • Transaction Processing: Fabric uses a simulate-order-validate-and-commit model comprising endorsement, ordering, validation, and ledger update phases.Validation applies VSCC endorsement checks and sequential MVCC checks before atomically updating StateDB with valid write-sets.

C. Configuration Parameters

The study examines how block size, endorsement policy, channels, resource allocation, and ledger database choice shape Fabric throughput and latency. These parameters expose batching trade-offs, parallelism, computational cost, and database-access differences.

  • Block Size: Block size creates a throughput-versus-latency trade-off because transactions are batched and peers process one block at a time.The study evaluates block size together with transaction arrival rate.
  • Endorsement Policy: Endorsement policy affects the executions, signatures, and VSCC policy checks required before transactions can be ordered.Evaluating endorsement expressions for satisfiability is NP-Complete, and endorsement signatures also require identity verification.
  • Channels: Channels process transactions independently and introduce parallelism, making channel count relevant to performance and scalability.Transactions on different channels are ordered, delivered, and processed independently on the same peers.
  • Resource Allocation: Resource allocation is varied because peers perform CPU-intensive signature operations and endorsing peers execute user chaincode.The experiments assume a low-latency, high-bandwidth datacenter network.
  • Ledger Database: Fabric supports GoLevelDB and CouchDB as state databases, with the latter using a client-server REST interface and document/JSON data model.GoLevelDB is embedded, whereas CouchDB is accessed through secure HTTP.

III. PROBLEM STATEMENT

The work benchmarks Fabric’s throughput and latency across configurable system conditions and uses instrumentation to identify bottlenecks for optimization. It defines transaction- and block-level latency components and evaluates them with a continuously stressed load generator.

  • Performance Benchmarking: The benchmarking goal is to characterize throughput and latency while varying Fabric configuration parameters and derive deployment guidelines.The intended users are developers and deployment engineers.
  • Optimization: The optimization goal is to use code-level instrumentation to identify bottlenecks and implement changes that alleviate them.This goal follows the performance characterization phase.
  • Metrics: Throughput measures the rate of transactions committed to the ledger, while latency measures time from proposal submission to transaction commit.Latency includes endorsement, broadcast, commit, and ordering components.
  • Metrics: VSCC, MVCC, and ledger-update latency measure block-level endorsement validation, concurrency-control validation, and state-database updates.MVCC checks transaction read-set versions, and ledger updates apply valid write-sets.

A. Setup and Workloads

The study benchmarks Fabric across configurable parameters using a custom workload and more than 1000 experiments. Block size and arrival rate create a throughput–latency trade-off, while serial VSCC validation limits utilization and performance.

  • Experimental setup: More than 1000 experiments evaluated Fabric performance across configurable parameters using averaged throughput and transaction-latency measurements.The benchmark varied workload and configuration conditions to characterize performance and identify bottlenecks.
  • Arrival rate and block size: At approximately 140 tps, throughput reached saturation while latency rose from hundreds of milliseconds to tens of seconds as arrival rate increased.The VSCC queue grew rapidly, affecting commit latency.
  • Arrival rate and block size: At 50 tps, increasing block size from 10 to 100 raised transaction latency fivefold, from 242 ms to 1250 ms.Larger blocks increased block-creation time at the orderer below saturation.
  • Arrival rate and block size: At 150 tps, increasing block size from 10 to 200 reduced latency from 14 seconds to 10 seconds and increased throughput by 3.5%.Larger blocks reduced validation-and-commit overhead when arrival rate exceeded saturation.
  • Resource utilization: CPU utilization increased only from 1.4% to 6.7% as arrival rate rose from 25 to 175 tps because VSCC processed one transaction at a time.Serial signature verification used only one vCPU, leaving CPU resources under-utilized.
  • Guidelines: Below saturation, lower block sizes reduce latency; at high arrival rates, higher block sizes improve throughput and reduce latency.These are the study’s configuration guidelines for differing arrival-rate regimes.

B. Impact of Endorsement Policy

Endorsement-policy structure materially affects Fabric’s validation cost. More signatures and nested sub-policies increase VSCC latency and reduce throughput, motivating simpler policies and cryptographic caching.

  • Policy structure: Policies with more sub-policies and signature verifications reduced throughput; the second and third AND/OR policies were 7% and 20% lower than other policies.Equivalent AND/OR and NOutOf policies can differ in performance because sub-policy search space and signature count affect validation.
  • Validation cost: VSCC latency increased linearly from 68 ms to 137 ms with more signature verifications and reached 172 ms and 203 ms for policies with sub-policies.Resource utilization followed a similar trend.
  • Validation cost: Policy validation performs identity deserialization, organization-MSP validation, and transaction-signature verification.Increasing sub-policies expands the search space and increases identities and signatures to validate.
  • Guideline: High performance is associated with endorsement policies containing fewer sub-policies and signatures.The paper states this as a configuration guideline for Fabric deployments.
  • Optimization: Caching deserialized identities and MSP information is proposed to avoid routine CPU-intensive cryptographic operations.The paper states that long-lived identities and separate CRLs avoid introducing a security risk.

C. Impact of Channels and Resource Allocation

Channels provide parallelism, but performance depends on sufficient and balanced CPU allocation. Across channels, under-provisioned or heterogeneous peers can become bottlenecks, so the paper recommends per-channel capacity and avoiding weak peers.

  • Channels: Increasing channels from 1 to 16 raised throughput from 140 tps to 832 tps in non-overloaded conditions and 1320 tps in overloaded conditions.Channels process transactions independently and maintain separate block chains.
  • Resource allocation: With 16 channels, reducing allocated vCPUs below 16 cut throughput from 848 tps to 32 tps, while endorsement latency rose from 37 ms to 21 s.CPU contention also increased commit latency from 640 ms to 49 s.
  • Heterogeneous peers: Allocating only 2 vCPUs to 2 of 8 peers reduced throughput from 848 tps to 417 tps for write-only transactions and 307 tps for read-write transactions.Endorsement timeouts and MVCC conflicts contributed to the reduction.
  • Scope: The evaluation assumes a datacenter or high-bandwidth network and does not study network-resource effects directly.The authors expect heterogeneous network resources to have an impact similar to heterogeneous CPU resources.
  • Guidelines: The study recommends allocating at least one vCPU per channel and matching additional capacity to expected channel load.It also recommends avoiding heterogeneous peers because less powerful peers dictate performance.
  • Optimization: Additional CPU power can be better utilized by processing transactions within and across channels.The paper identifies this as an optimization direction following the resource-allocation observations.

D. Impact of Ledger Database

The study finds substantial state-database effects on Fabric performance: GoLevelDB offers higher throughput, while CouchDB incurs increasing latency as transaction reads or writes grow. Bulk operations reduce CouchDB overhead, but database locking remains a constraint.

  • GoLevelDB achieved 3× greater throughput than CouchDB, reaching 140 tps versus 50 tps on a single channel.
  • CouchDB throughput fell from 50 tps to 18 tps as transactions increased from one to multiple writes, unlike GoLevelDB.
  • CouchDB endorsement and ledger-update latency rose from 40 ms and 240 ms with one write to 800 ms and 1200 ms with three writes.Whole-database read and write locks caused contention between endorsement and ledger update.
  • CouchDB MVCC latency increased with more reads because validation issued more GET REST API calls, but did not increase with more writes.
  • GoLevelDB is recommended for performance, whereas CouchDB is preferable when rich queries matter and applications can limit keys read or written.

E. Scalability and Fault Tolerant

Fabric scalability depends on channel, organization, peer, and endorsement-policy configuration, while node failures are generally tolerated under non-overloaded conditions but can cause synchronization delays under higher loads.

  • Endorsement-policy complexity controls scalability more directly than organization or peer counts when only a few organizations’ signatures are required.
  • Node failures did not affect performance in non-overloaded cases because clients could collect endorsements from other available nodes.
  • Under higher loads, node rejoining and ledger synchronization after failure incurred large delays.

VI. OPTIMIZATIONS STUDIED

The optimization study targets three observed bottlenecks: cryptographic endorsement checks, serial VSCC validation, and CouchDB access during MVCC validation and commit.

  • The study combines MSP caching, parallel VSCC validation, and bulk CouchDB read/write operations as three targeted Fabric optimizations.
  • MSP caching targets identity deserialization and identity validation with organizations’ MSPs in the cryptography module.
  • Bulk operations were integrated with MVCC validation and final commit to reduce CouchDB REST API calls and lock-holding duration.An existing bulk-operation implementation was available but had not been integrated with these phases.
  • MSP caching increased average throughput by 3× compared with a vanilla peer for the evaluated endorsement policies.The cache also reduced crypto-operation frequency and VSCC call-stack depth.

B. Parallel VSCC Validation of a Block

Parallelizing VSCC validation and batching CouchDB operations substantially improve Fabric throughput, while combined optimizations reach much higher throughput but leave sequential phases and resource underutilization as boundaries.

  • Parallel VSCC Validation of a Block: Parallel VSCC raised one-channel throughput from 130 tps to 800 tps for block size 30 and 980 tps for block size 300.For block size 30, VSCC latency fell from 300 ms to 30 ms.
  • Parallel VSCC Validation of a Block: Overloaded-case throughput and resource utilization increased from 1.5× for 16 channels to as much as 10× for one channel.The improvement decreased with more channels because channel-level block parallelism already consumed available vCPUs.
  • Bulk Read/Write During MVCC Validation & Commit: Bulk read/write raised CouchDB throughput from 50 tps to 115 tps for one write and from 26 tps to 100 tps for three writes.MVCC, ledger-update, and endorsement latency also decreased after batching database operations.
  • Bulk Read/Write During MVCC Validation & Commit: Bulk operations reduced endorsement latency by at least 3× through an at-least-8× reduction in commit lock-holding duration.Read-write MVCC latency fell by at least 6× through bulk reading of transaction read sets.
  • Combinations of Optimizations: Combined optimizations increased single-channel GoLevelDB throughput from 140 tps to 2250 tps, a 16× improvement.With CouchDB, throughput increased from 50 tps to 700 tps, a 14× improvement.
  • Combinations of Optimizations: With a simpler endorsement policy, single-channel GoLevelDB throughput reached 2700 tps, while 8- and 16-channel throughput reached 2700 tps from 1025 and 1321 tps.
  • Combinations of Optimizations: At 2700 tps, peer CPU utilization remained 60%, suggesting sequential VSCC and MVCC phases leave vCPUs underutilized.Pipelining VSCC and MVCC validation is identified as a potential optimization.

VII. RELATED WORK

Prior studies benchmarked public and permissioned blockchain performance, but this work broadens the evaluation of Hyperledger Fabric across workloads and configurable parameters while introducing optimizations based on observed bottlenecks.

  • Public-blockchain studies examined scalability, consensus limits, security implications, and operational metrics such as throughput, latency, bootstrap time, and transaction cost.
  • BlockBench compared Ethereum, Parity, and Hyperledger Fabric using micro- and macro-benchmarks spanning consensus, data, execution, and application layers.
  • Earlier Fabric work presented its architecture and measured a single Fabcoin application using customized validation, simplified endorsements and channels, and CLI-emulated clients.
  • This paper differs by comprehensively studying multiple workloads and application domains while retaining Fabric’s modularity.
  • The study varies block size, endorsement policy, channels, resource allocation, and state database choices, identifies bottlenecks, and evaluates three optimizations that improve single-channel performance by 16×.
  • The evaluation assumes the network is not a bottleneck, leaving geographically distributed deployments, arrival-rate distributions, topology, and ordering-service scalability for future work.
Loading 1805.11390v1…