Mi piace che ci sia più ricerca sulla privacy a livello RPC. È una parte di privacy di Ethereum poco studiata e poco apprezzata che merita una soluzione. Sfortunatamente, ruotare gli RPC non è quella soluzione, almeno nella forma descritta qui. Ecco perché 🧵

𝗣𝗿𝗼𝗯𝗹𝗲𝗺 𝟭: Nessun fornitore dovrebbe essere in grado di associare il tuo indirizzo Ethereum con il tuo indirizzo IP. 𝗣𝗿𝗼𝗯𝗹𝗲𝗺 𝟮: Nessun fornitore dovrebbe essere in grado di associare due dei tuoi indirizzi Ethereum tra loro. Particolarmente importante nel contesto degli indirizzi stealth.

La prima soluzione proposta non risolve nessuno dei problemi. Infatti, rende il problema 1 𝙬𝙤𝙧𝙨𝙚: invece di un fornitore che conosce il tuo IP e gli indirizzi Ethereum, ora 𝙢𝙪𝙡𝙩𝙞𝙥𝙡𝙚 di questi fornitori li conoscono entrambi.

La seconda soluzione risolve il problema 1 introducendo un middleware in un TEE. È essenzialmente un proxy cieco, per il quale la cecità è fornita dal TEE. Ma il problema 2 rimane irrisolto: i fornitori possono ancora associare i tuoi indirizzi Ethereum tra loro.

Le TEE non sono a prova di proiettile. Ma anche se assumiamo che funzionino come previsto, il cliente deve comunque verificare che il middleware con cui sta comunicando stia effettivamente girando in un TEE. Altrimenti, il cliente (portafoglio) non può essere sicuro che il middleware non stia effettivamente registrando tutto.

Il cliente può verificare questo eseguendo una danza di attestazione del carico di lavoro. È possibile, ma complicato da implementare. Non ho visto una vera implementazione di questo in pratica, e non mi è chiaro se sarebbe più facile da implementare rispetto a integrare un mixnet reale.

Un proxy dovrebbe essere cieco a ciò che trasmette. La crittografia risolve questo senza la necessità di assunzioni di fiducia TEE. I mixnet come Tor/Nym/HOPR funzionano in questo modo: crittografano il payload in più strati di crittografia, dove ogni salto rimuove uno strato di crittografia dalla cipolla.

Perché i mixnet non sono utilizzati oggi? - Gli utenti non richiedono la privacy a livello RPC dai loro sviluppatori di wallet. Walletbeat risolve questo. - Aspettative UX per RPC <100ms. I mixnet/middleware aggiungono latenza. - L'integrazione nei wallet del browser richiede la reimplementazione di TLS in JS per crittografare l'ultimo hop.

I mixnet da soli non risolvono nemmeno il problema 2. Il problema rimane che ruotare gli RPC in modo naif (fornitore casuale per ogni richiesta) è in realtà 𝙬𝙤𝙧𝙨𝙚 per la privacy: significa che più fornitori ottengono una visione di più dei tuoi indirizzi nel tempo.

Soluzione migliore: per un RPC riguardo `address`, invialo sempre al provider #`hash(address) modulo num_providers`. In altre parole, le query riguardanti lo stesso indirizzo vanno allo stesso provider RPC. Questo assicura che nessun provider apprenda il tuo insieme completo di indirizzi.

È anche meglio avere più fornitori di quanti indirizzi tu abbia. In questo modo, ogni fornitore apprende uno dei tuoi indirizzi, o nessuno; mai più di uno. Ma la vera soluzione? - Esegui il tuo nodo! - Chiedi al tuo sviluppatore di wallet di iniziare a preoccuparsi della privacy a livello RPC.

Cose che non ho trattato ma che contano: - Attacchi di correlazione temporale RPC. - Wallet che controllano il saldo di più indirizzi in un singolo RPC. - Richieste non Ethereum che rilasciano dati simili. I wallet di oggi ne sono pieni; chiedimi come lo so. - L2 con endpoint centralizzati. (lol)

Anche se questo thread sembra critico nei confronti del lavoro di @jimouris, voglio sottolineare che non è inteso come una critica. Rispetto molto chiunque si faccia avanti per affrontare questo problema. È poco studiato e ha bisogno di maggiore attenzione, quindi è incoraggiante vedere persone che ci lavorano.