Merci tout particulièrement à Dan Finlay, Karl Floersch, David Hoffman et aux équipes de Scroll et SoulWallet pour leurs commentaires et suggestions.

Alors qu'Ethereum passe d'une jeune technologie expérimentale à une technologie mature capable de proposer une expérience ouverte, globale et sans autorisation aux utilisateurs moyens, la pile doit subir trois transitions techniques majeures, à peu près simultanément :

• La transition vers la L2 : tout le monde passe aux cumuls
• La transition vers la sécurité des portefeuilles : tout le monde passe aux portefeuilles à contrats intelligents
• La transition vers la confidentialité : s'assurer que des transferts de fonds respectueux de la vie privée sont disponibles et s'assurer que tous les autres gadgets en cours de développement (rétablissement social, identité, réputation) préservent la confidentialité

Le triangle de transition écosystémique. Vous ne pouvez en choisir que 3 sur 3.

Sans le premier, Ethereum échoue parce que chaque transaction coûte 3,75 dollars (82,48 dollars s'il s'agit d'une nouvelle hausse), et chaque produit destiné au marché de masse oublie inévitablement la chaîne et adopte des solutions de contournement centralisées pour tout.

Sans le second, Ethereum échoue parce que les utilisateurs ne sont pas à l'aise pour stocker leurs fonds (et leurs actifs non financiers), et tout le monde passe à des plateformes d'échange centralisées.

Sans le troisième, Ethereum échoue parce que le fait de rendre toutes les transactions (et les POAP, etc.) accessibles au public représente un sacrifice de confidentialité bien trop important pour de nombreux utilisateurs, et tout le monde passe à des solutions centralisées qui masquent au moins quelque peu vos données.

Ces trois transitions sont cruciales pour les raisons ci-dessus. Mais ils constituent également un défi en raison de l'intense coordination nécessaire pour les résoudre correctement. Les fonctionnalités du protocole ne sont pas les seules à devoir être améliorées ; dans certains cas, la façon dont nous interagissons avec Ethereum doit changer fondamentalement, ce qui nécessite des modifications profondes de la part des applications et des portefeuilles.

Les trois transitions vont radicalement remodeler la relation entre les utilisateurs et les adresses

Dans un monde qui évolue en L2, les utilisateurs existeront sur de nombreuses L2. Êtes-vous membre d'ExampleDAO, qui vit sur Optimism ? Alors vous avez un compte sur Optimism ! Détenez-vous un CDP dans un système de stablecoin sur zkSync ? Alors vous avez un compte sur zkSync ! Avez-vous déjà essayé une application qui se trouve sur Kakarot ? Alors vous avez un compte sur Kakarot ! L'époque où les utilisateurs n'avaient qu'une seule adresse sera révolue.

J'ai de l'ETH à quatre endroits, selon mon point de vue sur Brave Wallet. Et oui, Arbitrum et Arbitrum Nova sont différents. Ne vous inquiétez pas, les choses vont devenir de plus en plus confuses avec le temps !

Les portefeuilles à contrats intelligents ajoutent à la complexité, car il est beaucoup plus difficile d'avoir la même adresse en L1 et dans les différentes L2. Aujourd'hui, la plupart des utilisateurs utilisent des comptes externes, dont l'adresse est littéralement un hash de la clé publique utilisée pour vérifier les signatures. Rien ne change donc entre la L1 et la L2. Avec les portefeuilles à contrats intelligents, il devient toutefois plus difficile de conserver une seule adresse. Bien que beaucoup de travail ait été fait pour essayer de faire des adresses des hachages de code équivalents sur tous les réseaux, notamment CREATE2 et la fabrique de singleton ERC-2470, il est difficile de faire en sorte que cela fonctionne parfaitement. Certaines L2 (par exemple. (« ZK-EVM de type 4 ») ne sont pas tout à fait équivalents à un EVM. Ils utilisent souvent Solidity ou un assemblage intermédiaire, ce qui empêche l'équivalence de hachage. Et même lorsque vous pouvez avoir une équivalence de hachage, la possibilité que les portefeuilles changent de propriétaire en raison de changements clés a d'autres conséquences peu intuitives.

La confidentialité oblige chaque utilisateur à avoir encore plus d'adresses, et cela peut même modifier le type d'adresses auquel nous avons affaire. Si les propositions d'adresses furtives sont largement utilisées, au lieu que chaque utilisateur n'ait que quelques adresses, soit une adresse par L2, les utilisateurs pourraient avoir une adresse par transaction. D'autres systèmes de confidentialité, même ceux qui existent déjà, tels que Tornado Cash, modifient différemment la façon dont les actifs sont stockés : les fonds de nombreux utilisateurs sont stockés dans le même contrat intelligent (et donc à la même adresse). Pour envoyer des fonds à un utilisateur en particulier, les utilisateurs devront s'appuyer sur le système d'adressage interne du système de confidentialité.

Comme nous l'avons vu, chacune des trois transitions affaiblit le modèle mental « un utilisateur ~= une adresse » de différentes manières, et certains de ces effets se répercutent sur la complexité de l'exécution des transitions. Les deux points de complexité sont les suivants :

1. Si vous voulez payer quelqu'un, comment allez-vous obtenir les informations nécessaires pour le payer ?
2. Si les utilisateurs ont de nombreux actifs stockés à différents endroits et dans différentes chaînes, comment s'y prennent-ils pour apporter des changements clés et favoriser la reprise sociale?

Les trois transitions et les paiements en chaîne (et l'identité)

J'ai des pièces sur Scroll et je veux payer pour le café (si le « je » est littéralement moi, l'auteur de cet article, alors « café » est bien sûr une métonymie de « thé vert »). Vous êtes en train de me vendre du café, mais vous êtes uniquement prête à recevoir des pièces sur Taiko. Que faire ?

Il existe essentiellement deux solutions :

1. Les portefeuilles de réception (qui peuvent être des marchands, mais aussi des particuliers) font de leur mieux pour prendre en charge chaque L2 et disposent de fonctionnalités automatisées pour consolider les fonds de manière asynchrone.
2. Le destinataire indique sa L2 en plus de son adresse, et le portefeuille de l'expéditeur achemine automatiquement les fonds vers la L2 de destination via un système de passerelle inter-L2.

Bien entendu, ces solutions peuvent être combinées : le destinataire fournit la liste des L2 qu'il est prêt à accepter, et le portefeuille de l'expéditeur prend en charge le paiement, ce qui peut impliquer soit un envoi direct s'il a de la chance, soit un parcours de passerelle entre L2.

Mais ce n'est qu'un exemple du défi majeur introduit par les trois transitions : des actions simples, comme payer quelqu'un, commencent à nécessiter bien plus d'informations qu'une simple adresse de 20 octets.

La transition vers des portefeuilles de contrats intelligents ne représente heureusement pas une lourde charge pour le système d'adressage, mais certains problèmes techniques persistent dans d'autres parties de la pile d'applications qui doivent être résolus. Les portefeuilles devront être mis à jour pour s'assurer qu'ils n'envoient pas seulement 21 000 gaz en même temps qu'une transaction, et il sera encore plus important de s'assurer que la partie destinataire des paiements suit non seulement les transferts d'ETH depuis les EOA, mais également les ETH envoyés par code de contrat intelligent. Des applications qui partent du principe que la propriété des adresses est immuable (par ex. Les NFT (qui interdisent les contrats intelligents pour faire appliquer les redevances) devront trouver d'autres moyens d'atteindre leurs objectifs. Les portefeuilles à contrats intelligents faciliteront également certaines choses, notamment si quelqu'un reçoit uniquement un jeton ERC20 autre que l'ETH, il pourra utiliser l'ERC-4337 pour payer l'essence avec ce jeton.

La confidentialité, en revanche, pose une fois de plus des défis majeurs que nous n'avons pas encore vraiment abordés. Le Tornado Cash original n'a introduit aucun de ces problèmes, car il ne permettait pas les virements internes : les utilisateurs ne pouvaient que déposer dans le système et en retirer. Une fois que vous pourrez effectuer des transferts internes, les utilisateurs devront utiliser le schéma d'adressage interne du système de confidentialité. Dans la pratique, les « informations de paiement » d'un utilisateur devraient contenir à la fois (i) une sorte de « clé publique de dépense », un engagement à respecter un secret que le destinataire pourrait utiliser pour dépenser, et (ii) un moyen permettant à l'expéditeur d'envoyer des informations cryptées que seul le destinataire peut déchiffrer, afin de l'aider à découvrir le paiement.

Les protocoles d'adresses furtifs reposent sur un concept de méta-adresses, qui fonctionnent de la manière suivante : une partie de la méta-adresse est une version masquée de la clé de dépense de l'expéditeur, et une autre partie est la clé de cryptage de l'expéditeur (même si une implémentation minimale pourrait définir ces deux clés comme identiques).

Présentation schématique d'un schéma d'adresses furtif abstrait basé sur le cryptage et les zk-SNARKS.

L'une des principales leçons à tirer est que dans un écosystème respectueux de la vie privée, un utilisateur disposera à la fois de clés publiques de dépenses et de clés de chiffrement, et les « informations de paiement » de l'utilisateur devront inclure les deux clés. Il existe également de bonnes raisons autres que les paiements pour se développer dans cette direction. Par exemple, si nous voulons des e-mails cryptés basés sur Ethereum, les utilisateurs devront fournir publiquement une sorte de clé de cryptage. Dans « EOA world », nous pourrions réutiliser les clés de compte pour cela, mais dans un monde de portefeuilles intelligents sécurisés, nous devrions probablement disposer de fonctionnalités plus explicites à cet égard. Cela permettrait également de rendre l'identité basée sur Ethereum plus compatible avec les écosystèmes de confidentialité décentralisés n'appartenant pas à Ethereum, notamment les clés PGP.

Les trois transitions et les clés de la reprise

La méthode par défaut pour mettre en œuvre les principaux changements et la reprise sociale dans un monde où il y a plusieurs adresses par utilisateur est de simplement demander aux utilisateurs d'exécuter la procédure de restauration pour chaque adresse séparément. Cela se fait en un clic : le portefeuille peut inclure un logiciel permettant d'exécuter la procédure de récupération sur toutes les adresses des utilisateurs en même temps. Cependant, malgré de telles simplifications de l'expérience utilisateur, la restauration multi-adresses naïve pose trois problèmes :

1. L'impossibilité de payer le gaz : celui-ci va de soi.
2. Adresses contrefactuelles : adresses pour lesquelles le contrat intelligent n'a pas encore été publié (en pratique, il s'agira d'un compte depuis lequel vous n'avez pas encore envoyé de fonds). En tant qu'utilisateur, vous avez un nombre potentiellement illimité d'adresses contrefactuelles : une ou plusieurs sur chaque L2, y compris des adresses L2 qui n'existent pas encore, et un tout autre ensemble infini d'adresses contrefactuelles issues de schémas d'adresses furtifs.
3. Confidentialité : si un utilisateur possède intentionnellement de nombreuses adresses pour ne pas les relier les unes aux autres, il ne veut certainement pas les lier toutes publiquement en les récupérant au même moment ou à peu près !

Il est difficile de résoudre ces problèmes. Heureusement, il existe une solution assez élégante qui fonctionne assez bien : une architecture qui sépare la logique de vérification de la détention d'actifs.

Chaque utilisateur a un contrat de keystore, qui existe en un seul endroit (il peut s'agir du réseau principal ou d'un L2 en particulier). Les utilisateurs ont ensuite des adresses sur différents L2, où la logique de vérification de chacune de ces adresses renvoie au contrat de keystore. Les dépenses effectuées à partir de ces adresses nécessiteraient une preuve figurant dans le contrat du magasin de clés indiquant la clé publique de dépenses en cours (ou, plus réaliste, très récente).

La preuve peut être mise en œuvre de plusieurs manières :

• Accès direct à la L1 en lecture seule à l'intérieur de la L2. Il est possible de modifier les L2 pour leur permettre de lire directement l'état L1. Si le contrat du keystore est en L1, cela signifierait que les contrats en L2 peuvent accéder au keystore « gratuitement »
• Succursales Merkle. Les branches de Merkle peuvent prouver un état L1 à un état L2, ou un état L2 à un L1, ou vous pouvez combiner les deux pour prouver des parties de l'état d'une L2 à une autre L2. Le principal point faible des preuves Merkle est le coût élevé du gaz dû à la longueur des preuves : potentiellement 5 ko pour une preuve, mais ce chiffre sera réduit à < 1 ko à l'avenir à cause des arbres Verkle.
• ZK-SNARKS. Vous pouvez réduire les coûts liés aux données en utilisant le ZK-SNARK d'une agence Merkle au lieu de la succursale elle-même. Il est possible de créer des techniques d'agrégation hors chaîne (par exemple, en plus de l'EIP-4337) pour qu'un seul ZK-SNARK vérifie toutes les preuves d'état inter-chaînes d'un bloc.
• Les engagements du KZG. Les L2, ou les schémas construits dessus, pourraient introduire un système d'adressage séquentiel, permettant aux preuves d'état de ce système de ne faire que 48 octets. Comme pour zk-SNARKS, un système à plusieurs preuves pourrait fusionner toutes ces preuves en une seule preuve par bloc.

Si nous voulons éviter de créer une seule preuve par transaction, nous pouvons mettre en place un système plus léger qui n'exige qu'une preuve inter-L2 pour le recouvrement. Les dépenses effectuées depuis un compte dépendent de la clé de dépenses dont la clé publique correspondante est stockée sur ce compte, mais pour les récupérer, il faudrait effectuer une transaction copiant la clé spending_pubkey actuelle dans le keystore. Les fonds déposés dans des adresses contrefactuelles sont en sécurité, même si vos anciennes clés ne le sont pas : pour « activer » une adresse contrefactuelle pour en faire un contrat de travail, il faudrait créer une épreuve transversale L2 à copier sur la clé spending_pubkey actuelle. Ce fil de discussion sur les forums Safe décrit comment une architecture similaire pourrait fonctionner.

Pour garantir la confidentialité d'un tel système, nous cryptons simplement le pointeur, et nous faisons toutes nos preuves dans zk-SNARKS :

Avec plus de travail (par exemple. en utilisant < a href= " https://notes.ethereum.org/@vbuterin/non_index_revealing_proof " > this travail comme point de départ), nous pourrions également éliminer la majeure partie de la complexité des zk-SNARKs et créer un schéma plus simple basé sur le KZG.

Ces programmes peuvent devenir complexes. Le côté positif, c'est qu'il existe de nombreuses synergies potentielles entre elles. Par exemple, le concept de « contrats de magasin de clés » pourrait également apporter une solution au défi des « adresses » mentionné dans la section précédente : si nous voulons que les utilisateurs aient des adresses persistantes, qui ne changent pas à chaque fois que l'utilisateur met à jour une clé, nous pourrions insérer des méta-adresses furtives, des clés de cryptage et d'autres informations dans le contrat de magasin de clés, et utiliser l'adresse du contrat de magasin de clés comme « adresse » de l'utilisateur.

De nombreuses infrastructures secondaires doivent être mises à jour

L'utilisation de l'ENS coûte cher. Aujourd'hui, en juin 2023, la situation n'est pas trop mauvaise : les frais de transaction sont importants, mais ils restent comparables aux frais de domaine ENS. L'enregistrement de zuzalu.eth m'a coûté environ 27 dollars, dont 11 dollars de frais de transaction. Mais s'il y a un nouveau marché haussier, les frais monteront en flèche. Même sans hausse du prix de l'ETH, le retour des frais de gaz à 200 gwei porterait les frais d'enregistrement d'un domaine à 104 dollars. Donc, si nous voulons que les gens utilisent réellement ENS, en particulier pour des cas d'utilisation tels que les réseaux sociaux décentralisés où les utilisateurs demandent une inscription quasi gratuite (et les frais de domaine ENS ne sont pas un problème car ces plateformes proposent des sous-domaines à leurs utilisateurs), nous avons besoin qu'ENS travaille sur la L2.

Heureusement, l'équipe de l'ENS s'est intensifiée et l'ENS en L2 est en train de se concrétiser ! L'ERC-3668 (alias « la norme CCIP ») et l'ENSIP-10 permettent de vérifier automatiquement les sous-domaines ENS de n'importe quelle L2. La norme CCIP impose la mise en place d'un contrat intelligent qui décrit une méthode pour vérifier les preuves de données relatives à la couche 2 et à un domaine (par ex. Optinames (utilise ecc.eth) peut être placée sous le contrôle d'un tel contrat. Une fois que le contrat CCIP contrôlera ecc.eth en L1, accéder à un sous-domaine .ecc.eth impliquera automatiquement de trouver et de vérifier une preuve (par ex. Merkle (branche) de l'État en L2 qui stocke réellement ce sous-domaine en particulier.

En fait, pour récupérer les preuves, il faut accéder à une liste d'URL stockées dans le contrat, ce qui ressemble à de la centralisation, mais je dirais que ce n'est pas le cas : c'est un modèle de confiance 1 sur N (les preuves non valides sont détectées par la logique de vérification de la fonction de rappel du contrat CCIP, et tant que ne serait-ce qu'une des URL renvoie une preuve valide, c'est bien). La liste des URL peut en contenir des dizaines.

L'effort du CCIP de l'ENS est une réussite, et il faut y voir le signe que les réformes radicales dont nous avons besoin sont réellement possibles. Mais il reste encore beaucoup à faire au niveau de la couche d'application. Quelques exemples :

• De nombreuses applications dépendent de la fourniture de signatures hors chaîne par les utilisateurs. Avec les comptes détenus par des tiers (EOA), c'est facile. L'ERC-1271 propose une méthode standardisée pour les portefeuilles à contrats intelligents. Cependant, de nombreuses applications ne sont toujours pas compatibles avec l'ERC-1271 ; elles en auront besoin.
• Dapps qui utilisent « Est-ce une EOA ? » pour faire de la discrimination entre les utilisateurs et les contrats (par exemple pour empêcher les transferts ou appliquer des redevances) seront résiliés. En général, je déconseille d'essayer de trouver une solution purement technique ici ; déterminer si un transfert particulier de contrôle cryptographique est un transfert de propriété effective est un problème difficile qui ne peut probablement pas être résolu sans recourir à des mécanismes communautaires hors chaîne. Très probablement, les demandes devront moins s'appuyer sur la prévention des transferts que sur des techniques telles que les impôts Harberger.
• La façon dont les portefeuilles interagissent avec les dépenses et les clés de cryptage devra être améliorée. Actuellement, les portefeuilles utilisent souvent des signatures déterministes pour générer des clés spécifiques à une application : signer un nonce standard (par exemple, le hachage du nom de l'application) avec la clé privée d'un EOA génère une valeur déterministe qui ne peut pas être générée sans clé privée, et c'est donc sécurisé d'un point de vue purement technique. Cependant, ces techniques sont « opaques » pour le portefeuille, l'empêchant de mettre en œuvre des contrôles de sécurité au niveau de l'interface utilisateur. Dans un écosystème plus mature, la signature, le cryptage et les fonctionnalités associées devront être gérés de manière plus explicite par les portefeuilles.
• Des clients légers (par ex. Helios) devra vérifier les L2 et pas seulement la L1. Aujourd'hui, les clients légers se concentrent sur la vérification de la validité des en-têtes L1 (à l'aide du protocole Light Client Sync) et sur la vérification des branches Merkle de l'état L1 et des transactions enracinées dans l'en-tête L1. Demain, ils devront également vérifier une preuve de l'état L2 enracinée dans la racine d'état stockée dans la L1 (une version plus avancée de cette version examinerait les pré-confirmations L2).

Les portefeuilles devront sécuriser à la fois les actifs et les données

Aujourd'hui, les portefeuilles ont pour but de sécuriser des actifs. Tout se passe en chaîne, et la seule chose que le portefeuille doit protéger, c'est la clé privée qui protège actuellement ces actifs. Si vous changez de clé, vous pouvez publier votre ancienne clé privée en toute sécurité sur Internet le lendemain. Dans un monde ZK, ce n'est plus vrai : le portefeuille ne se contente pas de protéger les informations d'authentification, il contient également vos données.

Nous avons vu les premiers signes d'un tel monde avec Zupass, le système d'identité basé sur ZK-SNARK qui a été utilisé à Zuzalu. Les utilisateurs disposaient d'une clé privée qu'ils utilisaient pour s'authentifier auprès du système, qui pouvait être utilisée pour apporter des preuves de base, comme « prouver que je suis un résident de Zuzalu, sans révéler lequel ». Mais le système Zupass a également commencé à intégrer d'autres applications, notamment stamps (la version Zupass de PoAP).

L'un de mes nombreux timbres Zupass, qui confirme que je suis fière de faire partie de Team Cat.

La principale caractéristique des timbres par rapport aux POAP est que les timbres sont privés : vous conservez les données localement, et vous ne prouvez un tampon (ou un calcul sur les timbres) qu'à quelqu'un si vous voulez qu'il ait ces informations vous concernant. Mais cela crée un risque supplémentaire : si vous perdez ces informations, vous perdez vos tampons.

Bien entendu, le problème de la conservation des données peut être réduit à celui de la détention d'une clé de cryptage unique : un tiers (ou même la chaîne) peut détenir une copie cryptée des données. Cela présente l'avantage pratique que les actions que vous effectuez ne modifient pas la clé de cryptage et ne nécessitent donc aucune interaction avec le système qui protège votre clé de cryptage. Mais quand même, si vous perdez votre clé de cryptage, vous perdez tout. Et d'un autre côté, si quelqu'un voit votre clé de cryptage, il voit tout ce qui a été chiffré avec cette clé.

La solution de facto de Zupass était d'encourager les utilisateurs à stocker leur clé sur plusieurs appareils (par exemple. ordinateur portable et téléphone), car le risque qu'ils perdent l'accès à tous leurs appareils en même temps est minime. Nous pourrions aller plus loin et utiliser le partage secret pour stocker la clé, partagée entre plusieurs tuteurs.

Ce type de relance sociale via MPC n'est pas une solution suffisante pour les portefeuilles, car cela signifie que non seulement les tuteurs actuels mais aussi les tuteurs précédents peuvent s'entendre pour voler vos actifs, ce qui représente un risque inacceptable. Mais les fuites de confidentialité présentent généralement un risque moindre que la perte totale d'actifs, et une personne dont le cas d'utilisation est très exigeant en matière de confidentialité peut toujours accepter un risque de perte plus élevé en ne sauvegardant pas la clé associée à ces actions exigeantes en matière de confidentialité.

Pour éviter de submerger l'utilisateur avec un système byzantin proposant de multiples voies de restauration, les portefeuilles qui soutiennent la reprise sociale devront probablement gérer à la fois le recouvrement des actifs et la récupération des clés de cryptage.

Retour à l'identité

L'un des points communs de ces changements est que le concept d' « adresse », un identifiant cryptographique que vous utilisez pour vous représenter sur la chaîne, va devoir changer radicalement. Les « Instructions pour interagir avec moi » ne seraient plus simplement une adresse ETH ; il faudrait, d'une manière ou d'une autre, une combinaison de plusieurs adresses sur plusieurs L2, de méta-adresses furtives, de clés de cryptage et d'autres données.

L'un des moyens d'y parvenir est de vous identifier : votre fiche ENS peut simplement contenir toutes ces informations, et si vous envoyez à quelqu'un bob.eth (ou bob.ecc.eth, ou...), ils pourraient rechercher et voir tout ce qui concerne la manière de payer et d'interagir avec vous, y compris de manière plus complexe, interdomaines et préservant la confidentialité.

Mais cette approche centrée sur l'ENS présente deux points faibles :

• Il y a trop de liens avec votre nom. Votre nom n'est pas vous, votre nom est l'un des nombreux attributs qui vous caractérisent. Il devrait être possible de changer de nom sans modifier l'intégralité de votre profil d'identité et sans mettre à jour toute une série de dossiers sur de nombreuses applications.
• Vous ne pouvez pas avoir de faux noms fiables. L'une des caractéristiques UX clés de toute blockchain est la possibilité d'envoyer des pièces à des personnes qui n'ont pas encore interagi avec la chaîne. Sans cette fonctionnalité, il y a un hic : pour interagir avec la chaîne, il faut payer des frais de transaction, ce qui implique... d'avoir déjà des pièces. Les adresses ETH, y compris les adresses de contrats intelligents avec CREATE2, disposent de cette fonctionnalité. Les noms ENS ne le font pas, parce que si deux Bob décident tous deux hors chaîne qu'il s'agit de bob.ecc.eth, il n'y a aucun moyen de choisir lequel d'entre eux portera le nom.

L'une des solutions possibles est d'intégrer plus d'éléments dans le contrat de keystore mentionné dans l'architecture plus tôt dans ce billet. Le contrat de magasin de clés peut contenir toutes les informations vous concernant et la manière d'interagir avec vous (et avec le CCIP, certaines de ces informations peuvent être hors chaîne), et les utilisateurs utiliseraient leur contrat de magasin de clés comme identifiant principal. Mais les actifs qu'ils reçoivent seraient entreposés dans toutes sortes d'endroits différents. Les contrats de keystore ne sont pas liés à un nom et peuvent être contrefactuels : vous pouvez générer une adresse qui ne peut être initialisée que par un contrat de keystore comportant certains paramètres initiaux fixes.

Une autre catégorie de solutions consiste à abandonner complètement le concept d'adresses destinées aux utilisateurs, dans le même esprit que le protocole de paiement Bitcoin. L'une des idées est de s'appuyer davantage sur les canaux de communication directs entre l'expéditeur et le destinataire ; par exemple, l'expéditeur pourrait envoyer un lien de réclamation (sous forme d'URL explicite ou de code QR) que le destinataire pourrait utiliser pour accepter le paiement comme il le souhaite.

Que l'expéditeur ou le destinataire agisse en premier, le fait de s'appuyer davantage sur les portefeuilles qui génèrent directement des informations de paiement à jour en temps réel pourrait réduire les frictions. Cela dit, les identifiants persistants sont pratiques (surtout avec l'ENS), et l'hypothèse d'une communication directe entre l'expéditeur et le destinataire est très délicate dans la pratique. Il se peut donc que nous finissions par voir une combinaison de différentes techniques.

Dans tous ces modèles, il est primordial de décentraliser les choses et de les rendre compréhensibles pour les utilisateurs. Nous devons nous assurer que les utilisateurs ont facilement accès à une vue actualisée de leurs actifs actuels et des messages qui leur sont destinés qui ont été publiés. Ces points de vue devraient reposer sur des outils ouverts, et non sur des solutions propriétaires. Il faudra travailler dur pour éviter que la complexité croissante de l'infrastructure de paiement ne se transforme en une « tour d'abstraction » opaque où les développeurs ont du mal à comprendre ce qui se passe et à l'adapter à de nouveaux contextes. Malgré les défis, l'évolutivité, la sécurité des portefeuilles et la confidentialité pour les utilisateurs réguliers sont cruciaux pour l'avenir d'Ethereum. Il ne s'agit pas seulement d'une question de faisabilité technique, mais d'accessibilité réelle pour les utilisateurs réguliers. Nous devons être à la hauteur pour relever ce défi.

Avertissement：

1. Cet article est repris de [Vitalik]. Tous les droits d'auteur appartiennent à l'auteur original [Vitalik Buterin]. En cas d'objection à cette réimpression, contactez l'équipe de Gate Learn, elle s'en occupera rapidement.
2. Avertissement en matière de responsabilité : Les points de vue et opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent en aucun cas un conseil d'investissement.
3. Les traductions de l'article dans d'autres langues sont effectuées par l'équipe de Gate Learn. Sauf mention contraire, il est interdit de copier, de distribuer ou de plagier les articles traduits.