Alors qu'Ethereum évolue d'une technologie jeune et expérimentale vers une pile technologique mature capable de fournir une expérience ouverte, globale et sans autorisation aux utilisateurs ordinaires, trois transitions technologiques majeures doivent se produire simultanément :
Le premier est la transformation de l'expansion de la capacité L2 - tout le monde se tourne vers la technologie Rollup ;
Deuxièmement, la transformation de la sécurité des portefeuilles - Tout le monde commence à utiliser des portefeuilles de contrats intelligents ;
Le troisième est la transformation de la confidentialité - en veillant à ce que la fonctionnalité de transfert de fonds préservant la confidentialité soit disponible et en veillant à ce que tous les autres outils en cours de développement (récupération sociale, vérification d'identité, réputation, etc.) disposent de fonctionnalités préservant la confidentialité.
Triangle de transformation de l'écosystème Ethereum. Vous ne pouvez choisir que les trois. *
Sans le premier élément, Ethereum échouera car chaque transaction coûte 3,75 $ (82,48 $ si nous traversons une autre course haussière), et chaque produit du marché de masse abandonnera inévitablement le commerce en chaîne et adoptera une solution centralisée.
Sans le deuxième élément, Ethereum échouerait car les utilisateurs ne seraient pas disposés à stocker leurs fonds (et leurs actifs non financiers) et tout le monde se tournerait vers des échanges centralisés.
Sans le troisième élément, Ethereum échouerait car pour de nombreux utilisateurs, toutes les transactions (et POAP, etc.) seraient visibles publiquement, le sacrifice de la vie privée serait trop important et tout le monde se tournerait vers au moins un certain niveau de données cachées Solution centralisée.
Pour les raisons décrites ci-dessus, ces trois transitions sont essentielles. Mais ils sont également difficiles en raison de la complexité de la coordination impliquée. 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 et profondément, nécessitant des changements majeurs dans les applications et les portefeuilles.
Ces trois transformations vont fondamentalement remodeler la relation entre les utilisateurs et les adresses
Dans un monde de mise à l'échelle L2, les utilisateurs existeront sur plusieurs réseaux L2. Êtes-vous membre d'ExampleDAO ? ExampleDAO est sur Optimisme. Alors vous avez un compte chez Optimism ! Détenez-vous un CDP d'un système stablecoin sur ZkSync ? Alors vous avez un compte sur ZkSync ! Avez-vous déjà essayé certaines des applications situées sur Kakarot ? Alors vous avez un compte sur Kakarot ! L'époque où les utilisateurs n'avaient qu'une seule adresse est révolue.
* Ma vue de portefeuille Brave, je tiens Ethereum à quatre endroits. Oui, Arbitrum et Arbitrum Nova sont différents. Ne vous inquiétez pas, les choses se compliqueront avec le temps ! *
** Les portefeuilles de contrats intelligents ajoutent plus de complexité car il est plus difficile d'avoir la même adresse sur L1 et divers réseaux L2. ** La plupart des utilisateurs utilisent aujourd'hui 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, la gestion d'une adresse devient plus difficile lors de l'utilisation d'un portefeuille de contrat intelligent. Bien que beaucoup de travail ait été fait pour essayer de faire des adresses un hachage de code équivalent sur différents réseaux, le plus important étant CREATE2 et l'usine de singleton ERC-2470, il est difficile d'y parvenir parfaitement. Certains réseaux L2 (par exemple, "ZK-EVM du quatrième type") ne sont pas exactement équivalents aux EVM, utilisant souvent Solidity ou un langage d'assemblage intermédiaire plutôt que des équivalents de hachage. Même si l'équivalence de hachage pouvait être obtenue, la possibilité que les portefeuilles changent de propriétaire par le biais de changements clés entraîne d'autres conséquences moins prévisibles.
** 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 furtive est largement utilisée, les utilisateurs peuvent avoir une adresse par transaction au lieu de seulement quelques adresses par utilisateur ou une adresse par réseau L2. D'autres systèmes de confidentialité, même ceux existants comme Tornado Cash, modifient la façon dont les actifs sont stockés de différentes manières : 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 système d'adressage interne du système de confidentialité.
Comme nous l'avons vu, ces trois transformations affaiblissent le modèle mental "un utilisateur ≈ une adresse" de différentes manières, dont certains effets augmentent à leur tour la complexité d'exécution de ces transformations. Deux des problèmes particulièrement complexes sont :
**1. Si vous souhaitez payer quelqu'un, comment obtiendrez-vous les informations de paiement ? **
**2. Si les utilisateurs stockent des actifs à différents endroits sur différentes chaînes, comment procèdent-ils aux changements clés et à la reprise sociale ? **
Ces trois transformations et paiements en chaîne (et identité)
Je détiens des jetons sur Scroll, et je veux les utiliser pour acheter du café (si le "je" littéral fait référence à Vitalik, l'auteur de cet article, alors "café" signifie bien sûr "thé vert"). Vous vendez du café sur Taiko, mais vous n'acceptez que des jetons sur Taiko. ce qu'il faut faire?
En gros il y a deux solutions :
Le portefeuille récepteur (qui peut être un commerçant ou un individu ordinaire) s'efforce de prendre en charge chaque L2 et dispose de certaines fonctions de fusion de fonds asynchrones.
Le bénéficiaire fournit ses informations L2 à côté de l'adresse, et le portefeuille de l'expéditeur achemine automatiquement les fonds vers la cible L2 via une sorte de système de pont inter-L2.
Bien sûr, ces solutions peuvent être utilisées en combinaison : le bénéficiaire fournit la liste L2 qu'il est prêt à accepter, et le portefeuille de l'expéditeur détermine le mode de paiement, qui peut être envoyé directement (avec de la chance) ou payé via un chemin ponté à travers le L2.
Mais ce n'est qu'un exemple d'un défi majeur introduit par les trois transformations : Des comportements de paiement simples commencent à nécessiter plus d'informations qu'une simple adresse de 20 octets.
Heureusement, le passage aux portefeuilles de contrats intelligents n'est pas un fardeau énorme pour 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 lors de l'envoi de transactions, mais qu'une plus grande attention doit être accordée pour s'assurer que l'extrémité réceptrice du portefeuille suit non seulement les transferts ETH depuis l'EOA, mais aussi les transferts ETH depuis le code de contrat intelligent. Les applications qui reposent sur la 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 non-ETH ERC20, il pourra utiliser un payeur ERC-4337 pour payer l'essence à l'aide de ce jeton.
D'un autre côté, la question de la vie privée est à nouveau un grand défi que nous n'avons pas encore vraiment résolu. 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 et retirer de l'argent dans le système. 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" de l'utilisateur devra contenir (i) une sorte de "clé publique de dépense", un engagement secret que le destinataire peut utiliser pour dépenser, et (ii) l'expéditeur peut envoyer des messages cryptés que seul le destinataire peut décrypter Le destinataire de l'aide découvre le mode de paiement.
Le protocole d'adresse Stealth repose sur le concept d'une méta-adresse, qui fonctionne comme suit : une partie de la méta-adresse est la clé de dépenses trompeuse de l'expéditeur, et l'autre partie est la clé chiffrée de l'expéditeur (bien qu'une implémentation minimale puisse définir les deux clés être le même).
Un aperçu des schémas d'adresses furtives abstraits basés sur le cryptage et les ZK-SNARK *
Une leçon clé ici est que ** dans un écosystème respectueux de la vie privée, 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 inclure les deux clés. ** En plus de payer, il existe d'autres bonnes raisons d'étendre 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, mais dans le monde des portefeuilles de contrats intelligents sécurisés, nous devrions probablement fournir des fonctionnalités plus explicites 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.
Ces trois transitions et la récupération des clés
Dans un monde où chaque utilisateur a plusieurs adresses, la méthode par défaut pour mettre en œuvre les changements clés et la récupération sociale consiste à faire en sorte que les utilisateurs exécutent le processus de récupération sur chaque adresse individuellement. Cela peut être fait en un seul clic : le portefeuille peut fournir une fonction logicielle pour effectuer le processus de récupération simultanément sur toutes les adresses de l'utilisateur. Cependant, même avec cette simplification de l'expérience utilisateur, la récupération multi-adresses pose trois problèmes :
1. Le coût du gaz n'est pas réaliste : Cela va de soi.
2. Adresses contrefactuelles : adresses qui n'ont pas encore émis de contrat intelligent (en fait, cela signifiera des comptes à partir desquels vous n'avez pas encore envoyé de fonds). En tant qu'utilisateur, vous pouvez avoir un nombre infini d'adresses virtuelles : une ou plusieurs sur chaque L2, y compris les L2 qui n'existent pas encore, et un ensemble infini d'adresses virtuelles résultant du schéma d'adresse furtive.
3. Confidentialité : si un utilisateur utilise intentionnellement plusieurs adresses pour éviter de les associer les unes aux autres, il ne souhaite certainement pas toutes les associer publiquement en les restaurant en même temps ou presque !
Résoudre ces problèmes est difficile. Heureusement, il existe une solution plutôt élégante qui fonctionne plutôt bien : Cette architecture sépare la logique de validation de la détention d'actifs.
Chaque utilisateur a un contrat de magasin de clés qui existe à un endroit (peut être le réseau principal ou un L2 spécifique). Ensuite, les utilisateurs ont des adresses sur différents L2, et la logique de vérification pour chaque adresse est un pointeur vers le contrat de magasin de clés. Dépenser des fonds à partir de ces adresses nécessitera de fournir une preuve d'une clé publique de dépenses actuelle (ou plus réaliste, très récente) pour les fonds.
Cette preuve peut être obtenue de plusieurs manières :
** Accès en lecture seule à L1 directement dans L2. ** L2 peut être modifié pour lui permettre 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 "libre" au magasin de clés.
**Succursales Merkle. ** Les branches Merkle peuvent prouver l'état L1 à L2, ou l'état L2 à L1, ou une combinaison des deux peut prouver l'état partiel d'un L2 à un autre L2. La principale faiblesse des preuves Merkle est le coût élevé du gaz en raison de la longueur de preuve, qui peut nécessiter une longueur de preuve de 5 Ko, mais en raison de l'utilisation d'arbres Verkle, cela sera réduit à <1 Ko à l'avenir.
**ZK-SNARK. ** Vous pouvez réduire les coûts de données en utilisant les ZK-SNARK des succursales Merkle au lieu d'utiliser les succursales elles-mêmes. Des techniques d'agrégation hors chaîne (par exemple, au-dessus de EIP-4337) peuvent être construites pour permettre à un seul ZK-SNARK de vérifier toutes les preuves d'état inter-chaînes dans un bloc.
** Promesse KZG. ** Qu'il s'agisse de L2 ou du schéma construit dessus, un système d'adressage séquentiel peut être introduit, permettant à la preuve d'état à l'intérieur du système de n'être que de 48 octets. Comme les ZK-SNARK, les schémas multi-preuves peuvent combiner toutes ces preuves en une seule preuve pour chaque bloc.
Si nous voulons éviter d'avoir besoin d'une preuve pour chaque transaction, nous pouvons implémenter un schéma plus léger qui ne nécessite qu'une récupération sur les preuves L2. Les dépenses à partir d'un compte dépendraient d'une clé de dépenses avec sa clé publique correspondante stockée dans le compte, mais la récupération nécessiterait une transaction pour copier la clé publique de dépenses actuelle dans le magasin de clés. Même si vos anciennes clés ne sont pas sécurisées, les fonds de l'adresse virtuelle sont en sécurité : "l'activation" de l'adresse virtuelle pour la transformer en un contrat utilisable nécessitera une preuve cross-L2 pour répliquer la clé publique de dépenses actuelle. Il existe un fil sur les forums Safe qui décrit le fonctionnement d'une architecture similaire.
Pour ajouter de la confidentialité à un tel schéma, nous n'avons qu'à chiffrer les pointeurs et faire toutes les preuves à l'intérieur des ZK-SNARK :
Avec d'autres travaux (par exemple en utilisant ce travail comme point de départ), nous pouvons également supprimer ZK - La plupart de la complexité des SNARK, en construisant un schéma basé sur KZG plus simplifié.
Ces scénarios peuvent devenir compliqués. L'avantage est qu'il existe de nombreuses synergies potentielles entre eux. Par exemple, le concept de « contrat de magasin de clés » peut également être une solution à « l'adresse » mentionnée dans la section précédente : si nous voulons que les utilisateurs aient des adresses persistantes qui ne changent pas à chaque fois qu'ils mettent à jour leurs clés, nous pouvons mettre la furtivité La méta-adresse, la clé de cryptage 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 à jour
L'utilisation de l'ENS coûte cher. Bien qu'il ne soit pas aussi cher qu'avant en juin 2023, les frais de transaction pour l'enregistrement d'un nom de domaine sont encore relativement élevés, ce qui est comparable au coût d'un nom de domaine ENS. Par exemple, il en coûte environ 27 $ pour s'inscrire sur zuzalu.eth, dont 11 $ de frais de transaction. Mais si le marché redevient haussier, les frais monteront en flèche. Même si le prix de l'ETH n'augmente pas, si les frais de gaz reviennent à 200 gwei, les frais de transaction pour l'enregistrement du nom de domaine atteindront 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 peuvent fournir aux utilisateurs des sous-domaines), nous avons besoin que ENS soit utilisé sur Couche 2.
Heureusement, l'équipe ENS s'est déjà renforcée et ENS est en cours d'implémentation sur la couche 2 ! ERC-3668 (également connu sous le nom de "norme CCIP") et ENSIP-10 fournissent un moyen de vérifier automatiquement les sous-domaines ENS sur n'importe quelle couche 2. La norme CCIP impose la mise en place d'un contrat intelligent qui décrit la méthode de vérification des preuves de données sur la couche 2, et un nom de domaine (par exemple, ecc.eth pour Optinames) peut être placé sous le contrôle d'un tel contrat. Une fois que le contrat CCIP contrôle ecc.eth sur L1, l'accès à un certain sous-domaine.ecc.eth trouvera et vérifiera automatiquement une preuve stockant l'état de la couche 2 de ce sous-domaine spécifique (par exemple, une succursale Merkle).
en réalité l'obtention de ces preuves implique l'accès à une liste d'URL stockées dans le contrat, bien que cela soit D'une certaine manière, cela peut ressembler à de la centralisation, mais je dirais que ce n'est pas le cas : c'est un modèle de confiance 1 à N (les preuves non valides sont interceptées par la logique de validation dans la fonction de rappel du contrat CCIP, tant que l'une des URL A qui renvoie une preuve valide, c'est bien). La liste d'URL peut contenir des dizaines d'URL.
**L'effort CCIP de l'ENS est une réussite et doit être considéré comme un signe que les réformes radicales dont nous avons besoin sont réellement possibles. ** Mais il reste encore de nombreuses réformes au niveau de l'application qui doivent être faites. Voici quelques exemples:
**De nombreux DApps s'appuient sur les utilisateurs pour fournir des signatures hors chaîne. **Pour les comptes externes (EOA), c'est facile. ERC-1271 fournit un moyen standardisé de le faire pour les portefeuilles de contrats intelligents. Cependant, de nombreux DApp ne prennent toujours pas en charge ERC-1271 et doivent être adaptés.
** Les DApps qui utilisent "est-ce un EOA ?" pour différencier les utilisateurs et les contrats (par exemple pour empêcher les transferts ou appliquer des redevances) auront des problèmes. ** En général, je déconseille d'essayer de trouver une solution purement technique ici ; déterminer si un transfert particulier de contrôle cryptographique est un transfert de propriété réelle est un problème difficile qui peut ne pas être résolu sans recourir à des solutions communautaires hors chaîne. mécanismes résolvent. Très probablement, les applications s'appuieront moins sur des moyens techniques de blocage des transferts et davantage sur des techniques telles que la taxe Harberger.
** L'interaction du portefeuille avec les paiements et les clés de cryptage 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 : signer un nonce standard (par exemple, un hachage du nom de l'application) avec la clé privée de l'EOA générera une valeur déterministe à moins que la clé privée ne soit en possession, sinon la valeur ne peut pas être généré et est donc purement 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 devront être gérés plus explicitement par les portefeuilles.
Les clients légers (tels que Helios) devront authentifier la couche 2 au lieu de simplement la couche 1**. ** Actuellement, le client léger se concentre sur la vérification de la validité des informations d'en-tête du bloc L1 (à l'aide du protocole de synchronisation du client léger) et sur la vérification de la branche Merkle de l'état L1 et des transactions basées sur les informations d'en-tête du bloc L1. À l'avenir, ils devront également vérifier les preuves de l'état L2 enraciné à la racine de l'état stocké dans L1 (les versions plus avancées examineront en fait la pré-confirmation L2).
Les portefeuilles devront protéger les actifs et les données
Actuellement, la mission du portefeuille est de protéger les actifs. Tout est stocké en chaîne, tout ce que le portefeuille doit protéger, ce sont les clés privées qui sécurisent actuellement ces actifs. Si vous modifiez la clé, vous pouvez publier en toute sécurité la clé privée précédente sur Internet le jour suivant. Cependant, dans un monde sans connaissance, ce n'est plus le cas : les portefeuilles ne se contentent pas de protéger les identifiants d'authentification, ils contiennent également vos données.
Nous voyons les premiers signes d'un tel monde à Zuzalu avec Zupass, un système d'identité basé sur ZK-SNARK. L'utilisateur dispose d'une clé privée qui est utilisée pour s'authentifier dans le système, qui peut être utilisée pour générer des preuves de base telles que "prouver que je suis un résident de Zuzalu sans révéler de quel résident je suis". Le système Zupass a également commencé à créer d'autres applications, notamment des timbres (version Zupass de POAP).
*Un de mes nombreux tampons Zupass confirmant que je suis membre de Team Cat. *
La principale caractéristique des tampons relatifs au POAP est qu'ils sont privés : vous conservez les données localement et ne prouvez un tampon à leur ZK (ou effectuez des calculs sur les tampons) que si vous souhaitez donner cette information à quelqu'un. Mais cela comporte également un risque supplémentaire : si vous perdez ces informations, vous perdrez vos tampons.
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 (même en 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 cryptage, de sorte qu'aucune interaction avec le système détenant la clé de cryptage n'est requise. Mais même dans ce cas, si vous perdez la clé de cryptage, vous perdez toutes vos données. Et, à son tour, si quelqu'un voit votre clé de cryptage, il pourra 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 en utilisant le partage de clés pour répartir le stockage de clés entre plusieurs protecteurs.
La récupération sociale via MPC n'est pas une solution adéquate pour les portefeuilles, car cela signifie que non seulement le protecteur actuel, mais aussi les protecteurs précédents pourraient s'entendre pour voler vos actifs, ce qui représente un risque inacceptable. Bien qu'une violation de la vie privée soit généralement moins risquée qu'une perte complète d'actifs, pour les cas d'utilisation avec des besoins de confidentialité élevés, un risque de perte plus élevé peut être accepté en ne sauvegardant pas les clés associées à ces besoins de confidentialité.
Pour éviter d'enliser les utilisateurs dans un système complexe de plusieurs chemins de récupération, les portefeuilles prenant en charge la récupération sociale peuvent avoir besoin de gérer à la fois les aspects de la récupération des actifs et de la récupération des clés de chiffrement.
Retour à l'identité
Un thème commun à ces changements est que le concept d'"adresse" en tant que représentation de l'identité sur la blockchain devra changer fondamentalement. ** "Instructions sur la façon d'interagir avec moi" ne sera plus seulement une adresse ETH ; express. **
L'une de ces façons consiste à utiliser ENS comme identité : votre dossier ENS peut contenir toutes les informations sur la façon de payer et d'interagir avec vous, si vous envoyez à quelqu'un bob.eth (ou bob.ecc.eth etc.), il peut se renseigner et découvrez tout ce qui interagit avec vous, y compris de manière plus complexe à travers les domaines et avec la protection de la vie privée.
Cependant, cette approche centrée sur l'ENS souffre de deux faiblesses :
**Il associe trop de contenu à votre nom. **Votre nom ne signifie pas tout sur vous, c'est juste l'un des nombreux attributs qui vous concernent. Il devrait être possible de changer votre nom sans migrer l'intégralité de votre profil d'identité et sans mettre à jour les enregistrements dans de nombreuses applications.
**Vous ne pouvez pas avoir de noms contrefactuels qui ne nécessitent pas de confiance. ** Une caractéristique clé de l'expérience utilisateur de toute blockchain est la possibilité d'envoyer des jetons à des personnes qui n'ont pas encore interagi avec la chaîne. Sans une telle fonctionnalité, il y a un dilemme : interagir avec la chaîne nécessite de payer des frais de transaction, et payer des frais de transaction nécessite… de posséder déjà des jetons. Les adresses ETH, y compris les adresses de contrat intelligent avec CREATE2, ont cette fonctionnalité. Les noms ENS ne le font pas, car si les deux Bobs décident hors chaîne qu'ils sont bob.ecc.eth, il n'y a aucun moyen de choisir quel Bob obtient le nom.
Une solution possible consiste à mettre plus de contenu dans le contrat de magasin de clés mentionné précédemment dans l'architecture de cet article. Un contrat de magasin de clés peut contenir diverses informations sur vous et vos interactions avec vous (et avec CCIP, certaines de ces informations peuvent être hors chaîne), les utilisateurs utiliseront leur contrat de magasin de clés comme identifiant principal. Cependant, les actifs qu'ils reçoivent réellement seront stockés dans une variété d'endroits différents. Les contrats de magasin de clés sont indépendants du nom et acceptent les noms virtuels : vous pouvez générer une adresse qui ne peut être initialisée que par un contrat de magasin de clés avec certains paramètres initiaux fixes.
Une autre classe de solutions consiste à abandonner complètement la notion d'adresses destinées aux utilisateurs, similaire au protocole de paiement de Bitcoin. Une idée est de s'appuyer davantage sur des canaux de communication directs entre l'expéditeur et le destinataire ; par exemple, l'expéditeur pourrait envoyer un lien de demande (sous forme d'URL explicite ou de code QR), que le destinataire pourrait utiliser pour envoyer toute demande qu'il souhaite accepter. paiement.
Que ce soit l'expéditeur ou le destinataire qui agisse en premier, s'appuyer davantage sur les portefeuilles pour générer des informations de paiement à jour en temps réel réduit les frictions. Cependant, les identifiants persistants sont pratiques (en particulier avec ENS), alors qu'en pratique, s'appuyer sur une communication directe entre l'expéditeur et le destinataire est un problème très délicat, de sorte qu'une combinaison de différentes techniques peut être observée.
Dans toutes ces conceptions, il est essentiel de rester décentralisé et compréhensible pour les utilisateurs. Nous devons nous assurer que les utilisateurs peuvent facilement accéder à une vue à jour de leurs actifs actuels et des messages qui leur sont destinés. Ces vues doivent s'appuyer sur des outils ouverts plutôt que sur des solutions propriétaires. Il faudra travailler dur pour empêcher la plus grande complexité de l'infrastructure de paiement de devenir une « tour d'abstraction » opaque, difficile à comprendre et à adapter aux nouveaux environnements. 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.
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 : L'écosystème Ethereum a besoin de trois transformations technologiques
Auteur : Vitalik, fondateur d'Ethereum ; Traduction : Jinse Finance cryptonaive
Alors qu'Ethereum évolue d'une technologie jeune et expérimentale vers une pile technologique mature capable de fournir une expérience ouverte, globale et sans autorisation aux utilisateurs ordinaires, trois transitions technologiques majeures doivent se produire simultanément :
Sans le premier élément, Ethereum échouera car chaque transaction coûte 3,75 $ (82,48 $ si nous traversons une autre course haussière), et chaque produit du marché de masse abandonnera inévitablement le commerce en chaîne et adoptera une solution centralisée.
Sans le deuxième élément, Ethereum échouerait car les utilisateurs ne seraient pas disposés à stocker leurs fonds (et leurs actifs non financiers) et tout le monde se tournerait vers des échanges centralisés.
Sans le troisième élément, Ethereum échouerait car pour de nombreux utilisateurs, toutes les transactions (et POAP, etc.) seraient visibles publiquement, le sacrifice de la vie privée serait trop important et tout le monde se tournerait vers au moins un certain niveau de données cachées Solution centralisée.
Pour les raisons décrites ci-dessus, ces trois transitions sont essentielles. Mais ils sont également difficiles en raison de la complexité de la coordination impliquée. 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 et profondément, nécessitant des changements majeurs dans les applications et les portefeuilles.
Ces trois transformations vont fondamentalement remodeler la relation entre les utilisateurs et les adresses
Dans un monde de mise à l'échelle L2, les utilisateurs existeront sur plusieurs réseaux L2. Êtes-vous membre d'ExampleDAO ? ExampleDAO est sur Optimisme. Alors vous avez un compte chez Optimism ! Détenez-vous un CDP d'un système stablecoin sur ZkSync ? Alors vous avez un compte sur ZkSync ! Avez-vous déjà essayé certaines des applications situées sur Kakarot ? Alors vous avez un compte sur Kakarot ! L'époque où les utilisateurs n'avaient qu'une seule adresse est révolue.
** Les portefeuilles de contrats intelligents ajoutent plus de complexité car il est plus difficile d'avoir la même adresse sur L1 et divers réseaux L2. ** La plupart des utilisateurs utilisent aujourd'hui 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, la gestion d'une adresse devient plus difficile lors de l'utilisation d'un portefeuille de contrat intelligent. Bien que beaucoup de travail ait été fait pour essayer de faire des adresses un hachage de code équivalent sur différents réseaux, le plus important étant CREATE2 et l'usine de singleton ERC-2470, il est difficile d'y parvenir parfaitement. Certains réseaux L2 (par exemple, "ZK-EVM du quatrième type") ne sont pas exactement équivalents aux EVM, utilisant souvent Solidity ou un langage d'assemblage intermédiaire plutôt que des équivalents de hachage. Même si l'équivalence de hachage pouvait être obtenue, la possibilité que les portefeuilles changent de propriétaire par le biais de changements clés entraîne d'autres conséquences moins prévisibles.
** 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 furtive est largement utilisée, les utilisateurs peuvent avoir une adresse par transaction au lieu de seulement quelques adresses par utilisateur ou une adresse par réseau L2. D'autres systèmes de confidentialité, même ceux existants comme Tornado Cash, modifient la façon dont les actifs sont stockés de différentes manières : 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 système d'adressage interne du système de confidentialité.
Comme nous l'avons vu, ces trois transformations affaiblissent le modèle mental "un utilisateur ≈ une adresse" de différentes manières, dont certains effets augmentent à leur tour la complexité d'exécution de ces transformations. Deux des problèmes particulièrement complexes sont :
**1. Si vous souhaitez payer quelqu'un, comment obtiendrez-vous les informations de paiement ? **
**2. Si les utilisateurs stockent des actifs à différents endroits sur différentes chaînes, comment procèdent-ils aux changements clés et à la reprise sociale ? **
Ces trois transformations et paiements en chaîne (et identité)
Je détiens des jetons sur Scroll, et je veux les utiliser pour acheter du café (si le "je" littéral fait référence à Vitalik, l'auteur de cet article, alors "café" signifie bien sûr "thé vert"). Vous vendez du café sur Taiko, mais vous n'acceptez que des jetons sur Taiko. ce qu'il faut faire?
En gros il y a deux solutions :
Le portefeuille récepteur (qui peut être un commerçant ou un individu ordinaire) s'efforce de prendre en charge chaque L2 et dispose de certaines fonctions de fusion de fonds asynchrones.
Le bénéficiaire fournit ses informations L2 à côté de l'adresse, et le portefeuille de l'expéditeur achemine automatiquement les fonds vers la cible L2 via une sorte de système de pont inter-L2.
Bien sûr, ces solutions peuvent être utilisées en combinaison : le bénéficiaire fournit la liste L2 qu'il est prêt à accepter, et le portefeuille de l'expéditeur détermine le mode de paiement, qui peut être envoyé directement (avec de la chance) ou payé via un chemin ponté à travers le L2.
Mais ce n'est qu'un exemple d'un défi majeur introduit par les trois transformations : Des comportements de paiement simples commencent à nécessiter plus d'informations qu'une simple adresse de 20 octets.
Heureusement, le passage aux portefeuilles de contrats intelligents n'est pas un fardeau énorme pour 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 lors de l'envoi de transactions, mais qu'une plus grande attention doit être accordée pour s'assurer que l'extrémité réceptrice du portefeuille suit non seulement les transferts ETH depuis l'EOA, mais aussi les transferts ETH depuis le code de contrat intelligent. Les applications qui reposent sur la 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 non-ETH ERC20, il pourra utiliser un payeur ERC-4337 pour payer l'essence à l'aide de ce jeton.
D'un autre côté, la question de la vie privée est à nouveau un grand défi que nous n'avons pas encore vraiment résolu. 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 et retirer de l'argent dans le système. 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" de l'utilisateur devra contenir (i) une sorte de "clé publique de dépense", un engagement secret que le destinataire peut utiliser pour dépenser, et (ii) l'expéditeur peut envoyer des messages cryptés que seul le destinataire peut décrypter Le destinataire de l'aide découvre le mode de paiement.
Le protocole d'adresse Stealth repose sur le concept d'une méta-adresse, qui fonctionne comme suit : une partie de la méta-adresse est la clé de dépenses trompeuse de l'expéditeur, et l'autre partie est la clé chiffrée de l'expéditeur (bien qu'une implémentation minimale puisse définir les deux clés être le même).
Une leçon clé ici est que ** dans un écosystème respectueux de la vie privée, 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 inclure les deux clés. ** En plus de payer, il existe d'autres bonnes raisons d'étendre 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, mais dans le monde des portefeuilles de contrats intelligents sécurisés, nous devrions probablement fournir des fonctionnalités plus explicites 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.
Ces trois transitions et la récupération des clés
Dans un monde où chaque utilisateur a plusieurs adresses, la méthode par défaut pour mettre en œuvre les changements clés et la récupération sociale consiste à faire en sorte que les utilisateurs exécutent le processus de récupération sur chaque adresse individuellement. Cela peut être fait en un seul clic : le portefeuille peut fournir une fonction logicielle pour effectuer le processus de récupération simultanément sur toutes les adresses de l'utilisateur. Cependant, même avec cette simplification de l'expérience utilisateur, la récupération multi-adresses pose trois problèmes :
1. Le coût du gaz n'est pas réaliste : Cela va de soi.
2. Adresses contrefactuelles : adresses qui n'ont pas encore émis de contrat intelligent (en fait, cela signifiera des comptes à partir desquels vous n'avez pas encore envoyé de fonds). En tant qu'utilisateur, vous pouvez avoir un nombre infini d'adresses virtuelles : une ou plusieurs sur chaque L2, y compris les L2 qui n'existent pas encore, et un ensemble infini d'adresses virtuelles résultant du schéma d'adresse furtive.
3. Confidentialité : si un utilisateur utilise intentionnellement plusieurs adresses pour éviter de les associer les unes aux autres, il ne souhaite certainement pas toutes les associer publiquement en les restaurant en même temps ou presque !
Résoudre ces problèmes est difficile. Heureusement, il existe une solution plutôt élégante qui fonctionne plutôt bien : Cette architecture sépare la logique de validation de la détention d'actifs.
Chaque utilisateur a un contrat de magasin de clés qui existe à un endroit (peut être le réseau principal ou un L2 spécifique). Ensuite, les utilisateurs ont des adresses sur différents L2, et la logique de vérification pour chaque adresse est un pointeur vers le contrat de magasin de clés. Dépenser des fonds à partir de ces adresses nécessitera de fournir une preuve d'une clé publique de dépenses actuelle (ou plus réaliste, très récente) pour les fonds.
Cette preuve peut être obtenue de plusieurs manières :
Si nous voulons éviter d'avoir besoin d'une preuve pour chaque transaction, nous pouvons implémenter un schéma plus léger qui ne nécessite qu'une récupération sur les preuves L2. Les dépenses à partir d'un compte dépendraient d'une clé de dépenses avec sa clé publique correspondante stockée dans le compte, mais la récupération nécessiterait une transaction pour copier la clé publique de dépenses actuelle dans le magasin de clés. Même si vos anciennes clés ne sont pas sécurisées, les fonds de l'adresse virtuelle sont en sécurité : "l'activation" de l'adresse virtuelle pour la transformer en un contrat utilisable nécessitera une preuve cross-L2 pour répliquer la clé publique de dépenses actuelle. Il existe un fil sur les forums Safe qui décrit le fonctionnement d'une architecture similaire.
Pour ajouter de la confidentialité à un tel schéma, nous n'avons qu'à chiffrer les pointeurs et faire toutes les preuves à l'intérieur des ZK-SNARK :
Ces scénarios peuvent devenir compliqués. L'avantage est qu'il existe de nombreuses synergies potentielles entre eux. Par exemple, le concept de « contrat de magasin de clés » peut également être une solution à « l'adresse » mentionnée dans la section précédente : si nous voulons que les utilisateurs aient des adresses persistantes qui ne changent pas à chaque fois qu'ils mettent à jour leurs clés, nous pouvons mettre la furtivité La méta-adresse, la clé de cryptage 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 à jour
L'utilisation de l'ENS coûte cher. Bien qu'il ne soit pas aussi cher qu'avant en juin 2023, les frais de transaction pour l'enregistrement d'un nom de domaine sont encore relativement élevés, ce qui est comparable au coût d'un nom de domaine ENS. Par exemple, il en coûte environ 27 $ pour s'inscrire sur zuzalu.eth, dont 11 $ de frais de transaction. Mais si le marché redevient haussier, les frais monteront en flèche. Même si le prix de l'ETH n'augmente pas, si les frais de gaz reviennent à 200 gwei, les frais de transaction pour l'enregistrement du nom de domaine atteindront 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 peuvent fournir aux utilisateurs des sous-domaines), nous avons besoin que ENS soit utilisé sur Couche 2.
Heureusement, l'équipe ENS s'est déjà renforcée et ENS est en cours d'implémentation sur la couche 2 ! ERC-3668 (également connu sous le nom de "norme CCIP") et ENSIP-10 fournissent un moyen de vérifier automatiquement les sous-domaines ENS sur n'importe quelle couche 2. La norme CCIP impose la mise en place d'un contrat intelligent qui décrit la méthode de vérification des preuves de données sur la couche 2, et un nom de domaine (par exemple, ecc.eth pour Optinames) peut être placé sous le contrôle d'un tel contrat. Une fois que le contrat CCIP contrôle ecc.eth sur L1, l'accès à un certain sous-domaine.ecc.eth trouvera et vérifiera automatiquement une preuve stockant l'état de la couche 2 de ce sous-domaine spécifique (par exemple, une succursale Merkle).
**L'effort CCIP de l'ENS est une réussite et doit être considéré comme un signe que les réformes radicales dont nous avons besoin sont réellement possibles. ** Mais il reste encore de nombreuses réformes au niveau de l'application qui doivent être faites. Voici quelques exemples:
Les portefeuilles devront protéger les actifs et les données
Actuellement, la mission du portefeuille est de protéger les actifs. Tout est stocké en chaîne, tout ce que le portefeuille doit protéger, ce sont les clés privées qui sécurisent actuellement ces actifs. Si vous modifiez la clé, vous pouvez publier en toute sécurité la clé privée précédente sur Internet le jour suivant. Cependant, dans un monde sans connaissance, ce n'est plus le cas : les portefeuilles ne se contentent pas de protéger les identifiants d'authentification, ils contiennent également vos données.
Nous voyons les premiers signes d'un tel monde à Zuzalu avec Zupass, un système d'identité basé sur ZK-SNARK. L'utilisateur dispose d'une clé privée qui est utilisée pour s'authentifier dans le système, qui peut être utilisée pour générer des preuves de base telles que "prouver que je suis un résident de Zuzalu sans révéler de quel résident je suis". Le système Zupass a également commencé à créer d'autres applications, notamment des timbres (version Zupass de POAP).
*Un de mes nombreux tampons Zupass confirmant que je suis membre de Team Cat. *
La principale caractéristique des tampons relatifs au POAP est qu'ils sont privés : vous conservez les données localement et ne prouvez un tampon à leur ZK (ou effectuez des calculs sur les tampons) que si vous souhaitez donner cette information à quelqu'un. Mais cela comporte également un risque supplémentaire : si vous perdez ces informations, vous perdrez vos tampons.
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 (même en 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 cryptage, de sorte qu'aucune interaction avec le système détenant la clé de cryptage n'est requise. Mais même dans ce cas, si vous perdez la clé de cryptage, vous perdez toutes vos données. Et, à son tour, si quelqu'un voit votre clé de cryptage, il pourra 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 en utilisant le partage de clés pour répartir le stockage de clés entre plusieurs protecteurs.
La récupération sociale via MPC n'est pas une solution adéquate pour les portefeuilles, car cela signifie que non seulement le protecteur actuel, mais aussi les protecteurs précédents pourraient s'entendre pour voler vos actifs, ce qui représente un risque inacceptable. Bien qu'une violation de la vie privée soit généralement moins risquée qu'une perte complète d'actifs, pour les cas d'utilisation avec des besoins de confidentialité élevés, un risque de perte plus élevé peut être accepté en ne sauvegardant pas les clés associées à ces besoins de confidentialité.
Pour éviter d'enliser les utilisateurs dans un système complexe de plusieurs chemins de récupération, les portefeuilles prenant en charge la récupération sociale peuvent avoir besoin de gérer à la fois les aspects de la récupération des actifs et de la récupération des clés de chiffrement.
Retour à l'identité
Un thème commun à ces changements est que le concept d'"adresse" en tant que représentation de l'identité sur la blockchain devra changer fondamentalement. ** "Instructions sur la façon d'interagir avec moi" ne sera plus seulement une adresse ETH ; express. **
L'une de ces façons consiste à utiliser ENS comme identité : votre dossier ENS peut contenir toutes les informations sur la façon de payer et d'interagir avec vous, si vous envoyez à quelqu'un bob.eth (ou bob.ecc.eth etc.), il peut se renseigner et découvrez tout ce qui interagit avec vous, y compris de manière plus complexe à travers les domaines et avec la protection de la vie privée.
Cependant, cette approche centrée sur l'ENS souffre de deux faiblesses :
Une solution possible consiste à mettre plus de contenu dans le contrat de magasin de clés mentionné précédemment dans l'architecture de cet article. Un contrat de magasin de clés peut contenir diverses informations sur vous et vos interactions avec vous (et avec CCIP, certaines de ces informations peuvent être hors chaîne), les utilisateurs utiliseront leur contrat de magasin de clés comme identifiant principal. Cependant, les actifs qu'ils reçoivent réellement seront stockés dans une variété d'endroits différents. Les contrats de magasin de clés sont indépendants du nom et acceptent les noms virtuels : vous pouvez générer une adresse qui ne peut être initialisée que par un contrat de magasin de clés avec certains paramètres initiaux fixes.
Une autre classe de solutions consiste à abandonner complètement la notion d'adresses destinées aux utilisateurs, similaire au protocole de paiement de Bitcoin. Une idée est de s'appuyer davantage sur des canaux de communication directs entre l'expéditeur et le destinataire ; par exemple, l'expéditeur pourrait envoyer un lien de demande (sous forme d'URL explicite ou de code QR), que le destinataire pourrait utiliser pour envoyer toute demande qu'il souhaite accepter. paiement.
Que ce soit l'expéditeur ou le destinataire qui agisse en premier, s'appuyer davantage sur les portefeuilles pour générer des informations de paiement à jour en temps réel réduit les frictions. Cependant, les identifiants persistants sont pratiques (en particulier avec ENS), alors qu'en pratique, s'appuyer sur une communication directe entre l'expéditeur et le destinataire est un problème très délicat, de sorte qu'une combinaison de différentes techniques peut être observée.
Dans toutes ces conceptions, il est essentiel de rester décentralisé et compréhensible pour les utilisateurs. Nous devons nous assurer que les utilisateurs peuvent facilement accéder à une vue à jour de leurs actifs actuels et des messages qui leur sont destinés. Ces vues doivent s'appuyer sur des outils ouverts plutôt que sur des solutions propriétaires. Il faudra travailler dur pour empêcher la plus grande complexité de l'infrastructure de paiement de devenir une « tour d'abstraction » opaque, difficile à comprendre et à adapter aux nouveaux environnements. 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.