# EF Priva Reads October Update

## Key Highlights

- Started 30+ collaboration groups with various projects inside and outside the Ethereum ecosystem, with **activated** collabs including: **`Tor Project`**, **`Lunascape browser`**, **`dRPC`**, **`Hinkal wallet`**, **`Envio indexer`**, **`cp0x decentralized frontends`**, **`Metri wallet`**, **`EF Stateless `**, **`Blockscout explorer`**, **`Acurast TEE`**.
- [Driving adoption](https://igor53627.github.io/tor-ethereum-ecosystem) of onion routing in the Ethereum ecosystem through internal implementations and external collabs: RPC providers, client nodes, wallets, indexers, block explorers, [decentralized] frontends, load balancers, and SDKs
- **dRPC collab**: [the first](https://drpc.org/docs/tor) infrastructure RPC provider to expose onion services into their [NodeCore load balancer](https://github.com/drpcorg/nodecore/blob/main/docs/nodecore/07-tor-setup.md) -**without API key, and with support for [uptream Tor services](https://github.com/drpcorg/nodecore/blob/main/docs/nodecore/05-upstream-config.md#tor-onion-upstreams)** such that .onion addresses are accessible from within their infra
- Collab agreement with Tor Project team: technical support for our [onionization efforts](https://hackmd.io/@alizk/H1ibTt70xx) in 4Q25 1Q26, embedded [Arti](https://tpo.pages.torproject.net/core/arti/) mid-term (1H26) in browser environment
- Blockscout collab: the [explorer](https://eth.blockscout.com) is now accessible via [.onion address](http://jcevta2iwkmce7dkytj2hbhr3qm7eidnbqkotpe2jfx7ldp45dyaehad.onion/)
- Hinkal collab: completed integration of Tor routing of transactions from Hinkal wallet to .onion RPC node
- Proposed a design for proving UBT-based state of L1 and kicked off collaboration with Geth/EF Stateless on provable UBT<>MPT equivalence. Intended for indexers and light clients: smaller UBT roots are advantageous for db-size-sensitive PIR and bandwidth/overhead-sensitive light clients
- [Geth/Reth instances behind .onion service](https://github.com/CPerezz/torpc/pull/2#issuecomment-3491141977), handling `eth_sendRawTx` originating locally (forward to Tor network) or received from behind .onion service (forward to ethp2p), building to Torpc by Carlos
- Spun up and [Nodejs-tested](https://voltrevo.github.io/tor-hazae41/) Snowflake Tor proxy instance for websocket-based access to Tor from wallets/frontends
- Integrate Echalot Tor lib into Viem.js, with Metri wallet being the first willing adopter
- [Investi](https://hackmd.io/@alizk/BJwFha2agl)gated [PIR](https://hackmd.io/@keewoolee/Skvu0BDRle) (private information retrieval) schemes and began early experimentation
- Contributed to Kohaku on [Helios](https://github.com/ethereum/kohaku-commons/pull/19) and provided support and follow-up on [TEE-ORAM](https://hackmd.io/@tkmct/BywaGeY2le) integration
- Drafted 2 RFPs for submission through the new Grant Management process: mixnet benchmarcking, CAP'Z'CHA (a zkID-based alternative to CAPCHA)
- Submitted 2x talks to Devconnect events and organized IRL meetups with potential collaborators on mixnets

## Top 1–3 Priorities for Next Month

1. Unblock onion address support in Echalot lib and get more wallets, infrastructure providers, and community full-node runners to adopt onion routing
2. Push 1-2 additional privacy-preserving indexing solutions to production
3. Implement provable UBT <> MPT equivalence and serve UBT-based reads to indexers, light clients

## Updates and Progress

### Onionization

- Edge `wallet`
- [Started working](https://github.com/voltrevo/echalote) on adding onion address support to Echalot as top priority
- Integrated Echalot Tor lib [into Viemjs](https://github.com/voltrevo/viem) (without .onion support for now). All wallets using it can then plug into Tor, starting with Metri wallet.
- Started collab with Lunascape Browser to add Tor support for `eth_sendRawTx` to their wallet as a start, currently blocked on our side by missing .onion support in Echalot lib. Meeting up with them at Devconnect.
- [Tested Echalot](https://voltrevo.github.io/tor-hazae41/) lib integration [from Node.js](https://github.com/voltrevo/tor-hazae41) through our Snowflake proxy. Cold start expected to initialize circuit building.
- Actively reaching out to other wallet SDKs to add native Tor support, such that all wallets/frontends can plug into it (websocket) with minimal change
- Working groups with wallets to integrate Tor for `eth_sendRawTx` RPC calls as a start: Hinkal, Brume, Ambire, Lunascape wallet, Metri
- Middle `proxy`:
- Spun up and [Nodejs-tested](https://voltrevo.github.io/tor-hazae41/) Snowflake proxy and tested routing through it, higher latency for the initial message but reduces in subsequent ones (circuit reuse)
- [Infra](https://igor53627.github.io/onion-service-monitor/) `RPC node`
- Spun Geth/Reth instance [co-located with Tor client and exposing .onion addresses](https://github.com/CPerezz/torpc/pull/2#issuecomment-3491141977). Transactions received through Tor are forwarded to ethp2p, while those received from localhost are forwarded to Tor network. Building on Torpc By Carlso.
- Worked with Blockscout [explorer](https://eth.blockscout.com) to provide a [.onion address](http://jcevta2iwkmce7dkytj2hbhr3qm7eidnbqkotpe2jfx7ldp45dyaehad.onion/)
- Worked with dRPC to provide .onion RPC endpoint via their load balancer (NodeCore) without requiring API keys
- Worked with cp0x to [support](https://github.com/cp0x-org/tornado-onion) TC onion frontend, more frontends to follow

- **Status**
- Edge: onion address support in Echalot ETA early Dec
- Middle: Snowflake instance in production
- Destination: dRPC and other community-run RPC providers now provide .onion RPC without API key, more infra and community partners are onboarding
- **Next**
- Edge: continue working on onion support for Echalot, continue seeking collab with wallet SDKs for integrations
- Middle: no further work required, long term other obfuscators besides Snowflake may be explored if a need arises
- Destination: continue hardening Geth/Reth<>Tor onion service; continue working with more RPC providers to provide onion RPC endpoints ideally without API keys
- **_Why it matters_**
- _To remove the link between Ethereum users' IP and internet trails, which are assumed to be unprotected, from their on-chain holdings and activities._

### Indexing

- Privacy-preserving [indexing solution started](https://docs.fileverse.io/0x203d13dBCDd56F880FFCa17EF9eBa18e0dE2bf91/1#key=TIz7vdYj3WIVT5aJpoKNIrwf9rEXke_GmMiIpt9dM6d6Ec6VcYVLnisoPYaKaMN9) with Metri (wallet), Envio (indexer), Acurast (TEE), our contribution being TLS-TEE authentication and wallet integration
- [Explored](https://hackmd.io/zNvSA68nQ72JgNUZ2XlP_g?view) PIR [schemes](https://hackmd.io/bctSz8FJRNmPe7MAVvhHQg) and [sketched](https://hackmd.io/59ZN_vEETO2oFbzRmtMv1g) designs to ensure privacy of query _and_ integrity of the response by integrating real-time zkVM proving and TEE-hosted indexing
- [Collab](https://hackmd.io/@alizk/Hkq1--L1-l) with Guilluame+ kicked off to maintain UBT-based Ethereum state [provably equivalent](https://hackmd.io/g8NWQNfsTsqhKqx5vF5ylA?view) to canonical MPT state, which reduces the indexing db size thereby minimizing the overhead for PIR
- **Status**:
- One active TEE-based indexing solution
- PIR-based indexing being explored hands-on
- **Next**:
- Activate more indexing solutions with wallet(s)<>indexer<>{TEE, PIR[<> zkVM]}
- Talk with more wallets on the types of indexing they typically need
- **_Why it matters_**
- _Privacy of reading Ethereum state is core to our mission, as that data leaks so much about users' holdings and intents, which leads to a host of exploitative and outright malicious targeting by various actors_

### Kohaku support

- Submitted a [major PR](https://github.com/ethereum/kohaku-commons/pull/19) for Helios integration into Kohaku
- Aligned over 3 syncs with Kohaku and Oblivious Labs on our support forward being the [hardening](https://www.npmjs.com/package/securitee) and technical advice on [wallet <> TEE-ORAM](https://hackmd.io/@tkmct/BywaGeY2le) connection, complementing the [work by the Helios](https://docs.fileverse.io/0xa059a9410518446f45218921144F188CBCa0ED98/0#key=FzJwfKE1vl0AcLZ7IW2PP1jcnAPiWRK0tC2_NQqfkHZIu_iPtlJQakfzKaTQ5_k_) team
- Started the initiative of provable UBT<>MPT equivalence which can be integrated by Helios minimizing the size and overhead of root verification
- **Status**:
- Waiting on Oblivious Labs to deliver the final solution for us to validate and help integrate into Kohaku by supporting Helio's devs
-
- **Next**:
- Start provable UBT<>MPT implementation. More syncs with Geth/Stateless of provable UBT<>MPT equivelance, IRL meeting in Devconnect
- Support Kohaku/Oblivious Labs/Helios when needed

### Mixnet

- Considered and rejected a proposal for mixnet benchmarking in a sandboxed network with synthetic data
- Planning Devconnect meeting with relevant mixnet folks in the ecosystem
- Delegated entry [[1]](https://hackmd.io/FdBGeWv9TBm5M1yDNVbQGQ?view) [[2]](https://hackmd.io/N3nZAuSbQkmxOvDJS07XFA) via FHE: users delegate the work that would have had to be done client side to send messages through a mixnet to an FHE server
- **Status**:
- Still researching the delegated FHE entry, digging into Sphinx
- Drafting an RFP for mixnet benchmarking to submit through the new Grant Management process
- **Next**:
- Devconnect mixnet meetup
- Review proposals for mixnet benchmarking
- **_Why it matters_**:
- _Many users and infrastructure providers prefer not to route general traffic. Creating an Ethereum-traffic-only mixnet alternative to Tor creates an additional option for privacy. Arguably the mixnet protocol (Sphinx) provides better privacy given the embedded random delays per packet and dummy traffic_