Ich liebe es, dass mehr Forschung in die RPC-Ebenen-Privatsphäre investiert wird. Es ist ein unterforschter, unterbewerteter Teil der Ethereum-Privatsphäre, der eine Lösung verdient. Leider ist das Rotieren von RPCs nicht diese Lösung, zumindest nicht in der hier beschriebenen Form. Hier ist der Grund 🧵

𝗣𝗿𝗼𝗯𝗹𝗲𝗺 𝟭: Kein Anbieter sollte in der Lage sein, Ihre Ethereum-Adresse mit Ihrer IP-Adresse zu verknüpfen. 𝗣𝗿𝗼𝗯𝗹𝗲𝗺 𝟮: Kein Anbieter sollte in der Lage sein, zwei Ihrer Ethereum-Adressen miteinander zu verknüpfen. Besonders wichtig im Kontext von Stealth-Adressen.

Die erste vorgeschlagene Lösung löst keines der Probleme. Tatsächlich macht sie Problem 1 𝙬𝙤𝙧𝙨𝙚: Statt eines Anbieters, der Ihre IP- und Ethereum-Adressen kennt, wissen jetzt 𝙢𝙪𝙡𝙩𝙞𝙥𝙡𝙚 solcher Anbieter beide.

Die zweite Lösung löst Problem 1, indem sie ein Middleware in einem TEE einführt. Es ist im Wesentlichen ein blinder Proxy, dessen Blindheit durch das TEE bereitgestellt wird. Aber Problem 2 bleibt ungelöst: Anbieter können weiterhin Ihre Ethereum-Adressen miteinander verknüpfen.

TEEs sind nicht kugelsicher. Aber selbst wenn wir annehmen, dass sie wie beabsichtigt funktionieren, muss der Client dennoch überprüfen, ob die Middleware, mit der er spricht, tatsächlich in einem TEE läuft. Andernfalls kann der Client (Wallet) sich nicht sicher sein, dass die Middleware nicht tatsächlich alles protokolliert.

Der Kunde kann dies überprüfen, indem er einen Workload-Attestations-Tanz durchführt. Es ist möglich, aber kompliziert umzusetzen. Ich habe in der Praxis noch keine echte Implementierung davon gesehen, und es ist mir nicht klar, ob das einfacher umzusetzen wäre, als einfach ein echtes Mixnet zu integrieren.

Ein Proxy sollte blind sein gegenüber dem, was er durchlässt. Kryptographie löst dies ohne die Notwendigkeit von TEE-Vertrauensannahmen. Mixnets wie Tor/Nym/HOPR funktionieren auf diese Weise: Verschlüsseln Sie die Nutzlast in mehreren Schichten von Verschlüsselung, wobei jeder Hop eine Schicht der Verschlüsselung von der Zwiebel abzieht.

Warum werden Mixnets heute nicht verwendet? - Benutzer fordern von ihren Wallet-Entwicklern keine RPC-Level-Privatsphäre. Walletbeat behebt dies. - <100ms RPCs UX-Erwartungen. Mixnets/Middleware fügen Latenz hinzu. - Die Integration in Browser-Wallets erfordert die Neuprogrammierung von TLS in JS, um den letzten Hop zu verschlüsseln.

Mixnets allein lösen auch nicht Problem 2. Das Problem bleibt, dass das naive Rotieren von RPCs (zufälliger Anbieter bei jeder Anfrage) tatsächlich 𝙬𝙤𝙧𝙨𝙚 für die Privatsphäre ist: das bedeutet, dass mehrere Anbieter über die Zeit einen Einblick in mehrere deiner Adressen erhalten.

Bessere Lösung: Bei einem RPC über `address` senden Sie es immer an den Anbieter #`hash(address) modulo num_providers`. Mit anderen Worten, Abfragen zu derselben Adresse gehen an denselben RPC-Anbieter. Dies stellt sicher, dass kein Anbieter Ihr vollständiges Set an Adressen erfährt.

Es ist auch besser, mehr Anbieter zu haben, als Adressen. Auf diese Weise lernt jeder Anbieter entweder eine deiner Adressen oder keine; niemals mehrere. Aber die wirkliche Lösung? - Betreibe deinen eigenen Knoten! - Bitte deinen Wallet-Entwickler, sich um die Privatsphäre auf RPC-Ebene zu kümmern.

Dinge, die ich nicht behandelt habe, aber auch wichtig sind: - RPC-Zeitkorrelationsangriffe. - Wallets, die den Kontostand mehrerer Adressen in einem einzigen RPC abfragen. - Nicht-Ethereum-Anfragen, die ähnliche Daten leaken. Die heutigen Wallets sind voll davon; frag mich, wie ich das weiß. - L2s mit zentralisierten Endpunkten. (lol)

Auch wenn dieser Thread kritisch gegenüber der Arbeit von @jimouris erscheint, möchte ich betonen, dass dies nicht als Angriff gemeint ist. Ich respektiere jeden, der sich tatsächlich bemüht, dieses Problem anzugehen. Dies ist unterforscht und benötigt mehr Aufmerksamkeit, daher ist es ermutigend zu sehen, dass Leute daran arbeiten.