Vision du portefeuille Ethereum idéal : une mise à niveau complète de l'expérience cross-chain à la protection de la vie privée

La couche de portefeuille dans l'infrastructure d'Ethereum est cruciale, mais souvent sous-estimée par les chercheurs et développeurs principaux de L1. Le portefeuille est la fenêtre par laquelle les utilisateurs interagissent avec le monde d'Ethereum, et ce n'est que lorsque le portefeuille lui-même possède les caractéristiques appropriées que les utilisateurs peuvent vraiment bénéficier des attributs de décentralisation, d'anti-censure, de sécurité et de confidentialité offerts par Ethereum et ses applications.

Récemment, les portefeuilles Ethereum ont fait des progrès significatifs en matière d'expérience utilisateur, de sécurité et de fonctionnalités. Cet article vise à décrire certaines caractéristiques qu'un portefeuille Ethereum idéal devrait avoir. Ce n'est pas une liste exhaustive, mais elle reflète les tendances du cypherpunk de l'auteur, mettant l'accent sur la sécurité et la confidentialité, tout en pouvant être moins efficace en termes d'expérience utilisateur. Cependant, par rapport à un déploiement et une itération simples basés sur des retours d'expérience, une liste de souhaits peut s'avérer moins efficace dans l'optimisation de l'expérience utilisateur, de sorte que se concentrer sur les attributs de sécurité et de confidentialité pourrait être plus précieux.

Expérience utilisateur des transactions inter-L2

La feuille de route pour améliorer l'expérience utilisateur cross-chain entre L2 devient de plus en plus claire, y compris les parties à court et à long terme. Cet article discutera des idées pouvant être mises en œuvre à court terme.

L'idée centrale est : (1) fonction d'envoi intégrée cross-chain L2, (2) adresse spécifique de la chaîne et demande de paiement. Le portefeuille devrait être en mesure de fournir à l'utilisateur une adresse conforme à un style de brouillon ERC spécifique.

Lorsque l'utilisateur reçoit une adresse au format, il peut la coller dans le champ "destinataire" du Portefeuille et cliquer sur "envoyer". Le Portefeuille devrait gérer automatiquement le processus d'envoi :

• Si la chaîne cible dispose déjà d'un nombre suffisant de jetons requis, envoyez-les directement.
• Si des jetons requis sont disponibles sur d'autres chaînes, utilisez un protocole DEX cross-chain similaire à ERC-7683 pour les envoyer.
• Si différents types de jetons sont présents sur la même chaîne ou sur d'autres chaînes, utilisez DEX pour les convertir au bon type et les envoyer, nécessitant le consentement explicite de l'utilisateur.

Cela s'applique au scénario de "paiement par adresse de copier-coller". Dans le cas où un dapp demande un dépôt, la meilleure pratique consiste à étendre l'API web3, permettant au dapp d'émettre des demandes de paiement spécifiques à la chaîne. Le portefeuille peut répondre de manière flexible à cette demande. Pour offrir une bonne expérience utilisateur, il est également nécessaire de normaliser la demande getAvailableBalance, et le portefeuille doit sérieusement considérer sur quelles chaînes les actifs des utilisateurs sont stockés par défaut, afin d'équilibrer la sécurité et la commodité des transferts.

Les demandes de paiement spécifiques à la chaîne peuvent également être intégrées dans des codes QR pour être scannées par des portefeuilles mobiles. Dans les scénarios de paiement en face à face ou en ligne, le receveur peut émettre un code QR ou un appel API web3 indiquant "J'ai besoin de Y unités de jetons Z sur la chaîne X, référence ID W". Le portefeuille peut répondre de manière flexible à cette demande. 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, le receveur étant responsable du transfert des fonds vers son propre portefeuille.

Un autre sujet connexe est le paiement de gas. Si un utilisateur reçoit des actifs sur un L2 sans ETH et doit envoyer une transaction, le portefeuille doit pouvoir utiliser automatiquement le protocole (, comme RIP-7755), pour payer le gas depuis d'autres chaînes ayant de l'ETH. Si le portefeuille prévoit que l'utilisateur effectuera davantage de transactions sur ce L2 à l'avenir, il peut également utiliser un DEX pour envoyer suffisamment d'ETH pour payer des centaines de gas, afin que les transactions futures puissent directement payer le gas sur L2 (, car cela est moins coûteux ).

Sécurité des comptes

Une bonne façon de conceptualiser la sécurité des comptes est qu'un excellent Portefeuille devrait jouer un rôle sur deux aspects : ( protéger les utilisateurs contre les attaques de hackers ou les comportements malveillants des développeurs de Portefeuille, ) protéger les utilisateurs contre l'impact de leurs propres erreurs.

La solution privilégiée est un portefeuille avec récupération sociale et multi-signatures, doté d'un contrôle d'accès hiérarchique. Les comptes utilisateurs disposent de deux niveaux de clés : une clé principale et N gardiens ( où N=5). La clé principale peut être utilisée pour des opérations de faible valeur et non financières. La majorité des gardiens doivent intervenir pour exécuter : (1) des opérations de haute valeur, telles que l'envoi de tous les fonds du compte, (2) modifier la clé principale ou tout gardien. Si nécessaire, la clé principale peut être autorisée à exécuter des opérations de haute valeur via un verrouillage temporel.

C'est un design de base qui peut être étendu. Les clés de session et des mécanismes d'autorisation tels que l'ERC-7715 peuvent aider à équilibrer la commodité et la sécurité entre différentes applications. Une architecture de gardien plus complexe, avec plusieurs périodes de verrouillage temporel à différents seuils, peut maximiser les chances de récupérer un compte légitime tout en minimisant le risque de vol.

( choix du tuteur

Pour les utilisateurs expérimentés de la communauté crypto, il est possible de choisir les clés de leurs amis et de leur famille comme gardiens. Si l'on demande à chacun de fournir une nouvelle adresse, il n'est même pas nécessaire de connaître l'identité des autres. Cependant, cela ne s'applique pas à la plupart des nouveaux utilisateurs.

La deuxième option est le gardien institutionnel : un service qui ne signe les transactions que lorsqu'il reçoit d'autres informations de confirmation demandées par l'utilisateur, comme un code de confirmation ou un appel vidéo avec un utilisateur de haute valeur ). Bien que des tentatives aient été faites depuis longtemps pour établir ce type de service, cela n'a pas encore beaucoup de succès.

La troisième option consiste en plusieurs appareils personnels ### tels que des téléphones, des ordinateurs de bureau, des portefeuilles matériels (. Cela est faisable mais plus difficile à configurer et à gérer pour les utilisateurs novices. Il existe également un risque de perte ou de vol simultané des appareils, surtout s'ils se trouvent au même endroit.

Dernièrement, nous commençons à voir de plus en plus de solutions basées sur des clés universelles. La clé peut être sauvegardée uniquement sur l'appareil, devenant ainsi une solution personnelle de l'appareil, ou elle peut être sauvegardée dans le cloud, la sécurité dépendant d'une sécurité complexe des mots de passe hybrides, d'institutions et d'hypothèses matérielles fiables. Bien que cela constitue un gain de sécurité précieux pour l'utilisateur moyen, cela ne suffit 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é emballé en ZK. Ce type comprend zk-email, Anon Aadhaar, Myna Wallet, etc. Fondamentalement, diverses formes d'ID centralisé de ) entreprise ou gouvernement ( peuvent être adoptées et converties en adresse Ethereum, les utilisateurs ne pouvant envoyer des transactions qu'en générant une preuve ZK-SNARK possédant un ID centralisé.

L'ID centralisé emballé dans ZK possède une "facilité d'utilisation pour les débutants" unique. Pour cela, il est nécessaire de le réaliser via une interface utilisateur simplifiée et intégrée : l'utilisateur doit simplement indiquer qu'il souhaite "example@gmail.com" comme tuteur, et cela devrait automatiquement générer en arrière-plan l'adresse zk-email Ethereum correspondante. Les utilisateurs avancés devraient être en mesure d'entrer leur e-mail ) ainsi que les valeurs de sel de confidentialité éventuellement conservées ( dans des applications tierces open source, et de confirmer que l'adresse générée est correcte. Cela devrait également s'appliquer à tout autre type de tuteur pris en charge.

Il est important de noter qu'un défi réel auquel fait face zk-email actuellement est qu'il dépend de la signature DKIM, qui utilise une clé renouvelée tous les quelques mois, et ces clés elles-mêmes ne sont pas signées par d'autres entités. Cela signifie qu'aujourd'hui, zk-email nécessite dans une certaine mesure de faire confiance au fournisseur lui-même ; si zk-email utilise TLSNotary dans un matériel de confiance pour vérifier les clés mises à jour, cela pourrait réduire cette situation, mais ce n'est pas idéal. On espère que les fournisseurs de messagerie commenceront à signer directement leurs clés DKIM. Actuellement, il est recommandé d'utiliser un zk-email comme gardien, mais il n'est pas conseillé d'utiliser la plupart des gardiens : ne pas stocker de fonds dans un zk-email endommagé signifie que les fonds ne peuvent pas être utilisés.

![Vitalik nouveau document : la vision du portefeuille idéal, une mise à niveau complète de l'expérience cross-chain à la protection de la vie privée])https://img-cdn.gateio.im/webp-social/moments-6e92b6b051653e68d5f93ed0d91891eb.webp(

) Nouveaux utilisateurs et Portefeuille dans l'application

Les nouveaux utilisateurs ne souhaitent en réalité pas 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 manière naturelle serait d'utiliser zk-email sur leur adresse e-mail, une clé stockée localement sur l'appareil de l'utilisateur ( qui pourrait être la clé universelle ) ainsi qu'une clé de sauvegarde détenue par le fournisseur, pour faire un choix 2 sur 3. Au fur et à mesure que l'utilisateur accumule plus d'expérience ou d'actifs, il devrait être invité à un moment donné à ajouter davantage 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 souhaitent pas que les utilisateurs téléchargent simultanément deux nouvelles applications ###, l'application elle-même ainsi qu'un portefeuille Ethereum (, ce qui entraîne une expérience utilisateur confuse. Cependant, de nombreux utilisateurs de portefeuilles intégrés devraient être en mesure de lier tous les portefeuilles ensemble, ce qui permettrait de se concentrer uniquement sur un "problème de contrôle d'accès". La méthode la plus simple consiste à adopter un schéma hiérarchique, à travers un processus "lien" rapide, permettant aux utilisateurs de définir le portefeuille principal comme le gardien de tous les portefeuilles intégrés.

![Vitalik nouvel article : la vision du portefeuille idéal, une mise à niveau complète de l'expérience cross-chain à la protection de la vie privée])https://img-cdn.gateio.im/webp-social/moments-2439f49163d0212333ea4207f34cdbef.webp(

) Protéger les utilisateurs contre la fraude et d'autres menaces externes

En plus de la sécurité des comptes, les portefeuilles d'aujourd'hui font également beaucoup de travail pour identifier les adresses frauduleuses, le phishing, les escroqueries et d'autres menaces externes, tout en s'efforçant de protéger les utilisateurs. En même temps, de nombreuses contre-mesures restent assez rudimentaires : par exemple, exiger un clic pour envoyer de l'Éther ou d'autres jetons à toute nouvelle adresse, quelle que soit la taille du montant envoyé. Il n'existe pas de solution miracle unique, mais une série d'améliorations continues pour différentes catégories de menaces. Il est précieux de continuer à travailler sur l'amélioration de cet aspect.

Vie privée

Il est maintenant temps de prendre la question de la confidentialité d'Ethereum plus au sérieux. La technologie ZK-SNARK est déjà très avancée, ne dépendant pas de portes dérobées pour réduire les risques réglementaires, et des technologies de confidentialité comme les pools de confidentialité ### deviennent de plus en plus matures, tandis que des infrastructures de second niveau telles que les mempools Waku et ERC-4337 deviennent également progressivement plus stables. Cependant, actuellement, effectuer des transferts privés sur Ethereum nécessite que les utilisateurs téléchargent et utilisent explicitement un "Portefeuille" de confidentialité. Cela entraîne un grand inconvénient 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 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 automatiquement du pool de confidentialité. Si l'utilisateur doit recevoir des fonds, le portefeuille peut générer automatiquement une adresse invisible.

De plus, le portefeuille peut automatiquement générer une nouvelle adresse pour chaque application à laquelle l'utilisateur participe (, comme le protocole defi ). Les dépôts proviendront d'un pool de confidentialité, et les retraits iront directement au pool de confidentialité. Cela permet aux utilisateurs de déconnecter leurs activités dans une application de celles dans d'autres applications.

Cette technologie est non seulement un moyen naturel de protéger le transfert d'actifs privés, mais aussi un moyen naturel de protéger l'identité privée. L'identité a déjà eu lieu sur la chaîne : toute application utilisant une preuve d'identité contrôlée par des portes, comme Gitcoin Grants(, tout chat contrôlé par des jetons, le protocole suivant Ethereum, etc., constitue une identité sur la chaîne. Nous espérons que cet écosystème pourra également protéger la vie privée. 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 devrait être la seule chose ayant une "vue globale" pouvant voir toutes les preuves simultanément. Un écosystème natif où chaque utilisateur possède plusieurs comptes contribue à atteindre cet objectif, tout comme les protocoles de preuve hors chaîne tels que EAS et Zupass.

Cela représente une vision pragmatique de la confidentialité d'Ethereum à moyen terme. Bien qu'il soit possible d'introduire certaines fonctionnalités dans L1 et L2 pour rendre les transmissions de protection de la vie privée plus efficaces et fiables, 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. Cela pourrait être le résultat idéal à long terme, mais cela nécessite une réflexion plus fondamentale sur le modèle de programmation,