Un grand merci à Liraz Siri, Yoav Weiss ainsi qu'aux développeurs d'ImToken, Metamask et OKX pour leurs retours et leurs critiques.
Une couche clé de l'infrastructure Ethereum est le portefeuille, mais elle est souvent sous-estimée par les chercheurs et développeurs principaux de L1. Le portefeuille est la fenêtre entre l'utilisateur et le monde Ethereum, et les utilisateurs ne peuvent bénéficier d'aucune des propriétés décentralisées, résistantes à la censure, sécurisées, privées ou autres offertes par Ethereum et ses applications, à moins que le portefeuille lui-même ne possède également ces propriétés.
Récemment, nous avons vu de grands progrès dans les portefeuilles Ethereum en matière d'amélioration de l'expérience utilisateur, de sécurité et de fonctionnalités. L'objectif de cet article est de donner mon propre avis sur certaines des caractéristiques que devrait avoir un portefeuille Ethereum idéal. Ce n'est pas une liste exhaustive ; elle reflète mes tendances de cypherpunk, centrées sur la sécurité et la confidentialité, et il est presque certain qu'elle est incomplète en termes d'expérience utilisateur. Cependant, je pense que la liste de souhaits est moins efficace pour optimiser l'expérience utilisateur que de déployer et d'itérer simplement en fonction des retours, donc je pense qu'il est plus précieux de se concentrer sur les attributs de sécurité et de confidentialité.
Expérience utilisateur des transactions inter-L2
Il existe désormais une feuille de route de plus en plus détaillée pour améliorer l'expérience utilisateur à travers les L2, qui se divise en sections à court et à long terme. Ici, je vais parler de la partie à court terme : des idées qui peuvent encore théoriquement être mises en œuvre aujourd'hui.
L'idée principale est (i) d'inclure l'envoi inter-L2, et (ii) des demandes de paiement et des adresses spécifiques à la chaîne. Votre portefeuille devrait être capable de vous fournir une adresse (dans le style de ce projet ERC), comme suit :
Lorsque quelqu'un (ou certaines applications) vous fournit une adresse sous ce format, vous devriez être capable de la coller dans le champ 'destinataire' du portefeuille, puis de cliquer sur 'envoyer'. Le portefeuille devrait traiter automatiquement les données envoyées de toutes les manières possibles :
Si vous avez déjà suffisamment de jetons du type requis sur la chaîne cible, envoyez directement les jetons.
Si vous avez des jetons du type requis sur une autre chaîne (ou plusieurs autres chaînes), utilisez des protocoles comme ERC-7683 (qui est en fait un DEX inter-chaînes) pour envoyer des jetons.
Si vous avez des jetons de différents types sur la même chaîne ou sur d'autres chaînes, utilisez une bourse décentralisée pour les convertir en monnaie du bon type sur la bonne chaîne et envoyer. Cela devrait nécessiter l'autorisation explicite de l'utilisateur : l'utilisateur verra combien de frais ils ont payés et combien le destinataire a reçu.
Modèle d'interface possible pour un portefeuille avec support d'adresses inter-chaînes
Ce qui précède s'applique au cas d'utilisation 'vous copiez-collez une adresse (ou ENS, par exemple, vitalik.eth @ optimism.eth) pour que quelqu'un vous paie'. Si la dapp demande un dépôt (voir cet exemple de Polymarket), alors le processus idéal est d'étendre l'API web3 et de permettre à la dapp d'émettre des demandes de paiement spécifiques à la chaîne. Ensuite, votre portefeuille sera en mesure de satisfaire cette demande de toutes les manières nécessaires. Pour garantir une bonne expérience utilisateur, il est également nécessaire de normaliser les demandes getAvailableBalance, et le portefeuille doit sérieusement réfléchir aux chaînes sur lesquelles il stocke par défaut les actifs des utilisateurs, afin de maximiser la sécurité et la commodité des transferts.
Les demandes de paiement spécifiques à la chaîne peuvent également être mises dans un code QR, et un portefeuille mobile peut scanner le code QR. Dans les scénarios de paiement de consommateurs en face à face (ou en ligne), le destinataire émettra un code QR ou un appel API web3 indiquant 'je veux X unités de jetons Y Z sur la chaîne, avec un ID de référence ou un rappel W', et le portefeuille pourra satisfaire cette demande de toutes les manières possibles. Une autre option est le protocole de lien de réclamation, où le portefeuille de l'utilisateur génère un code QR ou une URL contenant l'autorisation de réclamation pour obtenir un certain montant de fonds de leur contrat sur chaîne, le travail du destinataire étant de comprendre comment transférer ces fonds dans leur propre portefeuille.
Un autre sujet pertinent est le paiement des frais de gas. Si vous recevez des actifs sur un L2 sans ETH et que vous devez envoyer une transaction sur ce L2, le portefeuille devrait être capable d'utiliser automatiquement un protocole (comme RIP-7755) pour payer les frais de gas là où vous avez de l'ETH. Si le portefeuille souhaite que vous effectuiez plus de transactions sur L2 à l'avenir, il devrait également utiliser un DEX pour envoyer, par exemple, de l'ETH d'une valeur de plusieurs millions de frais de gas, afin que les transactions futures puissent être directement effectuées là-bas pour payer les frais de gas (car cela est moins cher).
Sécurité des comptes
Une façon de conceptualiser le défi de la sécurité des comptes est qu'un bon portefeuille doit agir simultanément dans deux domaines : (i) protéger les utilisateurs contre les attaques ou les abus des développeurs de portefeuilles, et (ii) protéger les utilisateurs contre les effets de leurs propres erreurs.
L' 'erreur' à gauche est involontaire. Cependant, lorsque je l'ai vue, j'ai réalisé qu'elle convenait parfaitement au contexte, donc j'ai décidé de la garder.
Ma solution préférée à cela, depuis plus de dix ans, a été la récupération sociale et les portefeuilles multisignatures, avec un contrôle d'accès hiérarchique. Le compte de l'utilisateur a deux niveaux de clés : une clé principale et N gardiens (par exemple N = 5). La clé principale est capable d'effectuer des opérations de faible valeur et non financières. La plupart des gardiens doivent exécuter (i) des opérations de haute valeur, comme envoyer toute la valeur du compte, ou (ii) modifier la clé principale ou tout gardien. Si nécessaire, il peut être permis à la clé principale d'effectuer des opérations de haute valeur par le biais d'un verrou temporel.
Ce qui précède est un design de base, extensible. Les clés de session et les mécanismes d'autorisation comme ERC-7715 peuvent aider à soutenir l'équilibre entre la commodité et la sécurité de différentes applications. Des architectures de gardien plus complexes, comme celles ayant plusieurs durées de verrouillage temporel à différents seuils, peuvent aider à maximiser les chances de récupérer avec succès un compte légitime tout en minimisant le risque de vol.
Ce qui précède est un design de base, extensible. Les clés de session et les mécanismes d'autorisation comme ERC-7715 peuvent aider à soutenir l'équilibre entre la commodité et la sécurité de différentes applications. Des architectures de gardien plus complexes, comme celles ayant plusieurs durées de verrouillage temporel à différents seuils, peuvent aider à maximiser les chances de récupérer avec succès un compte légitime tout en minimisant le risque de vol.
Qui ou quoi devrait être le gardien ?
Pour les utilisateurs expérimentés de la cryptomonnaie dans la communauté, une option viable est la clé de vos amis et de votre famille. Si vous demandez à chacun de vous fournir une nouvelle adresse, alors personne n'a besoin de savoir qui ils sont - en fait, vos gardiens n'ont même pas besoin de savoir qui sont les autres. S'ils ne vous ont pas informé, il est peu probable qu'ils s'entendent. Cependant, cette option n'est pas disponible pour la plupart des nouveaux utilisateurs.
La deuxième option est celle des gardiens institutionnels : des entreprises qui proposent des services de signature de transactions uniquement lorsque d'autres informations de confirmation sont reçues à la suite de votre demande : par exemple, un code de confirmation, ou pour les utilisateurs de haute valeur, un appel vidéo. Les gens ont longtemps essayé de créer cela, par exemple, j'ai présenté CryptoCorp en 2013. Cependant, jusqu'à présent, ces entreprises n'ont pas été très réussies.
La troisième option est d'utiliser plusieurs dispositifs personnels (par exemple, téléphone, ordinateur de bureau, portefeuille matériel). Cela peut fonctionner, mais c'est également difficile à configurer et à gérer pour les utilisateurs inexpérimentés. Il existe également un risque de perdre ou de voler simultanément les appareils, surtout s'ils sont situés au même endroit.
Récemment, nous avons commencé à voir plus de solutions basées sur la clé universelle. Les clés peuvent être sauvegardées uniquement sur votre appareil, ce qui en fait une solution de dispositif personnel, et peuvent également être sauvegardées dans le cloud, rendant leur sécurité dépendante d'hypothèses complexes de sécurité par mot de passe, institutionnelles et de matériel de confiance. En réalité, les clés représentent un gain de sécurité précieux pour l'utilisateur moyen, mais elles ne suffisent pas à elles seules pour protéger les économies de toute une vie de l'utilisateur.
Heureusement, avec ZK-SNARK, nous avons aussi une quatrième option : ID centralisé enveloppé dans ZK. Ce type comprend zk-email, Anon Aadhaar, Myna Wallet, etc. En gros, vous pouvez prendre des ID centralisés sous diverses formes (entreprises ou gouvernement) et les convertir en adresses Ethereum, vous ne pouvez envoyer des transactions qu'en générant une preuve de possession de l'ID centralisé via ZK-SNARK.
Avec cet ajout, nous avons maintenant un large éventail de choix, et l'ID centralisé enveloppé dans ZK a une 'facilité d'utilisation pour les débutants' unique.
Pour cela, il doit être réalisé par une interface simplifiée et intégrée : vous devriez être capable de spécifier simplement que vous voulez 'example@gmail.com' comme gardien, et cela devrait automatiquement générer l'adresse Ethereum zk-email correspondante sous le capot. Les utilisateurs avancés devraient être en mesure de saisir leur e-mail (et peut-être le sel de confidentialité stocké dans cet e-mail) dans une application tierce open source et confirmer que l'adresse générée est correcte. Cela devrait également être vrai pour tout autre type de gardien pris en charge.
Notez qu'un défi pratique auquel fait face zk-email aujourd'hui est qu'il repose sur une signature DKIM, qui utilise une clé qui est changée tous les quelques mois, et ces clés elles-mêmes ne sont pas signées par d'autres entités. Cela signifie que zk-email d'aujourd'hui a un certain niveau d'exigence de confiance au-delà du fournisseur lui-même ; si zk-email utilise TLSNotary pour vérifier les clés mises à jour sur du matériel de confiance, cela pourrait atténuer cela, mais ce n'est pas idéal. J'espère que les fournisseurs d'e-mails commenceront à signer directement leur clé DKIM. Aujourd'hui, je recommande à un gardien d'utiliser zk-email, mais je ne le recommande pas à la plupart des gardiens : ne stockez pas de fonds dans zk-email endommagé signifie que vous ne pouvez pas utiliser les fonds dans la configuration.
Nouveaux utilisateurs et portefeuilles en application
Les nouveaux utilisateurs ne souhaitent pas réellement entrer un grand nombre de gardiens lors de leur première inscription. Par conséquent, le portefeuille devrait leur offrir une option très simple. Une approche naturelle est d'utiliser zk-email sur leur adresse e-mail, une clé stockée localement sur l'appareil de l'utilisateur (peut-être une clé universelle) et une clé de sauvegarde détenue par le fournisseur, pour faire un choix 2 sur 3. À mesure que les utilisateurs gagnent en expérience ou accumulent plus d'actifs, ils devraient être invités à un moment donné à ajouter plus de gardiens.
L'intégration des portefeuilles dans les applications est inévitable, car les applications qui tentent d'attirer des utilisateurs non cryptographiques ne veulent pas que les utilisateurs téléchargent simultanément deux nouvelles applications (l'application elle-même, plus le portefeuille Ethereum), ce qui engendre une expérience utilisateur confuse. Cependant, de nombreux utilisateurs de portefeuilles d'application devraient être capables de lier tous leurs portefeuilles ensemble, afin de ne se soucier que d'un seul 'problème de contrôle d'accès'. La manière la plus simple d'y parvenir est d'adopter un schéma hiérarchique où il existe un processus de 'lien' rapide permettant aux utilisateurs de définir leur portefeuille principal comme le gardien de tous les portefeuilles d'application. Le client Farcaster Warpcast prend déjà en charge cela :
Par défaut, la récupération de votre compte Warpcast est contrôlée par l'équipe Warpcast. Cependant, vous pouvez 'prendre le contrôle' de votre compte Farcaster et modifier la récupération pour votre propre adresse.
Protéger les utilisateurs contre les arnaques et autres menaces externes
Outre la sécurité des comptes, les portefeuilles d'aujourd'hui font également beaucoup de travail pour identifier les adresses fausses, le phishing, les arnaques et d'autres menaces externes, en essayant de protéger les utilisateurs contre ces menaces. Dans le même temps, de nombreuses contre-mesures restent assez primitives : par exemple, exiger un clic pour envoyer de l'ETH ou d'autres jetons à une nouvelle adresse, que vous envoyiez 100 $ ou 100 000 $. Il n'existe pas de solution miracle ici. Il s'agit d'une série de corrections et d'améliorations lentes et continues visant différentes catégories de menaces. Cependant, continuer à travailler pour améliorer cela a énormément de valeur.
Confidentialité
Il est maintenant temps de prendre plus au sérieux la confidentialité sur Ethereum. La technologie ZK-SNARK est maintenant très avancée et les technologies de confidentialité qui ne dépendent pas de portes dérobées pour réduire les risques réglementaires (comme les pools de confidentialité) deviennent de plus en plus matures, tandis que des infrastructures de niveau secondaire comme Waku et les mempools ERC-4337 deviennent également progressivement plus stables. Cependant, jusqu'à présent, effectuer des transferts privés sur Ethereum nécessite que les utilisateurs téléchargent explicitement et utilisent des 'portefeuilles de confidentialité', comme Railway (ou Umbra pour des adresses invisibles). Cela crée une grande gêne et réduit le nombre de personnes prêtes à effectuer des transferts privés. La solution est que les transferts privés doivent être intégrés directement dans le portefeuille.
Une mise en œuvre simple est la suivante. Le portefeuille peut stocker une partie des actifs de l'utilisateur en tant que 'solde privé' dans un pool de confidentialité. Lorsque l'utilisateur effectue un transfert, il sort automatiquement du pool de confidentialité. Si l'utilisateur a besoin de recevoir des fonds, le portefeuille peut automatiquement générer une adresse invisible.
De plus, le portefeuille peut automatiquement générer une nouvelle adresse pour chaque application à laquelle l'utilisateur participe (par exemple, un protocole DeFi). Les dépôts proviendront du pool de confidentialité, tandis que les retraits entreront directement dans le pool de confidentialité. Cela permet de déconnecter les activités d'un utilisateur dans une application de celles dans d'autres applications.
Un avantage de cette technologie est qu'elle constitue non seulement un moyen naturel de transférer des actifs en préservant la confidentialité, mais aussi un moyen naturel de préserver l'identité. L'identité s'est déjà manifestée sur la chaîne : toute application utilisant des preuves d'identité contrôlées (comme Gitcoin Grants), tout chat contrôlé par des jetons, des protocoles Ethereum, etc., sont tous des identités sur chaîne. Nous espérons que cet écosystème pourra également préserver la confidentialité. Cela signifie que les activités des utilisateurs sur la chaîne ne doivent pas être collectées en un seul endroit : chaque projet doit être stocké séparément, et le portefeuille de l'utilisateur doit être la seule chose ayant une 'vue globale' capable de voir toutes vos preuves simultanément. Un écosystème natif où chaque utilisateur possède plusieurs comptes aide à atteindre cet objectif, comme les protocoles de preuves hors chaîne tels qu'EAS et Zupass.
Cela représente une vision pragmatique de la confidentialité sur Ethereum à moyen terme. Bien qu'il soit possible d'introduire certaines fonctionnalités sur L1 et L2 pour rendre les transferts protégés par la confidentialité plus efficaces et fiables, cela peut déjà être réalisé maintenant. Certains défenseurs de la confidentialité pensent que la seule chose acceptable est la confidentialité totale de tout : crypter tout l'EVM. Je pense que cela pourrait être le résultat idéal à long terme, mais cela nécessitera une reconsidération fondamentale du modèle de programmation et n'est pas encore prêt à être déployé sur Ethereum à un niveau de maturité suffisant. Nous avons en effet besoin d'une confidentialité par défaut pour obtenir un ensemble anonyme suffisamment grand. Cependant, se concentrer d'abord sur (i) les transferts entre comptes, et (ii) l'identité et les cas d'utilisation liés à l'identité (comme les preuves privées) est une première étape pragmatique, plus facile à réaliser, et le portefeuille peut commencer à l'utiliser dès maintenant.
Les portefeuilles Ethereum doivent également devenir des portefeuilles de données.
Une conséquence de toute solution de confidentialité efficace est qu'elle crée un besoin pour les utilisateurs de stocker des données hors chaîne, que ce soit pour des paiements, des identités ou d'autres cas d'utilisation. Cela est particulièrement évident dans Tornado Cash, qui exige que les utilisateurs conservent un 'reçu' pour chaque dépôt représentant 0,1 à 100 ETH. Les protocoles de confidentialité plus modernes conservent parfois des données cryptées sur chaîne et les décryptent à l'aide d'une seule clé privée. Cela comporte des risques, car si la clé est compromise, ou si l'informatique quantique devient faisable, les données seront complètement exposées. Des preuves hors chaîne, comme EAS et Zupass, rendent encore plus évident le besoin de stockage de données hors chaîne.
Le portefeuille doit non seulement devenir le logiciel de stockage d'accès à la chaîne, mais aussi le logiciel de stockage de vos données privées. Le monde non cryptographique prend également de plus en plus conscience de cela, par exemple, voyez le travail récent de Tim Berners-Lee sur le stockage de données personnelles. Tous les problèmes que nous devons résoudre autour de la garantie robuste du contrôle d'accès, nous devons également résoudre autour de la garantie robuste de l'accessibilité des données et de la non-divulgation. Peut-être que ces solutions peuvent s'additionner : si vous avez N gardiens, utilisez un partage secret M sur N entre ces N gardiens pour stocker vos données. Les données sont intrinsèquement plus difficiles à protéger car vous ne pouvez pas révoquer la part de données de quelqu'un, mais nous devrions proposer des solutions de stockage décentralisé aussi sûres que possible.
Accès sécurisé à la chaîne
De nos jours, les portefeuilles font confiance à leurs fournisseurs RPC pour leur fournir des informations sur la chaîne. C'est une vulnérabilité qui a deux aspects :
Les fournisseurs RPC peuvent essayer de voler de l'argent en leur fournissant de fausses informations, par exemple, sur les prix du marché.
Les fournisseurs RPC peuvent extraire des informations privées sur les applications et autres comptes avec lesquels l'utilisateur interagit.
Idéalement, nous voulons combler ces deux vulnérabilités. Pour résoudre le premier problème, nous avons besoin de clients légers normalisés pour L1 et L2, qui peuvent vérifier directement le consensus de la blockchain. Helios a déjà fait cela pour L1, et a commencé à effectuer certains travaux préliminaires pour soutenir certaines L2 spécifiques. Pour couvrir correctement toutes les L2, nous avons besoin d'une norme selon laquelle le contrat de configuration représentant L2 (également utilisé pour les adresses spécifiques à la chaîne) peut déclarer une fonction, peut-être de manière similaire à ERC-3668, incluant la logique pour obtenir le dernier état racine et vérifier les preuves d'état et les reçus pour ces racines d'état. De cette manière, nous aurons un client léger universel qui permettra au portefeuille de vérifier en toute sécurité tout état ou événement sur L1 et L2.
Pour la confidentialité, le seul moyen réaliste aujourd'hui est de faire fonctionner votre propre nœud complet. Toutefois, avec l'émergence des L2, faire fonctionner un nœud complet pour tout devient de plus en plus difficile. Ce qui équivaut à un client léger est la récupération d'information privée (PIR). Le PIR implique des serveurs qui conservent des copies de toutes les données et des clients qui envoient des requêtes cryptées au serveur. Le serveur exécute des calculs sur toutes les données, renvoie les données requises au client, et les crypte avec la clé du client, sans révéler au serveur quelles données le client a accédées.
Pour maintenir l'honnêteté des serveurs, les projets de bases de données eux-mêmes sont des branches Merkle, permettant ainsi au client de les vérifier à l'aide d'un client léger.
Le calcul du PIR (note de l'éditeur : généralement fait référence à la 'Récupération d'Information Privée', un protocole ou une technologie permettant aux utilisateurs de récupérer des informations d'une base de données sans révéler les informations récupérées) est très intensif. Il y a plusieurs façons de résoudre ce problème :
En utilisant la force brute : les améliorations des algorithmes ou du matériel dédié pourraient permettre au PIR de fonctionner suffisamment rapidement. Ces techniques peuvent dépendre du prétraitement : les serveurs peuvent stocker des données cryptées et mélangées pour chaque client, et le client peut interroger ces données. Le principal défi dans l'environnement Ethereum est d'adapter ces techniques à des ensembles de données en évolution rapide (comme dans un pays). Cela rend les coûts de calcul en temps réel plus bas, mais cela pourrait très probablement augmenter les coûts de calcul et de stockage globaux.
Atténuer les exigences de confidentialité : par exemple, il ne peut y avoir que 1 million de 'mixins' par recherche, donc le serveur saura qu'un client peut accéder à un million de valeurs possibles, mais ne saura rien de plus précis.
PIR multi-serveurs : si vous utilisez plusieurs serveurs, et que l'hypothèse d'honnêteté entre ces serveurs est de 1 sur N, alors l'algorithme PIR sera généralement plus rapide.
Anonymat plutôt que confidentialité : les requêtes peuvent être envoyées via un réseau de mixage, cachant ainsi l'expéditeur de la requête, mais pas le contenu de la requête. Cependant, faire cela efficacement augmentera inévitablement le délai, ce qui dégradera l'expérience utilisateur.
Trouver la bonne combinaison technologique dans un environnement Ethereum pour maximiser la confidentialité tout en maintenant l'utilité est une question de recherche ouverte, et j'encourage les cryptographes à essayer de le faire.
Portefeuille de clé de stockage idéal
Outre le transfert et l'accès aux états, un autre flux de travail important qui doit fonctionner de manière fluide dans un contexte inter-L2 est le changement de la configuration de validation d'un compte : que ce soit pour modifier sa clé (comme la récupération) ou apporter des modifications plus profondes à l'ensemble de la logique du compte. Il existe trois niveaux de solutions, classés par ordre croissant de difficulté :
Mise à jour des replays : lorsque l'utilisateur modifie sa configuration, le message autorisant ce changement sera rejoué sur chaque chaîne où le portefeuille détecte que l'utilisateur possède des actifs. Il est possible que le format de message et les règles de validation soient indépendants de la chaîne, permettant ainsi une répétition automatique sur autant de chaînes que possible.
Clé de stockage sur L1 : les informations de configuration résident sur L1, et les portefeuilles sur L2 utilisent L1S LOAD pour les lire ou un appel statique distant. Ainsi, il suffit de mettre à jour la configuration sur L1 pour que cela prenne effet automatiquement.
Clé de stockage sur L2 : les informations de configuration résident sur L2, et les portefeuilles sur L2 les lisent à l'aide de ZK-SNARK. Cela est similaire à (2), sauf que la mise à jour de la clé de stockage peut être moins chère, mais d'autre part, la lecture est plus coûteuse.
La solution (3) est particulièrement puissante car elle s'intègre bien à la confidentialité. Dans les 'solutions de confidentialité' normales, l'utilisateur possède un secret s, publie une 'valeur feuille' L sur la chaîne, et prouve que L = hash(s, 1) et N = hash(s, 2) pour certains secrets (jamais divulgués) qu'il contrôle. La valeur non valide N est publiée, rendant l'assurance que les dépenses futures de la même feuille échoueront sans divulguer L dépendante de la sécurité de l'utilisateur s. Une solution de confidentialité conviviale pour la récupération dirait que s est un emplacement (par exemple, une adresse et un emplacement de stockage) sur la chaîne, et l'utilisateur doit prouver la requête d'état : L = hash(sload(s), 1).
Sécurité des Dapp
Le maillon le plus faible en matière de sécurité des utilisateurs est souvent la dapp. La plupart du temps, les utilisateurs interagissent avec l'application en accédant à un site Web, le site télécharge implicitement le code d'interface utilisateur depuis le serveur en temps réel, puis l'exécute dans le navigateur. Si le serveur est piraté, ou si le DNS est piraté, l'utilisateur obtiendra une copie falsifiée de l'interface, ce qui pourrait l'inciter à effectuer des actions arbitraires. Des fonctionnalités de portefeuille comme la simulation de transactions sont très utiles pour réduire les risques, mais elles sont encore loin d'être parfaites.
Idéalement, nous transférerons l'écosystème vers un contrôle de version de contenu sur chaîne : les utilisateurs accéderont à dapp via leur nom ENS, qui contiendra la valeur de hachage IPFS de l'interface. La mise à jour de l'interface nécessitera une transaction sur chaîne provenant d'une signature multiple ou d'un DAO. Le portefeuille montrera aux utilisateurs s'ils interagissent avec une interface sur chaîne plus sécurisée ou une interface Web2 moins sécurisée. Le portefeuille pourra également indiquer aux utilisateurs s'ils interagissent avec une chaîne sécurisée (par exemple, phase 1+, audits de sécurité multiples).
Pour les utilisateurs soucieux de leur confidentialité, le portefeuille peut également ajouter un mode paranoïaque, exigeant que l'utilisateur clique pour accepter les requêtes HTTP, et pas seulement les opérations web3 :
Modèle d'interface possible pour le mode paranoïaque
Une approche plus avancée consiste à dépasser HTML + Javascript et à écrire la logique métier de la dapp dans un langage dédié (qui pourrait être une couche relativement mince sur Solidity ou Vyper). Ensuite, le navigateur peut générer automatiquement l'interface utilisateur pour toutes les fonctionnalités nécessaires. OKContract fait déjà cela.
Une autre direction est la défense de l'information économique cryptographique : les développeurs d'applications décentralisées (dapp), les entreprises de sécurité, les déployeurs de chaînes et d'autres peuvent établir une obligation, qui sera payée aux utilisateurs affectés (déterminés) par un DAO de règlement sur chaîne si la dapp est piratée ou nuit aux utilisateurs de manière hautement trompeuse. Le portefeuille peut montrer aux utilisateurs un score basé sur la taille de l'obligation.
Un avenir plus lointain
Tout ce qui précède a été fait dans le contexte d'interfaces traditionnelles, où il s'agit de pointer et de cliquer sur des objets et de saisir des choses dans des champs de texte. Cependant, nous sommes également à un tournant où un changement de paradigme plus profond se produit :
Intelligence artificielle, ce qui pourrait nous amener à passer du paradigme de la frappe par clic à un paradigme où 'vous dites ce que vous voulez faire, et le robot s'en occupe'
Interfaces cerveau-machine, avec des méthodes 'douces' comme le suivi des yeux, ainsi que des technologies plus directes et même invasives (voir : le premier patient Neuralink cette année)
Défense proactive du client : le navigateur Brave protège activement les utilisateurs contre les publicités, les traqueurs et de nombreux autres objets indésirables. De nombreux navigateurs, plugins et portefeuilles de cryptomonnaies disposent de toute une équipe dédiée à la protection des utilisateurs contre diverses menaces à la sécurité et à la confidentialité. Ces 'gardiens actifs' ne feront que devenir plus puissants au cours des dix prochaines années.
Ces trois tendances entraîneront une réflexion plus approfondie sur la façon dont les interfaces fonctionnent. Grâce à l'entrée en langage naturel, au suivi des yeux ou à des interfaces cerveau-machine plus directes, associées à votre historique (peut-être incluant des SMS, tant que toutes les données sont traitées localement), le 'portefeuille' pourra comprendre clairement et intuitivement ce que vous voulez faire. Ensuite, l'intelligence artificielle pourra traduire cette intuition en un 'plan d'action' concret : une série d'interactions sur et hors chaîne pour réaliser ce que vous souhaitez. Cela pourrait considérablement réduire le besoin d'interfaces utilisateur tierces. Si les utilisateurs interagissent avec des applications tierces (ou d'autres utilisateurs), l'intelligence artificielle devrait agir en représentant l'utilisateur, en identifiant toute menace et en proposant un plan d'action pour éviter cette menace. Idéalement, ces intelligences artificielles devraient avoir un écosystème ouvert, produit par différents groupes ayant des biais et des structures d'incitation variés.
Ces idées plus radicales reposent sur des technologies qui sont aujourd'hui très immatures, donc je ne mettrais pas mes actifs dans des portefeuilles qui en dépendent aujourd'hui. Cependant, des choses similaires semblent être une tendance future évidente, donc il vaut la peine de commencer à explorer cela de manière plus proactive.
