Private Information Retrieval for Ethereum State
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.