La fin obscure - Censorship.wtf

Source : https://www.youtube.com/watch?v=S-xJKY1ompk

La fin obscure - Censorship.wtf

Analyse de l'audience (0:00)

Tout le monde dans la salle a utilisé une chaîne EVM au cours des 30 derniers jours, mais il n'y avait aucun utilisateur RPC dans la salle.

Lorsque les gens comptent sur les ordinateurs des autres pour interagir avec les blockchains EVM, ils leur "font confiance" de manière inhérente, ce qui suggère qu'il existe une tendance commune autour de la confiance en certains acteurs d'infrastructure/entreprises pour le faire.

Le recours à l'infrastructure des autres implique une confiance, que celle-ci soit méritée ou non.

Que signifie le terme "confiance" ? (1:10)

La confiance dans ce contexte fait référence à la confiance dans les fournisseurs d'infrastructure comme Infura pour ne pas censurer les utilisateurs. Cela repose sur :

  • Le logiciel libre et open source (FOSS) qui peut être inspecté, modifié et auto-hébergé.
  • La standardisation via le processus EIP qui permet de faibles coûts de changement entre les fournisseurs.
  • Le matériel de vente au détail répandu qui rend l'auto-hébergement de nœuds plus facile.

La vérification des clients légers fournit un autre moyen d'opérer de manière trustless sans auto-hébergement, et il existe de nombreux fournisseurs proposant une vérification des clients légers, tels que Helios et kevlar.sh.

Enfin, il y a la question de la confiance de ne pas suivre toutes les activités des utilisateurs. Une solide confidentialité de la pile complète est nécessaire, car la résistance à la censure et la livraison de données trustless perdent de leur valeur si les fournisseurs peuvent encore surveiller toutes les actions.

Manque de confidentialité complète (3:30)

Nous sommes d'accord que le suivi des utilisateurs est problématique, sinon les efforts de confidentialité n'auraient aucun sens

La confidentialité on-chain est nécessaire même avec une bonne confidentialité de la couche d'exécution. Il y a des leaks d'informations au niveau de la couche P2P avec des intermédiaires techniques comme les solveurs, les constructeurs de blocs, les indexeurs, etc.

Les validateurs ne sont pas privés actuellement, bien qu'il y ait des efforts autour de l'élection secrète d'un leader unique (SSLE).

Appliquer la confidentialité (4:55)

L'ancien monde dispose de certaines protections de la vie privée comme le RGPD et le CCPA, ainsi que des politiques de confidentialité des entreprises. Celles-ci sont appliquées car il y a des entités identifiables derrière les services.

Ces anciennes réglementations et politiques de confidentialité du monde, impliquant que l'espace blockchain manque actuellement d'entités identifiables pour appliquer la confidentialité.

Faites-vous confiance aux opérateurs de nœuds choisis au hasard ? (5:50)

La décentralisation sans protection de la vie privée remplace la confiance dans les lois et réglementations par la confiance envers des opérateurs de nœuds aléatoires pour ne pas abuser des données des utilisateurs. Cela rend la confidentialité pire que dans le monde centralisé.

Se connecter à une couche d'exécution non privée (6:40)

Les couches d'exécution non privées permettent aux opérateurs de nœuds de lier tous nos comptes ensemble : PoAP, ENS, épargne, etc.

Ils peuvent également lier les comptes aux identités off-chain entre autres via les adresses IP.

Les fournisseurs de MEV voient l'activité des utilisateurs avant l'utilisateur lui-même - cela permet de fliquer les utilisateurs

Comment exploiter les utilisateurs (8:15)

Imaginons une application Uniswap entièrement décentralisée utilisant ENS, IPFS, The Graph et des fournisseurs de RPC décentralisés :

  1. L'attaquant exécute des nœuds IPFS pour identifier les utilisateurs actifs à partir de leurs requêtes.
  2. L'attaquant exécute ensuite des nœuds Graph non pas pour nourrir des données malveillantes, mais pour désanonymiser l'utilisateur et récolter ses données.
  3. En exécutant les nœuds Graph, l'attaquant voit chaque clic et sélection dans l'interface utilisateur de l'application. Cela permet le suivi sans avoir besoin de trackers

L'attaquant peut anticiper les transactions de l'utilisateur dans le mempool du fournisseur RPC. Il peut même anticiper en fonction des appels d'estimation de gas de l'utilisateur, avant même que la transaction n'atteigne le mempool.

Il faut considérer ce scénario comme un exemple des problèmes de confidentialité qui nécessitent des solutions à mesure que nous décentralisons les piles web3, et non comme un manque de respect pour les projets concernés.

Qu'en est-il de la confidentialité de la couche de consensus ? (11:00)

Une expérience montre que les validateurs peuvent être désanonymisés en collectant des données d'attestation et en liant les clés publiques aux adresses IP des nœuds phares. Cela permet de cibler les validateurs.

L'état (déplorable) des "d"Apps d'Ethereum (11:50)

Pour illustrer le problème, Sebastian a cité le déploiement IPFS d'Uniswap, qui enregistre les adresses de wallets liées aux identifiants d'appareil pour suivre les utilisateurs à travers les requêtes.

Le déploiement IPFS d'Uniswap enregistre chaque clic de bouton pour que les développeurs sachent exactement ce que fait l'utilisateur et quelle version de MetaMask il utilise, exposant d'éventuelles vulnérabilités.

Uniswap est un exemple à ne pas suivre. Le point principal est que les problèmes de confidentialité de la couche consensus et d'exécution existent et se produisent activement, rendant possible l'exploitation des utilisateurs.

Collecte de données (13:00)

L'industrie actuelle de la MEV est essentiellement un MVP (produit minimum viable) de collecte de données, montrant la valeur des données du mempool (diapo de gauche). Ce n'est qu'un petit sous-ensemble de ce qui est possible dans un système décentralisé.

Alors qu'Ethereum tente d'attirer des utilisateurs institutionnels, nous devrions considérer que les institutions comme les hedge funds récoltent déjà des données de manière extrêmement agressive.

Sebastian croit que l'exploitation abusive de la collecte de données par des acteurs malveillants est inévitable à mesure que les choses se décentralisent davantage, et ce n'est en rien un délire de complotiste.

Taille du marché (14:25)

Une solide confidentialité est la principale assurance contre l'exploitation des utilisateurs, qu'il s'agisse d'individus ou d'institutions. La confidentialité rend Ethereum sûr pour tous.

Les problèmes initialement mis en évidence autour du suivi web concernent la couche applicative. Les arguments de décentralisation concernent davantage les couches de transport et d'exécution. Mais la confidentialité est nécessaire à tous les niveaux.

Comment résoudre (15:00)

  • Nous devons défendre les valeurs fondamentales et dénoncer les acteurs qui ne sont pas alignés. Un soutien juridique est nécessaire car certaines équipes ont peur de travailler sur des fonctionnalités de confidentialité.
  • Les outils de confidentialité de la couche d'exécution existent mais ont besoin de plus d'intégration et d'utilisation.
  • Traiter les fuites P2P provenant des intermédiaires comme les solveurs, les builders, les indexeurs via des réseaux de mélange. Hopper est un réseau de mélange axé sur le middleware RPC.
  • L'inclusion forcée de transactions devrait se produire au niveau du wrapper RPC, pas de l'interface web. Cela permet la résistance à la censure.
  • La confidentialité de la couche consensus pour les validateurs est encore un problème non résolu par SSLE.