Sharded PIR Design
for the Ethereum State

Ali Atiia
Private Reads
Ethereum Foundation

Stateless Summit · EthCC 2026

privreads.ethereum.foundation

The Need to Protect the Privacy of Reads

The edge relies on the infrastructure to read state data: balances, transaction status, historical holdings, DeFi yields, AMM exchange rates, …

Simply reading part of the state reveals users' holdings and intentions, and undermines privacy protections like shielding.

What Do Users Actually Read?

Contexts of data consumption across wallet, frontend, and archival use cases

Answer: a bit of everything

Paradigms for Private Reads

Single-Server PIR

Cryptographic guarantee. One server, no coordination.

Our current focus is single-server PIR

No overhead of coordinating non-colluding parties
No assumptions on the availability or security of hardware

Multi-Server PIR

Non-colluding servers split the trust assumption.

TEE + ORAM

Trusted hardware executes queries inside enclaves; ORAM hides access patterns to memory.

...

PIR: Private Information Retrieval

The server answers queries while being completely oblivious to what is being accessed or what the query is about

Various cryptographic tools to achieve this hiding; example from FHE-based schemes:

Client encrypts the query under a lattice-based scheme (e.g. RLWE)
Server computes homomorphically over the entire database — operating on ciphertexts without ever decrypting them
Server returns an encrypted result that only the client can open

What Shapes PIR Performance?

The most consequential factors: database size and (for some schemes) update frequency

Meanwhile, looking at Ethereum data:

Frequently accessed & latency-sensitive

What are my balances?

Checked on every wallet open, every page load

Has my transaction been included?

Polled repeatedly after submission — incoming and outgoing

Less frequently accessed & less latency-sensitive

Transaction history

Behind multiple clicks in wallets, or pagination on a frontend

Independent verification of balances

Verification of internal (non-value) nodes can run in the background by a light client

A Slicing of the Ethereum State

The most consequential factors: database size and (for some schemes) update frequency

Pairing Schemes with Slices

RMS24

VIA Compress

Harmony-FF1

?

Example: use a server- and client-stateless scheme for "Express" because:
(a) it's consumed frequently in frontends (can't have client-side storage assumption)
(b) latency sensitive
(c) small in size so the performance should be ok despite query cost being linear in db size

PIR benchmarks

Genuine + Decoy = Full Privacy

Each slice (shard) is paired with the optimal scheme (engine) … but all schemes must be queried in parallel with decoy queries in addition to the real query, to preserve privacy

Note: more bandwidth is consumed but since the queries are independent, it doesn't affect the latency of the real query

Decoupling the Edge from the PIR Backend

The Edge continues expressing queries following Ethereum RPC specs
The heavy lifting of translating RPC calls to PIR queries is done in middleware (e.g. integrated in the few SDKs which the many wallets already use)
Abstract PIR interface minimizes the effect of backend upgrades on the middleware
(this is being worked on in Q2)

Optimizations & Ongoing Research

The Sidecar Pattern

A main PIR engine hosts bulk preprocessed data while a small sidecar engine absorbs real-time updates. Re-preprocessing happens lazily in the background — not on the critical path of every block.
Using Binary Tries instead of MPT

Binary tries (UBT) reduce Merkle proof overhead under PIR to ~9× vs ~48× for the current hexary MPT, among many other benefits. The equivalence of a UBT-based (EIP7864-enabled) shadow chain to the mainnet MPT chain is achieved by zkVM proving the execution of the former while including in that proving the verifier of the proof of the latter.
SNARKifying [part of] the Archival State to Drop Chunks of Merkle Paths

zkVM proofs of touched account headers eliminate the need to send Merkle roots for historical balance verification — dramatically reducing the archival state size, which is dominated by Merkle roots.
Delegating Hint Generation

Interactive-hint schemes achieve sublinear server time but impose bandwidth and/or compute overhead on clients during a preprocessing phase. Delegating this via FHE or MPC to servers would unlock sublinear performance for resource-constrained clients — prohibitively expensive today, but an active area of research.

Learn More:

ethresear.ch

Sharded PIR Design for the Ethereum State

Thanks

Sharded PIR Designfor the Ethereum State