Thanks for writing both of these up, @Brechy. As Ethereum Privacy Of Reads splits private reads into two problems, hiding who is asking and hiding what they ask for. That split is exactly how we have been building offchain privacy stack for the last several months: Raven on the query side, Nox on the network side.
Today every state read leaks. A wallet that calls eth_getBalance, eth_getStorageAt, or eth_call hands the provider both the address or slot it wants and the IP it is asking from. Shielded protocols/stealth payments/ID protocols are the sharpest case. In Railgun, Privacy Pools, Tornado, Semaphore, or Zcash you prove membership in a Merkle tree without revealing your own leaf, but to build that proof the wallet first fetches the sibling hashes along its path, and it fetches them from an RPC provider. The provider sees the commitment being pulled and the IP pulling it, and links the two. The proof hides what you did; the read that fed it tells the provider which note is yours. So @drllau is right that this is a public ledger, and that is not the part in dispute. The data was always public. What leaks is the access pattern over it: which address or slot a user reads, how often, and from where.
The two limitations you flag for PIR, server cost and scaling to a large database. The harder problem for Ethereum is that state changes every block, while PIR wants a fixed, preprocessed snapshot to answer against. We handle this with the main-and-sidecar design from the Sharded PIR Design post by Ali Atiia and Keewoo Lee. A large main engine is preprocessed at a snapshot and re-preprocessed lazily in the background. A small sidecar absorbs the writes that land after the snapshot, and every few thousand blocks the sidecar
folds into the main and resets. The client queries both engines at once and reads both answers back, which closes the timing channel that would otherwise reveal whether a record had just changed. The engine underneath is InsPIRe. It is hintless, so the client never downloads a large per-database hint, and it keeps no per-client state, so nothing on the server links one query from a wallet to the next. Its update cost scales with the number of changed shards rather than with the size of the whole database, which is what lets the snapshot move forward without rebuilding everything every block.
The PIR post notes that the missing piece is a production client that runs in a browser. We have built that. It is a gzipped WebAssembly client with a TypeScript SDK, plus a committed end-to-end demo where a wallet reads eth_getBalance for an address while the serving node never learns which address it read. The code is Apache-2.0 and deliberately generic. InsPIRe and a second scheme, iSimplePIR (eprint 2026/030), are both in the tree,
so the framework is not tied to one construction and can take on others as they mature.
The third limitation, IP-based tracking, sits on the network side, which is where Nox comes in. Your overview proposes Tor for that step. We think a mixnet is the better fit. Tor is an onion router, not a mixnet: it forwards packets immediately to keep latency low, and that forwarding preserves the timing pattern that ties a sender to a transaction. The correlation is not hypothetical. DeepCorr deanonymized low-latency onion routing at around 96% accuracy,
and the more recent RECTor showed the attack still holds under noise. Nox is a Multi-hop Sphinx mixnet for EVM networks that adds what Tor leaves out: each hop holds a packet for a delay drawn from an exponential distribution, every packet is the same fixed size on the wire, and the network runs cover traffic so there is no quiet window to correlate against. Nox already carries reads, not only transactions. A balance check, a log query, or a contract call sent through Nox reaches the provider from the exit node, so the provider never sees your address or your IP, and because reads do not change state, they leave no
on-chain trace. Raven hides what is being asked. Nox hides who is asking and from where. Nox And Raven is live.
We agree that rotating RPCs is the right first move. It ships today and needs no new cryptography. We would frame PIR as the far end of the same road rather than a separate track, since rotating providers, in your words, only makes deanonymization slightly harder, while PIR removes the query-content leak instead of spreading it across more parties. The same reasoning applies to the Tor step, where a mixnet is where that line lands.
The repo, the demo, and the sidecar design are linked above. We are happy to go deeper on any of it, or to compare notes with whatever working group forms around this.
Read more about Hisoka, Nox and Raven here:
