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 🧵
Einfache Idee: ein Server zwischen der Wallet und den RPC-Anbietern. Der Server verwendet zufällig für jede Anfrage einen anderen RPC.
Führe dies in einem TEE aus 🔒! Die Cloud sieht deine Anfragen nicht (vorsichtig, sie sehen immer noch Metadaten!) - und der RPC sieht deine IP nicht (sie sehen die der Cloud)
𝗣𝗿𝗼𝗯𝗹𝗲𝗺 𝟭: 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.
Ich sehe zwei Möglichkeiten, rotierende RPCs zu implementieren:
➡️ 1. Diese Funktionalität direkt in Wallets implementieren.
Vorteile 👍
• Schnell
• Nachteile 👎
• Dies kann nicht an jedes Wallet angepasst werden, da es jedes Mal implementiert werden müsste.
• **Wichtiger noch** sehen RPCs immer noch die IP des Benutzers.
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.
Einfache Idee: ein Server zwischen der Wallet und den RPC-Anbietern. Der Server verwendet zufällig für jede Anfrage einen anderen RPC.
Führe dies in einem TEE aus 🔒! Die Cloud sieht deine Anfragen nicht (vorsichtig, sie sehen immer noch Metadaten!) - und der RPC sieht deine IP nicht (sie sehen die der Cloud)
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.
3.089
25
Der Inhalt dieser Seite wird von Dritten bereitgestellt. Sofern nicht anders angegeben, ist OKX nicht der Autor der zitierten Artikel und erhebt keinen Anspruch auf das Urheberrecht an den Materialien. Der Inhalt wird ausschließlich zu Informationszwecken bereitgestellt und gibt nicht die Ansichten von OKX wieder. Er stellt keine wie auch immer geartete Befürwortung dar und sollte nicht als Anlageberatung oder Aufforderung zum Kauf oder Verkauf digitaler Vermögenswerte betrachtet werden. Soweit generative KI zur Bereitstellung von Zusammenfassungen oder anderen Informationen verwendet wird, können solche KI-generierten Inhalte ungenau oder inkonsistent sein. Bitte lesen Sie den verlinkten Artikel für weitere Details und Informationen. OKX ist nicht verantwortlich für Inhalte, die auf Websites Dritter gehostet werden. Der Besitz digitaler Vermögenswerte, einschließlich Stablecoins und NFTs, ist mit einem hohen Risiko verbunden und kann starken Schwankungen unterliegen. Sie sollten sorgfältig abwägen, ob der Handel mit oder der Besitz von digitalen Vermögenswerten angesichts Ihrer finanziellen Situation für Sie geeignet ist.