ZK-Rollup for Hyperledger Fabric: Architecture and Performance Evaluation

A big challenge posed in blockchain centric platforms is achieving scalability while also preserving user privacy. This report details the design, implementation and evaluation of a Layer-2 scaling solution for Hyperledger Fabric using Zero Knowledge Rollups (ZK Rollups). The proposed architecture introduces an off chain sequencer that accepts transactions immediately and sends them for batching into a Merkle tree based rollup, using ZK proofs to attest to the correctness and verifiability of the entire batch. The design aims to decouple transaction ingestion from actual on chain settlements to address Fabric scalability limitations and increase throughput under high load conditions. The baseline architecture in Hyperledger Fabric constrains transaction requests due to endorsement, ordering and validation phases, leading to a throughput of 5 to 7 TPS with an average latency of 4 seconds. Our Layer-2 solution achieves an ingestion throughput of 70 to 100 TPS, leading to an increase of nearly ten times due to the sequencer immediate acceptance of each transaction and reducing client perceived latency by nearly eighty percent to 700 to 1000 milliseconds. This work demonstrates that integrating ZK Rollups in Hyperledger Fabric enhances scalability while not compromising the security guarantees of a permissioned blockchain network.

💡 Research Summary

The paper presents a comprehensive design, implementation, and performance evaluation of a Layer‑2 scaling solution for Hyperledger Fabric that leverages Zero‑Knowledge Rollups (ZK‑Rollups). Recognizing that Fabric’s native transaction flow—endorsement, ordering, and validation—creates a severe throughput bottleneck (typically 5‑7 transactions per second with ~4 seconds latency), the authors introduce an off‑chain sequencer that immediately accepts client requests, queues them in Redis, and periodically batches 32 transactions into a Merkle‑tree‑based rollup. For each batch, a Poseidon‑based 5‑level Merkle tree is constructed, and a PLONK‑based ZK‑SNARK proof is generated to attest that the Merkle root correctly represents the batch contents. Only the proof, the Merkle root, an IPFS content identifier (CID) for the serialized batch data, and minimal metadata are submitted to Fabric via a custom chaincode function, dramatically reducing on‑chain computational load and preserving privacy because individual transaction details never appear on the ledger.

The system architecture consists of three logical layers: (1) a client layer exposing a REST API; (2) the Layer‑2 off‑chain sequencer that handles ingestion, batching, proof generation, and IPFS upload; and (3) the Layer‑1 on‑chain Fabric network that verifies the proof and records the batch commitment. The Fabric network is deployed in a Kubernetes cluster with two organizations, each having two peers, a three‑node Raft ordering service, and a Certificate Authority for identity and TLS management. The off‑chain components (sequencer, Redis, IPFS node) run as separate containers within the same cluster.

Performance evaluation is conducted on a local KinD (Kubernetes‑in‑Docker) cluster (8 CPU cores, 8 GB RAM) using the k6 load‑testing tool. Two workloads are compared: (a) a baseline where 20 virtual users directly invoke Fabric’s CreateAsset chaincode (synchronous, waiting for HTTP 200 after full endorsement, ordering, and commit), yielding 5‑7 TPS and 2.5‑3.5 seconds latency; and (b) the ZK‑Rollup workload where 50 virtual users POST to the sequencer’s /submit endpoint, receiving an HTTP 202 as soon as the request is queued, achieving 70‑100 TPS and 0.3‑0.4 seconds perceived latency. The authors note that the client‑perceived latency improves by roughly tenfold because the client no longer waits for the full consensus path.

Proof generation on the test hardware takes 35‑45 seconds per batch, which the authors acknowledge as a current bottleneck. However, they argue that with GPU or FPGA acceleration, proof creation can be reduced to under one second, making the settlement throughput comparable to the ingestion rate. IPFS upload adds only 1‑2 seconds per batch, which is negligible in the overall pipeline. Consequently, on production‑grade hardware the system could sustain >100 TPS end‑to‑end, far surpassing the baseline.

The paper situates its contribution within related work, highlighting that most ZK‑Rollup research focuses on public blockchains (e.g., Ethereum) and that few studies address permissioned environments. Prior attempts to embed ZK‑Proofs directly into Fabric have shown significant performance degradation (30‑87.5 % slower) due to on‑chain verification overhead. By moving proof generation off‑chain and only verifying a succinct proof on‑chain, the proposed architecture retains Fabric’s security guarantees (endorsement policies, TLS, CA‑issued certificates) while adding privacy and scalability.

Limitations include the fixed batch size of 32, static Merkle tree depth, and reliance on a single‑node proof generator in the experiments. Future work suggested includes dynamic batch sizing, multi‑GPU proof pipelines, and benchmarking alternative ZK‑SNARK libraries (e.g., Groth16, Halo2) for further latency reductions.

In summary, the study demonstrates that integrating ZK‑Rollups into Hyperledger Fabric can increase transaction throughput by an order of magnitude, cut client‑perceived latency by up to 90 %, and preserve the permissioned network’s privacy and security properties. This Layer‑2 approach offers a viable path for enterprise blockchain applications that demand high‑frequency, low‑latency processing, such as real‑time supply‑chain tracking, metaverse events, or confidential asset management.