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 cross-L2, qui comporte une partie à court terme et une partie à long terme. Ici, je vais parler de la partie à court terme: des idées qui sont théoriquement réalisables dès aujourd'hui.

Les idées principales sont (i) les envois intégrés entre L2 et (ii) les adresses et demandes de paiement spécifiques à chaque chaîne. Votre portefeuille devrait être capable de vous fournir une adresse (suivant le style de ce projet ERC) ressemble à ceci:

0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045@optimism.eth

Quand quelqu'un (ou une application) vous donne une adresse de ce format, vous devriez pouvoir la coller dans le champ "à" d'un portefeuille et cliquer sur "envoyer". Le portefeuille devrait automatiquement traiter cet envoi de la manière qu'il peut :

• Si vous avez déjà suffisamment de coins du type requis sur la chaîne de destination, envoyez directement les coins
• Si vous avez des pièces du type requis sur une autre chaîne (ou plusieurs autres chaînes), utilisez un protocole comme gate.ioERC-7683 (effectivement un DEX inter-chaînes) pour envoyer les coins
• Si vous avez des pièces d'un type différent sur la même chaîne ou sur d'autres chaînes, utilisez des échanges décentralisés pour les convertir en le bon type de pièce sur la bonne chaîne et les envoyer. Cela devrait nécessiter une autorisation explicite de l'utilisateur : l'utilisateur verrait combien de ce qu'il paie, et combien le destinataire reçoit.

Maquette d'une interface de portefeuille possible avec prise en charge d'adresse inter-chaîne

Ce qui précède concerne le « vous copiez-collez une adresse (ou ENS, par exemple, vitalik.eth@optimism.eth) pour que quelqu’un vous paie ». Si une dapp demande un dépôt (par exemple, voir cet exemple de Polymarket) puis le flux idéal consiste à étendre l'API web3 et permettre à l'application décentralisée de faire une demande de paiement spécifique à la chaîne. Votre portefeuille serait alors en mesure de satisfaire cette demande de la manière dont il en a besoin. Pour que l'expérience utilisateur fonctionne bien, il faudrait également standardiser une demande de solde disponible, et les portefeuilles devraient réfléchir sérieusement aux chaînes sur lesquelles ils stockent les actifs des utilisateurs par défaut pour 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 un scénario de paiement aux consommateurs en personne (ou en ligne), le destinataire créerait un code QR ou appellerait l'API web3 qui dit "Je veux X unités de token Y sur la chaîne Z, avec l'ID de référence ou le rappel W", et le portefeuille serait libre de satisfaire cette demande de la manière qu'il peut. Une autre option est un protocole de lien de réclamation, où le portefeuille de l'utilisateur génère un code QR ou une URL qui contient une autorisation pour réclamer une certaine quantité de fonds de leur contrat onchain, et c'est au destinataire de trouver comment déplacer ensuite ces fonds vers leur propre portefeuille.

Un autre sujet connexe est celui des paiements de gaz. Si vous recevez des actifs sur un L2 où vous n'avez pas encore d'ETH et que vous devez envoyer une transaction sur ce L2, un portefeuille devrait être en mesure d'utiliser automatiquement un protocole (par exemple, RIP-7755) payer le gaz sur une chaîne où vous avez de l'ETH. Si le portefeuille s'attend à ce que vous effectuiez d'autres transactions sur ce L2 à l'avenir, il devrait également simplement utiliser un DEX pour envoyer par exemple quelques millions de gaz d'ETH, afin que les transactions futures puissent dépenser le gaz directement là-bas (ce qui est moins cher).

Sécurité du compte

Une façon dont je conceptualise le défi de la sécurité du compte est qu'un bon portefeuille devrait être bon dans deux domaines simultanément : (i) protéger l'utilisateur contre le piratage ou la malveillance du développeur du portefeuille, et (ii) protéger l'utilisateur contre ses propres erreurs.

La faute de frappe "mistakles" à gauche était involontaire. Cependant, en la voyant, j'ai réalisé qu'elle était parfaitement appropriée pour le contexte, alors j'ai décidé de la garder.

Ma solution préférée à cela, pour surdixannées, a été la récupération sociale et les portefeuilles multisig, avec un contrôle d'accès gradué. Le compte d'un utilisateur dispose de deux couches 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 majorité des gardiens est nécessaire pour effectuer soit (i) des opérations de grande valeur, comme envoyer toute la valeur du compte, soit (ii) changer la clé principale ou l'un des gardiens. Si désiré, la clé principale peut être autorisée à effectuer des opérations de grande valeur avec un verrouillage temporel.

Ce qui précède est une conception de base et peut être augmenté. Des clés de session et des mécanismes d'autorisation tels queERC-7715, peut aider à soutenir différents équilibres entre la commodité et la sécurité pour différentes applications. Des architectures de gardien plus compliquées, telles que l'utilisation de multiples durées de verrouillage temporel à différents seuils, peuvent aider à maximiser les chances de récupération légitime du compte tout en minimisant le risque de vol.

Qui ou quoi devraient être les gardiens ?

Pour un utilisateur de crypto expérimenté qui se trouve au sein d'une communauté d'utilisateurs de crypto expérimentés, une option viable est les clés de vos amis et de votre famille. Si vous demandez à chacun d'entre eux 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. La chance qu'ils collaborent sans que l'un d'entre eux ne vous prévienne est minime. Pour la plupart des nouveaux utilisateurs, cependant, cette option n'est pas disponible.

Une deuxième option est les gardiens institutionnels : des entreprises spécialisées dans la réalisation du service de signer uniquement une transaction si elles reçoivent une autre confirmation qu'une demande provient de vous : par exemple, un code de confirmation ou, pour les utilisateurs à forte valeur, un appel vidéo. Les gens ont essayé de les créer depuis longtemps, par exemple, J'ai profilé CryptoCorp en 2013. Cependant, jusqu'à présent, de telles entreprises n'ont pas été très réussies.

Une troisième option consiste à utiliser plusieurs appareils personnels (par exemple un téléphone, un ordinateur de bureau, un portefeuille matériel). Cela peut fonctionner, mais c'est aussi difficile à configurer et à gérer pour les utilisateurs inexpérimentés. Il y a aussi un risque que les appareils soient perdus ou volés en même temps, surtout s'ils se trouvent au même endroit.

Récemment, nous avons commencé à voir de plus en plus de portefeuilles basés sur des passkeys. Les passkeys peuvent être sauvegardés uniquement sur vos appareils, ce qui en fait un type de solution personnelle, ou sauvegardés dans le cloud, ce qui rend leur sécurité dépendante d'une compliqué hybridede la sécurité des mots de passe, des hypothèses matérielles institutionnelles et de confiance. De manière réaliste, les clés d'accès sont un gain de sécurité précieux pour les utilisateurs ordinaires, mais elles ne sont pas suffisamment solides pour protéger à elles seules les économies de toute une vie d'un utilisateur.

Heureusement, avec ZK-SNARKs, nous avons une quatrième option : ZK-wrapped identifiant centralisé. Ce genre inclut zk-email, Anon Aadhaar, Portefeuille Myna, et bien d'autres. Fondamentalement, vous pouvez prendre de nombreuses formes d'identité centralisée (d'entreprise ou gouvernementale) et la transformer en une adresse Ethereum, à partir de laquelle vous ne pouvez envoyer des transactions qu'en générant une preuve de possession de l'identité centralisée avec ZK-SNARK.

Avec cet ajout, nous avons maintenant une large gamme d'options, et l'identification centralisée enveloppée de ZK est unique et conviviale pour les débutants.

Pour que cela fonctionne, il doit être implémenté avec une interface utilisateur rationalisée et intégrée: vous devriez être capable de spécifier simplement que vous voulez " example@gmail.com" en tant que gardien, et il devrait automatiquement générer l'adresse Ethereum zk-email correspondante sous le capot. Les utilisateurs avancés devraient pouvoir entrer leur adresse e-mail (ainsi qu'une valeur de sel pour la confidentialité, qui serait enregistrée dans cet e-mail) dans une application tierce open-source et confirmer que l'adresse générée est correcte. Il en va de même pour tout autre type de gardien pris en charge.

Maquette de l'interface Safe possible

Notez qu'aujourd'hui, un défi pratique avec le zk-email en particulier est qu'il dépend designatures DKIM, qui utilisent des clés qui sont tournées une fois tous les quelques mois, et ces clés ne sont pas elles-mêmes signées par une autre autorité. Cela signifie que zk-email a aujourd'hui un certain niveau d'exigence de confiance au-delà du fournisseur lui-même; cela pourrait être réduit si zk-email utilisait TLSNotaryà l'intérieur du matériel de confiance pour vérifier les clés mises à jour, mais ce n'est pas idéal. Espérons que les fournisseurs de messagerie commenceront à signer directement leurs clés DKIM. Aujourd'hui, je recommanderais d'utiliser le zk-email pour un gardien, mais pas pour la majorité de vos gardiens : ne stockez pas de fonds dans une configuration où la rupture du zk-email signifie que vous perdez l'accès à vos fonds.

Nouveaux utilisateurs et portefeuilles dans l'application

Les nouveaux utilisateurs ne voudront pas réaliste avoir à entrer un grand nombre de gardiens lors de leur première expérience d'inscription. Par conséquent, les portefeuilles devraient leur offrir une option très simple. Une voie naturelle est un 2-sur-3 utilisant zk-email sur leur adresse e-mail, une clé stockée localement sur l'appareil de l'utilisateur (qui pourrait être une clé de passage), et une clé de sauvegarde détenue par le fournisseur. À mesure qu'un utilisateur acquiert plus d'expérience ou d'actifs, à un moment donné, il devrait être incité à ajouter plus de gardiens.

Les portefeuilles intégrés dans les applications sont inévitables, car les applications qui tentent de séduire les utilisateurs non cryptographiques ne veulent pas d'une expérience utilisateur confuse en demandant à leurs utilisateurs de télécharger deux nouvelles applications (l'application elle-même, plus un portefeuille Ethereum) en même temps. Cependant, un utilisateur de nombreux portefeuilles d'applications devrait pouvoir lier tous leurs portefeuilles ensemble, afin de n'avoir qu'un seul 'élément de contrôle d'accès' à se préoccuper. La manière la plus simple de le faire est un schéma hiérarchique, où il existe un processus de 'liaison' rapide qui permet à un utilisateur de définir son portefeuille principal comme gardien de tous ses portefeuilles in-app. 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 de Warpcast. Cependant, vous pouvez «prendre la souveraineté» sur votre compte Farcaster et changer la récupération vers votre propre adresse.

Protéger les utilisateurs contre les escroqueries et autres menaces externes

En plus de la sécurité du compte, les portefeuilles d'aujourd'hui font beaucoup pour identifier les fausses adresses, le phishing, les escroqueries et autres menaces externes, et essaient de protéger leurs utilisateurs de telles menaces. En même temps, bon nombre des 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 $. Ici, il n'y a pas de solution miracle unique ; il s'agit d'une série de corrections lentes et d'améliorations continues pour différentes catégories de menaces. Cependant, il y a beaucoup de valeur à continuer à travailler dur pour s'améliorer ici.

Confidentialité

Il est maintenant temps de commencer à prendre la confidentialité sur Ethereum beaucoup plus au sérieux. La technologie ZK-SNARK est désormais très avancée, avec des technologies de confidentialité qui atténuent les risques réglementaires sans recourir à des portes dérobées, telles que Pools de confidentialité, sont de plus en plus matures, et les infrastructures secondaires comme Wakuet les Mempools ERC-4337 deviennent lentement plus stables. Cependant, jusqu'à présent, effectuer des transferts privés sur Ethereum a nécessité que les utilisateurs téléchargent et utilisent explicitement un portefeuille de confidentialité, tel que gate.io.chemin de fer (ou Ombrepouradresses furtives). Cela ajoute une grande gêne et réduit le nombre de personnes prêtes à effectuer des transferts privés. La solution consiste à intégrer directement les transferts privés dans les portefeuilles.

Une implémentation simple est la suivante. Un portefeuille pourrait stocker une partie des actifs d'un utilisateur comme un « solde privé » dans une piscine de confidentialité. Lorsqu'un utilisateur effectue un transfert, il se retirerait automatiquement de la piscine de confidentialité en premier. Si un utilisateur a besoin de recevoir des fonds, le portefeuille pourrait générer automatiquement une adresse furtive.

De plus, un portefeuille pourrait générer automatiquement une nouvelle adresse pour chaque application à laquelle un utilisateur participe (par exemple, un protocole defi). Les dépôts proviendraient du pool de confidentialité, et les retraits iraient directement dans le pool de confidentialité. Cela permet à l'activité d'un utilisateur dans une application donnée d'être dissociée de son activité dans d'autres applications.

Un avantage de cette technique est qu'elle constitue un moyen naturel de préserver non seulement le transfert d'actifs préservant la vie privée, mais aussi la préservation de l'identité. L'identité se produit déjà onchain : toute application qui utilise une porte d'entrée de preuve de personnalité (par ex. Gitcoin Grants), un chat avec une porte d'entrée de jeton, le Ethereum Suivre le Protocole, et bien plus encore, sont tous des identités onchain. Nous voulons que cet écosystème soit également préservateur de la vie privée. Cela signifie que l'activité d'un utilisateur onchain ne doit pas être collectée en un seul endroit : chaque élément doit être stocké séparément, et le portefeuille de l'utilisateur doit être la seule chose avec une “vue globale” qui voit toutes vos attestations en même temps. Un écosystème nativement multi-comptes par utilisateur aide à accomplir cela, tout comme les protocoles d'attestation hors chaîne comme EASetZupass.

Cela représente une vision pragmatique de la confidentialité d'Ethereum dans un avenir à moyen terme. Il peut être mis en œuvre dès aujourd'hui, bien qu'il existe des fonctionnalités qui peuvent être introduites au niveau L1 et L2 pour rendre les transferts préservant la confidentialité plus efficaces et fiables. Certains défenseurs de la confidentialité soutiennent que la seule chose acceptable est la confidentialité totale de tout : chiffrer l'intégralité de l'EVM. Je soutiendrais que cela pourrait être idéal comme résultat à long terme, mais cela nécessite une réflexion beaucoup plus fondamentale sur les modèles de programmation, et ce n'est actuellement pas au niveau de maturité où il est prêt à être déployé sur l'ensemble d'Ethereum. Nous avons besoin d'une confidentialité par défaut pour obtenir des ensembles d'anonymat suffisamment importants. Cependant, se concentrer d'abord sur la réalisation (i) des transferts entre comptes, et (ii) des cas d'utilisation liés à l'identité et à l'identité comme les attestations privés est une première étape pragmatique beaucoup plus facile à mettre en œuvre, et sur laquelle les portefeuilles peuvent commencer dès aujourd'hui.

Les portefeuilles Ethereum doivent également devenir des portefeuilles de données

Une conséquence de toute solution de confidentialité efficace, que ce soit pour les paiements, l'identité ou d'autres cas d'utilisation, est qu'elle crée un besoin pour l'utilisateur de stocker des données hors chaîne. Cela était évident dans Tornado Cash, qui exigeait que les utilisateurs sauvegardent chaque "note" individuelle représentant un dépôt de 0,1 à 100 ETH. Les protocoles de confidentialité plus modernes enregistrent parfois les données chiffrées sur la chaîne et utilisent une seule clé privée pour les décrypter. Cela présente des risques, car si la clé est jamais divulguée ou si les ordinateurs quantiques deviennent viables, toutes les données deviennent publiques. Les attestations hors chaîne telles que EAS et Zupass ont encore plus clairement besoin d'un stockage hors chaîne des données.

Les portefeuilles doivent devenir non seulement des logiciels pour stocker les autorisations d'accès onchain, mais aussi des logiciels pour stocker vos données privées. C'est quelque chose que le monde non-crypto reconnaît de plus en plus également, par exemple, voir le travaux récents dans les magasins de données personnelles. Tous les problèmes que nous devons résoudre pour garantir de manière robuste le contrôle des autorisations d'accès, nous devons également les résoudre pour garantir de manière robuste l'accessibilité et la non-divulgation des données. Peut-être que les solutions pourraient être superposées : si vous avez N gardiens, utilisez un partage de secret M-sur-N entre ces mêmes N gardiens pour stocker vos données. Les données sont intrinsèquement plus difficiles à sécuriser, car vous ne pouvez pas révoquer la part de quelqu'un, mais nous devrions trouver des solutions de garde décentralisées aussi sécurisées que possible.

Accès sécurisé à la chaîne

Aujourd'hui, les portefeuilles font confiance à leurs fournisseurs RPC pour leur fournir toutes les informations sur une chaîne. C'est une vulnérabilité à deux égards :

1. Le fournisseur RPC pourrait tenter de voler de l'argent en leur fournissant de fausses informations, par exemple sur les prix du marché
2. Le fournisseur RPC pourrait extraire des informations privées sur les applications et autres comptes avec lesquels un utilisateur interagit.

Idéalement, nous voulons boucher ces deux trous. Pour boucher le premier, nous avons besoin de clients légers standardisés pour L1 et L2 qui vérifient directement le consensus de la blockchain.Heliosdéjà fait cela pour L1, et a effectué des travaux préliminaires pour prendre en charge certains L2 spécifiques. Pour couvrir correctement tous les L2, ce dont nous avons besoin est une norme selon laquelle un contrat de configuration représentant un L2 (également utilisé pour les adresses spécifiques à la chaîne) peut déclarer une fonction, peut-être de manière similaire à,ERC-3668contenant la logique pour obtenir les racines d'état récentes et vérifier les preuves d'état et de reçus contre ces racines d'état. De cette façon, nous pourrions avoir un client léger universel, permettant aux portefeuilles de vérifier en toute sécurité tout état ou événement sur L1 et L2.

Pour la confidentialité, aujourd'hui, la seule approche réaliste est de faire fonctionner votre propre nœud complet. Cependant, maintenant que les L2 entrent en jeu, faire fonctionner un nœud complet de tout devient de plus en plus difficile. L'équivalent d'un client léger ici est récupération d'informations privées (PIR). PIR implique qu'un serveur détient une copie de toutes les données et qu'un client envoie au serveur une demande chiffrée. Le serveur effectue un calcul sur l'ensemble des données, renvoyant les données souhaitées par le client, chiffrées avec la clé du client, sans révéler au serveur quelle donnée le client a consultée.

Pour maintenir l'intégrité du serveur, les éléments individuels de la base de données seraient eux-mêmes des branches Merkle, de sorte que le client puisse les vérifier à l'aide de leur client léger.

PIR est très coûteux en termes de calcul. Il existe plusieurs solutions à ce problème:

• Force brute : des améliorations dans les algorithmes, ou du matériel spécialisé, pourraient potentiellement rendre le PIR suffisamment rapide pour être exécuté. Ces techniques peuvent dépendre d'une préparation préalable : les serveurs pourraient stocker des données chiffrées et mélangées pour chaque client, et les clients pourraient interroger ces données. Le principal défi dans le contexte d'Ethereum est d'adapter ces techniques aux ensembles de données qui changent rapidement (comme l'état). Cela permet de réduire les coûts de calcul en temps réel, mais cela peut également augmenter les coûts totaux de calcul et de stockage.
• Affaiblissez l'exigence de confidentialité : par exemple, chaque recherche ne peut avoir que 1 million de « mélanges », donc le serveur connaîtrait un million de valeurs possibles auxquelles le client aurait pu accéder, mais sans plus de précision
• PIR multi-serveur: les algorithmes PIR sont souvent beaucoup plus rapides si vous utilisez plusieurs serveurs avec une hypothèse d'honnêteté de 1-sur-N entre ces serveurs.
• Anonymat au lieu de confidentialité : au lieu de cacher le contenu de la demande, la demande pourrait être envoyée via un mixnet, cachant l'expéditeur de la demande. Cependant, faire cela augmente inévitablement la latence, aggravant l'expérience utilisateur.

Trouver la bonne combinaison de techniques pour maximiser la confidentialité tout en maintenant la praticité dans le contexte d'Ethereum est un problème de recherche ouvert, et j'encourage les cryptographes à essayer leur chance.

Portefeuilles de stockage idéaux

Mis à part les transferts et l'accès à l'état, un autre flux de travail important qui doit fonctionner en toute transparence dans un contexte inter-L2 est le changement de la configuration de validation d'un compte : qu'il s'agisse de changer ses clés (par exemple, de récupération) ou d'un changement plus profond de la logique entière du compte. Ici, il existe trois niveaux de solutions, dans l'ordre croissant de leur difficulté :

1. Mises à jour rejouées : lorsque qu'un utilisateur modifie sa configuration, un message autorisant ce changement est rejoué sur chaque chaîne où le portefeuille détecte que l'utilisateur possède des actifs. Potentiellement, le format du message et les règles de validation peuvent être rendus indépendants de la chaîne, de sorte qu'il peut être automatiquement rejoué sur autant de chaînes que possible.
2. Keystores sur L1 : les informations de configuration résident sur L1, et le portefeuille sur L2 les lit avec une L1SLOADouREMOTESTATICCALL. De cette façon, la mise à jour de la configuration ne doit être effectuée que sur L1 et la configuration devient automatiquement effective.
3. Keystores sur L2 : les informations de configuration résident sur L2, et le portefeuille sur L2 les lit avec un ZK-SNARK. Il s'agit de la même chose que (2), sauf que les mises à jour du keystore peuvent être moins chères, bien que d'autre part, les lectures soient plus coûteuses.

La solution (3) est particulièrement puissante car elle s’empile bien avec la confidentialité. Dans une « solution de confidentialité » normale, un utilisateur a un secret s, une « valeur feuille » L est publiée sur la chaîne, et un utilisateur prouve que L = hachage(s, 1) et N = hachage(s, 2) pour un secret (jamais révélé) qu’il contrôle. L’annulateur N est publié, ce qui permet de s’assurer que les dépenses futures de la même feuille échouent, sans jamais révéler L. Cela dépend de la sécurité de l’utilisateur. Une solution de confidentialité conviviale pour la récupération dirait plutôt : s est un emplacement (par exemple, une adresse et un emplacement de stockage) sur la chaîne, et l’utilisateur doit prouver une requête d’état : L = hash(sload(s), 1) .

Sécurité Dapp

Le maillon le plus faible de la sécurité d'un utilisateur est souvent le dapp. La plupart du temps, un utilisateur interagit avec une application en se rendant sur un site web, qui télécharge implicitement le code de l'interface utilisateur en temps réel à partir d'un serveur, puis l'exécute dans le navigateur. Si le serveur est piraté, ou si le DNS est piraté, l'utilisateur obtiendra une fausse copie de l'interface, ce qui pourrait tromper l'utilisateur en lui faisant faire des choses arbitraires. Les fonctionnalités du portefeuille telles que les simulations de transaction sont très utiles pour atténuer les risques, mais elles sont loin d'être parfaites.

Idéalement, nous déplacerions l'écosystème vers la version de contenu on-chain : un utilisateur accéderait à une dapp via son nom ENS, qui contiendrait le hachage IPFS de l'interface. Une transaction onchain à partir d'un multisig ou d'un DAO serait nécessaire pour mettre à jour l'interface. Les portefeuilles montreraient aux utilisateurs s'ils interagissent avec une interface onchain plus sécurisée ou une interface web2 moins sécurisée. Les portefeuilles peuvent également montrer aux utilisateurs s'ils interagissent avec une chaîne sécurisée (par exemple, étape 1+, plusieurs audits de sécurité).

Pour les utilisateurs soucieux de leur vie privée, les portefeuilles peuvent également ajouter un mode paranoïaque, qui oblige les utilisateurs à cliquer sur accepter les requêtes HTTP, et pas seulement les opérations web3 :

Maquette possible de l'interface pour le mode paranoïaque

Une approche plus avancée consisterait à aller au-delà de HTML + Javascript et à écrire la logique métier des dapps dans un langage dédié, peut-être une surcouche relativement mince de Solidity ou Vyper. Les navigateurs pourraient alors générer automatiquement une interface utilisateur pour toute fonctionnalité nécessaire.OKContractle fait déjà.

Une autre direction est l'info-défense cryptéo-économique : les développeurs de dapps, les sociétés de sécurité, les déployeurs de chaînes et autres peuvent fournir une garantie qui serait versée aux utilisateurs concernés si une dapp était piratée ou causait d'autres préjudices aux utilisateurs en agissant de manière très trompeuse, comme déterminé par un DAO d'arbitrage surchaîne. Le portefeuille pourrait montrer à un utilisateur un score basé sur la taille de la garantie.

Le futur à plus long terme

Ce qui précède concernait tous les interfaces conventionnels, qui impliquent de pointer et cliquer sur des éléments et d'entrer des éléments dans des champs de texte. Cependant, nous sommes également sur le point de voir des changements de paradigmes beaucoup plus profonds :

• L'IA, qui pourrait nous faire passer d'un paradigme de point-and-click-and-type à un paradigme de "dire ce que vous voulez faire et le bot le comprend"
• Interfaces cerveau-ordinateur, à la fois des approches « douces » telles que le suivi oculaire et des techniques plus directes voire invasives (voir:premier patient Neuralink cette année)
• Les clients qui se livrent à une défense active : le navigateur Braveprotège activement les utilisateurs contre les publicités, les traqueurs et de nombreux autres objets indésirables. De nombreux navigateurs, plugins et portefeuilles cryptographiques ont des équipes entières qui travaillent activement pour protéger les utilisateurs contre toutes sortes de menaces en matière de sécurité et de confidentialité. Ces sortes de « gardiens actifs » deviendront de plus en plus puissants dans la décennie à venir.

Ces trois tendances ensemble conduiront à une réflexion beaucoup plus approfondie sur le fonctionnement des interfaces. Grâce à la saisie de langage naturel, au suivi oculaire, ou éventuellement à des BCI plus directs, associés à la connaissance de votre historique (peut-être y compris les messages texte, tant que toutes les données sont traitées localement), un "portefeuille" pourrait avoir une idée intuitive claire de ce que vous voulez faire. L'IA pourrait alors traduire cette intuition en un "plan d'action" concret : une série d'interactions onchain et offchain qui réalisent ce que vous voulez. Cela pourrait grandement réduire la nécessité d'interfaces utilisateur tierces. Si un utilisateur interagit avec une application tierce (ou un autre utilisateur), l'IA devrait penser de manière adversaire au nom de l'utilisateur, et identifier toute menace et suggérer des plans d'action pour les éviter. Idéalement, il y aurait un écosystème ouvert de ces IA, produites par différents groupes avec des biais et des structures d'incitation différents.

Ces idées plus radicales dépendent d'une technologie extrêmement immature aujourd'hui, donc je ne mettrais pas mes actifs aujourd'hui dans un portefeuille qui en dépend. Cependant, quelque chose comme ça semble clairement être l'avenir, il vaut donc la peine de commencer à explorer plus activement dans cette direction.

Avertissement :

1. Cet article est reproduit à partir de [vitalik]. S'il y a des objections à cette reproduction, veuillez contacter la Porte d’apprentissageéquipe, et ils s'en occuperont rapidement.
2. Clause de non-responsabilité : Les points de vue et opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent aucun conseil en investissement.
3. Les traductions de l'article dans d'autres langues sont effectuées par l'équipe d'apprentissage de Gate. Sauf mention contraire, la copie, la distribution ou le plagiat des articles traduits est interdit.