L'origine de l'EIP-6963

Dans l'écosystème blockchain, les portefeuilles d'extension de navigateur sont des applications de portefeuille qui existent sous forme de modules complémentaires de navigateur. Ils permettent aux utilisateurs d'interagir facilement avec les comptes blockchain directement au sein des dApps, tels que l'envoi de transactions, la signature de messages ou l'interaction avec des contrats intelligents. L'exemple le plus typique est MetaMask, qui est devenu presque un outil standard pour utiliser les dApps de l'écosystème Ethereum. Contrairement aux applications traditionnelles, les portefeuilles d'extension de navigateur sont intégrés dans l'environnement du navigateur. Cette méthode simplifie le processus d'interaction de l'utilisateur avec la blockchain et élimine les barrières techniques liées aux opérations de nœuds complexes ou à la gestion des clés privées. Les utilisateurs n'ont qu'à installer l'extension pour commencer rapidement à utiliser le réseau blockchain.

Dans ce contexte, un "fournisseur de services" fait référence à la technologie sous-jacente ou à l'interface qui prend en charge ces fonctions de portefeuille. Par exemple, les portefeuilles communiquent avec les nœuds de la blockchain via le protocole JSON-RPC Ethereum, tandis que le fournisseur de services offre l'interface RPC correspondante pour permettre au portefeuille de gérer de manière sécurisée les interactions on-chain.

Imaginez que vous voulez utiliser un échange décentralisé (DEX) ou une place de marché NFT. Vous ouvrez le site Web de l'application décentralisée (dApp), excité de commencer à interagir. Cependant, un problème survient — votre navigateur a plusieurs extensions de portefeuille installées, telles que MetaMask, Coinbase Wallet et Brave Wallet, mais la dApp ne parvient pas à identifier correctement quel portefeuille vous utilisez actuellement et affiche même un message d'erreur : « Aucun portefeuille détecté, veuillez installer une extension de portefeuille. » Vous essayez de rafraîchir la page et de redémarrer le navigateur, mais le problème persiste. Ce scénario courant met en évidence un problème pratique : les mécanismes d'identification et d'interaction des extensions de portefeuille de navigateur sont inadéquats. À mesure que de plus en plus d'extensions de portefeuille et de fournisseurs de services émergent, l'expérience utilisateur devient de plus en plus complexe et déroutante.

Pour résoudre les problèmes d'interaction entre les portefeuilles et les dApps, la communauté a introduit l'EIP-1193 (Ethereum JavaScript Provider API), une norme universelle qui définit comment les dApps peuvent communiquer avec les portefeuilles via l'environnement du navigateur. L'idée principale de l'EIP-1193 est de gérer les fonctions de la blockchain fournies par le portefeuille via une interface normalisée. Par exemple, une dApp communique avec le portefeuille via l'objet window.ethereum, envoyant des demandes ou recevant des événements de la blockchain.

Bien que l'EIP-1193 aborde partiellement les problèmes de compatibilité entre les portefeuilles et les dApps, elle présente encore certaines limitations évidentes :

1. Conflit multi-portefeuilles : lorsque les utilisateurs ont plusieurs portefeuilles d'extension de navigateur installés, l'EIP-1193 lie par défaut window.ethereum au premier portefeuille chargé. Par conséquent, les autres portefeuilles peuvent ne pas être correctement reconnus, et dans certains cas, la dApp pourrait ne pas fonctionner du tout.
2. Manque de prise en charge multi-services : de nombreuses dApps souhaitent prendre en charge plusieurs portefeuilles, mais l'EIP-1193 ne fournit pas de mécanisme clair pour distinguer ou choisir entre différents fournisseurs de services. Cela force les développeurs de dApp à concevoir une logique complexe pour gérer l'adaptation du portefeuille.
3. Expérience utilisateur peu intuitive : Pour les utilisateurs réguliers, il est difficile de comprendre les raisons techniques derrière les messages d'erreur tels que "Aucun portefeuille détecté" ou "Connexion incorrecte", ce qui augmente le seuil d'utilisation et entraîne de la frustration.

Pour résoudre ce problème, la communauté a proposé l'EIP-6963 (Standard de découverte de portefeuille d'extension de navigateur), un plan d'amélioration pour les portefeuilles d'extension de navigateur visant à optimiser les mécanismes de découverte et d'interaction des portefeuilles. La solution vise à abaisser la barrière à l'entrée pour les nouveaux fournisseurs de portefeuille, à promouvoir une concurrence plus juste et à améliorer l'expérience utilisateur sur le réseau Ethereum. Plus précisément, elle introduit un ensemble d'événements de fenêtre et fournit un protocole de communication bidirectionnel, permettant aux bibliothèques Ethereum et aux scripts injectés par les extensions de navigateur d'interagir. Cela permettra aux utilisateurs de sélectionner leur portefeuille préféré en fonction de leurs besoins, améliorant ainsi l'expérience globale.

Analyse du code

Reverse DNS (RDNS)

Le DNS inverse (RDNS) garantit la stabilité des identifiants de fournisseur de portefeuille tout en prévenant les conflits de namespace. L'EIP-6963 met l'accent sur les règles que les conventions RDNS doivent suivre, telles que les formats de domaine valides et les parties de domaine contrôlées par le fournisseur. Il souligne également que les dApps ne devraient pas se fier à la valeur RDNS pour la détection de fonctionnalités afin d'éviter la possibilité d'incitations forgées ou malveillantes. L'interface ProviderDetail de l'EIP-6963 fournit aux dApps des métadonnées de fournisseur de portefeuille, aidant à l'interaction avec le portefeuille.

Détail du fournisseur EIP6963

Le détail du fournisseur EIP6963 est une interface utilisée pour déclarer et décrire les informations du fournisseur de portefeuille. En incluant des propriétés telles que les informations (métadonnées du portefeuille) et le fournisseur (interface du fournisseur de portefeuille), il permet aux dApps d'obtenir des informations détaillées sur les portefeuilles et d'interagir avec eux via des interfaces standardisées. Cette interface sert de base pour atteindre la compatibilité et l'interopérabilité entre les applications décentralisées et divers portefeuilles.

Mécanisme d'événement

Le mécanisme d'événement garantit que les dApps et les portefeuilles peuvent se découvrir et interagir les uns avec les autres sans dépendre d'un ordre d'exécution fixe. Cela permet à la découverte et à l'interaction entre les dApps et les portefeuilles de ne pas être affectées par l'ordre d'exécution, évitant ainsi les conflits et les erreurs.

Types d'événements

EIP6963AnnounceProviderEvent: Cet événement est utilisé par les portefeuilles pour annoncer leur présence. Il contient des informations sur le portefeuille (Détail du fournisseur EIP6963) et l'interface du portefeuille (Fournisseur EIP1193). La propriété de détail de cet événement contient les métadonnées figées du portefeuille (en utilisant Object.freeze()) pour assurer l'immuabilité.

Événement EIP6963RequestProviderEvent : Cet événement est utilisé par les dApps pour demander un fournisseur de portefeuille. La dApp utilise cet événement pour notifier le portefeuille qu'elle est prête et demande une interaction.

Concurrence d'événement

En raison de l'ordre d'exécution indéterminé du code d'application décentralisée et du portefeuille, des conditions de concurrence peuvent survenir. Le mécanisme d'événement est spécifiquement conçu pour garantir que les applications décentralisées et les portefeuilles peuvent gérer correctement les événements lorsqu'ils se découvrent mutuellement. Un portefeuille peut émettre en premier l'événement d'annonce, alors que l'application décentralisée pourrait ne pas être prête à l'écouter avant plus tard. Pour éviter les erreurs, le portefeuille réémettra l'événement d'annonce après le premier, garantissant que l'application décentralisée le reçoive en temps opportun.

Gestion des événements de dApp

Les dApps doivent écouter l'événement EIP6963AnnounceProviderEvent et ne doivent pas supprimer le gestionnaire d'événements pendant le chargement de la page. Cela garantit que la dApp peut écouter et répondre en continu à l'événement d'annonce du portefeuille pendant son cycle de vie. Après avoir géré l'événement d'annonce, la dApp doit déclencher l'événement EIP6963RequestProviderEvent pour demander une interaction supplémentaire avec le portefeuille.

Découverte et Changement de Portefeuille

Les dApps peuvent stocker plusieurs objets EIP6963ProviderDetail pour différents portefeuilles, permettant aux utilisateurs de choisir entre différents portefeuilles pour interagir dans la dApp. Cela offre une plus grande flexibilité aux utilisateurs, leur permettant de changer de portefeuille sans recharger la page.

Ce design permet une découverte et une interaction transparente entre les dApps et les portefeuilles grâce à l'EIP6963AnnounceProviderEvent et à l'EIP6963RequestProviderEvent. En utilisant des écouteurs d'événements et des déclencheurs d'événements, les dApps et les portefeuilles peuvent coordonner leurs actions malgré l'ordre d'exécution indéterminé, éviter les conditions de concurrence et garantir un comportement stable. De plus, les dApps peuvent changer de portefeuille en fonction des préférences de l'utilisateur, améliorant ainsi l'expérience utilisateur et l'interopérabilité des portefeuilles.

Compatibilité ascendante

Cet EIP ne nécessite pas le remplacement de window.ethereum, ce qui signifie qu'il ne cassera pas directement les applications existantes qui ne peuvent pas être mises à jour pour utiliser cette méthode de découverte de portefeuille. Cependant, il est fortement recommandé que les dApps implémentent cet EIP pour s'assurer qu'elles peuvent découvrir plusieurs fournisseurs de portefeuilles, et qu'elles désactivent l'utilisation de window.ethereum, sauf en tant que méthode de secours en cas d'échec de la découverte. De même, les fournisseurs de portefeuilles devraient maintenir la compatibilité avec window.ethereum pour assurer la compatibilité ascendante avec les dApps qui n'implémentent pas cet EIP. Pour éviter les problèmes de conflit d'espaces de noms précédents, il est recommandé que les portefeuilles injectent leur objet fournisseur dans un espace de noms de portefeuille spécifique, puis procurent l'objet à l'espace de noms window.ethereum.

Conception de sécurité

Pollution du prototype de l'objet du fournisseur de portefeuille

Les extensions de navigateur, en particulier les extensions de portefeuille, ont la capacité de modifier le contenu de la page et les objets fournisseurs, ce qui est une fonctionnalité essentielle de leur conception. Les objets fournisseurs de différents portefeuilles sont considérés comme des interfaces très fiables pour transmettre des données de transaction. Pour éviter les modifications non intentionnelles de l'interaction entre le dApp et le portefeuille par la page ou d'autres extensions, la meilleure pratique est de geler l'objet EIP1193Provider en utilisant Object.freeze() avant que le portefeuille ne déclenche l'événement eip6963:announceProvider. Cela garantit que l'objet ne peut pas être modifié. Cependant, dans certains cas, la compatibilité Web peut nécessiter la modification de cet objet. Dans de tels cas, les développeurs de portefeuilles doivent trouver un équilibre entre la sécurité et la compatibilité Web.

Contrefaçon et Altération de Portefeuille

Les dApps devraient détecter activement si les propriétés ou les fonctions de l'objet fournisseur de portefeuille ont été altérées pour empêcher la falsification ou l'altération d'autres portefeuilles. Une façon de détecter la falsification est de vérifier si la propriété uuid dans les deux objets EIP6963ProviderInfo est cohérente. Les dApps et leurs bibliothèques de découverte devraient prendre en compte d'autres méthodes potentielles de falsification et prendre des mesures de protection supplémentaires pour prévenir de tels comportements, garantissant la sécurité de l'utilisateur.

Prévenir l'exécution de JavaScript dans les SVG

L'utilisation d'images SVG peut entraîner des attaques de script entre sites (XSS), car les SVG peuvent contenir du code JavaScript. Ce code s'exécute dans le contexte de la page et pourrait potentiellement modifier le contenu de la page ou affecter d'autres portefeuilles. Par conséquent, lors du rendu des icônes, les dApps doivent tenir compte de la manière de gérer de tels risques de sécurité pour empêcher que des images malveillantes ne soient utilisées comme techniques d'obscurcissement, cachant ainsi des modifications malveillantes de la page ou du portefeuille.

Prévention du pistage du portefeuille

L’un des avantages du mécanisme de boucle d’événements simultanés utilisé dans cette conception est que la dApp et le portefeuille peuvent tous deux lancer le processus d’annonce du fournisseur. Par conséquent, les implémenteurs de portefeuilles peuvent choisir de s’annoncer à toutes les pages ou de prendre d’autres mesures pour réduire la probabilité que les utilisateurs soient pris d’empreintes digitales via l’objet window.ethereum injecté. Une alternative possible consiste pour le portefeuille à retarder l’injection de l’objet provider jusqu’à ce que la dApp annonce l’événement eip6963 :requestProvider. À ce stade, le portefeuille peut lancer un flux de consentement de l’interface utilisateur, demandant à l’utilisateur s’il est prêt à partager l’adresse de son portefeuille. Cette approche permet au portefeuille d’activer une fonction de « connexion privée ». Cependant, lors de l’adoption de cette approche, le portefeuille doit également réfléchir à la manière d’assurer la rétrocompatibilité avec les dApps qui ne prennent pas en charge cette EIP.

Fonctionnalités des améliorations EIP-6963

Simplification du processus de découverte du portefeuille

EIP-6963, proposé en mai 2023 comme nouvelle norme Ethereum et adopté en octobre de la même année, vise à remédier au manque de normes clairement définies telles que window.ethereum. La norme introduit un mécanisme de découverte de fournisseur à injection multiple, permettant aux dApps de découvrir et de se connecter de manière fiable à tous les portefeuilles installés sur le navigateur d'un utilisateur. Cela surmonte les limitations et conflits présentés par les méthodes traditionnelles. Comparé à l'approche traditionnelle window.ethereum, l'EIP-6963 simplifie le processus de découverte du portefeuille, soutenant la coexistence de plusieurs extensions de portefeuille dans le même navigateur. Cette innovation améliore considérablement l'interopérabilité de l'écosystème Ethereum et améliore l'expérience utilisateur.

Définition claire et expérience utilisateur améliorée

L'EIP-6963 n'est pas seulement une amélioration fonctionnelle ; elle améliore également la reconnaissance des portefeuilles et l'expérience utilisateur en permettant aux portefeuilles d'injecter des informations telles que le nom, le logo, l'UUID et le DNS inversé (RDNS). Les dApps peuvent afficher ces informations, permettant aux utilisateurs de comprendre clairement avec quel portefeuille ils interagissent, évitant ainsi toute confusion et toute mauvaise manipulation. Cela se traduit par une interface plus claire, plus fiable et plus conviviale. De cette manière, l'EIP-6963 offre aux utilisateurs une expérience plus fluide, réduisant les litiges potentiels et les difficultés opérationnelles inutiles, tout en contribuant positivement à l'écosystème global d'Ethereum.

Risques potentiels pour la sécurité

La conception de l'EIP-6963 introduit des vulnérabilités de sécurité potentielles. En fournissant une liste de tous les portefeuilles enregistrés, elle facilite l'interaction entre les dApps et les utilisateurs, mais pourrait également être utilisée de manière abusive par des applications malveillantes. Les dApps malveillantes pourraient lire la liste des portefeuilles installés par les utilisateurs, déduisant ainsi leurs activités blockchain ou distributions d'actifs. Si le mécanisme d'enregistrement de service manque de vérification rigoureuse, des portefeuilles malveillants pourraient se faire passer pour des fournisseurs de services légitimes, incitant les utilisateurs à accorder l'accès et à voler des actifs. Par conséquent, des mesures de sécurité supplémentaires (telles que le consentement de l'utilisateur et la validation de l'inscription) sont nécessaires.

Complexité de l'expérience utilisateur

En termes d'expérience utilisateur, le support multi-portefeuille de l'EIP-6963, bien qu'il s'agisse d'une amélioration significative, pourrait également augmenter la complexité. Par exemple, après qu'un utilisateur a installé plusieurs portefeuilles, le dApp pourrait présenter trop d'options, ce qui pourrait embrouiller l'utilisateur quant au choix du portefeuille. De plus, certains portefeuilles peuvent avoir des noms ou des logos qui ne sont pas intuitifs, ce qui augmente la difficulté d'identification. Pour les utilisateurs qui ont besoin de changer fréquemment de portefeuille, cette flexibilité pourrait devenir un fardeau plutôt qu'un avantage.

Résumé

L’EIP-6963 introduit une approche axée sur les événements pour résoudre des problèmes tels que la coexistence multi-portefeuilles, les conflits d’espaces de noms et la protection de la vie privée des utilisateurs dans les applications Web3, améliorant ainsi considérablement l’expérience utilisateur. Ce mécanisme standardisé permet aux dApps de découvrir et de connecter automatiquement plusieurs portefeuilles sans changement manuel, tout en évitant la concurrence et les conflits entre les portefeuilles, améliorant ainsi la fluidité et la stabilité des connexions. L’EIP-6963 renforce également la sécurité en gelant les objets des fournisseurs de portefeuille afin d’empêcher toute falsification, ce qui réduit les risques de sécurité potentiels. En termes de confidentialité, les utilisateurs peuvent choisir de partager ou non l’adresse de leur portefeuille, ce qui empêche les fuites d’identité et la prise d’empreintes digitales. L’EIP-6963 maintient la rétrocompatibilité avec les interfaces plus anciennes, assurant une transition en douceur pour les systèmes existants, tout en simplifiant le travail des développeurs de dApp et en améliorant la prise en charge multiplateforme et multi-appareils. Dans l’ensemble, l’EIP-6963 améliore l’interopérabilité, la sécurité et la protection de la vie privée dans le Web3 et fournit aux développeurs des outils plus efficaces, favorisant ainsi le développement de l’écosystème Web3.