Jeg elsker at mer forskning går inn på personvern på RPC-nivå. Det er en lite undersøkt, undervurdert del av Ethereums personvern som fortjener en løsning. Dessverre er ikke roterende RPC-er den løsningen, i hvert fall ikke i den formen som er beskrevet her. Her er grunnen 🧵

Problem 1: Ingen leverandør skal kunne knytte Ethereum-adressen din til IP-adressen din. Problem 2: Ingen leverandør skal kunne knytte to av Ethereum-adressene dine til hverandre. Spesielt viktig i sammenheng med stealth-adresser.

Den første løsningen som foreslås løser ingen av problemene. Faktisk gjør det problem 1 verre: i stedet for én leverandør som kjenner IP- og Ethereum-adressene dine, kjenner nå flere slike leverandører dem begge.

Den andre løsningen løser problem 1 ved å introdusere en mellomvare i en TEE. Det er i hovedsak en blind proxy, som blindhet er gitt av TEE. Men problem 2 forblir uløst: Leverandører kan fortsatt knytte Ethereum-adressene dine til hverandre.

TEE-er er ikke skuddsikre. Men selv om vi antar at de fungerer etter hensikten, må klienten fortsatt bekrefte at mellomvaren de snakker med faktisk kjører i en TEE i det hele tatt. Ellers kan ikke klienten (lommeboken) være sikker på at mellomvaren faktisk ikke logger alt.

Klienten kan bekrefte dette ved å utføre en arbeidsmengdeattesteringsdans. Det er mulig, men komplisert å implementere. Jeg har ikke sett en reell implementering av dette i praksis, og det er ikke klart for meg om det ville være lettere å implementere enn bare å integrere et faktisk mixnet.

En proxy bør være blind for hva den passerer gjennom. Kryptografi løser dette uten behov for TEE-tillitsforutsetninger. Mixnets som Tor/Nym/HOPR fungerer på denne måten: Krypter nyttelasten i flere lag med kryptering, der hvert hopp skreller ett lag med kryptering av løken.

Hvorfor brukes ikke mixnets i dag? - Brukere ber ikke om personvern på RPC-nivå fra lommebokutviklerne sine. Walletbeat fikser dette. - < 100 ms RPC-er UX-forventninger. Mixnets/mellomvare legger til ventetid. - Integrering i nettleserlommebøker krever reimplementering av TLS i JS for å kryptere det siste hoppet.

Mixnets alene løser heller ikke problem 2. Problemet er fortsatt at roterende RPC-er naivt (tilfeldig leverandør på hver forespørsel) faktisk er verre for personvernet: det betyr at flere leverandører får oversikt over flere av adressene dine over tid.

Bedre løsning: for en RPC om 'adresse', send den alltid til leverandør #'hash(adresse) modulo num_providers'. Spørringer om samme adresse går med andre ord til samme RPC-leverandør. Dette sikrer at ingen leverandør lærer hele settet med adresser.

Det er også bedre å ha flere leverandører enn du har adresser. På denne måten lærer hver leverandør enten én av adressene dine, eller ingen; aldri flere. Men den virkelige løsningen? - Kjør din egen node! - Be lommebokutvikleren din om å begynne å bry seg om personvern på RPC-nivå.

Ting jeg ikke dekket, men som også betyr noe: - RPC-timingkorrelasjonsangrep. - Lommebøker som slår opp saldoen til flere adresser i én enkelt RPC. - Ikke-Ethereum-forespørsler som lekker lignende data. Dagens lommebøker er fulle av dem; spør meg hvordan jeg vet det. - L2-er med sentraliserte endepunkter. (lol)

Selv om denne tråden virker kritisk til @jimouris arbeid, vil jeg understreke at den ikke er ment som en dunk. Jeg respekterer alle som faktisk trår til for å takle dette problemet. Dette er lite undersøkt og trenger mer oppmerksomhet, så det er oppmuntrende å se folk jobbe med det.