Líbí se mi, že se více výzkumu zabývá ochranou soukromí na úrovni RPC. Je to nedostatečně prozkoumaná a nedoceněná součást soukromí Ethereum, která si zaslouží řešení. Bohužel, rotace RPC není tímto řešením, alespoň v zde popsané podobě. Zde je důvod 🧵

Problém 1: Žádný poskytovatel by neměl být schopen přiřadit vaši adresu Ethereum k vaší IP adrese. Problém 2: Žádný poskytovatel by neměl být schopen vzájemně spojit dvě z vašich adres Ethereum. Zvláště důležité v souvislosti s utajenými adresami.

První navrhované řešení neřeší ani jeden z problémů. Ve skutečnosti to problém 1 zhoršuje: místo jednoho poskytovatele, který zná vaši IP adresu a adresu Ethereum, je nyní zná více takových poskytovatelů.

Druhé řešení řeší problém 1 zavedením middlewaru v TEE. Jedná se v podstatě o slepý proxy, pro který je slepota poskytována TEE. Problém 2 však zůstává nevyřešen: Poskytovatelé mohou stále vzájemně spojovat vaše adresy Ethereum.

T-kusy nejsou neprůstřelné. Ale i když předpokládáme, že fungují tak, jak mají, klient stále potřebuje ověřit, že middleware, se kterým mluví, skutečně běží v TEE. V opačném případě si klient (peněženka) nemůže být jistý, že middleware ve skutečnosti neloguje vše.

Klient si to může ověřit provedením atestačního tance pracovní zátěže. Je to možné, ale komplikované na implementaci. Neviděl jsem skutečnou implementaci tohoto v praxi a není mi jasné, zda by to bylo jednodušší implementovat, než jen integrovat skutečný mixnet.

Zástupce by měl být slepý k tomu, co projde. Kryptografie to řeší bez potřeby předpokladů důvěry TEE. Mixnety jako Tor/Nym/HOPR fungují takto: Zašifrujte payload do více vrstev šifrování, kde každý skok odlupuje jednu vrstvu šifrování z cibule.

Proč se dnes nepoužívají mixnety? - Uživatelé nepožadují od vývojářů svých peněženek soukromí na úrovni RPC. Walletbeat to napravuje. - Očekávání UX <100ms RPC. Mixnety/middleware zvyšují latenci. - Integrace do peněženek prohlížeče vyžaduje opětovnou implementaci protokolu TLS v JS pro šifrování posledního skoku.

Mixnety samy o sobě také neřeší problém 2. Problémem zůstává, že naivní rotace RPC (náhodný poskytovatel na každém požadavku) je ve skutečnosti horší pro soukromí: znamená to, že více poskytovatelů získá v průběhu času přehled o více vašich adresách.

Lepší řešení: pro RPC o 'adrese' jej vždy posílejte poskytovateli #'hash(address) modulo num_providers'. Jinými slovy, dotazy na stejnou adresu jsou směrovány ke stejnému poskytovateli RPC. Tím zajistíte, že se žádný poskytovatel nedozví celou sadu vašich adres.

Je také lepší mít více poskytovatelů, než máte adres. Tímto způsobem se každý poskytovatel dozví buď jednu z vašich adres, nebo žádnou; nikdy ne více. Ale skutečné řešení? - Spusťte svůj vlastní uzel! - Požádejte vývojáře peněženky, aby se začal starat o soukromí na úrovni RPC.

Věci, o kterých jsem se nezmínil, ale na kterých také záleží: - Útoky na korelaci časování protokolu RPC. - Peněženky vyhledávající zůstatek na více adresách v jednom RPC. - Požadavky mimo Ethereum, které unikají podobná data. Dnešní peněženky jsou jich plné; zeptejte se mě, jak to vím. - L2s s centralizovanými koncovými body. (lol)

I když se toto vlákno zdá být kritické k práci @jimouris, chci zdůraznit, že není zamýšleno jako smeč. Velmi si vážím každého, kdo se skutečně postaví k řešení tohoto problému. To je nedostatečně prozkoumáno a vyžaduje více pozornosti, takže je povzbudivé vidět, jak na tom lidé pracují.