Research

PIR Optimizations

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

← Back