Bringing Private Reads to Hyperledger Fabric via Private Information Retrieval

TL;DR

This work tackles the privacy risk that Hyperledger Fabric endorsing peers face when evaluating read queries, by embedding a homomorphic-encryption–based private information retrieval (PIR) mechanism directly into Fabric chaincode. The approach maps the world-state records to a plaintext polynomial m_DB and performs ciphertext–plaintext multiplication within evaluate transactions to retrieve a single record without revealing the index, preserving Fabric's endorsement and audit semantics. The authors introduce a multi-channel CPIR architecture, a concrete polynomial database construction, and a detailed performance evaluation showing practical latencies (around 113 ms end-to-end) and modest network traffic for private reads on small, sensitive datasets. They provide extensive parameter analyses, storage profiling, and a working open-source implementation, demonstrating the feasibility of PIR-based private reads in permissioned ledgers while outlining clear directions to improve scalability, constant-time security, and fully encrypted on-chain computations.

Abstract

Permissioned blockchains ensure integrity and auditability of shared data but expose query parameters to peers during read operations, creating privacy risks for organizations querying sensitive records. This paper proposes a Private Information Retrieval (PIR) mechanism to enable private reads from Hyperledger Fabric's world state, allowing endorsing peers to process encrypted queries without learning which record is accessed. We implement and benchmark a PIR-enabled chaincode that performs ciphertext-plaintext (ct-pt) homomorphic multiplication directly within evaluate transactions, preserving Fabric's endorsement and audit semantics. The prototype achieves an average end-to-end latency of 113 ms and a peer-side execution time below 42 ms, with approximately 2 MB of peer network traffic per private read in development mode--reducible by half under in-process deployment. Storage profiling across three channel configurations shows near-linear growth: block size increases from 77 kilobytes to 294 kilobytes and world-state from 112 kilobytes to 332 kilobytes as the ring dimension scales from 8,192 to 32,768 coefficients. Parameter analysis further indicates that ring size and record length jointly constrain packing capacity, supporting up to 512 records of 64 bytes each under the largest configuration. These results confirm the practicality of PIR-based private reads in Fabric for smaller, sensitive datasets and highlight future directions to optimize performance and scalability.

Figures (9)

• Figure 1: “Workflow. $\mathcal{DW}$ initializes the ledger via $\mathcal{GW}$, which triggers chaincode on endorsing peers ($\mathcal{DO}$). $\mathcal{DO}$ executes the protocol and persists state in world state ($m_{DB}$, metadata, JSON records). $\mathcal{DR}$ later obtains metadata, submits $ct_q=Enc_{pk}(v_i)$, $\mathcal{DO}$ evaluates $ct_r=Eval(ct_q,m{\mathrm{DB}})$ against world state, and $\mathcal{DR}$ decrypts to $d_i$.
• Figure 2: $m_{DB}$ construction from JSON to plaintext polynomial. Each record is serialized to bytes, mapped into a fixed slot window $record_s$, and packed into a coefficient vector $c$. The vector is then encoded as a BGV plaintext polynomial $m_{DB}$, which is stored in the Fabric world state.
• Figure 3: Feasible configurations under the joint constraints $\mathcal{C}$, $\mathcal{M}$, and $\mathcal{D}$. Dashed curves show ring-capacity limits for $\log N \in \{13,14,15\}$, vertical lines mark template-driven minima $record_{\mu,\log N}$, and x-axis ticks correspond to discrete slot sizes $\mathcal{S}$. Circles indicate feasible triples $(\log N,record_s,n)$.
• Figure 4: Multi-channel CPIR architecture. Each channel instantiates a separate CPIR chaincode and maintains its own $m_{DB}$ polynomial, parameterized by $\log N$. This allows compact, mid-size, and rich CTI records to coexist under the same Fabric network.
• Figure 5: Cryptographic performance of the BGV-based CPIR system: (A) latency by algorithmic stage, (B) artifact size by ring configuration, and (C) allocated-slot utilization.