Roadmap
PIR schemes tailored to the Ethereum hot state and archival history, allowing users to read chain data from remote servers without revealing what is being queried. The sharded approach optimizes for different data types, contexts of usage, and tolerance to latency.
Now
Q4 2026
PIR Genesis
First end-to-end PIR deployment over live Ethereum state — a sharded system fronted by versioned middleware that routes each RPC call to the right shard, with two inaugural shards on insPIRe / VIA. First demo: end-to-end ETH balance retrieval.
Ongoing
Reproducible benchmarks
Benchmarks of PIR schemes via independent replication of paper-reported setups, and new db/entry/hardware-standardized setups
Next
In progress
Skirrt batch-PIR
In-house double-stateless batch-PIR scheme that retrieves a full Merkle proof in one batched query — >10× lower communication than prior batching. Paper & reference implementation in progress.
Q3 2026
GPU scale-up
Side-by-side GPU benchmarking of VIA, insPIRe and OnionPIRv2 with the SNU SCALE lab (result headed to ICS 2026).
Later
H2 2026
E2E sharded PIR on Ethereum state
Q3 2026
Archival-state snarkification
Technical post on snarkifying archival state to reduce database size, enabling smaller PIR servers -> less PIR overhead.
2027
PIR ↔ statelessness
Exploring PIR served from Ethereum nodes and how that interacts with the statelessness route taken by the protocol.
2027+
Incentivized state serving
Explore micropayments / an incentive layer for state retrieval.
Impact
- Users can read state data without revealing what they queried, all while expressing those queries through the same Ethereum RPC standard.
- Hardens the privacy guarantees provided by other measures (shielding, network-level privacy).
- Provide developers with a unified, stable PIR interface and query/response/preprocessing standards.
⏸ Paused (Q3 2026) following a team change — a mainnet binary-trie node was built in Q2; the workstream is on hold pending re-scoping. Provably L1-equivalent execution-layer node running against a Unified Binary Tree (EIP-7864). PIR servers, wallets, and light clients can begin consuming binary-based state today, ahead of EIP-7864 inclusion in protocol, while relying on equivalence proofs for data validity.
Now
Paused
UBT sidecar on Geth
Geth-based UBT node syncing mainnet. Currently blocked by inefficient binary conversion; upstream optimization are underway.
Paused
UBT on Ethrex
Initial implementation late Q1 via Lambda contribution. Sync stable on Hoodi (Apr 2026).
Paused
MPT equiv. with BALs
Prove BAL-root-hash-containing header a la light client, use said proof as input to the zkVM proof of UBT node, thereby bypassing MPT completely. zkVM (UBT) proves same BAL is applied to the binary trie.
Next
Paused
Shadow chain sync to mainnet
Full mainnet synchronization producing MPT-equivalent state roots per block.
Paused
zkVM proving of UBT transitions
Recursive zkVM proof verification that UBT state updates match MPT updates.
Paused
UBT ↔ PIR integration
Integration enabling PIR services to use provable UBT state without trusting a node operator.
Impact
- Unlocks binary-trie benefits for the PIR usecase ahead of EIP-7864 protocol inclusion.
- Wallets and light clients can begin upgrading to the binary format all while trustless verifying its equivalence to on-chain MPT state.
- Contributes to EIP-7864 testing and benchmarking ahead of its inclusion fork.
Pluggable abstraction over anonymization networks (onion nets, mixnets, or any other). The edge — in-browser wallets, SDKs, light clients — can swap networks without app-layer changes. The architecture and access/validation standard may be extended to accessing P2P networks generally.
Now
In progress
Architecture & anon-RPC standard
Pluggable design for accessing anonymity networks (client-binary validation, signaling/discovery). Public write-up shipped as Power to the Edges; draft anon-RPC standard published, with a live browser demo.
Next
Q3 2026
Architecture publication
Publish access-layer architecture with a community feedback invitation at the engineering monthly.
Q3 2026
Unified WebRTC transport spec
WebRTC transport spec usable across browser and Node.js environments, with standardized WASM-binary validation.
Q3 2026
Pilot deployment
Standard implementation with a pilot deployment exercising the wallet → Tor → EL node pathway end-to-end.
Exploratory
Q3 2026
Lean / formal methods
Lean-based formal verification kicking off July with Leo Alt (Powdr Labs), starting from rustls-rustcrypto primitives and our PIR cores.
Privacy-preserving RPC aggregation
Collaborate with the Protocol State team on state serving & RPC decentralization — an aggregator / reverse-proxy layer with IP-stripping and query-mixing, complementing the anonymity-network access path.
Impact
- Wallets can swap between anonymity networks (Tor, mixnets, others) without code changes.
- Prevents lock-in and switching costs.
- Prevents ISP traffic linkage to Ethereum activity.
- Removes the dependency on centralized RPC providers.
Anonymized RPC for wallets, frontends, and dApps — Arti (Tor's official Rust client) compiled to WebAssembly, running entirely in the browser.
Now
Q3 2026
Wallet / SDK / light-client integrations
Integrating TorJS in-house via PRs — ethers.js as the primary target, then dependent wallets, plus Kohaku / Ambire.
In progress
Upstream to the Tor Project
Merge async / time compatibility fixes back into Arti. WASM-readiness plumbing lands in Arti; the JS wrapper stays external.
Q3 2026
WebRTC transport
Browser-native WebRTC transport, with broader implications for the Abstract Access Layer.
Next
Q3 2026
Broader SDK / light-client rollout
Integrations into ethers.js, viem.js, Helios.
Q3 2026
Messenger protocol survey
Survey of messenger protocols, and in the process integrate onion routing in those that lack it.
Later
Q3 2026critical
External security audit
Third-party audit of the WASM-compiled Arti.
Q3 2026+
Edge-to-P2P transaction broadcasting
Demo/highlights/awareness of the particular usecase of broadcasting transactions from the [constrained] edges directly to Ethereum.
Q3 2026+
PIR-over-Tor bootstrap
Use PIR to privately retrieve Tor directory information at bootstrap.
Hybrid PQ key exchange
Prioritize a hybrid key exchange against store-now-decrypt-later (deferring a full PQ-Arti to the Tor Project roadmap), plus formal verification of rustls-rustcrypto.
Impact
- Users gain onion routing even in constrained environments like browser wallets and frontends — no extensions, plugins, or native binaries required.
- Servers see queries but not the IPs they came from, breaking the link between Ethereum activity and identity.
- Adoption is one npm install away — TorJS slots into existing fetch()-based code with minimal integration work.
Delivered in Q2 2026
TLDR: the quarter converged the workstreams onto concrete artifacts — a double-stateless PIR engine fast enough to serve a larger chunk of the Ethereum hot state, a network-agnostic access-layer design with its first public write-up, and a binary-trie node building against mainnet. (See theMay–June update for the full write-up.)
- insPIRe on GPU (CUDA) — a GPU implementation of our double-stateless PIR workhorse (inspire-gpu):36 ms over a 16 GB database on a single RTX 5090, a ~300–400 KB round trip, and under 2× memory blow-up.Impact: the same GPU serves roughly 4× more data than preprocessed schemes, moving practical PIR over a real slice of hot state within reach.
- Power to the Edges — the first public write-up of the network-agnostic (access layer): the case for a direct browser↔p2p channel, and a design that lets clients plug into any anonymity network (Tor, mixnets, others) through one common interface.Impact: accessibility, privacy, and resilience without depending on a handful of HTTPS gateways.
- KPS — key-pinned streams — a cross-language (Go + Rust) transport underneath the access layer (kps): WebRTC for browsers and QUIC for native behind one API, with an interop test matrix. JS packages live on npm (
@kpstreams/webrtc-client,@kpstreams/quic-client,@kpstreams/server).Impact: the edge can dial p2p nodes directly, pinning a certificate hash instead of relying on the web PKI and domain names. - VIA in Rust — a production-grade reference implementation (via-rs) running VIA-C and batched VIA-B end to end at ≥120-bit security, with the earlier parameterization issue fixed in the open.Impact: a second inaugural PIR scheme, independently reviewed, ready to anchor a PIR shard.
- Multi-agent LLM audit of TorJS / Arti — a “swarm” audit over the TorJS/Arti fork and its upstream crates, run with EF’s Protocol Security team; findings communicated to the Tor Project.Impact: security review at the dependency depth that matters before broader integration.
- tor-js on npm —tor-js split out under the privacy-ethereum org, with 0.3.1–0.3.3shipped to npm in June; upstream Arti kept WASM-ready rather than WASM-specific.Impact: Arti-backed
fetch()is onenpm installaway.
Delivered in Q1 2026
TLDR: correctness-focused reference specs of PIR schemes[1][2]which anchor subsequent production-grade implementation, a PIR systemdesignfor a path towards practical PIR for the entire Ethereum state, and a browser-embeddable[1][2][3]Tor client unlocking onion routing Ethereum user traffic (RPC or otherwise) without configurations or installation.
- Embedded Arti in the browser — Tor's official Rust clientcompiled to WebAssembly and exposed through a
fetch()-compatible API, with IndexedDB persistence, cross-tab locking, and a Brotli-compressed ~3 MB bootstrap bundle that replaces fetching thousands of micro-descriptors. (Technical post,integration docs,fork.)Impact: wallets, frontends, and dApps can route traffic through Tor from inside the browser — no extension, configurations, installations, or system-wide native binary. - Sharded PIR design for the Ethereum state — a blueprint for serving hot state, immutable logs, and archival history through different cryptographic engines, with a sidecar that absorbs real-time updates while the main engine serves stable snapshots. (ethresear.ch post.)Impact: sharding creates a path towards practical PIR for the entire Ethereum hot and archival state; creates a unified interface and shared assumptions about data slicing and update flow that anyone can design towards, reducing friction of integration/upgrading/swapping of schemes.
- Specs and reference impl of select PIR schemes — readable, executable specs forPlinko, RMS24, and VIA (with its VIA-B and VIA-CB variants), prioritizing correctness over performance so they can anchor production implementations downstream.Impact: accelerating implementations of production-grade schemes; validating performance outlook and surfacing bottlenecks (e.g. the intractable iPRF step in Plinko) beyond what the papers present in asymptotic terms.