Sharded PIR Design for the Ethereum State

Privacy
,
4

That framing makes sense — for Ethereum, privacy is about the query, not the data.

SPIR solves a problem that doesn’t really exist here. The chain is already public, so hiding the database from the client isn’t necessary. What does matter is preventing the server (or RPC provider) from learning which address you’re querying.

That’s exactly where keyword PIR becomes the right abstraction.

Instead of:

  • index → value

you get:

  • address (key) → balance / state

And as you pointed out, the key advantage is that performance scales with database size, not the key space — which is critical when “possible addresses” are effectively unbounded.

The cuckoo hashing transformation is also a practical bridge. It lets you map:

key → deterministic index

so standard PIR schemes can still be used under the hood while preserving the developer-friendly “query by address” interface.

Why This Matters in Practice

Today’s typical flow:

  • User queries RPC

  • RPC sees the address

  • RPC can profile behavior over time

With PIR:

  • Query remains private

  • Server returns the correct state

  • No leakage of which address was accessed

This becomes increasingly important as more systems rely on:

  • wallet-level analytics

  • behavioral tracking

  • MEV-related inference

Broader Implication

What you’re describing is essentially decoupling data availability from access privacy:

  • Data stays public

  • Access patterns become private

That’s a powerful shift.

It aligns with a broader trend in Ethereum design:

  • public state

  • private intent

  • verifiable execution

You see similar ideas emerging across the stack — minimizing trust in intermediaries while preserving transparency. Even outside core infra, systems like Maticslot follow that philosophy at the application layer: direct on-chain execution with no internal balance abstraction, so state is public and verifiable, while interaction happens directly from the wallet.

Takeaway

Keyword PIR fits Ethereum naturally because:

  • users think in addresses, not indices

  • privacy concern is who queries what, not what exists

  • scalability depends on state size, not key space

SPIR solves the wrong problem here.
PIR — specifically keyword PIR — solves the right one.

1 Like