Pitch

A mixnet tailored and sandboxed for Ethereum RPC traffic amongst the edges (wallets, frontends, dApps), Ethereum p2p nodes, and infrastructure service providers brings the anonymity benefits without the drawbacks and caveats of general-traffic anonymization networks.

Abstract

Network-level privacy is fundamental ingredient and a pre-requisite to the efficacy of other privacy tooling and practices for Ethereum users. Running an anonymized routing client to blanket-protect all device traffic comes with challenges such as censoring of exit-node traffic by some service providers, and slower speed which affects the UX of some user applications. Some service providers, such as full node runners or RPC providers, may be obligated by local laws to not participate in relaying general anonymized traffic.

To bring network-level privacy to Ethereum-specific traffic irrespective of these obstacles, we need tailored solutions that users simply opt-in with a toggle-like UI elements in edge contexts: frontends, wallets, and dApps. The infrastructure that support the edges include full nodes (which can themselves be edges when used by co-locating wallets and dApps by Ethereum power users for example), pluggable-transport bridges that allow edges in constrained environments (like the browser) to communicate with the onion or mixing network despite blocked access to their device’s network sockets, and infrastructure providers such as RPC-as-a-service nodes and MEV-protection relayers.

The goal is to develop an anonymized routing we need client-side, bridge, and server-side components to facilitate the routing of Ethereum RPC traffic at the edges and infrastructure.

Onionization vs. Mixing

Both onion routing and mixing rely on origin-encrypted hops of communication that break the link not only between users and endpoints, but also among the hops along the route except the immediate links on the path. Mixing protocols introduced two extra ingredients albeit with potentially higher latency: decoy traffic and random delays. On the other hand onionized routing has been battle-tested much longer and optimized thanks to Tor Project which has been serving millions of users.

Because of the tailored nature of the traffic, the healthy size of Ethereum network, and the aforementioned extra privacy features of mixing, we expect the latency of an Ethereum mixnet to be acceptable.

Expected deliverables

The deliverables are expected to provide more details on the following points:

  1. A design to enforce rate-limiting
  2. A design to enforce Ethereum-RPC-traffic-only
  3. Discv5 specs of the mixing service
  4. Implementation of mix-node as a sidecar into at least one EL node
  5. Implementation of mix-client as a wasm binary
  6. Integration of mix-client into a wallet SDK
  7. Pluggable-transport bridge between a mix-client and an entry node

Received deliverables

The following deliverables were made available in support of this ROP: