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
Q2 2026
insPIRe on GPU
The largest DB that can be served assuming 16 GPUs and 1k QPS.
Q2 2026
Balance-retrieval demo
End-to-end demo of ETH balance retrieval over insPIRe.
Ongoing
Reproducible benchmarks
Benchmarks of PIR schemes via independent replication of paper-reported setups, and new db/entry/hardware-standardized setups
Next
Q2 2026
Sharded PIR design
Flesh out the multi-engine sharded architecture & middleware with >=2 inaugural schemes.
Q2 2026
VIA in Rust
Port VIA from Pythonic specs (Q1 grant) to a production-grade Rust implementation.
Q2–Q3 2026
GPU scale-up
Benchmark other leading PIR candidates with no or minimal client-side state — OnionPIRv2, VIA, [unpublished].
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.
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.
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
Blocked
UBT sidecar on Geth
Geth-based UBT node syncing mainnet. Currently blocked by inefficient binary conversion; upstream optimization are underway.
In progress
UBT on Ethrex
Initial implementation late Q1 via Lambda contribution. Sync stable on Hoodi (Apr 2026).
Q2 2026
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
Q2 2026 critical
Shadow chain sync to mainnet
Full mainnet synchronization producing MPT-equivalent state roots per block.
Q3 2026
zkVM proving of UBT transitions
Recursive zkVM proof verification that UBT state updates match MPT updates.
Contingent
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 sketch
Foundational design for abstracted access to anonymization networks, including client-binary validation and signaling/discovery protocols.
In progress
WebRTC transport kit
Foundational transport for the access layer — connectivity from the edge (browsers, wallets) to a range of infrastructure: PIR servers, anonymity-network nodes, and Ethereum p2p nodes.
Next
Q2 2026
Architecture publication
Publish access-layer architecture with a community feedback invitation at the engineering monthly.
Q2 2026
Unified WebRTC transport spec
WebRTC transport spec usable across browser and Node.js environments, with standardized WASM-binary validation.
Q2 2026
Pilot deployment
Standard implementation with a pilot deployment exercising the wallet → Tor → EL node pathway end-to-end.
Exploratory
Lean / formal methods
Lean and formal-methods integration for critical access-layer components (starting with eg RustCrypto lib); verified builds for privacy primitives.
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.
Arti — Tor's official Rust client — compiled to WebAssembly. Anonymized RPC from wallets, frontends, and dApps, running entirely in the browser.
Now
Shipped
tor-js on npm
Published as
tor-js; npm install tor-js wires Arti-backed fetch() into any browser or Node.js project. Q2 2026
Wallet / SDK / light-client integrations
Unlock onion routing in edge contexts via TorJS integrations
Q2 2026
Upstream to the Tor Project
Merge async / time compatibility fixes back into Arti. WASM-readiness plumbing lands in Arti; the JS wrapper stays external.
Q2 2026
WebRTC transport
Browser-native WebRTC transport, with broader implications for the Abstract Access Layer.
Next
Q2 2026
Internal LLM-based security audit
Internal audit of the WASM-compiled Arti.
Q2 2026
Broader SDK / light-client rollout
Integrations into ethers.js, viem.js, Helios.
Q2–Q3 2026
Messenger protocol survey
Survey of messenger protocols and a in the process integrate onion routing in those that lack it.
Later
Q3 2026 critical
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.
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 Q1 2026
TLDR: correctness-focused reference specs of PIR schemes [1] [2] which anchor subsequent production-grade implementation, a PIR system design for 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 client
compiled 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 for Plinko, 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.