Vitalik publie un nouvel article technique : La vision du portefeuille idéal – Une mise à niveau complète, de l'expérience multi-chaînes à la protection de la vie privée
2024.12.03
Partager versPartager sur Twitter
Dédié à des analyses Web3 approfondies
Partager sur WeChat
Partager sur WeiboPartager sur WeChat
Partager le lien de l’article
Partager l’affiche visuelle
TechFlow SélectionTechFlow Sélection
Vitalik publie un nouvel article technique : La vision du portefeuille idéal – Une mise à niveau complète, de l'expérience multi-chaînes à la protection de la vie privée
Le portefeuille est une fenêtre entre l'utilisateur et le monde d'Ethereum. Je pense qu'il est le plus précieux de se concentrer sur les attributs de sécurité et de confidentialité.
2024.12.03 - 11:34:03
Vitalik以太坊Layer2
Dédié à des analyses Web3 approfondiesLe portefeuille est une fenêtre entre l'utilisateur et le monde d'Ethereum. Je pense qu'il est le plus précieux de se concentrer sur les attributs de sécurité et de confidentialité.
Remerciements particuliers à Liraz Siri, Yoav Weiss ainsi qu'aux développeurs d'ImToken, Metamask et OKX pour leurs retours et examens.
Une couche clé de la pile d'infrastructure Ethereum est constituée par les portefeuilles, souvent sous-estimés par les chercheurs et développeurs principaux de la couche 1 (L1). Les portefeuilles sont la fenêtre entre l'utilisateur et le monde Ethereum : les utilisateurs ne peuvent bénéficier des propriétés offertes par Ethereum et ses applications — décentralisation, résistance à la censure, sécurité, confidentialité, etc. — que si le portefeuille lui-même possède également ces caractéristiques.
Récemment, nous avons observé des progrès significatifs dans l'amélioration de l'expérience utilisateur, de la sécurité et des fonctionnalités des portefeuilles Ethereum. Cet article vise à présenter mon point de vue personnel sur certaines fonctionnalités que devrait idéalement posséder un portefeuille Ethereum. Il ne s'agit pas d'une liste exhaustive ; elle reflète mes tendances « cypherpunk », en se concentrant sur la sécurité et la confidentialité, et est presque certainement incomplète du point de vue de l'expérience utilisateur. Toutefois, je pense que les listes de souhaits sont moins efficaces pour optimiser l’expérience utilisateur que le déploiement itératif fondé sur les retours concrets. Ainsi, je considère qu’il est plus utile de me concentrer sur les attributs de sécurité et de confidentialité.
Lorsqu’une personne (ou une application) vous fournit une adresse au format ci-dessus, vous devriez pouvoir la coller dans le champ « destinataire » de votre portefeuille, puis cliquer sur « envoyer ». Le portefeuille devrait automatiquement gérer tout ce processus de transfert de données, quelle que soit la manière requise :
Modèle d’interface possible pour un portefeuille prenant en charge les adresses inter-chaînes
Ce scénario concerne le cas d'utilisation où « vous copiez-collez une adresse (ou un ENS, par exemple vitalik.eth@optimism.eth) afin que quelqu’un vous paie ». Si une dApp demande un dépôt (voir par exemple cet exemple Polymarket), le flux idéal consisterait à étendre l’API web3 pour permettre aux dApps d’émettre des demandes de paiement spécifiques à une chaîne. Votre portefeuille pourrait alors satisfaire cette demande de n’importe quelle manière appropriée. Pour garantir une bonne expérience utilisateur, il faudra aussi standardiser les requêtes getAvailableBalance, et les portefeuilles devront réfléchir sérieusement à la chaîne par défaut où stocker les actifs des utilisateurs, afin d’optimiser sécurité et commodité des transferts.
Les demandes de paiement spécifiques à une chaîne peuvent également être intégrées à des codes QR que les portefeuilles mobiles peuvent scanner. Dans des scénarios de paiement en ligne ou en personne, le destinataire émettrait un code QR ou un appel API web3 indiquant : « Je veux X unités du jeton Y sur la chaîne Z, avec un identifiant de référence ou un rappel W ». Le portefeuille serait alors libre de satisfaire cette demande comme il l’entend. Une alternative consiste en un protocole de lien de réclamation, où le portefeuille de l’utilisateur génère un code QR ou une URL contenant une autorisation de réclamation permettant de retirer une certaine somme depuis un contrat sur sa chaîne, et le destinataire devra ensuite trouver comment transférer ces fonds vers son propre portefeuille.
Un autre sujet connexe est le paiement du gaz. Si vous recevez des actifs sur une L2 où vous n’avez pas encore d’ETH, et devez effectuer une transaction sur cette L2, le portefeuille devrait pouvoir utiliser automatiquement un protocole (comme RIP-7755) pour payer le gaz depuis un endroit où vous avez de l’ETH. Si le portefeuille prévoit que vous ferez davantage de transactions sur cette L2, il pourrait aussi utiliser un DEX pour y envoyer une petite quantité d’ETH (par exemple quelques centaines de milliers de gas), afin que vos futures transactions puissent directement utiliser ce gaz (ce qui est moins coûteux).
Le mot « erreur » à gauche est involontaire. Toutefois, quand je l’ai vu, j’ai trouvé qu’il s’intégrait bien au contexte, donc j’ai décidé de le garder.
Ma solution préférée à ce problème, depuis plus dedix ans, reste les portefeuilles à récupération sociale et multisignatures avec contrôle d’accès hiérarchisé. Le compte de l’utilisateur dispose de deux niveaux de clés : la clé principale et N gardiens (par exemple N = 5). La clé principale peut effectuer des opérations à faible valeur ou non financières. La majorité des gardiens est requise pour exécuter (i) des opérations à haute valeur, comme envoyer toute la valeur du compte, ou (ii) modifier la clé principale ou l’un des gardiens. Si nécessaire, on peut autoriser la clé principale à exécuter des opérations à haute valeur via un verrou temporel.
C’est là la conception de base, qui peut être étendue. Des mécanismes tels que les clés de session et ERC-7715 peuvent aider à ajuster l’équilibre entre commodité et sécurité selon les différentes applications. Des architectures plus complexes de gardiens — par exemple avec plusieurs durées de verrou temporel selon différents seuils — peuvent maximiser les chances de récupération légitime tout en minimisant les risques de vol.
Avec cette nouveauté, nous disposons désormais d’un large éventail d’options, et les identités centralisées enveloppées par ZK se distinguent par leur grande accessibilité pour les débutants.
Pour cela, elles doivent être implémentées via une interface simple et intégrée : vous devriez pouvoir simplement indiquer « example@gmail.com » comme gardien, et le système devrait automatiquement générer l’adresse Ethereum zk-email correspondante en arrière-plan. Les utilisateurs avancés devraient pouvoir entrer leur e-mail (et éventuellement un sel de confidentialité stocké avec celui-ci) dans une application tierce open source, et vérifier que l’adresse générée est correcte. La même chose devrait être possible pour tout autre type de gardien pris en charge.
Notez qu’un défi pratique actuel de zk-email est qu’il repose sur des signatures DKIM, utilisant des clés changées tous les quelques mois, et que ces clés ne sont pas elles-mêmes signées par une autre entité. Cela signifie que zk-email impose actuellement un niveau de confiance légèrement supérieur à celui du fournisseur lui-même. Cette situation pourrait être atténuée si zk-email utilisait TLSNotary dans du matériel sécurisé de confiance pour vérifier les nouvelles clés, mais ce n’est pas idéal. On espère que les fournisseurs de messagerie commenceront à signer directement leurs clés DKIM. Aujourd’hui, je recommande d’utiliser zk-email comme gardien unique, mais pas comme majorité : ne placez pas vos fonds dans une configuration où la compromission de zk-email empêcherait l’accès à vos actifs.
Par défaut, la récupération de votre compte Warpcast est contrôlée par l’équipe Warpcast. Cependant, vous pouvez « reprendre » votre compte Farcaster et changer la récupération pour qu’elle pointe vers votre propre adresse.
Un avantage de cette approche est qu’elle constitue non seulement un moyen naturel de transférer des actifs de manière privée, mais aussi d’assurer la confidentialité de l’identité. L’identité existe déjà sur la blockchain : toute application utilisant une preuve d’identité (ex. Gitcoin Grants), tout chat contrôlé par jeton, le protocole Ethereum Follow, etc., relève de l’identité sur chaîne. Nous souhaitons que cet écosystème protège également la vie privée. Cela signifie que les activités sur chaîne de l’utilisateur ne devraient pas être regroupées en un seul endroit : chaque projet devrait stocker ses données séparément, et seul le portefeuille de l’utilisateur devrait avoir une « vue globale » capable de rassembler toutes les preuves. Un écosystème nativement basé sur plusieurs comptes par utilisateur aide à atteindre cet objectif, tout comme les protocoles hors chaîne comme EAS et Zupass.
Ceci représente une vision pragmatique de la confidentialité sur Ethereum à moyen terme. Bien que certaines fonctionnalités puissent être introduites au niveau L1 et L2 pour rendre les transferts privés plus efficaces et fiables, cela peut déjà être mis en œuvre dès maintenant. Certains défenseurs de la confidentialité pensent que seule une confidentialité totale de tout (comme chiffrer l’ensemble de l’EVM) est acceptable. Je pense que cela pourrait être un objectif à long terme idéal, mais cela nécessiterait une refonte fondamentale du modèle de programmation, et n’a pas encore atteint un niveau de maturité suffisant pour être déployé sur Ethereum. Nous avons besoin de confidentialité par défaut pour obtenir un ensemble d’anonymat suffisamment grand. Toutefois, commencer par se concentrer sur (i) les transferts entre comptes, et (ii) l’identité et les cas d’usage associés (comme les preuves privées) est une première étape pragmatique, plus facile à réaliser, et que les portefeuilles peuvent commencer à implémenter dès aujourd’hui.
Pour garantir l’honnêteté du serveur, chaque élément de la base de données est lui-même une branche Merkle, que le client peut vérifier via un client léger.
La PIR (TechFlow note : généralement appelée « Private Information Retrieval », une technique permettant à un utilisateur de récupérer des informations d’une base de données sans révéler quelle information a été récupérée.) est extrêmement coûteuse en calcul. Plusieurs voies existent pour y remédier :
La solution (3) est particulièrement puissante car elle s’intègre bien à la confidentialité. Dans une solution de confidentialité normale, l’utilisateur possède un secret 
Modèle d’interface possible pour le mode paranoïaque
Une approche plus avancée consisterait à aller au-delà du HTML + Javascript, en écrivant la logique métier des dApps dans un langage spécialisé (peut-être une fine couche au-dessus de Solidity ou Vyper). Le navigateur pourrait alors générer automatiquement l’interface utilisateur nécessaire. OKContract fait déjà cela.
Une autre direction est la défense informationnelle crypto-économique : les développeurs de dApps, sociétés de sécurité, déployeurs de chaînes, etc., pourraient déposer une caution, qui serait versée aux utilisateurs affectés (après décision d’un DAO d’arbitrage sur chaîne) en cas de piratage ou de tromperie grave. Le portefeuille pourrait afficher aux utilisateurs un score basé sur la taille de la caution.
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 inter-L2, comprenant des éléments à court terme et à long terme. Ici, je vais aborder les aspects à court terme : des idées qui pourraient déjà être mises en œuvre aujourd’hui. L'idée centrale repose sur deux piliers : (i) envoi intégré inter-L2, et (ii) adresses et demandes de paiement spécifiques à chaque chaîne. Votre portefeuille devrait pouvoir vous fournir une adresse (suivant le style de cette proposition ERC) comme celle-ci :
Lorsqu’une personne (ou une application) vous fournit une adresse au format ci-dessus, vous devriez pouvoir la coller dans le champ « destinataire » de votre portefeuille, puis cliquer sur « envoyer ». Le portefeuille devrait automatiquement gérer tout ce processus de transfert de données, quelle que soit la manière requise :
- Si vous avez déjà suffisamment de jetons du type requis sur la chaîne cible, envoyez directement les jetons.
- Si vous avez les jetons requis sur une autre chaîne (ou plusieurs autres chaînes), utilisez un protocole tel que ERC-7683, qui agit essentiellement comme un DEX inter-chaînes.
- Si vous détenez un type différent de jeton sur la même chaîne ou sur une autre chaîne, utilisez un DEX décentralisé pour convertir ces actifs en la bonne quantité du bon type de jeton sur la bonne chaîne, puis envoyez-les. Cette opération devrait nécessiter l’autorisation explicite de l’utilisateur : il doit voir clairement les frais payés et la quantité reçue par le destinataire.
Modèle d’interface possible pour un portefeuille prenant en charge les adresses inter-chaînes
Ce scénario concerne le cas d'utilisation où « vous copiez-collez une adresse (ou un ENS, par exemple vitalik.eth@optimism.eth) afin que quelqu’un vous paie ». Si une dApp demande un dépôt (voir par exemple cet exemple Polymarket), le flux idéal consisterait à étendre l’API web3 pour permettre aux dApps d’émettre des demandes de paiement spécifiques à une chaîne. Votre portefeuille pourrait alors satisfaire cette demande de n’importe quelle manière appropriée. Pour garantir une bonne expérience utilisateur, il faudra aussi standardiser les requêtes getAvailableBalance, et les portefeuilles devront réfléchir sérieusement à la chaîne par défaut où stocker les actifs des utilisateurs, afin d’optimiser sécurité et commodité des transferts.
Les demandes de paiement spécifiques à une chaîne peuvent également être intégrées à des codes QR que les portefeuilles mobiles peuvent scanner. Dans des scénarios de paiement en ligne ou en personne, le destinataire émettrait un code QR ou un appel API web3 indiquant : « Je veux X unités du jeton Y sur la chaîne Z, avec un identifiant de référence ou un rappel W ». Le portefeuille serait alors libre de satisfaire cette demande comme il l’entend. Une alternative consiste en un protocole de lien de réclamation, où le portefeuille de l’utilisateur génère un code QR ou une URL contenant une autorisation de réclamation permettant de retirer une certaine somme depuis un contrat sur sa chaîne, et le destinataire devra ensuite trouver comment transférer ces fonds vers son propre portefeuille.
Un autre sujet connexe est le paiement du gaz. Si vous recevez des actifs sur une L2 où vous n’avez pas encore d’ETH, et devez effectuer une transaction sur cette L2, le portefeuille devrait pouvoir utiliser automatiquement un protocole (comme RIP-7755) pour payer le gaz depuis un endroit où vous avez de l’ETH. Si le portefeuille prévoit que vous ferez davantage de transactions sur cette L2, il pourrait aussi utiliser un DEX pour y envoyer une petite quantité d’ETH (par exemple quelques centaines de milliers de gas), afin que vos futures transactions puissent directement utiliser ce gaz (ce qui est moins coûteux).
Sécurité du compte
Une façon dont je conceptualise le défi de la sécurité des comptes est qu’un bon portefeuille doit jouer un rôle double : (i) protéger l’utilisateur contre les attaques malveillantes ou les piratages provenant des développeurs du portefeuille lui-même, et (ii) protéger l’utilisateur contre ses propres erreurs.
Le mot « erreur » à gauche est involontaire. Toutefois, quand je l’ai vu, j’ai trouvé qu’il s’intégrait bien au contexte, donc j’ai décidé de le garder.
Ma solution préférée à ce problème, depuis plus dedix ans, reste les portefeuilles à récupération sociale et multisignatures avec contrôle d’accès hiérarchisé. Le compte de l’utilisateur dispose de deux niveaux de clés : la clé principale et N gardiens (par exemple N = 5). La clé principale peut effectuer des opérations à faible valeur ou non financières. La majorité des gardiens est requise pour exécuter (i) des opérations à haute valeur, comme envoyer toute la valeur du compte, ou (ii) modifier la clé principale ou l’un des gardiens. Si nécessaire, on peut autoriser la clé principale à exécuter des opérations à haute valeur via un verrou temporel.
C’est là la conception de base, qui peut être étendue. Des mécanismes tels que les clés de session et ERC-7715 peuvent aider à ajuster l’équilibre entre commodité et sécurité selon les différentes applications. Des architectures plus complexes de gardiens — par exemple avec plusieurs durées de verrou temporel selon différents seuils — peuvent maximiser les chances de récupération légitime tout en minimisant les risques de vol.
Qui ou quoi devraient être les gardiens ?
Pour les utilisateurs expérimentés de la communauté cryptographique, une option viable consiste en les clés de vos amis et membres de votre famille. Si vous leur demandez simplement de vous fournir une nouvelle adresse, personne n’a besoin de savoir qui ils sont — en fait, vos gardiens n’ont même pas besoin de se connaître entre eux. S’ils ne communiquent pas entre eux, le risque de collusion est très faible. Toutefois, cette option n’est pas accessible à la plupart des nouveaux utilisateurs. Une deuxième option est celle des gardiens institutionnels : des entreprises spécialisées qui signent uniquement des transactions après avoir reçu une confirmation supplémentaire de votre part, par exemple un code de vérification, ou un appel vidéo pour les utilisateurs à haut volume. Ce type de service a été tenté depuis longtemps, par exemple j’en ai présenté un appelé CryptoCorp en 2013. Jusqu’à présent, ces entreprises n’ont pas rencontré un grand succès. La troisième option est d’utiliser plusieurs appareils personnels (téléphone, ordinateur de bureau, portefeuille matériel). Cela fonctionne, mais est difficile à configurer et gérer pour les utilisateurs inexpérimentés. Il existe aussi un risque que tous les appareils soient perdus ou volés simultanément, surtout s’ils sont stockés au même endroit. Récemment, nous voyons apparaître davantage de solutions basées sur les clés universelles (passkeys). Ces clés peuvent être sauvegardées uniquement sur vos appareils (solution similaire aux appareils personnels), ou dans le cloud, rendant leur sécurité dépendante d’hypothèses complexes combinant sécurité cryptographique, confiance institutionnelle et matériel sécurisé (Apple, Google). En pratique, les passkeys représentent un gain de sécurité précieux pour les utilisateurs ordinaires, mais elles ne suffisent pas seules à protéger l’intégralité des économies d’un utilisateur. Heureusement, grâce aux ZK-SNARK, une quatrième option émerge : les identités centralisées enveloppées par ZK. Ce type inclut zk-email, Anon Aadhaar, Myna Wallet, etc. Fondamentalement, vous pouvez prendre une identité centralisée (gouvernementale ou d’entreprise), et la transformer en une adresse Ethereum, où vous ne pouvez envoyer des transactions qu’en produisant une preuve ZK-SNARK attestant que vous possédez cette identité.
Avec cette nouveauté, nous disposons désormais d’un large éventail d’options, et les identités centralisées enveloppées par ZK se distinguent par leur grande accessibilité pour les débutants.
Pour cela, elles doivent être implémentées via une interface simple et intégrée : vous devriez pouvoir simplement indiquer « example@gmail.com » comme gardien, et le système devrait automatiquement générer l’adresse Ethereum zk-email correspondante en arrière-plan. Les utilisateurs avancés devraient pouvoir entrer leur e-mail (et éventuellement un sel de confidentialité stocké avec celui-ci) dans une application tierce open source, et vérifier que l’adresse générée est correcte. La même chose devrait être possible pour tout autre type de gardien pris en charge.
Notez qu’un défi pratique actuel de zk-email est qu’il repose sur des signatures DKIM, utilisant des clés changées tous les quelques mois, et que ces clés ne sont pas elles-mêmes signées par une autre entité. Cela signifie que zk-email impose actuellement un niveau de confiance légèrement supérieur à celui du fournisseur lui-même. Cette situation pourrait être atténuée si zk-email utilisait TLSNotary dans du matériel sécurisé de confiance pour vérifier les nouvelles clés, mais ce n’est pas idéal. On espère que les fournisseurs de messagerie commenceront à signer directement leurs clés DKIM. Aujourd’hui, je recommande d’utiliser zk-email comme gardien unique, mais pas comme majorité : ne placez pas vos fonds dans une configuration où la compromission de zk-email empêcherait l’accès à vos actifs.
Nouveaux utilisateurs et portefeuilles intégrés aux applications
Les nouveaux utilisateurs ne souhaitent pas vraiment renseigner un grand nombre de gardiens lors de leur première inscription. Les portefeuilles devraient donc leur proposer une option très simple. Un chemin naturel serait d’utiliser un schéma 2-sur-3 combinant : l’adresse e-mail via zk-email, une clé stockée localement sur l’appareil de l’utilisateur (probablement une passkey), et une clé de sauvegarde détenue par le fournisseur. À mesure que l’utilisateur gagne en expérience ou accumule plus d’actifs, il devrait être invité à ajouter davantage de gardiens. L'intégration des portefeuilles dans les applications est inévitable, car les applications cherchant à attirer des utilisateurs non cryptographiques ne veulent pas obliger les utilisateurs à télécharger deux nouvelles applications (l’application elle-même et un portefeuille Ethereum), ce qui compliquerait l’expérience. Toutefois, les utilisateurs de portefeuilles d’applications devraient pouvoir lier tous leurs portefeuilles ensemble, afin de n’avoir qu’un seul « problème de contrôle d’accès ». La méthode la plus simple consiste à adopter un schéma hiérarchique, avec un processus rapide de « liaison » permettant à l’utilisateur de désigner son portefeuille principal comme gardien de tous ses portefeuilles intégrés. Le client Farcaster Warpcast prend déjà cela en charge :
Par défaut, la récupération de votre compte Warpcast est contrôlée par l’équipe Warpcast. Cependant, vous pouvez « reprendre » votre compte Farcaster et changer la récupération pour qu’elle pointe 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 modernes font beaucoup pour détecter les fausses adresses, le phishing, les escroqueries et autres menaces externes, et protéger les utilisateurs autant que possible. Toutefois, de nombreuses contre-mesures restent assez primitives : par exemple, exiger un clic pour envoyer ETH ou d’autres jetons vers une nouvelle adresse, que ce soit 100 dollars ou 100 000 dollars. Ici, aucune solution miracle n’existe. Il s’agit plutôt d’une série continue et progressive de correctifs pour différentes catégories de menaces. Malgré cela, continuer à améliorer ces protections présente une grande valeur.Confidentialité
Il est temps de prendre au sérieux la confidentialité sur Ethereum. La technologie ZK-SNARK est désormais très avancée, et les outils de confidentialité ne reposant pas sur des portes dérobées (comme les pools de confidentialité) deviennent de plus en plus matures. De même, les infrastructures secondaires comme Waku et les mempools ERC-4337 gagnent progressivement en stabilité. Toutefois, jusqu’à présent, effectuer un transfert privé sur Ethereum nécessite que l’utilisateur télécharge explicitement un « portefeuille privé », comme Railway (ou Umbra pour les adresses furtives). Cela crée une grande friction et limite fortement le nombre d’utilisateurs prêts à effectuer des transferts privés. La solution est que les transferts privés doivent être intégrés directement dans les portefeuilles. Une implémentation simple serait la suivante : le portefeuille stocke automatiquement une partie des actifs de l’utilisateur comme « solde privé » dans un pool de confidentialité. Lorsqu’un transfert est initié, les fonds sont automatiquement retirés du pool. Si l’utilisateur doit recevoir des fonds, le portefeuille peut générer automatiquement une adresse furtive. De plus, le portefeuille peut générer automatiquement une nouvelle adresse pour chaque application dans laquelle l’utilisateur participe (par exemple, un protocole DeFi). Les dépôts proviendraient du pool de confidentialité, et les retraits iraient directement vers celui-ci. Cela permet de dissocier l’activité de l’utilisateur sur une application donnée de son activité sur d’autres applications.
Un avantage de cette approche est qu’elle constitue non seulement un moyen naturel de transférer des actifs de manière privée, mais aussi d’assurer la confidentialité de l’identité. L’identité existe déjà sur la blockchain : toute application utilisant une preuve d’identité (ex. Gitcoin Grants), tout chat contrôlé par jeton, le protocole Ethereum Follow, etc., relève de l’identité sur chaîne. Nous souhaitons que cet écosystème protège également la vie privée. Cela signifie que les activités sur chaîne de l’utilisateur ne devraient pas être regroupées en un seul endroit : chaque projet devrait stocker ses données séparément, et seul le portefeuille de l’utilisateur devrait avoir une « vue globale » capable de rassembler toutes les preuves. Un écosystème nativement basé sur plusieurs comptes par utilisateur aide à atteindre cet objectif, tout comme les protocoles hors chaîne comme EAS et Zupass.
Ceci représente une vision pragmatique de la confidentialité sur Ethereum à moyen terme. Bien que certaines fonctionnalités puissent être introduites au niveau L1 et L2 pour rendre les transferts privés plus efficaces et fiables, cela peut déjà être mis en œuvre dès maintenant. Certains défenseurs de la confidentialité pensent que seule une confidentialité totale de tout (comme chiffrer l’ensemble de l’EVM) est acceptable. Je pense que cela pourrait être un objectif à long terme idéal, mais cela nécessiterait une refonte fondamentale du modèle de programmation, et n’a pas encore atteint un niveau de maturité suffisant pour être déployé sur Ethereum. Nous avons besoin de confidentialité par défaut pour obtenir un ensemble d’anonymat suffisamment grand. Toutefois, commencer par se concentrer sur (i) les transferts entre comptes, et (ii) l’identité et les cas d’usage associés (comme les preuves privées) est une première étape pragmatique, plus facile à réaliser, et que les portefeuilles peuvent commencer à implémenter dès aujourd’hui.
Les portefeuilles Ethereum doivent aussi devenir des portefeuilles de données
Une conséquence de toute solution de confidentialité efficace est qu’elle crée un besoin pour l’utilisateur de stocker des données hors chaîne, que ce soit pour les paiements, l’identité ou d’autres usages. Cela est évident dans Tornado Cash, qui exige que l’utilisateur conserve chaque « billet » représentant un dépôt de 0,1 à 100 ETH. Les protocoles de confidentialité plus modernes stockent parfois des données chiffrées sur chaîne, déchiffrables avec une seule clé privée. Cela comporte un risque : si la clé est compromise, ou si les ordinateurs quantiques deviennent réalisables, toutes les données deviennent publiques. Le besoin de stockage hors chaîne est encore plus évident avec des protocoles comme EAS et Zupass. Les portefeuilles doivent devenir non seulement des logiciels de gestion des accès sur chaîne, mais aussi des logiciels de stockage de données privées. Même en dehors du monde cryptographique, cette prise de conscience grandit, par exemple le travail récent de Tim Berners-Lee sur le stockage personnel des données. Tous les problèmes que nous devons résoudre autour de garanties robustes d’accès, nous devons aussi les résoudre autour de la disponibilité et de la non-fuite des données. Peut-être pouvons-nous superposer ces solutions : si vous avez N gardiens, utilisez un partage secret M-sur-N pour stocker vos données entre eux. Les données sont intrinsèquement plus difficiles à protéger, car on ne peut pas annuler la part d’une personne, mais nous devrions proposer des solutions de garde décentralisées aussi sûres que possible.Accès sécurisé à la chaîne
Aujourd’hui, les portefeuilles font confiance à leur fournisseur RPC pour leur donner toute information sur la chaîne. C’est une faille comportant deux aspects :- Le fournisseur RPC pourrait tenter de voler de l’argent en fournissant de fausses informations, par exemple sur les prix du marché.
- Le fournisseur RPC peut extraire des informations privées sur les applications et comptes avec lesquels l’utilisateur interagit.
Pour garantir l’honnêteté du serveur, chaque élément de la base de données est lui-même une branche Merkle, que le client peut vérifier via un client léger.
La PIR (TechFlow note : généralement appelée « Private Information Retrieval », une technique permettant à un utilisateur de récupérer des informations d’une base de données sans révéler quelle information a été récupérée.) est extrêmement coûteuse en calcul. Plusieurs voies existent pour y remédier :
- Force brute : des améliorations algorithmiques ou du matériel spécialisé pourraient rendre la PIR suffisamment rapide. Ces techniques pourraient reposer sur un prétraitement : le serveur stocke des données chiffrées et brouillées pour chaque client, et le client interroge ces données. Le défi dans l’environnement Ethereum est d’adapter ces techniques à des jeux de données changeant rapidement (comme l’état). Cela rend le calcul en temps réel moins coûteux, mais augmente probablement le coût total en calcul et stockage.
- Assouplir les exigences de confidentialité : par exemple, limiter chaque recherche à 1 million de « mixins », de sorte que le serveur sache que le client a accédé à l’un parmi un million de valeurs possibles, mais rien de plus précis.
- PIR multi-serveurs : si vous utilisez plusieurs serveurs, et que l’hypothèse d’honnêteté est 1 parmi N, les algorithmes PIR deviennent généralement plus rapides.
- Anonymat au lieu de confidentialité : les requêtes peuvent être envoyées via un réseau mixte, masquant l’expéditeur au lieu du contenu. Toutefois, cela augmente inévitablement la latence, nuisant à l’expérience utilisateur.
Portefeuille idéal avec coffre-fort de clés
Outre les transferts et l’accès à l’état, un autre flux de travail important qui doit fonctionner harmonieusement dans un contexte multi-L2 est la modification de la configuration de validation d’un compte : que ce soit changer ses clés (par exemple, récupération), ou apporter des modifications plus profondes à la logique du compte. Trois niveaux de solutions existent, classés par difficulté croissante :- Réémission des mises à jour : lorsque l’utilisateur modifie sa configuration, le message autorisant ce changement est réémis sur chaque chaîne où le portefeuille détecte que l’utilisateur possède des actifs. Idéalement, le format du message et les règles de validation seraient indépendants de la chaîne, permettant une réémission automatique sur autant de chaînes que possible.
- Coffre-fort de clés sur L1 : les informations de configuration sont stockées sur L1, et les portefeuilles sur L2 les lisent via L1SLOAD ou appel statique distant. Ainsi, une mise à jour sur L1 suffit, et la configuration devient effective partout.
- Coffre-fort de clés sur L2 : les informations sont sur L2, et les portefeuilles utilisent des ZK-SNARK pour les lire. Identique à (2), sauf que la mise à jour du coffre-fort est potentiellement moins chère, mais la lecture plus coûteuse.
La solution (3) est particulièrement puissante car elle s’intègre bien à la confidentialité. Dans une solution de confidentialité normale, l’utilisateur possède un secret s, publie une « valeur feuille » L sur chaîne, et prouve que L = hash(s, 1) et N = hash(s, 2) pour un secret s qu’il contrôle (jamais divulgué). L’« invalidateur » N est publié pour empêcher toute future dépense de la même feuille, sans révéler L, tant que s reste sécurisé. Une solution de confidentialité compatible avec la récupération dirait : s est un emplacement (adresse et slot de stockage) sur chaîne, et l’utilisateur doit prouver une requête d’état : L = hash(sload(s), 1).
Sécurité des dApps
Le maillon le plus faible de la sécurité utilisateur est souvent la dApp. La plupart du temps, les utilisateurs interagissent avec une application via un site web, qui télécharge implicitement en temps réel le code de l’interface utilisateur depuis un serveur, puis l’exécute dans le navigateur. Si le serveur est piraté, ou si le DNS est compromis, l’utilisateur obtient une copie falsifiée de l’interface, pouvant le tromper pour exécuter des actions arbitraires. Des fonctionnalités comme la simulation de transactions dans les portefeuilles aident à réduire ce risque, mais elles sont loin d’être parfaites. À terme, nous devrions migrer l’écosystème vers un contrôle de version des contenus sur chaîne : l’utilisateur accède à la dApp via son nom ENS, qui contient le hachage IPFS de l’interface. Mettre à jour l’interface nécessite une transaction sur chaîne signée par une multisignature ou un DAO. Le portefeuille afficherait à l’utilisateur s’il interagit avec une interface plus sécurisée (sur chaîne) ou moins sécurisée (Web2). Le portefeuille pourrait aussi indiquer si l’on interagit avec une chaîne sécurisée (par exemple phase 1+, audits multiples). Pour les utilisateurs soucieux de confidentialité, le portefeuille pourrait ajouter un mode paranoïaque, exigeant que l’utilisateur clique pour accepter chaque requête HTTP, et pas seulement les opérations web3 :
Modèle d’interface possible pour le mode paranoïaque
Une approche plus avancée consisterait à aller au-delà du HTML + Javascript, en écrivant la logique métier des dApps dans un langage spécialisé (peut-être une fine couche au-dessus de Solidity ou Vyper). Le navigateur pourrait alors générer automatiquement l’interface utilisateur nécessaire. OKContract fait déjà cela.
Une autre direction est la défense informationnelle crypto-économique : les développeurs de dApps, sociétés de sécurité, déployeurs de chaînes, etc., pourraient déposer une caution, qui serait versée aux utilisateurs affectés (après décision d’un DAO d’arbitrage sur chaîne) en cas de piratage ou de tromperie grave. Le portefeuille pourrait afficher aux utilisateurs un score basé sur la taille de la caution.
Un futur plus lointain
Tout ce qui précède suppose un cadre d’interface traditionnel, basé sur pointer, cliquer et saisir du texte. Pourtant, nous sommes aussi à l’aube d’un changement de paradigme plus profond :- Intelligence artificielle, qui pourrait nous faire passer d’un paradigme basé sur les clics et la frappe à un paradigme du type « dites ce que vous voulez faire, et un robot s’occupe du reste ».
- Interfaces cerveau-machine, allant des méthodes « douces » comme le suivi oculaire, à des technologies plus directes, voire invasives (voir : le premier patient Neuralink).
- Défense active côté client : le navigateur Brave protège activement les utilisateurs contre la publicité, le pistage et bien d'autres menaces. De nombreux navigateurs, extensions et portefeuilles cryptographiques disposent désormais d’équipes entières dédiées à la protection contre les menaces de sécurité et de confidentialité. Ces « gardiens actifs » ne feront que gagner en puissance au cours des dix prochaines années.
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
Ajouter aux favoris
Partager sur les réseaux sociaux
@VitalikButerin
