Applied Cryptography for Privacy in Ethereum

Three parts

Ethereum is an applied-cryptography R&D program

• Cutting-edge R&D has gone, and still goes, into:
  • breaking the trade-off between the three pillars every blockchain must balance: security, decentralization, scalability;
  • hardening the guarantees of permissionless, censorship-resistant access to the protocol, in a privacy-preserving manner.

Three pillars, one tension

The one last problem to solve before the trilemma is fully overcome: incentivised hosting and sharing of partial state, for the future where the Ethereum state becomes extremely large.

TLDR: Ethereum blockchain is: BFT consensus + VM + merklized state and logs.

Proof of stake

• Validators bond ETH (32 minimum) and run a node; misbehavior (equivocation) is slashed: security is economic, not computational.
• Time is divided into 12 s slots; one validator proposes a block, a committee attests; every validator votes once per 32-slot epoch.
• Finality: a ⅔-supermajority checkpoint vote (Casper FFG) makes blocks irreversible unless ≥⅓ of stake is destroyed, a unique balance of safety/liveness [2].
• Feasible only because of signature aggregation: ~1M attestations per epoch compress to a few signatures per block.

Adoption

Example applications

The cryptography running Ethereum today

All non-PQS components must be upgraded away: on the live system, with no maintenance window.

Lean Ethereum: three herculean replacements

Each one: live migration, ~1M participants, zero downtime. The hardest is consensus, where BLS aggregation has no cheap post-quantum analogue: everything reduces to hash functions, plus SNARKs over hashes.

leanVM, and ~$2M of open invitations

• leanVM: a minimal zkVM for SNARK-based signature aggregation, built on WHIR (hash-based proximity proofs) + Poseidon2 over the 31-bit KoalaBear field.
• Leading signature candidate: XMSS, with public key ~52 B (≈BLS-sized) but signatures ~3.1 kB → SNARK aggregation is mandatory, not optional.
• Both performance and safety hinge on SNARK-friendly hashes and on proximity testing for Reed–Solomon codes.

ethresear.ch/t/exploring-the-design-space-for.. PQ key-registry design space

Scaling by verifying, not re-executing

• Today every full node re-executes every transaction: the gas limit is bounded by the slowest acceptable node.
• zkVMs change the model: the block builder proves the block's execution with a SNARK; everyone else verifies it and accepts the block without having to re-execute.
• ethproofs.org tracks the race: independent zkVM teams proving real mainnet blocks: currently ~94% of tracked proofs land in ≤10 s, at ~$0.01–0.03 per block proof.
• Target: real-time proving, the proof ready within the 12 s slot, which raises the gas limit and lets phones verify full blocks; the roadmap ends at enshrined L1 proofs.

ethproofs.org

The privacy R&D map

I will zoom into the first two.

Everything on Ethereum is public by default

• Everything on-chain is public, forever: balances, transfers, votes, names, counterparties; by design, that is what makes it verifiable.
• And trustless access requires a full node (>1 TB NVMe, days to sync), so almost everyone reads the chain through someone else's server.
• So even reading public data leaks your assets, affiliations, and counterparties from query patterns alone; no cryptography is broken.

Transparency is the feature. Surveillance is the side-effect.

Two surfaces of privacy leakage

Privacy leakage from reads: a curious or malicious server can profile you just by tracking what you read, undermining privacy measures you worked hard to follow elsewhere. Shielding your transactions doesn't help if the read pattern alone tells the same story.

ethereum-magicians.org/t/a-maximally-simple.. Privacy Roadmap

• Already standard: stealth addresses, via ERC-5564 (final) + ERC-6538 registry: non-interactive one-time addresses with view tags.
• Censorship-resistance as a complement: FOCIL (EIP-7805, draft) inclusion lists guarantee privacy transactions can't be quietly excluded.
• Privacy has become a major priority for the Ethereum Foundation and the ecosystem at large.

The access layer: privacy of traffic and query contents from remote state providers

• Provider learns: your IP, all your addresses in one breath (linkage), the assets and dapps you care about, and when you check them.
• Concentration makes it worse: most wallet traffic defaults to a handful of providers.

This layer is where my team (Private Reads, EF) works.

TorJS: network-level privacy where wallets live

• Wallets are browser extensions and web apps; they can't ship a Tor daemon. TorJS brings a Tor client into the JS/browser environment, so RPC traffic can be onion-routed from inside the wallet.
• What it fixes: the IP → identity link. The provider no longer knows where the query came from.
• What it cannot fix: the query content: addresses inside the query still link to each other and profile the (now pseudonymous) user.

Anonymous transport is necessary but not sufficient: content-level protection needs PIR.

privreads.ethereum.foundation/docs/torjs TorJS docs

An abstract access layer: anon-rpc

• Today each wallet hard-wires its own provider integrations; privacy tech would need to be re-integrated wallet by wallet.
• anon-rpc: a common abstraction over how clients reach chain data, so transports (Tor, mixnets) and query protections (PIR) slot in beneath every wallet at once.
• Goal: make the private path the default path, not a power-user opt-in.

ongoing work

privreads.ethereum.foundation/feed/anon-rpc anon-rpc design post

Private Information Retrieval

The taxonomy, against Ethereum's constraints

github.com/0xalizk/PIR-Eng-Notes

Sharded PIR for the Ethereum state

Observer's view = monolithic PIR over the whole state. Performance = per-slice optimized: the genuine answer arrives at the small slice's latency, not the monolith's.

Decoys are real queries: each engine sees a uniform access either way. Subtleties (timing side-channels → wait-for-all / m-of-k; all-data-or-nothing coverage).

Doubly-stateless PIR, tailored to GPUs

• Doubly-stateless: no per-client state on the server and no client-side hint for updates to invalidate: any client queries cold; the 12 s mutation costs nothing per client.
• Why insist on it: users query the state from all sorts of contexts (wallets, dApps, a website they are just passing through), so statelessness makes the PIR solution applicable to everyone, requiring no a priori storage or preprocessing on their part.
• InsPIRe (current focus):
  • single-server lattice PIR with silent preprocessing (server-side only, no hint download)
  • vs. YPIR: ~50% smaller queries, 5× smaller keys, up to 25% more throughput
    • ~36 ms latency per query, 390 KB communication, ~6.5 s setup, on a 16 GB DB
• The price is raw server compute, a memory-bandwidth-bound linear scan, shaped for GPUs: our GPU port of InsPIRe is underway, with promising early numbers.

The paper's benchmarks are CPU; the GPU figures are our own in-progress, unpublished work.

Open problems

• Doubly-efficient PIR: drive online server work sublinear, touch strictly fewer bits than the database per query, with communication below the database size, so answering beats just downloading the state. Today this needs heavy preprocessing or non-standard assumptions.
• Hint delegation under a frequently mutating database: client-stateful schemes precompute a hint that a 12 s state change can invalidate; cheap incremental repair, or delegating the preprocessing itself (FHE-based, round-optimal, cf. ThorPIR), is barely explored.
• Hardware acceleration: doubly-stateless lattice PIR is a memory-bandwidth-bound linear scan; GPU/FPGA is the lever (current GPU state of the art: GPIR, 2026). The bar is hundreds of GB at thousands of queries per second, sub-100 ms.
• Provable security & batching: 128-bit security under standard assumptions, not heuristics; plus many-client batching and anonymity-set-aware sharding.

A PIR solution for the entire Ethereum state (300 GB+ hot, 2 TB+ archival) would be the largest demonstration of PIR to date. The few existing PIR deployments serve comparatively tiny databases.

Using a PIR-friendlier state trie

Scale to serve: ~10⁸ accounts, ~10⁹ storage slots, 300 GB+ hot state, mutating every 12 s, orders of magnitude beyond most PIR benchmarks.

$\forall\,(k,v):\ (k,v)\in\mathrm{MPT}\iff(k,v)\in\mathrm{UBT}$

• The PIR backend can serve the UBT (flat, index-addressable, one SNARK-friendly hash) while mainnet keeps the MPT.
• A per-block zk proof binds the two roots to the same state, so private reads get the PIR-friendly structure before it ships on-chain.
• It pays off: a read under PIR costs ~48× on the MPT versus ~9× on the binary tree (our analysis).

privreads.ethereum.foundation/workstreams/ubt/

EIP-7864 is draft, not scheduled; the hash choice is open (BLAKE3 in the current draft; Poseidon2 and Keccak candidates). A geth binary-trie prototype today is ~1.7× slower on reads and ~2.5× on writes than the MPT (CPerezz benchmarks), optimization ongoing. Verkle, its EC-based predecessor, was de-prioritized largely for post-quantum reasons.

Summary of open problems in Ethereum R&D generally

Questions, and pointers

privreads.ethereum.foundation the team

ethresear.ch Ethereum Research

ethereum-magicians.org Technical Forum