Podoba mi się, że coraz więcej badań poświęca się prywatności na poziomie RPC. Jest to niedostatecznie zbadana, niedoceniana część prywatności Ethereum, która zasługuje na rozwiązanie. Niestety, obrotowe RPC nie są tym rozwiązaniem, przynajmniej w formie opisanej tutaj. Oto dlaczego 🧵

𝗣𝗿𝗼𝗯𝗹𝗲𝗺 𝟭: Żaden dostawca nie powinien być w stanie powiązać twojego adresu Ethereum z twoim adresem IP. 𝗣𝗿𝗼𝗯𝗹𝗲𝗺 𝟮: Żaden dostawca nie powinien być w stanie powiązać dwóch twoich adresów Ethereum ze sobą. Szczególnie ważne w kontekście adresów stealth.

Pierwsze zaproponowane rozwiązanie nie rozwiązuje żadnego z problemów. W rzeczywistości pogarsza problem 1: zamiast jednego dostawcy, który zna Twój adres IP i adresy Ethereum, teraz 𝙢𝙪𝙡𝙩𝙞𝙥𝙡𝙚 takich dostawców zna je oba.

Drugie rozwiązanie rozwiązuje problem 1, wprowadzając middleware w TEE. Jest to zasadniczo ślepy proxy, którego ślepotę zapewnia TEE. Jednak problem 2 pozostaje nierozwiązany: Dostawcy wciąż mogą łączyć twoje adresy Ethereum ze sobą.

TEE nie są niezawodne. Ale nawet jeśli założymy, że działają zgodnie z zamierzeniami, klient nadal musi zweryfikować, że oprogramowanie pośredniczące, z którym rozmawia, rzeczywiście działa w TEE. W przeciwnym razie klient (portfel) nie może być pewny, że oprogramowanie pośredniczące nie rejestruje wszystkiego.

Klient może to zweryfikować, wykonując taniec atestacji obciążenia. Jest to możliwe, ale skomplikowane do wdrożenia. Nie widziałem prawdziwej implementacji tego w praktyce i nie jest dla mnie jasne, czy byłoby to łatwiejsze do wdrożenia niż po prostu zintegrowanie rzeczywistej sieci mieszanej.

Proxy powinien być ślepy na to, co przepuszcza. Kryptografia rozwiązuje to bez potrzeby założeń dotyczących zaufania do TEE. Mixnety takie jak Tor/Nym/HOPR działają w ten sposób: Szyfrują ładunek w wielu warstwach szyfrowania, gdzie każdy skok zdejmuje jedną warstwę szyfrowania z cebuli.

Dlaczego mixnety nie są dziś używane? - Użytkownicy nie proszą twórców swoich portfeli o prywatność na poziomie RPC. Walletbeat naprawia to. - Oczekiwania dotyczące UX <100 ms RPC. Mixnety/oprogramowanie pośredniczące zwiększają opóźnienia. - Integracja z portfelami przeglądarkowymi wymaga ponownej implementacji TLS w JS w celu zaszyfrowania ostatniego przeskoku.

Same sieci mieszane same w sobie nie rozwiązują problemu 2. Problem pozostaje taki, że naiwne rotowanie RPC (losowy dostawca przy każdym żądaniu) jest w rzeczywistości 𝙬𝙤𝙧𝙨𝙚 dla prywatności: oznacza to, że wielu dostawców uzyskuje widok na wiele twoich adresów w czasie.

Lepsze rozwiązanie: dla RPC dotyczącego `adresu`, zawsze wysyłaj go do dostawcy #`hash(adres) modulo num_providers`. Innymi słowy, zapytania dotyczące tego samego adresu trafiają do tego samego dostawcy RPC. To zapewnia, że żaden dostawca nie pozna twojego pełnego zestawu adresów.

Lepiej jest mieć więcej dostawców niż adresów. W ten sposób każdy dostawca poznaje jeden z twoich adresów lub żaden; nigdy wiele. Ale prawdziwe rozwiązanie? - Uruchom własny węzeł! - Poproś swojego dewelopera portfela, aby zaczął dbać o prywatność na poziomie RPC.

Rzeczy, których nie omówiłem, ale które również mają znaczenie: - Ataki korelacji czasowej RPC. - Portfele sprawdzające saldo wielu adresów w jednym RPC. - Żądania spoza Ethereum, które ujawniają podobne dane. Dzisiejsze portfele są pełne takich; zapytaj mnie, jak to wiem. - L2 z centralizowanymi punktami końcowymi. (lol)

Nawet jeśli ten wątek wydaje się krytyczny wobec pracy @jimouris, chcę podkreślić, że nie jest to zamierzony atak. Bardzo szanuję każdego, kto rzeczywiście podejmuje się rozwiązania tego problemu. To jest niedostatecznie zbadane i wymaga większej uwagi, więc cieszy mnie, że są ludzie, którzy nad tym pracują.