Lorsqu'Ethereum passe d'une jeune technologie expérimentale à une pile technologique mature qui peut véritablement apporter une expérience ouverte, globale et sans autorisation aux utilisateurs ordinaires, la pile doit passer par trois transformations technologiques majeures, à peu près simultanément :
Changement de mise à l'échelle L2 - tous migrés vers des cumuls
Wallet Security Shift - Tous migrent vers des portefeuilles de contrats intelligents
Privacy Shift - Assurez-vous que les transferts d'argent préservent la confidentialité et assurez-vous que tous les autres outils en cours de développement (récupération sociale, identité, réputation) préservent la confidentialité
C'est le triangle de la transformation de l'écosystème. Vous ne pouvez en choisir que 3 sur 3.
Sans le premier, Ethereum échouerait car chaque transaction coûterait 3,75 $ (82,48 $ si nous avions une autre course haussière), et chaque produit du marché de masse finirait par oublier la chaîne, et prendrait une solution centralisée pour tout.
Sans le second, Ethereum échouerait car les utilisateurs seraient réticents à stocker leurs fonds (et actifs non financiers) et tous passeraient à des échanges centralisés.
Sans un tiers, Ethereum échouerait, car toutes les transactions (et les POAP, etc.) seraient publiques pour que tout le monde puisse les voir, ce qui serait un sacrifice exorbitant de la vie privée pour de nombreux utilisateurs, et tout le monde se déplacerait pour avoir au moins quelques données cachées centralisées solution.
Pour les raisons évoquées ci-dessus, ces trois transitions sont critiques. Mais ils sont également difficiles en raison de l'intense coordination nécessaire pour les résoudre. Non seulement la fonctionnalité du protocole doit être améliorée, mais il existe des cas où des changements assez fondamentaux doivent être apportés à la façon dont nous interagissons avec Ethereum, nécessitant des modifications profondes des applications et des portefeuilles.
Ces trois changements vont révolutionner la relation entre les utilisateurs et les adresses
Dans un monde étendu à la L2, les utilisateurs existeront dans de nombreuses L2. Êtes-vous membre d'ExampleDAO, qui est sur Optimism ? Alors vous avez un compte sur Optimism ! Détenez-vous CDP dans le système stablecoin de ZkSync ? Alors vous avez un compte sur ZkSync ! Avez-vous essayé des applications qui se trouvent sur Kakarot ? Alors vous avez un compte sur Kakarot ! L'époque où les utilisateurs n'avaient qu'une seule adresse est révolue.
J'ai ETH à quatre endroits, selon ma vue Brave Wallet. Oui, Arbitrum et Arbitrum Nova sont différents. Ne vous inquiétez pas, cela se compliquera avec le temps !
Les portefeuilles de contrats intelligents ajoutent plus de complexité, ce qui rend plus difficile d'avoir la même adresse sur L1 et divers L2. Aujourd'hui, la plupart des utilisateurs utilisent des comptes externes dont les adresses sont en fait le hachage de la clé publique utilisée pour vérifier la signature - donc rien ne change entre L1 et L2. Cependant, avec les portefeuilles de contrats intelligents, il devient plus difficile de conserver une adresse. Alors que beaucoup de travail a été fait pour essayer de faire des adresses un hachage de code équivalent à travers le réseau, notamment les usines de singleton CREATE2 et ERC-2470, il a été très difficile de le faire parfaitement. Certains L2 (tels que les "ZK-EVM de type 4") ne sont pas entièrement équivalents aux EVM, utilisant généralement Solidity ou un assemblage intermédiaire à la place, empêchant l'équivalence de hachage. Même si vous pouviez avoir une équivalence de hachage, la possibilité que les portefeuilles changent de propriétaire par le biais de changements de clé a d'autres conséquences non intuitives.
La confidentialité nécessite plus d'adresses par utilisateur et peut même modifier les types d'adresses que nous traitons. Si la proposition d'adresse privée est largement utilisée, au lieu de quelques adresses par utilisateur ou d'une adresse par L2, il peut y avoir une adresse par transaction. D'autres systèmes de confidentialité, même ceux existants comme Tornado Cash, modifient la façon dont les actifs sont stockés différemment : 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 spécifique, l'utilisateur doit s'appuyer sur le propre système d'adresse interne du système de confidentialité.
Comme nous l'avons vu, les trois changements ont affaibli le modèle mental « un utilisateur ~= une adresse » de différentes manières, et certains de ces effets se sont répercutés sur la complexité de la mise en œuvre des changements. Deux complications particulières sont :
Si vous voulez payer quelqu'un, comment obtenez-vous les informations pour le payer ?
Si un utilisateur stocke de nombreux actifs à différents endroits sur différentes chaînes, comment effectue-t-il le remplacement des clés et la récupération sociale ?
Trois transitions sont liées aux paiements en chaîne (et à l'identité)
J'ai des pièces sur Scroll et je veux payer pour du café (si "je" se réfère littéralement à moi en tant qu'auteur de cet article, alors "café" est bien sûr un métonyme pour "thé vert"). Vous me vendez du café, mais vous ne recevrez que des pièces sur Taiko. que fais-je?
En gros il y a deux solutions :
Le portefeuille destinataire (qui peut être un commerçant ou simplement un particulier) s'efforce de prendre en charge chaque niveau 2, avec certaines fonctionnalités automatiques pour intégrer les fonds de manière asynchrone.
Le destinataire fournit son L2 et son adresse, et le portefeuille de l'expéditeur achemine automatiquement les fonds vers le L2 cible via une sorte de système de pont inter-L2.
Bien sûr, ces solutions peuvent être combinées : le destinataire fournit la liste L2 qu'il est prêt à accepter, et le portefeuille de l'expéditeur calcule le paiement, qui peut impliquer un envoi direct (s'il a de la chance) ou via un chemin ponté à travers la L2.
Mais ce n'est qu'un exemple du défi clé introduit par les trois changements : quelque chose d'aussi simple que de payer quelqu'un commence à exiger plus d'informations qu'une simple adresse de 20 octets.
Le passage aux portefeuilles de contrats intelligents n'a heureusement pas beaucoup alourdi le système d'adresses, mais il reste encore quelques problèmes techniques qui doivent être résolus dans d'autres parties de la pile d'applications. Les portefeuilles doivent être mis à jour pour s'assurer qu'ils n'envoient pas seulement 21000 gaz dans les transactions, mais plus important encore pour garantir que le côté réception du paiement du portefeuille suit non seulement les transferts ETH depuis les EOA, mais également les ETH envoyés par code de contrat intelligent. Les applications qui reposent sur l'hypothèse d'une propriété immuable des adresses (par exemple, les NFT qui interdisent les contrats intelligents pour faire respecter les redevances) devront trouver d'autres moyens d'atteindre leurs objectifs. Les portefeuilles de contrats intelligents faciliteront également certaines choses - en particulier, si quelqu'un n'accepte que des jetons ERC20 non ETH, il pourra utiliser un payeur ERC-4337 pour payer l'essence avec ce jeton.
D'autre part, la vie privée présente à nouveau des défis majeurs que nous n'avons pas encore vraiment résolus. Le Tornado Cash d'origine n'a pas introduit ces problèmes car il ne prenait pas en charge les transferts internes : les utilisateurs ne pouvaient que déposer dans le système et retirer. Une fois que vous pouvez effectuer des transferts internes, les utilisateurs doivent utiliser le schéma d'adresse interne du système de confidentialité. En pratique, le "message de paiement" d'un utilisateur doit contenir (i) une sorte de "clé publique de dépense", une promesse d'un secret que le destinataire peut utiliser pour dépenser, et (ii) l'expéditeur envoie un message crypté que seul le le destinataire peut déchiffrer un moyen d'aider les destinataires à découvrir les paiements.
Le protocole d'adresse de confidentialité repose sur le concept de méta-adresse, qui fonctionne de la manière suivante : une partie de la méta-adresse est une version masquée de la clé de dépenses de l'expéditeur, et l'autre partie est la clé de chiffrement de l'expéditeur (bien que des implémentations minimales peut définir ce Les deux clés sont les mêmes).
La leçon clé ici est que dans un écosystème axé sur la confidentialité, les utilisateurs auront des clés publiques de dépenses et des clés publiques de chiffrement, et les « informations de paiement » des utilisateurs devront contenir les deux clés. En plus de payer, il existe d'autres bonnes raisons de se développer dans cette direction. Par exemple, si nous voulions des e-mails cryptés sur Ethereum, les utilisateurs devraient fournir publiquement une forme de clé de cryptage. Dans un "monde EOA", nous pourrions réutiliser les clés de compte pour y parvenir, mais dans un monde de portefeuilles de contrats intelligents sécurisés, nous devrions probablement avoir des fonctionnalités plus explicites pour y parvenir. Cela contribuera également à rendre les identités basées sur Ethereum plus compatibles avec les écosystèmes de confidentialité décentralisés non-Ethereum, l'exemple le plus frappant étant les clés PGP.
Trois transformations et récupération de clé
Dans un monde où un utilisateur peut avoir plusieurs adresses, la méthode par défaut pour mettre en œuvre les changements clés et la récupération sociale consiste à demander à l'utilisateur d'effectuer des procédures de récupération sur chaque adresse individuellement. Cela peut être fait en un clic : les portefeuilles peuvent contenir un logiciel pour effectuer des procédures de récupération sur toutes les adresses des utilisateurs simultanément. Cependant, même avec une telle simplification UX, il y a trois problèmes avec la récupération multi-adresses naïve :
Factures de gaz irréalistes : celle-ci parle d'elle-même.
Adresse contrefactuelle : une adresse dont le contrat intelligent n'a pas encore été publié (en fait, cela signifie un compte à partir duquel vous n'avez pas encore envoyé de fonds). En tant qu'utilisateur, vous disposez d'un nombre potentiellement infini d'adresses contrefactuelles : une ou plusieurs sur chaque L2, y compris les L2 qui n'existent pas encore, et un ensemble complètement différent d'adresses contrefactuelles infinies, dérivées du schéma d'adresse stéganographique.
Confidentialité : si un utilisateur a intentionnellement plusieurs adresses pour éviter de les lier ensemble, il ne veut certainement pas toutes les lier publiquement en les restaurant en même temps ou à peu près !
Résoudre ces problèmes est difficile. Heureusement, il existe une solution plutôt élégante qui fonctionne plutôt bien : une architecture qui sépare la logique de validation de la détention d'actifs.
Chaque utilisateur dispose d'un contrat de magasin de clés qui existe à un emplacement (il peut s'agir du réseau principal ou d'un L2 spécifique). Les utilisateurs ont alors des adresses sur différents L2, où la logique de vérification pour chaque adresse est un pointeur vers le contrat de magasin de clés. Les dépenses à partir de ces adresses nécessiteront une preuve dans le contrat de magasin de clés indiquant la clé publique de dépenses actuelle (ou plus réaliste, la plus récente).
La preuve peut être obtenue de plusieurs manières :
Accès L1 en lecture seule directement dans L2. L2 peut être modifié pour leur donner un moyen de lire directement l'état de L1. Si le contrat de magasin de clés est sur L1, cela signifie que les contrats de L2 ont un accès "gratuit" au magasin de clés.
Branche Merkel. Les branches de Merkle peuvent prouver des états L1 à L2, ou des états L2 à L1, ou vous pouvez combiner les deux pour prouver des parties d'un état L2 à un autre L2. La principale faiblesse des preuves de Merkle est le coût élevé du gaz dû à la longueur de la preuve : une preuve peut nécessiter 5 ko, même si cela sera réduit à moins de 1 ko à l'avenir grâce aux arbres de Verkle.
ZK-SNARK. Vous pouvez réduire les coûts de données en utilisant les ZK-SNARK des succursales Merkle au lieu des succursales elles-mêmes. Des techniques d'agrégation hors chaîne (par exemple, basées sur EIP-4337) peuvent être construites de sorte qu'un seul ZK-SNARK vérifie toutes les preuves d'état inter-chaînes en un seul bloc.
Engagement KZG. L2, ou les schémas construits dessus, peuvent introduire un système d'adressage séquentiel qui permet aux preuves d'état à l'intérieur de ce système de n'avoir que 48 octets de long. Comme les ZK-SNARK, un schéma multi-preuves peut combiner toutes ces preuves en une seule preuve pour chaque bloc.
Si nous voulons éviter de faire une preuve pour chaque transaction, nous pouvons implémenter une solution plus légère, il suffit de faire une preuve cross-L2 lors de la récupération. Les dépenses à partir d'un compte dépendront d'une clé de dépenses dont la clé publique correspondante est stockée dans le compte, mais la récupération nécessitera une transaction copiant la clé publique de dépenses actuelle dans le magasin de clés. Les fonds dans une adresse contrefactuelle sont en sécurité même si votre ancienne clé ne l'est pas : "activer" une adresse contrefactuelle, la transformer en un contrat de travail nécessitera de faire une preuve croisée L2 qui reproduit la clé publique de dépenses actuelle. Ce fil sur les forums Safe décrit comment une architecture similaire pourrait fonctionner.
Pour ajouter de la confidentialité à un tel schéma, il suffit de chiffrer le pointeur, puis de faire toutes les preuves dans ZK-SNARK :
Avec plus de travail (par exemple, en utilisant ce travail comme point de départ), nous pouvons également éliminer la majeure partie de la complexité des ZK-SNARK et créer un schéma basé sur KZG plus simple.
Ces scénarios peuvent devenir compliqués. Cependant, il existe de nombreuses synergies potentielles entre ces programmes. Par exemple, le concept de « contrat de magasin de clés » pourrait également être une solution au défi de « l'adresse » mentionné dans la section précédente : si nous voulons que les utilisateurs aient des adresses persistantes qui ne changent pas lorsque les utilisateurs mettent à jour leurs clés, nous possible de mettre des méta-adresses secrètes, des clés de chiffrement et d'autres informations dans un contrat de magasin de clés, et d'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, juin 2023, les choses ne vont pas trop mal : les frais de transaction, bien qu'élevés, sont comparables aux frais de domaine ENS. L'inscription sur zuzalu.eth m'a coûté environ 27 $, dont 11 $ de frais de transaction. Mais si nous avons un autre marché haussier, les frais monteront en flèche. Même sans l'augmentation du prix des ETH, le retour des frais de gaz à 200 gwei augmenterait les frais de transaction pour l'enregistrement de domaine à 104 $. Donc, si nous voulons que les gens utilisent réellement ENS, en particulier pour des cas d'utilisation tels que les médias sociaux décentralisés où les utilisateurs demandent un enregistrement presque gratuit (les frais de domaine ENS ne sont pas un problème puisque ces plates-formes fournissent des sous-domaines à leurs utilisateurs), nous avons besoin d'ENS Runs on L2 .
Heureusement, l'équipe de l'ENS est déjà en mouvement, et l'ENS en L2 est bel et bien en marche ! ERC-3668 (également connu sous le nom de "norme CCIP"), avec ENSIP-10, fournit une méthode pour valider automatiquement les sous-domaines ENS sur n'importe quelle L2. La norme CCIP impose la mise en place d'un smart contract qui décrit une méthode de vérification des preuves des données L2, et les noms de domaine (ecc.eth pour Optinames par exemple) peuvent être placés sous le contrôle d'un tel contrat. Une fois que le contrat CCIP contrôle ecc.eth sur L1, l'accès à un sous-domaine.ecc.eth impliquera automatiquement de trouver et de vérifier l'état L2 de la preuve (par exemple, la branche Merkle) qui stocke réellement ce sous-domaine particulier.
En fait, l'obtention de preuves implique l'accès à une série d'URL stockées dans le contrat, ce qui ressemble certes à une centralisation, même si je dirais que ce n'est pas le cas : c'est un modèle de confiance 1 sur N (les preuves invalides seraient bloquées par CCIP. La vérification la logique dans la fonction de rappel du contrat capture que, tant qu'il y a une URL qui renvoie une preuve valide, il n'y a pas de problème). Cette liste d'URL peut contenir des dizaines d'URL.
Le travail de la CCIP de l'ENS est une success story et doit être vu comme le signe que la réforme radicale dont nous avons besoin est possible. Mais davantage de réformes au niveau des applications sont nécessaires. Voici quelques exemples :
De nombreux dapps comptent sur les utilisateurs pour fournir des signatures hors chaîne. Pour les comptes externes (EOA), c'est facile. ERC-1271 fournit un moyen standardisé pour les portefeuilles de contrats intelligents de le faire. Cependant, de nombreux dapps ne prennent toujours pas en charge ERC-1271 ; ils doivent le prendre en charge.
Les Dapps qui utilisent "Est-ce que c'est EOA ?" pour différencier les utilisateurs et les contrats (par exemple, pour empêcher les transferts ou faire respecter les redevances) vont casser. En général, je déconseillerais d'essayer de trouver une solution purement technique ; la question de savoir si un transfert particulier de contrôle cryptographique est un transfert d'intérêt bénéficiaire est une question difficile qui ne peut être résolue sans recourir à une communauté hors chaîne - mécanismes pilotés Prochaine solution. Très probablement, les applications devront s'appuyer moins sur le blocage des transferts et davantage sur des techniques telles que la taxe Harberger.
La façon dont les portefeuilles interagissent avec les dépenses et les clés de chiffrement devra être améliorée. Actuellement, les portefeuilles utilisent généralement des signatures déterministes pour générer des clés spécifiques à l'application : un nonce standard (par exemple, un hachage du nom de l'application) est signé avec la clé privée de l'EOA, générant un nonce qui ne peut pas être généré sans la clé privée. La valeur déterministe de , il est donc techniquement sûr. Cependant, ces techniques sont "opaques" pour le portefeuille, empêchant les portefeuilles 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 chiffrement et les fonctions associées doivent être gérés plus explicitement par les portefeuilles.
Les clients légers (par exemple Helios) devront vérifier L2, pas seulement L1. Aujourd'hui, les clients légers se concentrent sur la vérification de la validité de l'en-tête L1 (à l'aide du protocole de synchronisation du client léger) et sur la validation de l'état L1 et des fourches Merkle des transactions provenant de l'en-tête L1. Demain, ils doivent également vérifier la preuve de l'état L2 provenant de la racine d'état stockée dans L1 (cette version plus avancée regarde en fait la pré-confirmation de L2).
Les portefeuilles doivent protéger les actifs et les données
Désormais, l'activité du portefeuille consiste à protéger les actifs. Tout est en chaîne, et la seule chose que le portefeuille doit protéger, ce sont les clés privées qui protègent actuellement ces actifs. Si vous changez de clé, vous pouvez publier en toute sécurité votre clé privée précédente sur Internet le lendemain. Cependant, dans un monde de preuves à connaissance nulle, ce n'est plus le cas : les portefeuilles ne protègent pas seulement les identifiants d'authentification, ils protègent vos données.
Nous avons vu les premiers signes d'un tel monde avec Zupass, le système d'identité basé sur ZK-SNARK utilisé à Zuzalu. Les utilisateurs ont une clé privée, qu'ils utilisent pour authentifier le système, qui peut être utilisée pour faire des preuves de base comme "prouver que je suis un résident de Zuzalu, mais ne pas révéler lequel". Cependant, le système Zupass a également commencé à avoir d'autres applications construites dessus, notamment Stamps (la version Zupass des POAP).
Un de mes nombreux tampons Zupass prouvant que je suis un fier membre de Team Cat.
La principale caractéristique que les tampons offrent sur les POAP est que les tampons sont privés : vous détenez les données localement et vous ne leur prouvez le tampon (ou un calcul dessus) que si vous voulez qu'ils aient ces informations sur vous. Mais cela augmente le risque : si vous perdez ces informations, vous perdez votre tampon.
Bien entendu, le problème de la détention des données se ramène au problème de la détention d'une clé cryptographique : un tiers (voire la chaîne) peut détenir une copie chiffrée des données. Cela présente l'avantage pratique que l'action que vous effectuez ne modifie pas la clé de chiffrement, de sorte qu'aucune interaction avec le système qui protège votre clé de chiffrement n'est requise. Mais même dans ce cas, si vous perdez votre clé de cryptage, vous perdez tout. Inversement, si quelqu'un voit votre clé de cryptage, il peut voir tout ce qui est crypté avec cette clé.
La solution de facto de Zupass est d'encourager les gens à stocker leurs clés sur plusieurs appareils (par exemple, ordinateur portable et téléphone), car les chances qu'ils les perdent tous en même temps sont minces. Nous pouvons aller plus loin et utiliser un partage secret pour stocker la clé, en divisant la clé entre plusieurs tuteurs.
Cette récupération sociale via MPC n'est pas une solution adéquate 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 est un risque élevé inacceptable. Cependant, une violation de la vie privée présente généralement moins de risques qu'une perte totale d'actifs, et si quelqu'un a besoin d'un cas d'utilisation hautement préservant la vie privée, il peut accepter un risque de perte plus élevé en ne sauvegardant pas les clés associées qui nécessitent la confidentialité. actions de préservation.
Pour éviter de submerger les utilisateurs avec un système complexe de plusieurs chemins de récupération, les portefeuilles qui prennent en charge la récupération sociale peuvent avoir besoin de gérer à la fois la récupération des actifs et la récupération des clés de chiffrement.
Retour à la question d'identité
Un thème commun de ces changements est que le concept d'une "adresse" que vous utilisez en chaîne comme identifiant cryptographique qui représente "vous" doit changer radicalement. Les "instructions sur la façon d'interagir avec moi" ne sont plus simplement une adresse ETH ; elles doivent contenir une combinaison de plusieurs adresses sur plusieurs L2, des méta-adresses secrètes, des clés de chiffrement et d'autres données sous une forme ou une autre.
Une façon d'y parvenir est de faire de l'ENS votre identité : votre dossier ENS peut contenir toutes ces informations, et si vous envoyez à quelqu'un bob.eth (ou bob.ecc.eth, ou...), il pourra se renseigner sur toutes les choses qui paient et interagissent avec vous, y compris de manière plus complexe, transversale et préservant la vie privée.
Cependant, cette approche centrée sur l'ENS présente deux faiblesses :
Il lie trop de choses à votre nom. Votre nom n'est pas vous, votre nom n'est qu'un de vos nombreux attributs. Vous devriez pouvoir changer votre nom sans déplacer l'intégralité de votre profil d'identité ni mettre à jour un tas d'enregistrements dans de nombreuses applications.
Vous ne pouvez pas avoir de noms contrefactuels non fiables. Une caractéristique UX clé de toute blockchain est la possibilité d'envoyer des pièces à des personnes qui n'ont pas encore interagi avec la chaîne. Sans une telle fonctionnalité, il y a un problème de poule et d'œuf : interagir avec la chaîne nécessite de payer des frais de transaction, et payer des frais nécessite... de posséder déjà des pièces. Les adresses ETH, y compris les adresses de contrat intelligent avec CREATE2, ont cette fonctionnalité. Le nom ENS ne le fait pas, car si deux Bobs décident tous les deux qu'ils sont bob.ecc.eth hors chaîne, il n'y a aucun moyen de choisir lequel reçoit le nom.
Une solution possible consiste à mettre plus d'éléments dans le contrat de magasin de clés mentionné dans l'architecture plus haut dans cet article. Le contrat de magasin de clés peut contenir diverses informations sur vous et sur la façon dont vous interagissez avec lui (via CCIP, dont certaines peuvent être hors chaîne), et les utilisateurs peuvent utiliser leur contrat de magasin de clés comme identifiant principal. Mais les actifs réels qu'ils reçoivent seront stockés dans une variété d'endroits différents. Les contrats de magasin de clés ne sont pas liés aux noms, ils sont compatibles contrefactuels : vous pouvez générer une adresse qui ne peut être initialisée que par un contrat de magasin de clés avec des paramètres initiaux fixes.
Une autre catégorie de solutions concerne l'abandon du concept d'adresses orientées utilisateurs, qui s'apparente dans l'esprit au protocole de paiement Bitcoin. Une idée consiste à 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 Accepter les paiements comme il le souhaite.
Que ce soit l'expéditeur ou le destinataire qui agisse en premier, s'appuyer davantage sur les portefeuilles pour générer directement des informations de paiement à jour en temps réel réduit les frictions. Cela dit, les identifiants persistants sont pratiques (en particulier avec ENS) et, dans la pratique, l'hypothèse d'une communication directe entre l'expéditeur et le destinataire est un problème très délicat, nous pourrions donc envisager une combinaison de différentes technologies.
Dans toutes ces conceptions, il est essentiel de garder les choses à la fois décentralisées et compréhensibles pour les utilisateurs. Nous devons nous assurer que les utilisateurs peuvent facilement accéder à la vue la plus récente de leurs actifs actuels, ainsi qu'aux informations publiées qui leur sont destinées. Ces vues doivent s'appuyer sur des outils ouverts plutôt que sur des solutions propriétaires. Il faudra travailler dur pour empêcher une infrastructure de paiement plus complexe de devenir une "tour d'abstraction" opaque permettant aux développeurs de comprendre ce qui se passe et de l'adapter au nouvel environnement. Malgré les défis, il est primordial d'atteindre l'évolutivité, la sécurité du portefeuille et la confidentialité d'Ethereum pour les utilisateurs ordinaires. Il ne s'agit pas seulement de faisabilité technique, il s'agit d'accessibilité réelle pour l'utilisateur moyen. Nous devons relever ce défi.
Un merci spécial à Dan Finlay, Karl Floersch, David Hoffman et les équipes Scroll et SoulWallet pour leurs commentaires, critiques et suggestions.
Voir l'original
Le contenu est fourni à titre de référence uniquement, il ne s'agit pas d'une sollicitation ou d'une offre. Aucun conseil en investissement, fiscalité ou juridique n'est fourni. Consultez l'Avertissement pour plus de détails sur les risques.
Vitalik : Transformation nécessaire d'Ethereum - Mise à l'échelle L2, sécurité du portefeuille et confidentialité
Lorsqu'Ethereum passe d'une jeune technologie expérimentale à une pile technologique mature qui peut véritablement apporter une expérience ouverte, globale et sans autorisation aux utilisateurs ordinaires, la pile doit passer par trois transformations technologiques majeures, à peu près simultanément :
Changement de mise à l'échelle L2 - tous migrés vers des cumuls
Wallet Security Shift - Tous migrent vers des portefeuilles de contrats intelligents
Privacy Shift - Assurez-vous que les transferts d'argent préservent la confidentialité et assurez-vous que tous les autres outils en cours de développement (récupération sociale, identité, réputation) préservent la confidentialité
C'est le triangle de la transformation de l'écosystème. Vous ne pouvez en choisir que 3 sur 3.
Sans le premier, Ethereum échouerait car chaque transaction coûterait 3,75 $ (82,48 $ si nous avions une autre course haussière), et chaque produit du marché de masse finirait par oublier la chaîne, et prendrait une solution centralisée pour tout.
Sans le second, Ethereum échouerait car les utilisateurs seraient réticents à stocker leurs fonds (et actifs non financiers) et tous passeraient à des échanges centralisés.
Sans un tiers, Ethereum échouerait, car toutes les transactions (et les POAP, etc.) seraient publiques pour que tout le monde puisse les voir, ce qui serait un sacrifice exorbitant de la vie privée pour de nombreux utilisateurs, et tout le monde se déplacerait pour avoir au moins quelques données cachées centralisées solution.
Pour les raisons évoquées ci-dessus, ces trois transitions sont critiques. Mais ils sont également difficiles en raison de l'intense coordination nécessaire pour les résoudre. Non seulement la fonctionnalité du protocole doit être améliorée, mais il existe des cas où des changements assez fondamentaux doivent être apportés à la façon dont nous interagissons avec Ethereum, nécessitant des modifications profondes des applications et des portefeuilles.
Ces trois changements vont révolutionner la relation entre les utilisateurs et les adresses
Dans un monde étendu à la L2, les utilisateurs existeront dans de nombreuses L2. Êtes-vous membre d'ExampleDAO, qui est sur Optimism ? Alors vous avez un compte sur Optimism ! Détenez-vous CDP dans le système stablecoin de ZkSync ? Alors vous avez un compte sur ZkSync ! Avez-vous essayé des applications qui se trouvent sur Kakarot ? Alors vous avez un compte sur Kakarot ! L'époque où les utilisateurs n'avaient qu'une seule adresse est révolue.
J'ai ETH à quatre endroits, selon ma vue Brave Wallet. Oui, Arbitrum et Arbitrum Nova sont différents. Ne vous inquiétez pas, cela se compliquera avec le temps !
Les portefeuilles de contrats intelligents ajoutent plus de complexité, ce qui rend plus difficile d'avoir la même adresse sur L1 et divers L2. Aujourd'hui, la plupart des utilisateurs utilisent des comptes externes dont les adresses sont en fait le hachage de la clé publique utilisée pour vérifier la signature - donc rien ne change entre L1 et L2. Cependant, avec les portefeuilles de contrats intelligents, il devient plus difficile de conserver une adresse. Alors que beaucoup de travail a été fait pour essayer de faire des adresses un hachage de code équivalent à travers le réseau, notamment les usines de singleton CREATE2 et ERC-2470, il a été très difficile de le faire parfaitement. Certains L2 (tels que les "ZK-EVM de type 4") ne sont pas entièrement équivalents aux EVM, utilisant généralement Solidity ou un assemblage intermédiaire à la place, empêchant l'équivalence de hachage. Même si vous pouviez avoir une équivalence de hachage, la possibilité que les portefeuilles changent de propriétaire par le biais de changements de clé a d'autres conséquences non intuitives.
La confidentialité nécessite plus d'adresses par utilisateur et peut même modifier les types d'adresses que nous traitons. Si la proposition d'adresse privée est largement utilisée, au lieu de quelques adresses par utilisateur ou d'une adresse par L2, il peut y avoir une adresse par transaction. D'autres systèmes de confidentialité, même ceux existants comme Tornado Cash, modifient la façon dont les actifs sont stockés différemment : 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 spécifique, l'utilisateur doit s'appuyer sur le propre système d'adresse interne du système de confidentialité.
Comme nous l'avons vu, les trois changements ont affaibli le modèle mental « un utilisateur ~= une adresse » de différentes manières, et certains de ces effets se sont répercutés sur la complexité de la mise en œuvre des changements. Deux complications particulières sont :
Si vous voulez payer quelqu'un, comment obtenez-vous les informations pour le payer ?
Si un utilisateur stocke de nombreux actifs à différents endroits sur différentes chaînes, comment effectue-t-il le remplacement des clés et la récupération sociale ?
Trois transitions sont liées aux paiements en chaîne (et à l'identité)
J'ai des pièces sur Scroll et je veux payer pour du café (si "je" se réfère littéralement à moi en tant qu'auteur de cet article, alors "café" est bien sûr un métonyme pour "thé vert"). Vous me vendez du café, mais vous ne recevrez que des pièces sur Taiko. que fais-je?
En gros il y a deux solutions :
Le portefeuille destinataire (qui peut être un commerçant ou simplement un particulier) s'efforce de prendre en charge chaque niveau 2, avec certaines fonctionnalités automatiques pour intégrer les fonds de manière asynchrone.
Le destinataire fournit son L2 et son adresse, et le portefeuille de l'expéditeur achemine automatiquement les fonds vers le L2 cible via une sorte de système de pont inter-L2.
Bien sûr, ces solutions peuvent être combinées : le destinataire fournit la liste L2 qu'il est prêt à accepter, et le portefeuille de l'expéditeur calcule le paiement, qui peut impliquer un envoi direct (s'il a de la chance) ou via un chemin ponté à travers la L2.
Mais ce n'est qu'un exemple du défi clé introduit par les trois changements : quelque chose d'aussi simple que de payer quelqu'un commence à exiger plus d'informations qu'une simple adresse de 20 octets.
Le passage aux portefeuilles de contrats intelligents n'a heureusement pas beaucoup alourdi le système d'adresses, mais il reste encore quelques problèmes techniques qui doivent être résolus dans d'autres parties de la pile d'applications. Les portefeuilles doivent être mis à jour pour s'assurer qu'ils n'envoient pas seulement 21000 gaz dans les transactions, mais plus important encore pour garantir que le côté réception du paiement du portefeuille suit non seulement les transferts ETH depuis les EOA, mais également les ETH envoyés par code de contrat intelligent. Les applications qui reposent sur l'hypothèse d'une propriété immuable des adresses (par exemple, les NFT qui interdisent les contrats intelligents pour faire respecter les redevances) devront trouver d'autres moyens d'atteindre leurs objectifs. Les portefeuilles de contrats intelligents faciliteront également certaines choses - en particulier, si quelqu'un n'accepte que des jetons ERC20 non ETH, il pourra utiliser un payeur ERC-4337 pour payer l'essence avec ce jeton.
D'autre part, la vie privée présente à nouveau des défis majeurs que nous n'avons pas encore vraiment résolus. Le Tornado Cash d'origine n'a pas introduit ces problèmes car il ne prenait pas en charge les transferts internes : les utilisateurs ne pouvaient que déposer dans le système et retirer. Une fois que vous pouvez effectuer des transferts internes, les utilisateurs doivent utiliser le schéma d'adresse interne du système de confidentialité. En pratique, le "message de paiement" d'un utilisateur doit contenir (i) une sorte de "clé publique de dépense", une promesse d'un secret que le destinataire peut utiliser pour dépenser, et (ii) l'expéditeur envoie un message crypté que seul le le destinataire peut déchiffrer un moyen d'aider les destinataires à découvrir les paiements.
Le protocole d'adresse de confidentialité repose sur le concept de méta-adresse, qui fonctionne de la manière suivante : une partie de la méta-adresse est une version masquée de la clé de dépenses de l'expéditeur, et l'autre partie est la clé de chiffrement de l'expéditeur (bien que des implémentations minimales peut définir ce Les deux clés sont les mêmes).
La leçon clé ici est que dans un écosystème axé sur la confidentialité, les utilisateurs auront des clés publiques de dépenses et des clés publiques de chiffrement, et les « informations de paiement » des utilisateurs devront contenir les deux clés. En plus de payer, il existe d'autres bonnes raisons de se développer dans cette direction. Par exemple, si nous voulions des e-mails cryptés sur Ethereum, les utilisateurs devraient fournir publiquement une forme de clé de cryptage. Dans un "monde EOA", nous pourrions réutiliser les clés de compte pour y parvenir, mais dans un monde de portefeuilles de contrats intelligents sécurisés, nous devrions probablement avoir des fonctionnalités plus explicites pour y parvenir. Cela contribuera également à rendre les identités basées sur Ethereum plus compatibles avec les écosystèmes de confidentialité décentralisés non-Ethereum, l'exemple le plus frappant étant les clés PGP.
Trois transformations et récupération de clé
Dans un monde où un utilisateur peut avoir plusieurs adresses, la méthode par défaut pour mettre en œuvre les changements clés et la récupération sociale consiste à demander à l'utilisateur d'effectuer des procédures de récupération sur chaque adresse individuellement. Cela peut être fait en un clic : les portefeuilles peuvent contenir un logiciel pour effectuer des procédures de récupération sur toutes les adresses des utilisateurs simultanément. Cependant, même avec une telle simplification UX, il y a trois problèmes avec la récupération multi-adresses naïve :
Factures de gaz irréalistes : celle-ci parle d'elle-même.
Adresse contrefactuelle : une adresse dont le contrat intelligent n'a pas encore été publié (en fait, cela signifie un compte à partir duquel vous n'avez pas encore envoyé de fonds). En tant qu'utilisateur, vous disposez d'un nombre potentiellement infini d'adresses contrefactuelles : une ou plusieurs sur chaque L2, y compris les L2 qui n'existent pas encore, et un ensemble complètement différent d'adresses contrefactuelles infinies, dérivées du schéma d'adresse stéganographique.
Confidentialité : si un utilisateur a intentionnellement plusieurs adresses pour éviter de les lier ensemble, il ne veut certainement pas toutes les lier publiquement en les restaurant en même temps ou à peu près !
Résoudre ces problèmes est difficile. Heureusement, il existe une solution plutôt élégante qui fonctionne plutôt bien : une architecture qui sépare la logique de validation de la détention d'actifs.
Chaque utilisateur dispose d'un contrat de magasin de clés qui existe à un emplacement (il peut s'agir du réseau principal ou d'un L2 spécifique). Les utilisateurs ont alors des adresses sur différents L2, où la logique de vérification pour chaque adresse est un pointeur vers le contrat de magasin de clés. Les dépenses à partir de ces adresses nécessiteront une preuve dans le contrat de magasin de clés indiquant la clé publique de dépenses actuelle (ou plus réaliste, la plus récente).
La preuve peut être obtenue de plusieurs manières :
Accès L1 en lecture seule directement dans L2. L2 peut être modifié pour leur donner un moyen de lire directement l'état de L1. Si le contrat de magasin de clés est sur L1, cela signifie que les contrats de L2 ont un accès "gratuit" au magasin de clés.
Branche Merkel. Les branches de Merkle peuvent prouver des états L1 à L2, ou des états L2 à L1, ou vous pouvez combiner les deux pour prouver des parties d'un état L2 à un autre L2. La principale faiblesse des preuves de Merkle est le coût élevé du gaz dû à la longueur de la preuve : une preuve peut nécessiter 5 ko, même si cela sera réduit à moins de 1 ko à l'avenir grâce aux arbres de Verkle.
ZK-SNARK. Vous pouvez réduire les coûts de données en utilisant les ZK-SNARK des succursales Merkle au lieu des succursales elles-mêmes. Des techniques d'agrégation hors chaîne (par exemple, basées sur EIP-4337) peuvent être construites de sorte qu'un seul ZK-SNARK vérifie toutes les preuves d'état inter-chaînes en un seul bloc.
Engagement KZG. L2, ou les schémas construits dessus, peuvent introduire un système d'adressage séquentiel qui permet aux preuves d'état à l'intérieur de ce système de n'avoir que 48 octets de long. Comme les ZK-SNARK, un schéma multi-preuves peut combiner toutes ces preuves en une seule preuve pour chaque bloc.
Si nous voulons éviter de faire une preuve pour chaque transaction, nous pouvons implémenter une solution plus légère, il suffit de faire une preuve cross-L2 lors de la récupération. Les dépenses à partir d'un compte dépendront d'une clé de dépenses dont la clé publique correspondante est stockée dans le compte, mais la récupération nécessitera une transaction copiant la clé publique de dépenses actuelle dans le magasin de clés. Les fonds dans une adresse contrefactuelle sont en sécurité même si votre ancienne clé ne l'est pas : "activer" une adresse contrefactuelle, la transformer en un contrat de travail nécessitera de faire une preuve croisée L2 qui reproduit la clé publique de dépenses actuelle. Ce fil sur les forums Safe décrit comment une architecture similaire pourrait fonctionner.
Pour ajouter de la confidentialité à un tel schéma, il suffit de chiffrer le pointeur, puis de faire toutes les preuves dans ZK-SNARK :
Avec plus de travail (par exemple, en utilisant ce travail comme point de départ), nous pouvons également éliminer la majeure partie de la complexité des ZK-SNARK et créer un schéma basé sur KZG plus simple.
Ces scénarios peuvent devenir compliqués. Cependant, il existe de nombreuses synergies potentielles entre ces programmes. Par exemple, le concept de « contrat de magasin de clés » pourrait également être une solution au défi de « l'adresse » mentionné dans la section précédente : si nous voulons que les utilisateurs aient des adresses persistantes qui ne changent pas lorsque les utilisateurs mettent à jour leurs clés, nous possible de mettre des méta-adresses secrètes, des clés de chiffrement et d'autres informations dans un contrat de magasin de clés, et d'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, juin 2023, les choses ne vont pas trop mal : les frais de transaction, bien qu'élevés, sont comparables aux frais de domaine ENS. L'inscription sur zuzalu.eth m'a coûté environ 27 $, dont 11 $ de frais de transaction. Mais si nous avons un autre marché haussier, les frais monteront en flèche. Même sans l'augmentation du prix des ETH, le retour des frais de gaz à 200 gwei augmenterait les frais de transaction pour l'enregistrement de domaine à 104 $. Donc, si nous voulons que les gens utilisent réellement ENS, en particulier pour des cas d'utilisation tels que les médias sociaux décentralisés où les utilisateurs demandent un enregistrement presque gratuit (les frais de domaine ENS ne sont pas un problème puisque ces plates-formes fournissent des sous-domaines à leurs utilisateurs), nous avons besoin d'ENS Runs on L2 .
Heureusement, l'équipe de l'ENS est déjà en mouvement, et l'ENS en L2 est bel et bien en marche ! ERC-3668 (également connu sous le nom de "norme CCIP"), avec ENSIP-10, fournit une méthode pour valider automatiquement les sous-domaines ENS sur n'importe quelle L2. La norme CCIP impose la mise en place d'un smart contract qui décrit une méthode de vérification des preuves des données L2, et les noms de domaine (ecc.eth pour Optinames par exemple) peuvent être placés sous le contrôle d'un tel contrat. Une fois que le contrat CCIP contrôle ecc.eth sur L1, l'accès à un sous-domaine.ecc.eth impliquera automatiquement de trouver et de vérifier l'état L2 de la preuve (par exemple, la branche Merkle) qui stocke réellement ce sous-domaine particulier.
En fait, l'obtention de preuves implique l'accès à une série d'URL stockées dans le contrat, ce qui ressemble certes à une centralisation, même si je dirais que ce n'est pas le cas : c'est un modèle de confiance 1 sur N (les preuves invalides seraient bloquées par CCIP. La vérification la logique dans la fonction de rappel du contrat capture que, tant qu'il y a une URL qui renvoie une preuve valide, il n'y a pas de problème). Cette liste d'URL peut contenir des dizaines d'URL.
Le travail de la CCIP de l'ENS est une success story et doit être vu comme le signe que la réforme radicale dont nous avons besoin est possible. Mais davantage de réformes au niveau des applications sont nécessaires. Voici quelques exemples :
De nombreux dapps comptent sur les utilisateurs pour fournir des signatures hors chaîne. Pour les comptes externes (EOA), c'est facile. ERC-1271 fournit un moyen standardisé pour les portefeuilles de contrats intelligents de le faire. Cependant, de nombreux dapps ne prennent toujours pas en charge ERC-1271 ; ils doivent le prendre en charge.
Les Dapps qui utilisent "Est-ce que c'est EOA ?" pour différencier les utilisateurs et les contrats (par exemple, pour empêcher les transferts ou faire respecter les redevances) vont casser. En général, je déconseillerais d'essayer de trouver une solution purement technique ; la question de savoir si un transfert particulier de contrôle cryptographique est un transfert d'intérêt bénéficiaire est une question difficile qui ne peut être résolue sans recourir à une communauté hors chaîne - mécanismes pilotés Prochaine solution. Très probablement, les applications devront s'appuyer moins sur le blocage des transferts et davantage sur des techniques telles que la taxe Harberger.
La façon dont les portefeuilles interagissent avec les dépenses et les clés de chiffrement devra être améliorée. Actuellement, les portefeuilles utilisent généralement des signatures déterministes pour générer des clés spécifiques à l'application : un nonce standard (par exemple, un hachage du nom de l'application) est signé avec la clé privée de l'EOA, générant un nonce qui ne peut pas être généré sans la clé privée. La valeur déterministe de , il est donc techniquement sûr. Cependant, ces techniques sont "opaques" pour le portefeuille, empêchant les portefeuilles 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 chiffrement et les fonctions associées doivent être gérés plus explicitement par les portefeuilles.
Les clients légers (par exemple Helios) devront vérifier L2, pas seulement L1. Aujourd'hui, les clients légers se concentrent sur la vérification de la validité de l'en-tête L1 (à l'aide du protocole de synchronisation du client léger) et sur la validation de l'état L1 et des fourches Merkle des transactions provenant de l'en-tête L1. Demain, ils doivent également vérifier la preuve de l'état L2 provenant de la racine d'état stockée dans L1 (cette version plus avancée regarde en fait la pré-confirmation de L2).
Les portefeuilles doivent protéger les actifs et les données
Désormais, l'activité du portefeuille consiste à protéger les actifs. Tout est en chaîne, et la seule chose que le portefeuille doit protéger, ce sont les clés privées qui protègent actuellement ces actifs. Si vous changez de clé, vous pouvez publier en toute sécurité votre clé privée précédente sur Internet le lendemain. Cependant, dans un monde de preuves à connaissance nulle, ce n'est plus le cas : les portefeuilles ne protègent pas seulement les identifiants d'authentification, ils protègent vos données.
Nous avons vu les premiers signes d'un tel monde avec Zupass, le système d'identité basé sur ZK-SNARK utilisé à Zuzalu. Les utilisateurs ont une clé privée, qu'ils utilisent pour authentifier le système, qui peut être utilisée pour faire des preuves de base comme "prouver que je suis un résident de Zuzalu, mais ne pas révéler lequel". Cependant, le système Zupass a également commencé à avoir d'autres applications construites dessus, notamment Stamps (la version Zupass des POAP).
Un de mes nombreux tampons Zupass prouvant que je suis un fier membre de Team Cat.
La principale caractéristique que les tampons offrent sur les POAP est que les tampons sont privés : vous détenez les données localement et vous ne leur prouvez le tampon (ou un calcul dessus) que si vous voulez qu'ils aient ces informations sur vous. Mais cela augmente le risque : si vous perdez ces informations, vous perdez votre tampon.
Bien entendu, le problème de la détention des données se ramène au problème de la détention d'une clé cryptographique : un tiers (voire la chaîne) peut détenir une copie chiffrée des données. Cela présente l'avantage pratique que l'action que vous effectuez ne modifie pas la clé de chiffrement, de sorte qu'aucune interaction avec le système qui protège votre clé de chiffrement n'est requise. Mais même dans ce cas, si vous perdez votre clé de cryptage, vous perdez tout. Inversement, si quelqu'un voit votre clé de cryptage, il peut voir tout ce qui est crypté avec cette clé.
La solution de facto de Zupass est d'encourager les gens à stocker leurs clés sur plusieurs appareils (par exemple, ordinateur portable et téléphone), car les chances qu'ils les perdent tous en même temps sont minces. Nous pouvons aller plus loin et utiliser un partage secret pour stocker la clé, en divisant la clé entre plusieurs tuteurs.
Cette récupération sociale via MPC n'est pas une solution adéquate 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 est un risque élevé inacceptable. Cependant, une violation de la vie privée présente généralement moins de risques qu'une perte totale d'actifs, et si quelqu'un a besoin d'un cas d'utilisation hautement préservant la vie privée, il peut accepter un risque de perte plus élevé en ne sauvegardant pas les clés associées qui nécessitent la confidentialité. actions de préservation.
Pour éviter de submerger les utilisateurs avec un système complexe de plusieurs chemins de récupération, les portefeuilles qui prennent en charge la récupération sociale peuvent avoir besoin de gérer à la fois la récupération des actifs et la récupération des clés de chiffrement.
Retour à la question d'identité
Un thème commun de ces changements est que le concept d'une "adresse" que vous utilisez en chaîne comme identifiant cryptographique qui représente "vous" doit changer radicalement. Les "instructions sur la façon d'interagir avec moi" ne sont plus simplement une adresse ETH ; elles doivent contenir une combinaison de plusieurs adresses sur plusieurs L2, des méta-adresses secrètes, des clés de chiffrement et d'autres données sous une forme ou une autre.
Une façon d'y parvenir est de faire de l'ENS votre identité : votre dossier ENS peut contenir toutes ces informations, et si vous envoyez à quelqu'un bob.eth (ou bob.ecc.eth, ou...), il pourra se renseigner sur toutes les choses qui paient et interagissent avec vous, y compris de manière plus complexe, transversale et préservant la vie privée.
Cependant, cette approche centrée sur l'ENS présente deux faiblesses :
Il lie trop de choses à votre nom. Votre nom n'est pas vous, votre nom n'est qu'un de vos nombreux attributs. Vous devriez pouvoir changer votre nom sans déplacer l'intégralité de votre profil d'identité ni mettre à jour un tas d'enregistrements dans de nombreuses applications.
Vous ne pouvez pas avoir de noms contrefactuels non fiables. Une caractéristique UX clé de toute blockchain est la possibilité d'envoyer des pièces à des personnes qui n'ont pas encore interagi avec la chaîne. Sans une telle fonctionnalité, il y a un problème de poule et d'œuf : interagir avec la chaîne nécessite de payer des frais de transaction, et payer des frais nécessite... de posséder déjà des pièces. Les adresses ETH, y compris les adresses de contrat intelligent avec CREATE2, ont cette fonctionnalité. Le nom ENS ne le fait pas, car si deux Bobs décident tous les deux qu'ils sont bob.ecc.eth hors chaîne, il n'y a aucun moyen de choisir lequel reçoit le nom.
Une solution possible consiste à mettre plus d'éléments dans le contrat de magasin de clés mentionné dans l'architecture plus haut dans cet article. Le contrat de magasin de clés peut contenir diverses informations sur vous et sur la façon dont vous interagissez avec lui (via CCIP, dont certaines peuvent être hors chaîne), et les utilisateurs peuvent utiliser leur contrat de magasin de clés comme identifiant principal. Mais les actifs réels qu'ils reçoivent seront stockés dans une variété d'endroits différents. Les contrats de magasin de clés ne sont pas liés aux noms, ils sont compatibles contrefactuels : vous pouvez générer une adresse qui ne peut être initialisée que par un contrat de magasin de clés avec des paramètres initiaux fixes.
Une autre catégorie de solutions concerne l'abandon du concept d'adresses orientées utilisateurs, qui s'apparente dans l'esprit au protocole de paiement Bitcoin. Une idée consiste à 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 Accepter les paiements comme il le souhaite.
Que ce soit l'expéditeur ou le destinataire qui agisse en premier, s'appuyer davantage sur les portefeuilles pour générer directement des informations de paiement à jour en temps réel réduit les frictions. Cela dit, les identifiants persistants sont pratiques (en particulier avec ENS) et, dans la pratique, l'hypothèse d'une communication directe entre l'expéditeur et le destinataire est un problème très délicat, nous pourrions donc envisager une combinaison de différentes technologies.
Dans toutes ces conceptions, il est essentiel de garder les choses à la fois décentralisées et compréhensibles pour les utilisateurs. Nous devons nous assurer que les utilisateurs peuvent facilement accéder à la vue la plus récente de leurs actifs actuels, ainsi qu'aux informations publiées qui leur sont destinées. Ces vues doivent s'appuyer sur des outils ouverts plutôt que sur des solutions propriétaires. Il faudra travailler dur pour empêcher une infrastructure de paiement plus complexe de devenir une "tour d'abstraction" opaque permettant aux développeurs de comprendre ce qui se passe et de l'adapter au nouvel environnement. Malgré les défis, il est primordial d'atteindre l'évolutivité, la sécurité du portefeuille et la confidentialité d'Ethereum pour les utilisateurs ordinaires. Il ne s'agit pas seulement de faisabilité technique, il s'agit d'accessibilité réelle pour l'utilisateur moyen. Nous devons relever ce défi.
Un merci spécial à Dan Finlay, Karl Floersch, David Hoffman et les équipes Scroll et SoulWallet pour leurs commentaires, critiques et suggestions.