I love that more research is going into RPC-level privacy. It is an under-researched, under-appreciated part of Ethereum privacy that deserves a solution. Unfortunately, rotating RPCs isn't that solution, at least in the form described here. Here's why 🧵

𝗣𝗿𝗼𝗯𝗹𝗲𝗺 𝟭: No provider should be able to associate your Ethereum address with your IP address. 𝗣𝗿𝗼𝗯𝗹𝗲𝗺 𝟮: No provider should be able to associate two of your Ethereum addresses with one another. Particularly important in the context of stealth addresses.

The first solution proposed solves neither problem. In fact, it makes problem 1 𝙬𝙤𝙧𝙨𝙚: instead of one provider that knows your IP and Ethereum addresses, now 𝙢𝙪𝙡𝙩𝙞𝙥𝙡𝙚 such providers know them both.

The second solution solves problem 1 by introducing a middleware in a TEE. It is essentially a blind proxy, for which blindness is provided by the TEE. But problem 2 remains unsolved: Providers can still associate your Ethereum addresses with one another.

TEEs are not bulletproof. But even if we assume they work as intended, the client still needs to verify that the middleware they are talking to is actually running in a TEE at all. Otherwise, the client (wallet) can't be sure the middleware isn't actually logging everything.

The client can verify this by performing a workload attestation dance. It is possible, but complicated to implement. I have not seen a real implementation of this in practice, and it's not clear to me if that would be easier to implement than just integrating an actual mixnet.

A proxy should be blind to what it passes through. Cryptography solves this without the need for TEE trust assumptions. Mixnets such as Tor/Nym/HOPR work this way: Encrypt the payload in multiple layers of encryption, where each hop peels one layer of encryption off the onion.

Why aren't mixnets used today? - Users don't ask for RPC-level privacy out of their wallet developers. Walletbeat fixes this. - <100ms RPCs UX expectations. Mixnets/middleware add latency. - Integration in browser wallets requires reimplementing TLS in JS to encrypt the last hop.

Mixnets alone also don't solve problem 2. The problem remains that rotating RPCs naively (random provider on each request) is actually 𝙬𝙤𝙧𝙨𝙚 for privacy: it means multiple providers get a view of multiple of your addresses over time.

Better solution: for an RPC about `address`, always send it to provider #`hash(address) modulo num_providers`. In other words, queries about the same address go to the same RPC provider. This ensures no provider learns your full set of addresses.

It is also better to have more providers than you have addresses. This way, each provider learns either one of your addresses, or none; never multiple. But the real fix? - Run your own node! - Ask your wallet developer to start caring about RPC-level privacy.

Things I didn't cover but also matter: - RPC timing correlation attacks. - Wallets looking up multiple addresses' balance in a single RPC. - Non-Ethereum requests that leak similar data. Today's wallets are full of those; ask me how I know. - L2s with centralized endpoints. (lol)

Even if this thread appears critical of @jimouris's work, I want to emphasize that it is not intended as a dunk. I highly respect anyone who actually steps up to tackle this problem. This is under-researched and needs more attention, so it's heartening to see folks working on it.