Titre original : Ce que j'aimerais voir dans un portefeuille
Auteur : Vitalik, fondateur d'Ethereum ; Compilation : Deng Tong, Jinse Finance
Un grand merci à Liraz Siri, Yoav Weiss ainsi qu'aux développeurs d'ImToken, Metamask et OKX pour leurs retours et leurs révisions.
Une couche clé de l'infrastructure de la pile Ethereum est le portefeuille, mais elle est souvent sous-estimée par les chercheurs et développeurs L1. Le portefeuille est la fenêtre entre l'utilisateur et le monde Ethereum, et l'utilisateur ne peut 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 que si le portefeuille lui-même possède également ces propriétés.
Récemment, nous avons vu de grands progrès des portefeuilles Ethereum en matière d'expérience utilisateur, de sécurité et de fonctionnalités. Le but de cet article est de donner mon propre avis sur certaines des caractéristiques que devrait posséder un portefeuille Ethereum idéal. Ce n'est pas une liste exhaustive ; elle reflète mes tendances de cypherpunk, axées sur la sécurité et la confidentialité, et il est presque certain qu'elle n'est pas complète en ce qui concerne l'expérience utilisateur. Cependant, je pense que la liste des souhaits est moins efficace pour optimiser l'expérience utilisateur que de simplement déployer et itérer en fonction des retours, donc je pense que se concentrer sur les attributs de sécurité et de confidentialité est le plus précieux.
Expérience utilisateur à travers les transactions L2
Il existe maintenant une feuille de route de plus en plus détaillée pour améliorer l'expérience utilisateur inter-L2, avec des parties à court et à long terme. Ici, je vais parler de la partie à court terme : des idées qui, théoriquement, peuvent encore être mises en œuvre aujourd'hui.
L'idée centrale est (i) d'intégrer des envois inter-chaînes, 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 :
0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045@optimism.eth
Lorsque quelqu'un (ou certaines applications) vous fournit une adresse dans ce format, vous devriez pouvoir la coller dans le champ "destinataire" du portefeuille, puis cliquer sur "envoyer". Le portefeuille devrait automatiquement traiter les données envoyées de la manière la plus efficace possible :
Si vous avez déjà suffisamment de types de jetons requis sur la chaîne cible, envoyez directement les jetons ;
Si vous avez des jetons requis sur une autre chaîne (ou plusieurs autres chaînes), utilisez des protocoles tels que l'ERC-7683 (qui est en réalité un DEX inter-chaînes) pour envoyer les jetons ;
Si vous avez des jetons de types différents sur la même chaîne ou sur d'autres chaînes, utilisez une bourse décentralisée pour les convertir en jetons du bon type sur la bonne chaîne et les envoyer. Cela devrait nécessiter l'autorisation explicite de l'utilisateur : l'utilisateur verra combien de frais ils ont payés et combien le receveur a reçu.
Modèle d'interface possible pour un portefeuille avec prise en charge des adresses inter-chaînes
Ce qui précède s'applique au cas d'utilisation "Vous copiez et collez une adresse (ou ENS, par exemple, vitalik.eth@optimism.eth) pour que quelqu'un vous paie". Si le dapp demande un dépôt (voir par exemple l'exemple de Polymarket), alors le flux idéal consiste à étendre l'API web3 et à permettre au dapp de faire des demandes de paiement spécifiques à la chaîne. Ensuite, votre portefeuille sera capable de satisfaire cette demande de toutes les manières nécessaires. Pour que l'expérience utilisateur soit bonne, il faut également normaliser les demandes getAvailableBalance, et le portefeuille doit sérieusement considérer sur quelles chaînes il stocke par défaut les actifs des utilisateurs, afin de maximiser la sécurité et la facilité des transferts.
Les demandes de paiement spécifiques à la chaîne peuvent également être intégrées dans des codes QR, que les portefeuilles mobiles peuvent scanner. Dans les scénarios de paiement face à face (ou en ligne), le receveur émettra un code QR ou un appel API web3 indiquant "Je veux X unités de jeton Y sur la chaîne Z, avec l'ID de référence ou le rappel W", 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éclamer un certain montant de fonds de son contrat sur la chaîne, il appartient au receveur de savoir comment transférer ces fonds sur son compte.
Un autre sujet pertinent est le paiement de Gas. Si vous recevez des actifs sur un L2 où vous n'avez pas d'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 le Gas sur la chaîne où vous avez de l'ETH. Si le portefeuille souhaite que vous réalisiez davantage de transactions à l'avenir sur L2, il devrait également utiliser uniquement DEX pour envoyer. Des ETH d'une valeur de plusieurs millions de Gas, afin que les transactions futures puissent directement y dépenser du Gas (car cela est moins coûteux).
Sécurité des comptes
Une façon de conceptualiser le défi de la sécurité des comptes est qu'un bon portefeuille devrait agir sur deux fronts : (i) protéger les utilisateurs contre les hackers ou attaques malveillantes des développeurs de portefeuille et (ii) protéger les utilisateurs contre les erreurs qu'ils pourraient commettre.
L'"erreur" à gauche est involontaire. Cependant, quand je l'ai vu, j'ai réalisé qu'elle s'adapte très bien au contexte, alors j'ai décidé de la conserver.
Pendant plus d'une décennie, ma solution préférée a été la récupération sociale et les portefeuilles multi-signatures avec contrôle d'accès hiérarchique. Les comptes des utilisateurs ont 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) changer 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 verrouillage temporel.
Les éléments ci-dessus constituent la conception de base, qui peut être étendue. Les mécanismes d'autorisation tels que les clés de session et l'ERC-7715 peuvent aider à soutenir un équilibre différent entre la commodité et la sécurité des différentes applications. Des architectures de gardiens plus complexes, comme celles ayant plusieurs durées de verrouillage temporel à différents seuils, peuvent aider à maximiser les chances de récupérer un compte légitime avec succès tout en minimisant les risques de vol.
Qui ou quoi devrait être le gardien ?
Pour les utilisateurs de cryptomonnaies expérimentés au sein de 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 ils sont les uns des autres. S'ils ne vous ont pas donné d'informations, la probabilité qu'ils conspirent est très faible. Cependant, cette option n'est pas disponible pour la plupart des nouveaux utilisateurs.
Une seconde option est celle des gardiens institutionnels : des entreprises qui fournissent des services et ne signeront une transaction que lorsqu'elles ont une confirmation supplémentaire de votre demande. Un code de confirmation ou un appel vidéo pour les utilisateurs de haute valeur. Cela fait longtemps que les gens essaient de créer ces choses. J'ai introduit CryptoCorp en 2013. Cependant, jusqu'à présent, ces types d'entreprises n'ont pas très bien réussi.
Une troisième option est d'utiliser plusieurs appareils personnels (comme un téléphone, un bureau, un portefeuille matériel). Cela est faisable, mais difficile à configurer et à gérer pour les utilisateurs inexpérimentés. Il existe également un risque de perte ou de vol d'appareils, surtout s'ils se trouvent au même endroit.
Récemment, nous commençons à voir de plus en plus de portefeuilles basés sur des clés. Les clés ne peuvent être sauvegardées que sur votre appareil, ce qui en fait une solution personnelle, ou sauvegardées dans le cloud, ce qui rend leur sécurité dépendante d'un mélange complexe d'hypothèses de sécurité liées aux clés, institutionnelles et matérielles de confiance. En réalité, pour l'utilisateur moyen, les clés représentent un gain de sécurité précieux, mais elles ne suffisent pas à protéger les économies de toute une vie de l'utilisateur.
Heureusement, avec ZK-SNARK, nous avons une quatrième option : l'ID centralisé enveloppé dans ZK. Ce type inclut 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, que 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 d'options, et l'ID centralisé enveloppé dans ZK a une "convivialité unique pour les débutants".
Pour cela, cela nécessite d'être réalisé par une UI simplifiée et intégrée : vous devriez pouvoir spécifier simplement que vous voulez "example@gmail.com" comme gardien, et cela devrait automatiquement générer l'adresse zk-email Ethereum correspondante sous le capot. Les utilisateurs avancés devraient pouvoir entrer leur e-mail (et éventuellement une valeur de sel de confidentialité sauvegardée 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 le cas pour tout autre type de gardien pris en charge.
Modèle d'interface de sécurité possible
Veuillez noter qu'un défi pratique auquel le zk-email est confronté aujourd'hui est qu'il dépend de la signature DKIM, qui utilise une clé qui est renouvelée tous les quelques mois, et que ces clés elles-mêmes ne sont pas signées par aucune autre entité. Cela signifie que le zk-email d'aujourd'hui a un certain niveau d'exigence de confiance qui dépasse le fournisseur lui-même ; si le zk-email utilise TLSNotary sur du matériel de confiance pour vérifier la clé mise à jour, cela pourrait réduire cette situation, mais ce n'est pas idéal. J'espère que les fournisseurs d'e-mails commenceront à signer directement leurs clés DKIM. Aujourd'hui, je recommande à un gardien d'utiliser le zk-email, mais je ne recommande pas à la plupart des gardiens de l'utiliser : ne stockez pas de fonds dans le zk-email endommagé, ce qui signifie que vous ne pouvez pas utiliser les fonds dans la configuration.
Nouveaux utilisateurs et portefeuilles intégrés aux applications
Les nouveaux utilisateurs ne veulent en réalité pas entrer un grand nombre de gardiens lors de leur première expérience d'inscription. Par conséquent, le portefeuille devrait leur offrir une option très simple. Une manière naturelle de le faire 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 effectuer un choix 2-of-3. À mesure que l'utilisateur gagne en expérience ou accumule plus d'actifs, il devrait être invité à ajouter plus de gardiens à un moment donné.
L'intégration des portefeuilles dans les applications est inévitable, car les applications qui tentent d'attirer des utilisateurs non cryptographiques ne souhaitent pas que les utilisateurs téléchargent simultanément deux nouvelles applications (l'application elle-même, plus le portefeuille Ethereum), ce qui compliquerait l'expérience utilisateur. Cependant, de nombreux utilisateurs de portefeuilles d'applications devraient pouvoir lier tous leurs portefeuilles ensemble, afin qu'ils n'aient à se soucier que d'un seul "problème de contrôle d'accès". La manière la plus simple de le faire est d'adopter une approche hiérarchique, où il y a un processus "lien" rapide permettant aux utilisateurs de définir leur portefeuille principal comme gardien de tous les portefeuilles intégrés aux applications. 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 escroqueries et autres menaces externes
Au-delà de la sécurité des comptes, les portefeuilles d'aujourd'hui font également beaucoup pour identifier les adresses fausses, le phishing, les escroqueries et d'autres menaces externes, et s'efforcent de protéger les utilisateurs contre de telles menaces. Pendant ce temps, de nombreuses contre-mesures restent assez primitives : par exemple, exiger un clic pour envoyer de l'ETH ou d'autres jetons à toute nouvelle adresse, que vous envoyiez 100 dollars ou 100 000 dollars. Il n'existe pas de solution unique ici. Il s'agit d'une série de correctifs et d'améliorations progressives et lentes pour différentes catégories de menaces. Cependant, continuer à s'efforcer d'améliorer ici a beaucoup de valeur.
Confidentialité
Il est temps de commencer à prendre plus au sérieux la confidentialité sur Ethereum. La technologie ZK-SNARK est désormais très avancée, et les techniques de protection de la vie privée ne reposant pas sur des 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 secondaires telles que 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 et utilisent explicitement un "portefeuille de confidentialité", tel que Railway (ou Umbra pour les adresses invisibles). Cela engendre un grand inconvénient 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 comme "solde privé" dans un pool de confidentialité. Lorsque l'utilisateur effectue un transfert, il sort d'abord automatiquement du pool de confidentialité. Si l'utilisateur doit recevoir des fonds, le portefeuille peut automatiquement générer une adresse invisible.
De plus, le portefeuille pourrait générer automatiquement une nouvelle adresse pour chaque application à laquelle l'utilisateur participe (par exemple, un protocole DeFi). Les dépôts proviendront d'un pool de confidentialité, et les retraits iront directement dans ce pool de confidentialité. Cela permet de dissocier l'activité de l'utilisateur dans une application de son activité dans d'autres applications.
Un avantage de cette technologie est qu'elle représente non seulement un moyen naturel de transférer des actifs de manière à préserver la vie privée, mais aussi un moyen naturel de préserver l'identité de manière privée. L'identité a déjà eu lieu sur la chaîne : toute application utilisant un contrôle d'accès basé sur une identification (comme Gitcoin Grants), tout chat contrôlé par un jeton, le protocole Ethereum, etc., est une identité sur la chaîne. Nous voulons que cet écosystème protège également la vie privée. Cela signifie que l'activité des utilisateurs sur la chaîne ne devrait pas être collectée en un seul endroit : chaque projet devrait être stocké séparément, et le portefeuille de l'utilisateur devrait être la seule chose ayant une "vue globale" capable de voir toutes vos preuves simultanément. Un écosystème multi-comptes natif par utilisateur aide à atteindre cet objectif, tout comme des protocoles de preuve hors chaîne tels qu'EAS et Zupass.
Cela représente une vision pragmatique de la confidentialité d'Ethereum à moyen terme. Bien que certaines fonctionnalités puissent être introduites sur L1 et L2 pour rendre la protection de la vie privée des transferts plus efficace et fiable, cela peut déjà être réalisé maintenant. Certains défenseurs de la vie privée estiment que la seule chose acceptable est la confidentialité totale de tout : chiffrer l'ensemble de l'EVM. Je pense que cela pourrait être le résultat idéal à long terme, mais cela nécessiterait une réévaluation plus fondamentale du modèle de programmation, et il n'est pas encore à un niveau de maturité prêt pour le déploiement sur Ethereum. Nous avons effectivement besoin d'une confidentialité par défaut pour obtenir un ensemble d'anonymat suffisamment grand. Cependant, se concentrer d'abord sur (i) les transferts entre comptes, et (ii) l'identité et les cas d'utilisation associés à l'identité (comme les preuves privées) est une première étape pragmatique, plus facile à réaliser, et que le portefeuille peut commencer à utiliser dès maintenant.
Le portefeuille Ethereum doit également devenir un portefeuille de données
Une conséquence de toute solution de confidentialité efficace est qu'elle générera un besoin pour l'utilisateur de stocker des données hors chaîne. Cela est évident dans Tornado Cash, qui demande aux utilisateurs de conserver des "tickets" représentant des dépôts de 0,1 à 100 ETH. Les protocoles de confidentialité plus modernes conservent parfois des données cryptées sur la chaîne et les décryptent à l'aide d'une seule clé privée. Cela est risqué, car si la clé est compromise, ou si des ordinateurs quantiques deviennent viables, toutes les données seront rendues publiques. Les preuves hors chaîne comme EAS et Zupass rendent la nécessité de stockage de données hors chaîne encore plus évidente.
Un portefeuille doit non seulement devenir un logiciel de stockage d'accès à la chaîne, mais aussi un logiciel de stockage de vos données personnelles. 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 l'assurance robuste du contrôle d'accès, nous devons également les résoudre autour de l'assurance robuste de l'accessibilité des données et de leur non-divulgation. Peut-être que ces solutions peuvent se superposer : si vous avez N gardiens, utilisez un partage de secret M-of-N entre ces N gardiens pour stocker vos données. Il est par nature plus difficile de protéger les données, car vous ne pouvez pas révoquer la part de données de quelqu'un, mais nous devrions proposer des solutions d'hébergement décentralisées aussi sûres que possible.
Accès sécurisé à la chaîne
Aujourd'hui, les portefeuilles font confiance à leurs fournisseurs RPC pour leur fournir toute information concernant la chaîne. C'est une faille, avec deux aspects :
Les fournisseurs RPC pourraient 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 avec lesquelles l'utilisateur interagit et d'autres comptes
Idéalement, nous voulons colmater ces deux failles. Pour résoudre le premier problème, nous avons besoin de clients légers standardisé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 également fait des travaux préliminaires pour soutenir certains L2 spécifiques. Pour couvrir correctement tous les L2, nous avons besoin d'une norme selon laquelle les contrats de configuration, représentant L2 (également utilisés pour les adresses spécifiques à la chaîne), peuvent déclarer une fonction, peut-être d'une manière similaire à l'ERC-3668, incluant l'obtention des racines d'état les plus récentes et prouvant et recevant en fonction de ces racines d'état. Cela nous permettrait d'avoir un client léger universel, permettant au portefeuille de vérifier en toute sécurité tout état ou événement sur L1 et L2.
Pour la confidentialité, la seule méthode réaliste aujourd'hui est d'exécuter votre propre nœud complet. Cependant, maintenant que L2 entre dans le champ de vision, il devient de plus en plus difficile d'exécuter un nœud complet pour tout. Ce qui équivaut à un client léger ici est la recherche d'informations privées (PIR). Le PIR implique des serveurs qui conservent des copies de toutes les données et un client qui envoie des requêtes cryptées aux serveurs. Le serveur effectue des calculs sur toutes les données, retourne les données requises au client, et crypte celles-ci avec la clé du client, sans révéler au serveur quelle donnée le client a accédée.
Pour maintenir l'honnêteté des serveurs, les différents projets de base de données sont eux-mêmes des branches Merkle, de sorte que le client peut les vérifier avec un client léger.
Le volume de calcul pour le PIR est très élevé. Il existe plusieurs façons de résoudre ce problème :
Force brute : les améliorations des algorithmes ou du matériel dédié pourraient rendre le PIR suffisamment rapide. Ces techniques pourraient dépendre de prétraitements : les serveurs peuvent stocker des données cryptées et brouillées pour chaque client, et le client peut interroger ces données. Le principal défi dans l'environnement Ethereum est d'adapter ces technologies aux ensembles de données en rapide évolution (comme un pays). Cela rend le coût de calcul en temps réel plus bas, mais pourrait augmenter le coût total de calcul et de stockage.
Atténuer les exigences de confidentialité : par exemple, il ne peut y avoir qu'un million de "mixins" par recherche, de sorte que le serveur sache quels millions de valeurs possibles le client peut accéder, mais ne sache rien de plus fin.
PIR multi-serveurs : si vous utilisez plusieurs serveurs, et que l'hypothèse d'honnêteté entre ces serveurs est de 1-of-N, alors l'algorithme PIR sera généralement plus rapide.
Anonymat plutôt que confidentialité : les requêtes peuvent être envoyées via mixnet, dissimulant ainsi l'expéditeur de la requête sans cacher le contenu de la requête. Cependant, le faire efficacement augmentera inévitablement la latence, ce qui dégradera l'expérience utilisateur.
Trouver la bonne combinaison de technologies dans l'environnement Ethereum pour maximiser la confidentialité tout en maintenant la praticité est une question de recherche ouverte, et j'encourage les cryptographes à essayer de le faire.
Portefeuille idéal de coffre-fort
En plus du transfert et de l'accès à l'état, un autre flux de travail important qui doit fonctionner sans heurts dans un contexte inter-L2 est le changement de la configuration de validation des comptes : que ce soit pour changer sa clé (comme la récupération) ou pour effectuer des changements plus profonds dans toute la logique du compte. Il existe trois solutions de niveau, classées par ordre croissant de difficulté :
Replays de mise à jour : lorsque l'utilisateur change sa configuration, le message autorisant ce changement sera replays sur chaque chaîne où le portefeuille détecte que l'utilisateur possède des actifs. Il est possible que le format du message et les règles de validation soient indépendants de la chaîne, permettant ainsi un replay automatique sur autant de chaînes que possible.
Clé de coffre-fort sur L1 : les informations de configuration sont situées sur L1, et le portefeuille sur L2 utilise L1SLOAD ou REMOTESTATICCALL pour les lire. Ainsi, il suffit de mettre à jour la configuration sur L1, et celle-ci sera automatiquement appliquée.
Clé de coffre-fort sur L2 : les informations de configuration résident sur L2, et le portefeuille sur L2 les lit en utilisant ZK-SNARK. Cela est similaire à (2), sauf que les mises à jour de coffre-fort peuvent être moins coûteuses, mais d'autre part, la lecture est plus coûteuse.
La solution (3) est particulièrement puissante, car elle s'intègre bien dans la confidentialité. Dans les "solutions de confidentialité" normales, l'utilisateur a un secret s, "valeur feuille" L publiée sur la chaîne, et l'utilisateur prouve que L = hash(s, 1) et N = hash(s, 2) pour certains secrets (jamais révélés) qu'il contrôle. N, l'invalidateur, est publié, garantissant que les dépenses futures de la même feuille échouent sans divulguer L. Cela dépend de l'utilisateur pour garantir la sécurité de s. Une solution de confidentialité conviviale dirait : s est une position sur la chaîne (comme une adresse et un emplacement de stockage), et l'utilisateur doit prouver une requête d'état : L = hash(sload(s), 1).
Sécurité des dapps
Le maillon le plus faible en matière de sécurité des utilisateurs est souvent le dapp. La plupart du temps, les utilisateurs interagissent avec les applications en accédant à des sites web, qui téléchargent implicitement le code de l'interface utilisateur en temps réel depuis le serveur, puis l'exécutent dans le navigateur. Si le serveur est piraté, ou si le DNS est attaqué, l'utilisateur obtiendra une copie fausse de l'interface, ce qui pourrait inciter l'utilisateur à effectuer des actions non désirées. Des fonctionnalités de portefeuille telles que la simulation de transactions sont très utiles pour réduire les risques, mais elles sont encore loin d'être parfaites.
Idéalement, nous déplacerions l'écosystème vers le contrôle de version de contenu sur la chaîne : les utilisateurs accéderaient au dapp via leur nom ENS, qui contiendrait le hachage IPFS de l'interface. La mise à jour de l'interface nécessiterait une transaction sur la chaîne provenant d'une signature multiple ou d'une DAO. Le portefeuille montrerait aux utilisateurs s'ils interagissent avec une interface sur la chaîne plus sécurisée ou une interface Web2 moins sécurisée. Le portefeuille pourrait également montrer 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 vie privée, le portefeuille pourrait é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 un mode paranoïaque
Une approche plus avancée consiste à aller au-delà de HTML + Javascript et à écrire la logique métier du dapp dans un langage dédié (peut-être une couche relativement mince sur Solidity ou Vyper). Ensuite, le navigateur pourrait automatiquement générer l'UI pour toute fonctionnalité requise. OKContract a déjà commencé à le faire.
Une autre direction est la défense des informations économiques cryptographiques : les développeurs de dapp, les entreprises de sécurité, les déployeurs de chaînes et d'autres peuvent établir une garantie, si le dapp est piraté ou nuit aux utilisateurs de manière très trompeuse, cette garantie sera versée aux utilisateurs concernés. Cela serait géré par certaines DAO de règlement sur la chaîne. Le portefeuille pourrait afficher un score basé sur la taille de la garantie.
Un avenir à plus long terme
Tout ce qui précède se déroule dans le contexte d'interfaces traditionnelles, impliquant de pointer et de cliquer sur des choses et d'entrer des choses dans des champs de texte. Cependant, nous sommes également à un tournant où un changement de paradigme plus profond se profile :
Intelligence artificielle, ce qui pourrait nous amener à passer du paradigme de la frappe par clic à celui de "dites ce que vous voulez faire, le robot s'en occupera" ;
Interfaces cerveau-machine, avec des méthodes "douces" comme le suivi oculaire, ainsi que des technologies plus directes et même invasives (voir : le premier patient de Neuralink cette année) ;
Défense proactive du client : le navigateur Brave protège activement les utilisateurs contre la publicité, les traceurs et de nombreux autres objets nuisibles. De nombreux navigateurs, plugins et portefeuilles cryptographiques ont des équipes entières consacrées à protéger les utilisateurs contre diverses menaces de sécurité et de confidentialité. Ces "gardiens proactifs" deviendront de plus en plus puissants au cours de la prochaine décennie.
Ces trois tendances conduiront ensemble à une réflexion plus approfondie sur la manière dont les interfaces fonctionnent. Grâce à des entrées en langage naturel, au suivi oculaire, ou finalement à des interfaces cerveau-machine plus directes et même invasives (voir : le premier patient de Neuralink cette année), ajoutées à votre historique (peut-être incluant des SMS, tant que toutes les données sont traitées localement), le "portefeuille" pourrait comprendre clairement et intuitivement ce que vous voulez faire. Ensuite, l'intelligence artificielle pourrait transformer cette intuition en un "plan d'action" concret : une série d'interactions sur la chaîne et hors chaîne pour accomplir ce que vous souhaitez. Cela pourrait considérablement réduire la nécessité d'interfaces utilisateur tierces. Si les utilisateurs interagissent effectivement avec des applications tierces (ou d'autres utilisateurs), l'intelligence artificielle devrait penser de manière antagoniste au nom des utilisateurs, identifier toute menace et proposer un plan d'action pour éviter les menaces. Idéalement, ces intelligences artificielles devraient avoir un écosystème ouvert, produit par différents groupes ayant des biais et des structures d'incitation différents.
Ces idées plus radicales dépendent de technologies aujourd'hui extrêmement immatures, donc je ne mettrais pas mes actifs dans un portefeuille qui en dépend. Cependant, il semble évident que des choses similaires sont les tendances futures, donc cela vaut la peine de commencer à explorer plus activement dans cette direction.
