Auteur original : Vitalik Buterin, fondateur d'Ethereum
Un merci spécial à Dan Finlay, Karl Floersch, David Hoffman et les équipes Scroll et SoulWallet pour leurs commentaires, critiques et suggestions.
Alors qu'Ethereum passe d'une technologie jeune et expérimentale à une pile technologique mature capable de fournir véritablement une expérience ouverte, globale et sans autorisation aux utilisateurs ordinaires, la pile devra traverser trois transitions technologiques majeures à peu près simultanément :
Transition d'expansion L2 - tout le monde passe aux rollups
Transition de sécurité du portefeuille - tout le monde passe aux portefeuilles de contrats intelligents
Transition de confidentialité - Assurez-vous que les transferts de fonds préservant la confidentialité sont disponibles et assurez-vous que tous les autres gadgets en développement (récupération sociale, identité, réputation) préservent la confidentialité
Triangle de transition écosystémique.
Sans le premier, Ethereum échouerait car chaque transaction coûte 3,75 $ (82,48 $ si nous avons une autre course haussière) et chaque produit destiné au marché de masse oubliera inévitablement la chaîne et adoptera une solution de contournement centralisée pour tout.
Sans le second, Ethereum aurait échoué car les utilisateurs étaient réticents à stocker leurs fonds (et actifs non financiers) et tout le monde s'est tourné vers des échanges centralisés.
Sans un tiers, Ethereum échouerait car toutes les transactions (et POAP, etc.) Une solution centralisée qui cache au maximum vos données.
Ces trois transitions sont essentielles pour les raisons décrites ci-dessus. Mais ils sont également difficiles, car les traiter correctement nécessite une coordination étroite. Ce n'est pas seulement la fonctionnalité du protocole qui doit être améliorée ; dans certains cas, la façon dont nous interagissons avec Ethereum doit changer fondamentalement, ce qui nécessite des changements profonds dans les applications et les portefeuilles.
Ces trois transitions vont fondamentalement remodeler la relation entre les utilisateurs et les adresses
Dans un monde étendu à la L2, les utilisateurs existeront sur de nombreuses L2. Êtes-vous membre d'ExampleDAO qui s'appuie sur l'Optimisme ? Alors vous avez un compte Optimisme ! Détenez-vous CDP dans le système stablecoin sur ZkSync ? Alors vous avez un compte sur ZkSync ! Avez-vous essayé certaines des applications sur kakarot? Alors vous avez un compte sur Kakarot ! L'époque où un utilisateur n'avait qu'une seule adresse est révolue.
*Selon mon point de vue Brave Wallet, j'ai ETH à quatre endroits. Oui, Arbitrum et Arbitrum Nova sont différents. Ne vous inquiétez pas, cela deviendra de plus en plus sale avec le temps ! *
Les portefeuilles de contrats intelligents ajoutent de la complexité et rendent plus difficile d'avoir la même adresse en L1 et dans différentes L2. Aujourd'hui, la plupart des utilisateurs utilisent des comptes externes dont les adresses sont en fait des hachages des clés publiques utilisées pour vérifier les signatures - donc rien ne change entre L1 et L2. Cependant, avec les portefeuilles de contrats intelligents, il devient plus difficile de réserver une adresse. Bien que beaucoup de travail ait été fait pour essayer de faire des adresses un hachage de code équivalent sur tous les réseaux, notamment les usines de singletons CREATE2 et ERC-2470, il a été difficile de faire en sorte que cela fonctionne parfaitement. Certains L2 (tels que "Type 4 ZK-EVM") ne sont pas exactement équivalents à EVM, généralement Solidity ou des assemblages intermédiaires sont utilisés à la place pour empêcher 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 avec lesquelles nous traitons. Si la proposition d'adresse furtive est largement utilisée, au lieu de seulement quelques adresses par utilisateur, ou une adresse par L2, les utilisateurs peuvent avoir une adresse par transaction. D'autres systèmes de confidentialité, même ceux existants tels que 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 devra s'appuyer sur le propre système d'adressage interne du système de confidentialité.
Comme nous l'avons vu, chacune de ces trois transitions affaiblit le modèle mental "un utilisateur ~= une adresse" de différentes manières, certains de ces effets se répercutant sur la complexité de la mise en œuvre de la transition. Deux points de complication particuliers sont :
Si vous vouliez payer quelqu'un, comment obtiendriez-vous des informations sur la façon de le payer ?
Si un utilisateur possède de nombreux actifs à travers des chaînes stockées à différents endroits, comment effectuent-ils les changements clés et la récupération sociale ?
Trois transitions et paiements en chaîne (et identités)
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 pouvez recevoir des pièces que sur Taiko. ce qu'il faut faire
En gros il y a deux solutions :
Le portefeuille destinataire (qui peut être un commerçant ou un particulier) travaille très dur pour prendre en charge chaque niveau 2, avec une certaine automatisation pour intégrer les fonds de manière asynchrone.
Le bénéficiaire fournit son L2 et son adresse, et le portefeuille de l'expéditeur achemine automatiquement les fonds vers le L2 de destination via un système de pont inter-L2.
Bien sûr, ces solutions peuvent être combinées : le destinataire fournit une liste de L2 qu'il est prêt à accepter, et le portefeuille de l'expéditeur calcule le paiement, qui peut impliquer un envoi direct ou un chemin ponté à travers la L2 s'il a de la chance.
Mais ce n'est qu'un exemple d'un défi clé que présentent ces trois transitions : des opérations simples comme payer quelqu'un commencent à nécessiter plus d'informations qu'une simple adresse de 20 octets.
Heureusement, la transition vers des portefeuilles de contrats intelligents ne surchargera pas le système d'adressage, mais il reste encore quelques problèmes techniques à résoudre dans d'autres parties de la pile d'applications. Les portefeuilles devront être mis à jour pour s'assurer qu'ils n'envoient pas seulement 21000 gaz avec la transaction, et il est plus important de s'assurer que l'extrémité de réception du paiement du portefeuille suit non seulement le transfert ETH depuis l'EOA, mais suit également l'ETH. envoyé par le 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 appliquer les redevances) devront trouver d'autres moyens d'atteindre leurs objectifs. Les portefeuilles de contrats intelligents faciliteront également les choses - notamment, si quelqu'un ne reçoit qu'un jeton non-ETH ERC20, il pourra utiliser ce jeton pour payer l'essence à l'aide de payeurs ERC-4337.
La confidentialité, en revanche, pose à nouveau un grand défi que nous n'avons pas encore vraiment relevé. Le Tornado Cash d'origine ne présentait aucun de 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 en retirer. Cependant, une fois les transferts internes possibles, les utilisateurs devront utiliser le schéma d'adressage interne du système de confidentialité. En pratique, le "message de paiement" d'un utilisateur doit contenir (i) une sorte de "clé de dépense", une promesse d'un secret que le destinataire peut utiliser pour dépenser, et (ii) un moyen pour l'expéditeur d'envoyer la crypto-monnaie uniquement Informations que le bénéficiaire peut déchiffrer pour l'aider à découvrir le paiement.
Le protocole d'adresse furtive repose sur le concept d'une méta-adresse, qui fonctionne de cette manière : 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 cryptage de l'expéditeur (bien que des implémentations minimales puissent définir à la fois les touches sont les mêmes).
Diagramme schématique d'un schéma d'adresse furtif abstrait basé sur le chiffrement et les ZK-SNARK.
Une leçon clé ici est que dans un écosystème respectueux de la vie privée, les utilisateurs auront à la fois des clés publiques de consommation et des clés publiques de chiffrement, et les "informations de paiement" de l'utilisateur doivent inclure les deux clés. Au-delà des paiements, il y a de bonnes raisons de 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 le "monde EOA", nous pourrions réutiliser les clés de compte pour cela, mais dans le monde des portefeuilles de contrats intelligents sécurisés, nous devrions probablement fournir une fonction plus explicite pour cela. Cela contribue également à rendre les identités basées sur Ethereum plus compatibles avec les écosystèmes de confidentialité décentralisés non-Ethereum, en particulier les clés PGP.
Trois transitions et récupération de clé
La méthode par défaut pour mettre en œuvre des changements critiques et une récupération sociale dans un monde où chaque utilisateur a plusieurs adresses consiste simplement à demander à l'utilisateur d'exécuter le processus de récupération sur chaque adresse séparément. Cela peut être fait en un seul clic : les portefeuilles peuvent contenir des logiciels capables d'effectuer des procédures de récupération sur toutes les adresses d'un utilisateur simultanément. Cependant, même avec cette simplification de l'expérience utilisateur, il y a trois problèmes avec une simple récupération multi-adresse :
Le coût du gaz n'est pas pratique : celui-ci est explicite.
Adresses contrefactuelles : adresses que le contrat intelligent n'a pas encore émises (en fait, cela signifie des comptes à partir desquels vous n'avez pas encore envoyé de fonds). En tant qu'utilisateur, vous pouvez avoir un nombre infini d'adresses contrefactuelles : une ou plusieurs adresses sur chaque L2, y compris les L2 qui n'existent pas encore, et un autre ensemble infini d'adresses contrefactuelles résultant du schéma d'adresses furtives.
Confidentialité : si un utilisateur a intentionnellement plusieurs adresses pour éviter de les lier les unes aux autres, 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 élégante qui fonctionne raisonnablement 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 validation pour chaque adresse est un pointeur vers le contrat de magasin de clés. Les dépenses à partir de ces adresses nécessitent une preuve d'entrée 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 direct en lecture seule dans L2. L2 peut être modifié pour lire directement l'état de L1. Si le contrat du magasin de clés est sur L1, cela signifie que les contrats au sein de L2 ont un accès "libre" au magasin de clés
Succursale de Merkel. Les branches Merkle peuvent attester l'état L1 à L2, ou l'état L2 à L1, ou vous pouvez combiner les deux pour attester l'état partiel d'un 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, mais celle-ci sera réduite à < 1 ko dans le futur grâce aux arbres de Verkle.
ZK-SNARK. Vous pouvez réduire les coûts de données en utilisant les fourches ZK-SNARK de Merkle au lieu des fourches elles-mêmes. Des techniques d'agrégation hors chaîne peuvent être construites (par exemple, au-dessus de l'EIP-4337) pour qu'un ZK-SNARK vérifie toutes les preuves d'état inter-chaînes dans un bloc.
Promesse KZG. L2, ou les schémas construits au-dessus d'eux, peuvent introduire un système d'adressage séquentiel, permettant aux preuves d'état dans ce système de n'avoir que 48 octets de long. Comme les ZK-SNARK, plusieurs schémas de preuve peuvent 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 un schéma plus léger qui ne nécessite qu'une seule preuve cross-L2 pour récupérer. 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 pour copier la clé publique de dépenses actuelle dans le magasin de clés. Les fonds dans des adresses contrefactuelles sont en sécurité même si vos anciennes clés ne le sont pas : "activer" une adresse contrefactuelle pour la transformer en un contrat de travail nécessite une preuve croisée L2 pour dupliquer les dépenses actuelles_pubkey. Ce fil sur les forums Safe décrit le fonctionnement d'une architecture similaire.
Pour ajouter de la confidentialité à un tel schéma, nous chiffrons simplement ce pointeur, puis nous faisons toutes les preuves dans les ZK-SNARK :
Avec plus de travail (par exemple, en utilisant ce travail comme point de départ), nous pouvons également supprimer 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. Du côté positif, il existe de nombreuses synergies potentielles entre eux. Par exemple, le concept de « contrats de magasin de clés » peut également résoudre le défi « d'adresse » mentionné dans la section précédente : si nous voulons que les utilisateurs aient des adresses permanentes qui ne changent pas à chaque fois que l'utilisateur effectue une nouvelle saisie, nous pouvons mettre les méta-adresses cachées , les clés de chiffrement et d'autres informations sont placées dans le contrat de magasin de clés, et l'adresse du contrat de magasin de clés est utilisée comme "adresse" de l'utilisateur.
De nombreuses infrastructures secondaires doivent être mises à niveau
L'utilisation de l'ENS coûte cher. Aujourd'hui, en juin 2023, les choses ne vont pas si mal : les frais de transaction sont élevés, mais toujours 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 de l'ETH, ramener les frais de gaz à 200 gwei augmenterait les frais de tx pour les enregistrements 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 exigent un enregistrement presque gratuit (et les frais de domaine ENS ne sont pas un problème puisque ces plates-formes fournissent à leurs utilisateurs des sous-domaines), nous avons besoin d'ENS à L2 pour travailler .
Heureusement, l'équipe de l'ENS est montée au créneau et l'ENS en L2 se passe ! ERC-3668 (alias "norme CCIP"), avec ENSIP-10, fournit un moyen de rendre les sous-domaines ENS sur n'importe quel L2 automatiquement vérifiables. La norme CCIP exige la création d'un contrat intelligent qui décrit une méthode de vérification des preuves des données L2, et que les domaines (par exemple Optinames utilisent ecc.eth) peuvent être placés sous le contrôle d'un tel contrat. Une fois que le contrat CCIP prend le contrôle de ecc.eth sur L1, l'accès à un sous-domaine.ecc.eth impliquera automatiquement de trouver et de vérifier la preuve d'état (par exemple la branche Merkle) dans L2 où ce sous-domaine particulier est réellement stocké.
En fait, l'obtention des preuves implique une liste d'URL stockées dans le contrat, ce qui semble être centralisé, mais je pense 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 dans la fonction de rappel du contrat CCIP , tant que l'une des URL renvoie une preuve valide, c'est bien). La liste des URL peut en contenir des dizaines.
L'effort de l'ENS CCIP est une réussite, et il faut y voir le signe que la réforme radicale dont nous avons besoin est réellement possible. Mais il reste encore de nombreuses réformes de la couche application à faire. Quelques exemples :
De nombreux dapps comptent sur les utilisateurs pour fournir des signatures hors chaîne. Avec un compte externe (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 en auront besoin.
Les Dapps qui utilisent "Est-ce que c'est EOA ?" pour différencier les utilisateurs et les contrats (par exemple, empêcher les transferts ou appliquer des redevances) seront rompus. En général, je déconseille de rechercher ici des solutions purement techniques ; 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 être résolu sans aborder certains mécanismes communautaires hors chaîne. Très probablement, les applications devront s'appuyer moins sur la prévention du détournement et davantage sur des techniques telles que les taxes Harberger.
Doit améliorer la façon dont les portefeuilles interagissent avec les dépenses et les clés de chiffrement. Actuellement, les portefeuilles utilisent généralement des signatures déterministes pour générer des clés spécifiques à l'application : signer un nonce standard (tel qu'un hachage du nom de l'application) avec la clé privée de l'EOA génère une valeur déterministe qui ne peut pas être générée sans la clé privée. Il est donc sûr. dans un sens purement technique. Cependant, ces techniques sont "opaques" pour les portefeuilles, empêchant les portefeuilles de mettre en œuvre des contrôles de sécurité au niveau de l'interface utilisateur. Dans les écosystèmes plus matures, la signature, le chiffrement et les fonctions associées devront être gérés plus explicitement par les portefeuilles.
Les clients légers (tels que Helios) devront authentifier L2 et pas seulement 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 de synchronisation du client léger) et sur la vérification des fourches Merkle de l'état L1 et des transactions enracinées dans les en-têtes L1. Demain, ils doivent également vérifier la preuve de l'état L2, qui est enracinée dans la racine d'état stockée dans L1 (la version la plus avancée examine en fait la pré-confirmation L2).
Les portefeuilles devront protéger les actifs et les données
Aujourd'hui, les portefeuilles servent à 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 sécurisent actuellement ces actifs. Si vous modifiez votre clé, vous pouvez publier en toute sécurité votre clé privée précédente sur Internet le lendemain. Cependant, dans le monde ZK, ce n'est plus vrai : le portefeuille ne protège pas seulement les identifiants 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 utilisé par Zuzalu. L'utilisateur dispose d'une clé privée pour s'authentifier auprès du système, qui peut être utilisée pour faire des preuves de base telles que "prouver que je suis un résident de Zuzalu sans révéler lequel". Mais le système Zupass a également commencé à créer d'autres applications, notamment stamp (la version Zupass de POAP).
Un de mes nombreux tampons Zupass confirmant que je suis un fier membre de Team Cat.
La principale caractéristique qu'offrent les tampons par rapport au POAP est que les tampons sont privés : vous conservez les données localement, et si vous voulez que quelqu'un ait des informations sur vous, il vous suffit de prouver un tampon (ou un calcul sur un tampon) à quelqu'un. Mais cela ajoute un risque : si vous perdez ces informations, vous perdez le tampon.
Bien sûr, le problème de la détention des données peut être réduit au problème de la détention d'une seule clé de chiffrement : un tiers (ou même une 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. D'un autre côté, si quelqu'un voit votre clé de cryptage, il peut voir tout ce qui est crypté avec cette clé.
La solution pratique de Zupass est d'encourager les gens à stocker leurs clés sur plusieurs appareils (comme un ordinateur portable et un téléphone), car les chances qu'ils perdent l'accès à tous en même temps sont minces. Nous pouvons aller plus loin et utiliser un partage secret pour stocker les clés, réparties 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 pourraient s'entendre pour voler vos actifs, ce qui est un risque inacceptable. Mais le risque d'atteinte à la vie privée est généralement inférieur au risque total de perte d'actifs, et les personnes ayant des cas d'utilisation élevés de la vie privée peuvent toujours accepter un risque de perte plus élevé en ne sauvegardant pas les clés associées à ces opérations exigeantes en matière de confidentialité.
Pour éviter que les utilisateurs ne soient submergés par les systèmes byzantins avec 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 à l'identité
L'une des choses que ces changements ont en commun est que le concept d'"adresse", l'identifiant cryptographique que vous utilisez pour représenter "vous" sur la chaîne, doit fondamentalement changer. Les "instructions sur la façon d'interagir avec moi" ne seront plus simplement une adresse ETH ; elles doivent être une combinaison de plusieurs adresses sur plusieurs L2, des méta-adresses furtives, des clés de chiffrement et d'autres données sous une forme ou une autre.
Une façon consiste à faire de l'ENS votre identité : votre enregistrement ENS peut simplement contenir toutes ces informations, et si vous envoyez à quelqu'un bob.eth (ou bob.ecc.eth, ou...), il peut rechercher et voir tout sur la façon dont il paie et interagit avec vous, y compris des méthodes interdomaines plus complexes et préservant la confidentialité.
Mais cette approche centrée sur l'ENS a deux faiblesses :
Il associe trop de choses à votre nom de domaine. Votre nom de domaine n'est pas vous, votre nom de domaine est l'un des nombreux attributs de vous. Il devrait être possible de changer votre nom de domaine sans déplacer tout votre profil d'identité et sans mettre à jour tout un tas d'enregistrements dans de nombreuses applications.
Vous ne pouvez pas avoir de maïs contrefactuel non fiable. 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 piège : interagir avec la chaîne nécessite le paiement de frais de transaction, ce qui nécessite… d'avoir déjà des pièces. Les adresses ETH, y compris les adresses de contrat intelligent avec CREATE2, ont cette fonctionnalité. Les noms ENS ne le seront 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 d'entre eux reçoit le nom.
Une solution possible consiste à mettre plus de contenu 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 toutes sortes d'informations sur vous et sur la façon dont vous interagissez avec lui (pour CCIP, certaines de ces informations peuvent être hors chaîne), et les utilisateurs utiliseront 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 sont indépendants du nom et sont compatibles avec les contrefactuels : vous pouvez générer une adresse dont il peut être prouvé qu'elle n'est initialisée que par un contrat de magasin de clés avec certains paramètres initiaux fixes.
Un autre type de solution s'apparente au protocole de paiement Bitcoin, abandonnant complètement le concept d'adresses orientées utilisateur. 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 pour suivre sa volonté d'accepter le paiement.
Que l'expéditeur ou le destinataire se déplace 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), alors que l'hypothèse d'une communication directe entre l'expéditeur et le destinataire est très délicate en pratique, nous pouvons donc finir par voir une combinaison de différentes technologies.
Dans toutes ces conceptions, rendre les choses à la fois discrètes et faciles à comprendre pour les utilisateurs est le plus important. Nous devons nous assurer que les utilisateurs ont un accès facile à la dernière vue de leurs actifs actuels et des nouvelles publiées pour eux. Ces perspectives doivent s'appuyer sur des outils ouverts et non sur des solutions propriétaires. Empêcher une infrastructure de paiement plus complexe de devenir une "tour d'abstraction" opaque où les développeurs ont du mal à comprendre ce qui se passe et à l'adapter au nouvel environnement demandera un travail acharné. Malgré les défis, l'évolutivité, la sécurité du portefeuille et la confidentialité des utilisateurs ordinaires sont essentielles pour l'avenir d'Ethereum. 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.
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 Buterin : les trois transitions techniques d'Ethereum
Auteur original : Vitalik Buterin, fondateur d'Ethereum
Un merci spécial à Dan Finlay, Karl Floersch, David Hoffman et les équipes Scroll et SoulWallet pour leurs commentaires, critiques et suggestions.
Alors qu'Ethereum passe d'une technologie jeune et expérimentale à une pile technologique mature capable de fournir véritablement une expérience ouverte, globale et sans autorisation aux utilisateurs ordinaires, la pile devra traverser trois transitions technologiques majeures à peu près simultanément :
Sans le premier, Ethereum échouerait car chaque transaction coûte 3,75 $ (82,48 $ si nous avons une autre course haussière) et chaque produit destiné au marché de masse oubliera inévitablement la chaîne et adoptera une solution de contournement centralisée pour tout.
Sans le second, Ethereum aurait échoué car les utilisateurs étaient réticents à stocker leurs fonds (et actifs non financiers) et tout le monde s'est tourné vers des échanges centralisés.
Sans un tiers, Ethereum échouerait car toutes les transactions (et POAP, etc.) Une solution centralisée qui cache au maximum vos données.
Ces trois transitions sont essentielles pour les raisons décrites ci-dessus. Mais ils sont également difficiles, car les traiter correctement nécessite une coordination étroite. Ce n'est pas seulement la fonctionnalité du protocole qui doit être améliorée ; dans certains cas, la façon dont nous interagissons avec Ethereum doit changer fondamentalement, ce qui nécessite des changements profonds dans les applications et les portefeuilles.
Ces trois transitions vont fondamentalement remodeler la relation entre les utilisateurs et les adresses
Dans un monde étendu à la L2, les utilisateurs existeront sur de nombreuses L2. Êtes-vous membre d'ExampleDAO qui s'appuie sur l'Optimisme ? Alors vous avez un compte Optimisme ! Détenez-vous CDP dans le système stablecoin sur ZkSync ? Alors vous avez un compte sur ZkSync ! Avez-vous essayé certaines des applications sur kakarot? Alors vous avez un compte sur Kakarot ! L'époque où un utilisateur n'avait qu'une seule adresse est révolue.
Les portefeuilles de contrats intelligents ajoutent de la complexité et rendent plus difficile d'avoir la même adresse en L1 et dans différentes L2. Aujourd'hui, la plupart des utilisateurs utilisent des comptes externes dont les adresses sont en fait des hachages des clés publiques utilisées pour vérifier les signatures - donc rien ne change entre L1 et L2. Cependant, avec les portefeuilles de contrats intelligents, il devient plus difficile de réserver une adresse. Bien que beaucoup de travail ait été fait pour essayer de faire des adresses un hachage de code équivalent sur tous les réseaux, notamment les usines de singletons CREATE2 et ERC-2470, il a été difficile de faire en sorte que cela fonctionne parfaitement. Certains L2 (tels que "Type 4 ZK-EVM") ne sont pas exactement équivalents à EVM, généralement Solidity ou des assemblages intermédiaires sont utilisés à la place pour empêcher 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 avec lesquelles nous traitons. Si la proposition d'adresse furtive est largement utilisée, au lieu de seulement quelques adresses par utilisateur, ou une adresse par L2, les utilisateurs peuvent avoir une adresse par transaction. D'autres systèmes de confidentialité, même ceux existants tels que 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 devra s'appuyer sur le propre système d'adressage interne du système de confidentialité.
Comme nous l'avons vu, chacune de ces trois transitions affaiblit le modèle mental "un utilisateur ~= une adresse" de différentes manières, certains de ces effets se répercutant sur la complexité de la mise en œuvre de la transition. Deux points de complication particuliers sont :
Si vous vouliez payer quelqu'un, comment obtiendriez-vous des informations sur la façon de le payer ?
Si un utilisateur possède de nombreux actifs à travers des chaînes stockées à différents endroits, comment effectuent-ils les changements clés et la récupération sociale ?
Trois transitions et paiements en chaîne (et identités)
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 pouvez recevoir des pièces que sur Taiko. ce qu'il faut faire
En gros il y a deux solutions :
Bien sûr, ces solutions peuvent être combinées : le destinataire fournit une liste de L2 qu'il est prêt à accepter, et le portefeuille de l'expéditeur calcule le paiement, qui peut impliquer un envoi direct ou un chemin ponté à travers la L2 s'il a de la chance.
Mais ce n'est qu'un exemple d'un défi clé que présentent ces trois transitions : des opérations simples comme payer quelqu'un commencent à nécessiter plus d'informations qu'une simple adresse de 20 octets.
Heureusement, la transition vers des portefeuilles de contrats intelligents ne surchargera pas le système d'adressage, mais il reste encore quelques problèmes techniques à résoudre dans d'autres parties de la pile d'applications. Les portefeuilles devront être mis à jour pour s'assurer qu'ils n'envoient pas seulement 21000 gaz avec la transaction, et il est plus important de s'assurer que l'extrémité de réception du paiement du portefeuille suit non seulement le transfert ETH depuis l'EOA, mais suit également l'ETH. envoyé par le 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 appliquer les redevances) devront trouver d'autres moyens d'atteindre leurs objectifs. Les portefeuilles de contrats intelligents faciliteront également les choses - notamment, si quelqu'un ne reçoit qu'un jeton non-ETH ERC20, il pourra utiliser ce jeton pour payer l'essence à l'aide de payeurs ERC-4337.
La confidentialité, en revanche, pose à nouveau un grand défi que nous n'avons pas encore vraiment relevé. Le Tornado Cash d'origine ne présentait aucun de 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 en retirer. Cependant, une fois les transferts internes possibles, les utilisateurs devront utiliser le schéma d'adressage interne du système de confidentialité. En pratique, le "message de paiement" d'un utilisateur doit contenir (i) une sorte de "clé de dépense", une promesse d'un secret que le destinataire peut utiliser pour dépenser, et (ii) un moyen pour l'expéditeur d'envoyer la crypto-monnaie uniquement Informations que le bénéficiaire peut déchiffrer pour l'aider à découvrir le paiement.
Le protocole d'adresse furtive repose sur le concept d'une méta-adresse, qui fonctionne de cette manière : 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 cryptage de l'expéditeur (bien que des implémentations minimales puissent définir à la fois les touches sont les mêmes).
Une leçon clé ici est que dans un écosystème respectueux de la vie privée, les utilisateurs auront à la fois des clés publiques de consommation et des clés publiques de chiffrement, et les "informations de paiement" de l'utilisateur doivent inclure les deux clés. Au-delà des paiements, il y a de bonnes raisons de 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 le "monde EOA", nous pourrions réutiliser les clés de compte pour cela, mais dans le monde des portefeuilles de contrats intelligents sécurisés, nous devrions probablement fournir une fonction plus explicite pour cela. Cela contribue également à rendre les identités basées sur Ethereum plus compatibles avec les écosystèmes de confidentialité décentralisés non-Ethereum, en particulier les clés PGP.
Trois transitions et récupération de clé
La méthode par défaut pour mettre en œuvre des changements critiques et une récupération sociale dans un monde où chaque utilisateur a plusieurs adresses consiste simplement à demander à l'utilisateur d'exécuter le processus de récupération sur chaque adresse séparément. Cela peut être fait en un seul clic : les portefeuilles peuvent contenir des logiciels capables d'effectuer des procédures de récupération sur toutes les adresses d'un utilisateur simultanément. Cependant, même avec cette simplification de l'expérience utilisateur, il y a trois problèmes avec une simple récupération multi-adresse :
Résoudre ces problèmes est difficile. Heureusement, il existe une solution élégante qui fonctionne raisonnablement bien : une architecture qui sépare la logique de validation de la détention d'actifs.
La preuve peut être obtenue de plusieurs manières :
Pour ajouter de la confidentialité à un tel schéma, nous chiffrons simplement ce pointeur, puis nous faisons toutes les preuves dans les ZK-SNARK :
Ces scénarios peuvent devenir compliqués. Du côté positif, il existe de nombreuses synergies potentielles entre eux. Par exemple, le concept de « contrats de magasin de clés » peut également résoudre le défi « d'adresse » mentionné dans la section précédente : si nous voulons que les utilisateurs aient des adresses permanentes qui ne changent pas à chaque fois que l'utilisateur effectue une nouvelle saisie, nous pouvons mettre les méta-adresses cachées , les clés de chiffrement et d'autres informations sont placées dans le contrat de magasin de clés, et l'adresse du contrat de magasin de clés est utilisée comme "adresse" de l'utilisateur.
De nombreuses infrastructures secondaires doivent être mises à niveau
L'utilisation de l'ENS coûte cher. Aujourd'hui, en juin 2023, les choses ne vont pas si mal : les frais de transaction sont élevés, mais toujours 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 de l'ETH, ramener les frais de gaz à 200 gwei augmenterait les frais de tx pour les enregistrements 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 exigent un enregistrement presque gratuit (et les frais de domaine ENS ne sont pas un problème puisque ces plates-formes fournissent à leurs utilisateurs des sous-domaines), nous avons besoin d'ENS à L2 pour travailler .
Heureusement, l'équipe de l'ENS est montée au créneau et l'ENS en L2 se passe ! ERC-3668 (alias "norme CCIP"), avec ENSIP-10, fournit un moyen de rendre les sous-domaines ENS sur n'importe quel L2 automatiquement vérifiables. La norme CCIP exige la création d'un contrat intelligent qui décrit une méthode de vérification des preuves des données L2, et que les domaines (par exemple Optinames utilisent ecc.eth) peuvent être placés sous le contrôle d'un tel contrat. Une fois que le contrat CCIP prend le contrôle de ecc.eth sur L1, l'accès à un sous-domaine.ecc.eth impliquera automatiquement de trouver et de vérifier la preuve d'état (par exemple la branche Merkle) dans L2 où ce sous-domaine particulier est réellement stocké.
L'effort de l'ENS CCIP est une réussite, et il faut y voir le signe que la réforme radicale dont nous avons besoin est réellement possible. Mais il reste encore de nombreuses réformes de la couche application à faire. Quelques exemples :
Les portefeuilles devront protéger les actifs et les données
Aujourd'hui, les portefeuilles servent à 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 sécurisent actuellement ces actifs. Si vous modifiez votre clé, vous pouvez publier en toute sécurité votre clé privée précédente sur Internet le lendemain. Cependant, dans le monde ZK, ce n'est plus vrai : le portefeuille ne protège pas seulement les identifiants 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 utilisé par Zuzalu. L'utilisateur dispose d'une clé privée pour s'authentifier auprès du système, qui peut être utilisée pour faire des preuves de base telles que "prouver que je suis un résident de Zuzalu sans révéler lequel". Mais le système Zupass a également commencé à créer d'autres applications, notamment stamp (la version Zupass de POAP).
La principale caractéristique qu'offrent les tampons par rapport au POAP est que les tampons sont privés : vous conservez les données localement, et si vous voulez que quelqu'un ait des informations sur vous, il vous suffit de prouver un tampon (ou un calcul sur un tampon) à quelqu'un. Mais cela ajoute un risque : si vous perdez ces informations, vous perdez le tampon.
Bien sûr, le problème de la détention des données peut être réduit au problème de la détention d'une seule clé de chiffrement : un tiers (ou même une 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. D'un autre côté, si quelqu'un voit votre clé de cryptage, il peut voir tout ce qui est crypté avec cette clé.
La solution pratique de Zupass est d'encourager les gens à stocker leurs clés sur plusieurs appareils (comme un ordinateur portable et un téléphone), car les chances qu'ils perdent l'accès à tous en même temps sont minces. Nous pouvons aller plus loin et utiliser un partage secret pour stocker les clés, réparties 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 pourraient s'entendre pour voler vos actifs, ce qui est un risque inacceptable. Mais le risque d'atteinte à la vie privée est généralement inférieur au risque total de perte d'actifs, et les personnes ayant des cas d'utilisation élevés de la vie privée peuvent toujours accepter un risque de perte plus élevé en ne sauvegardant pas les clés associées à ces opérations exigeantes en matière de confidentialité.
Pour éviter que les utilisateurs ne soient submergés par les systèmes byzantins avec 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 à l'identité
L'une des choses que ces changements ont en commun est que le concept d'"adresse", l'identifiant cryptographique que vous utilisez pour représenter "vous" sur la chaîne, doit fondamentalement changer. Les "instructions sur la façon d'interagir avec moi" ne seront plus simplement une adresse ETH ; elles doivent être une combinaison de plusieurs adresses sur plusieurs L2, des méta-adresses furtives, des clés de chiffrement et d'autres données sous une forme ou une autre.
Une façon consiste à faire de l'ENS votre identité : votre enregistrement ENS peut simplement contenir toutes ces informations, et si vous envoyez à quelqu'un bob.eth (ou bob.ecc.eth, ou...), il peut rechercher et voir tout sur la façon dont il paie et interagit avec vous, y compris des méthodes interdomaines plus complexes et préservant la confidentialité.
Mais cette approche centrée sur l'ENS a deux faiblesses :
Une solution possible consiste à mettre plus de contenu 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 toutes sortes d'informations sur vous et sur la façon dont vous interagissez avec lui (pour CCIP, certaines de ces informations peuvent être hors chaîne), et les utilisateurs utiliseront 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 sont indépendants du nom et sont compatibles avec les contrefactuels : vous pouvez générer une adresse dont il peut être prouvé qu'elle n'est initialisée que par un contrat de magasin de clés avec certains paramètres initiaux fixes.
Un autre type de solution s'apparente au protocole de paiement Bitcoin, abandonnant complètement le concept d'adresses orientées utilisateur. 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 pour suivre sa volonté d'accepter le paiement.
Dans toutes ces conceptions, rendre les choses à la fois discrètes et faciles à comprendre pour les utilisateurs est le plus important. Nous devons nous assurer que les utilisateurs ont un accès facile à la dernière vue de leurs actifs actuels et des nouvelles publiées pour eux. Ces perspectives doivent s'appuyer sur des outils ouverts et non sur des solutions propriétaires. Empêcher une infrastructure de paiement plus complexe de devenir une "tour d'abstraction" opaque où les développeurs ont du mal à comprendre ce qui se passe et à l'adapter au nouvel environnement demandera un travail acharné. Malgré les défis, l'évolutivité, la sécurité du portefeuille et la confidentialité des utilisateurs ordinaires sont essentielles pour l'avenir d'Ethereum. 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.