Private Retrieval

Private Information Retrieval for Ethereum, scalable obliviousness primitives ensuring servers cannot learn what clients read.

Cryptographic protocols that let users query Ethereum data from remote servers without revealing what they are reading.

The Problem

Every time a wallet checks a balance, verifies a transaction receipt, or reads contract storage from a remote server, the server learns exactly which records were accessed. This read-pattern leakage enables MEV extraction, frontrunning, identity correlation, and surveillance. Even with encrypted connections, the pattern of accesses reveals a lot about the user.

Approach: Sharded PIR

The sharded PIR design segments Ethereum state into data slices and serves each slice through a PIR engine tuned for its size and access profile. The server processes encrypted queries and returns encrypted responses, never learning which record was requested.

Data Slices

No single PIR scheme can handle all of Ethereum’s data while meeting the latency and client/server overhead requirements in different contexts. The design segments the state into slices, each paired with a PIR engine tuned for its size, access profile, and likely context of consumption:

  • Hot mutable state (1–10 GB): balances, nonces, contract storage. Latency-critical, updates every block. Requires double-stateless schemes (no persistent client or server state) to avoid session linkability.
  • State with Merkle proofs (~100–300 GB), full state for light clients. Larger databases where preprocessing tradeoffs matter.
  • Immutable logs and receipts (hundreds of GB), append-only data that can leverage schemes with expensive one-time hint generation.
  • Archival / warehouse data (2–30 TB): historical queries, high latency tolerance. Multi-GPU parallelism essential at this scale.

PIR Schemes

Multiple PIR schemes are being built, benchmarked, and integrated. The current frontrunners for the sharded architecture:

  • insPIRe, a double-stateless single-server scheme with server-side preprocessing. Handles database updates cheaply and without involving clients, making it well-suited for hot mutable state; speccing and GPU acceleration are the current focus.
  • VIA, a lattice-based scheme being specified and implemented with reusable primitives across VIA, VIA-B, and VIA-CB variants.
  • OnionPIRv2, an FHE-native single-server scheme with strong performance characteristics for medium-sized databases.
  • Harmony / RMS24, preprocessing-based schemes suitable for immutable or slowly-changing data slices where one-time hint generation cost is amortized over many queries.

Ongoing Research

Reach out with proposals if you would like to collaborate on these ideas.

PIR for Merkle Trees

Clients need not just leaf values but Merkle proofs to verify state against roots. Retrieving these proofs privately adds overhead: either by running separate PIR queries per tree level, or by pre-attaching proof paths to database entries (increasing storage). UBT’s binary structure is significantly cheaper here than MPT’s hexary branching. Hybrid strategies that balance query count against storage blowup are being explored. See section 8 of the design post for the analysis.

SNARKifying Archival State to Reduce DB Size

PIR databases for archival Ethereum state can grow to terabytes. Replacing Merkle proofs with succinct SNARK proofs of state validity would shrink the database significantly, clients verify a proof instead of fetching and hashing Merkle paths. The idea is to chain recursive zkVM proofs per block, so any historical balance, nonce, or codehash lookup can be verified against a single succinct proof rather than full Merkle paths. See section 8 of the design post for details.

Delegating Hint Generation in Interactive-Hint Schemes

Interactive-hint schemes like Plinko and RMS24 achieve sublinear online server time but require clients to stream entire databases during hint generation. Delegating this to a server via FHE or MPC could reduce both computational and bandwidth burden on clients, though this remains prohibitively expensive with current constructions.

Concretely Efficient DEPIR

Doubly Efficient PIR (DEPIR) combines client-stateless simplicity with asymptotically sublinear server-side cost. However, constants in existing asymptotic bounds place current constructions orders of magnitude behind practical PIR schemes on real databases. Achieving concrete efficiency would dramatically simplify the PIR landscape: a single client-stateless scheme with sublinear per-query cost could serve all data slices.

Resources