Ik hou ervan dat er meer onderzoek wordt gedaan naar RPC-niveau privacy. Het is een onderbelicht, ondergewaardeerd onderdeel van Ethereum privacy dat een oplossing verdient. Helaas is het draaien van RPC's niet die oplossing, althans niet in de vorm die hier wordt beschreven. Hier is waarom 🧵
Eenvoudig idee: een server tussen de wallet en de RPC-providers. De server gebruikt willekeurig een andere RPC voor elke aanvraag. Voer dit uit in een TEE 🔒! De cloud ziet je aanvragen niet (voorzichtig, ze zien nog steeds metadata!) - en de RPC ziet je IP niet (ze zien dat van de cloud)
𝗣𝗿𝗼𝗯𝗹𝗲𝗺 𝟭: Geen enkele provider zou in staat moeten zijn om jouw Ethereum-adres te koppelen aan jouw IP-adres. 𝗣𝗿𝗼𝗯𝗹𝗲𝗺 𝟮: Geen enkele provider zou in staat moeten zijn om twee van jouw Ethereum-adressen met elkaar te koppelen. Bijzonder belangrijk in de context van stealth-adressen.
De eerste voorgestelde oplossing lost geen van beide problemen op. In feite maakt het probleem 1 𝙬𝙤𝙧𝙨𝙩𝙚: in plaats van één provider die uw IP- en Ethereum-adressen kent, weten nu 𝙢𝙪𝙡𝙩𝙞𝙥𝙡𝙚 dergelijke providers ze beide.
Ik zie twee manieren om roterende RPC's te implementeren: ➡️ 1. Implementeer deze functionaliteit direct in wallets. Voordelen 👍 • Snel • Nadelen 👎 • Dit kan niet worden aangepast aan elke wallet, omdat het elke keer geïmplementeerd moet worden. • **Belangrijker nog** RPC's zien nog steeds het IP-adres van de gebruiker.
De tweede oplossing lost probleem 1 op door een middleware in een TEE in te voeren. Het is in wezen een blinde proxy, waarvan de blindheid wordt geleverd door de TEE. Maar probleem 2 blijft onopgelost: Providers kunnen nog steeds uw Ethereum-adressen met elkaar associëren.
Eenvoudig idee: een server tussen de wallet en de RPC-providers. De server gebruikt willekeurig een andere RPC voor elke aanvraag. Voer dit uit in een TEE 🔒! De cloud ziet je aanvragen niet (voorzichtig, ze zien nog steeds metadata!) - en de RPC ziet je IP niet (ze zien dat van de cloud)
TEEs zijn niet waterdicht. Maar zelfs als we aannemen dat ze werken zoals bedoeld, moet de cliënt nog steeds verifiëren dat de middleware waarmee ze praten, daadwerkelijk in een TEE draait. Anders kan de cliënt (portemonnee) er niet zeker van zijn dat de middleware niet alles aan het loggen is.
De klant kan dit verifiëren door een workload attestatie dans uit te voeren. Het is mogelijk, maar ingewikkeld om te implementeren. Ik heb nog geen echte implementatie hiervan in de praktijk gezien, en het is voor mij niet duidelijk of dat gemakkelijker te implementeren zou zijn dan gewoon een echte mixnet te integreren.
Een proxy zou blind moeten zijn voor wat het doorgeeft. Cryptografie lost dit op zonder de noodzaak voor TEE-vertrouwensassumpties. Mixnets zoals Tor/Nym/HOPR werken op deze manier: Versleutel de payload in meerdere lagen van versleuteling, waarbij elke hop één laag van versleuteling van de ui afpelt.
Waarom worden mixnets vandaag de dag niet gebruikt? - Gebruikers vragen niet om RPC-niveau privacy van hun wallet-ontwikkelaars. Walletbeat lost dit op. - <100ms RPCs UX verwachtingen. Mixnets/middleware voegen latentie toe. - Integratie in browser wallets vereist het opnieuw implementeren van TLS in JS om de laatste hop te versleutelen.
Mixnets alleen lossen probleem 2 ook niet op. Het probleem blijft dat het naief roteren van RPC's (willekeurige provider bij elke aanvraag) eigenlijk 𝙬𝙤𝙧𝙨𝙚 is voor privacy: het betekent dat meerdere providers in de loop van de tijd een overzicht krijgen van meerdere van je adressen.
Betere oplossing: voor een RPC over `adres`, stuur het altijd naar provider #`hash(adres) modulo num_providers`. Met andere woorden, verzoeken over hetzelfde adres gaan naar dezelfde RPC-provider. Dit zorgt ervoor dat geen enkele provider je volledige set adressen leert.
Het is ook beter om meer providers te hebben dan dat je adressen hebt. Op deze manier leert elke provider ofwel een van je adressen, of geen; nooit meerdere. Maar de echte oplossing? - Draai je eigen node! - Vraag je wallet-ontwikkelaar om zich meer te bekommeren om RPC-niveau privacy.
Dingen die ik niet heb behandeld maar ook belangrijk zijn: - RPC-timing correlatie aanvallen. - Wallets die het saldo van meerdere adressen opzoeken in een enkele RPC. - Niet-Ethereum verzoeken die vergelijkbare gegevens lekken. De wallets van vandaag zitten vol met die; vraag me hoe ik dat weet. - L2's met gecentraliseerde eindpunten. (lol)
Ook al lijkt deze thread kritisch over het werk van @jimouris, ik wil benadrukken dat het niet bedoeld is als een afwijzing. Ik heb veel respect voor iedereen die daadwerkelijk de stap zet om dit probleem aan te pakken. Dit is onder-onderzocht en heeft meer aandacht nodig, dus het is bemoedigend om te zien dat mensen hieraan werken.
Origineel weergeven
3,11K
25
De inhoud op deze pagina wordt geleverd door derden. Tenzij anders vermeld, is OKX niet de auteur van het (de) geciteerde artikel(en) en claimt geen auteursrecht op de materialen. De inhoud is alleen bedoeld voor informatieve doeleinden en vertegenwoordigt niet de standpunten van OKX. Het is niet bedoeld als een goedkeuring van welke aard dan ook en mag niet worden beschouwd als beleggingsadvies of een uitnodiging tot het kopen of verkopen van digitale bezittingen. Voor zover generatieve AI wordt gebruikt om samenvattingen of andere informatie te verstrekken, kan deze door AI gegenereerde inhoud onnauwkeurig of inconsistent zijn. Lees het gelinkte artikel voor meer details en informatie. OKX is niet verantwoordelijk voor inhoud gehost op sites van een derde partij. Het bezitten van digitale activa, waaronder stablecoins en NFT's, brengt een hoge mate van risico met zich mee en de waarde van deze activa kan sterk fluctueren. Overweeg zorgvuldig of de handel in of het bezit van digitale activa geschikt voor je is in het licht van je financiële situatie.