J'adore que davantage de ... | polymutex OKX Feed

J'adore que davantage de recherches soient consacrées à la confidentialité au niveau des RPC. C'est un aspect sous-recherché et sous-apprécié de la confidentialité d'Ethereum qui mérite une solution. Malheureusement, faire tourner les RPC n'est pas cette solution, du moins dans la forme décrite ici. Voici pourquoi 🧵

Dimitris

Idée simple : un serveur entre le portefeuille et les fournisseurs RPC. Le serveur utilise aléatoirement un RPC différent pour chaque demande. Exécutez cela dans un TEE 🔒 ! Le cloud ne voit pas vos demandes (attention, ils voient toujours les métadonnées !) - et le RPC ne voit pas votre IP (ils voient celle du cloud)

𝗣𝗿𝗼𝗯𝗹𝗲𝗺 𝟭 : Aucun fournisseur ne devrait être en mesure d'associer votre adresse Ethereum à votre adresse IP. 𝗣𝗿𝗼𝗯𝗹𝗲𝗺 𝟮 : Aucun fournisseur ne devrait être en mesure d'associer deux de vos adresses Ethereum entre elles. Particulièrement important dans le contexte des adresses furtives.

La première solution proposée ne résout aucun des problèmes. En fait, elle aggrave le problème 1 : au lieu d'un seul fournisseur qui connaît votre adresse IP et vos adresses Ethereum, maintenant plusieurs de ces fournisseurs les connaissent tous les deux.

Dimitris

Je vois deux façons d'implémenter des RPC rotatifs : ➡️ 1. Implémenter cette fonctionnalité directement dans les portefeuilles. Avantages 👍 • Rapide • Inconvénients 👎 • Cela ne peut pas être adapté à n'importe quel portefeuille car cela devrait être implémenté à chaque fois. • **Plus important encore** les RPC voient toujours l'IP de l'utilisateur.

La deuxième solution résout le problème 1 en introduisant un middleware dans un TEE. C'est essentiellement un proxy aveugle, dont l'aveuglement est assuré par le TEE. Mais le problème 2 reste non résolu : les fournisseurs peuvent toujours associer vos adresses Ethereum les unes aux autres.

Dimitris

Les TEE ne sont pas infaillibles. Mais même si nous supposons qu'ils fonctionnent comme prévu, le client doit toujours vérifier que le middleware avec lequel il communique fonctionne réellement dans un TEE. Sinon, le client (portefeuille) ne peut pas être sûr que le middleware ne journalise pas tout.

Le client peut vérifier cela en effectuant une danse d'attestation de charge de travail. C'est possible, mais compliqué à mettre en œuvre. Je n'ai pas vu de véritable mise en œuvre de cela en pratique, et il n'est pas clair pour moi si cela serait plus facile à mettre en œuvre que d'intégrer un véritable mixnet.

Un proxy doit être aveugle à ce qu'il transmet. La cryptographie résout ce problème sans avoir besoin d'hypothèses de confiance TEE. Les mixnets tels que Tor/Nym/HOPR fonctionnent de cette manière : cryptez la charge utile en plusieurs couches de cryptage, où chaque saut retire une couche de cryptage de l'oignon.

Pourquoi les mixnets ne sont-ils pas utilisés aujourd'hui ? - Les utilisateurs ne demandent pas de confidentialité au niveau RPC de la part de leurs développeurs de portefeuille. Walletbeat corrige cela. - Attentes UX des RPC <100ms. Les mixnets/middleware ajoutent de la latence. - L'intégration dans les portefeuilles de navigateur nécessite de réimplémenter TLS en JS pour chiffrer le dernier saut.

Les mixnets à eux seuls ne résolvent pas non plus le problème 2. Le problème reste que faire tourner les RPC de manière naïve (fournisseur aléatoire à chaque demande) est en réalité 𝙬𝙤𝙧𝙨𝙚 pour la vie privée : cela signifie que plusieurs fournisseurs obtiennent une vue de plusieurs de vos adresses au fil du temps.

Meilleure solution : pour un RPC concernant `address`, envoyez-le toujours au fournisseur #`hash(address) modulo num_providers`. En d'autres termes, les requêtes concernant la même adresse vont au même fournisseur RPC. Cela garantit qu'aucun fournisseur ne découvre votre ensemble complet d'adresses.

Il est également préférable d'avoir plus de fournisseurs que d'adresses. De cette façon, chaque fournisseur apprend soit l'une de vos adresses, soit aucune ; jamais plusieurs. Mais la vraie solution ? - Faites fonctionner votre propre nœud ! - Demandez à votre développeur de portefeuille de commencer à se soucier de la confidentialité au niveau RPC.

Choses que je n'ai pas couvertes mais qui comptent aussi : - Attaques de corrélation de timing RPC. - Portefeuilles vérifiant le solde de plusieurs adresses dans un seul RPC. - Requêtes non-Ethereum qui fuient des données similaires. Les portefeuilles d'aujourd'hui en sont pleins ; demandez-moi comment je le sais. - L2 avec des points de terminaison centralisés. (lol)

Même si ce fil semble critique envers le travail de @jimouris, je tiens à souligner que ce n'est pas destiné à être une attaque. Je respecte énormément quiconque se lève réellement pour s'attaquer à ce problème. C'est un sujet peu étudié et qui nécessite plus d'attention, donc c'est réconfortant de voir des gens travailler dessus.

Afficher l’original

Provenance :

3,11 k

Le contenu de cette page est fourni par des tiers. Sauf indication contraire, OKX n’est pas l’auteur du ou des articles cités et ne revendique aucun droit d’auteur sur le contenu. Le contenu est fourni à titre d’information uniquement et ne représente pas les opinions d’OKX. Il ne s’agit pas d’une approbation de quelque nature que ce soit et ne doit pas être considéré comme un conseil en investissement ou une sollicitation d’achat ou de vente d’actifs numériques. Dans la mesure où l’IA générative est utilisée pour fournir des résumés ou d’autres informations, ce contenu généré par IA peut être inexact ou incohérent. Veuillez lire l’article associé pour obtenir davantage de détails et d’informations. OKX n’est pas responsable du contenu hébergé sur des sites tiers. La détention d’actifs numériques, y compris les stablecoins et les NFT, implique un niveau de risque élevé et leur valeur peut considérablement fluctuer. Examinez soigneusement votre situation financière pour déterminer si le trading ou la détention d’actifs numériques vous convient.