Auteur original : Jarrod Watts
Compilation originale : Frank, Foresight News
La dernière proposition EIP-7702 de Vitalik Buterin pourrait être l’un des changements les plus marquants de l’histoire d’Ethereum. Cet article présentera le fonctionnement de cette nouvelle proposition et tout ce que vous devez savoir pour la mettre en œuvre.
Premièrement, la nouvelle proposition EIP-7702 est étonnamment courte, ce qui laisse certaines personnes perplexes quant à son fonctionnement réel. Afin de comprendre la proposition 7702, nous devons d'abord comprendre les trois autres propositions qui y sont mentionnées :
EIP-4337
EIP-3074
EIP-5003
Commençons par l'objectif commun de toutes ces propositions, "l'abstraction de compte" - EOA (les comptes "ordinaires") sur Ethereum sont terribles, ils sont risqués et ont des fonctionnalités très limitées, tandis que l'abstraction de compte permet aux utilisateurs d'utiliser des contrats intelligents comme compte pour ajouter plus de fonctionnalités et de sécurité pour résoudre ce problème.
EIP-4337
EIP-4337, qui a été mis en ligne sur le réseau principal en mars 2023, permet d'écrire des contrats intelligents comme des comptes afin qu'ils puissent vérifier et exécuter des transactions, ce qui améliore de nombreuses expériences utilisateur (UX).
Depuis sa sortie, EIP-4337 a été largement adopté, principalement par Polygon, tandis que Base a connu une activité accrue au cours des derniers mois.
La dernière innovation liée à l'EIP-4337 provient de l'écosystème Coinbase et du Coinbase Smart Wallet, qui est basé sur la technologie biométrique et offre une excellente expérience utilisateur. J'ai créé une autre petite démo à l'ETH Global Sydney le week-end dernier pour le démontrer.
Alors, quel est le problème avec l'EIP-4337 ? Pourquoi une autre proposition de résumé de compte aujourd’hui ? Parce que l’EOA reste de loin le type de compte le plus utilisé.
En plus de cela, la plupart des comptes de contrat intelligent EIP-4337 sont contrôlés par un seul signataire EOA. Voici l'exemple de code :
Parce qu'il n'y a aucun moyen de "convertir" l'EOA de l'utilisateur en compte de contrat intelligent, il existe cette étrange solution intermédiaire - principalement en raison du manque de prise en charge native de la connexion des comptes de contrat intelligents dans les applications Web3, la plupart des gens utilisent encore aujourd'hui plug -dans des portefeuilles tels que MetaMask Utilisez EOA.
EIP-3074
Cela nous amène à notre prochaine proposition : EIP-3074.
En fait, cette proposition a été faite avant l'EIP-4337, mais elle n'a pas encore été fusionnée dans les tentatives du réseau principal EIP-3074 pour donner plus de pouvoir à l'EOA, leur permettant de déléguer le contrôle de leur EOA aux contrats intelligents.
La proposition décrit ce qui suit, en ajoutant deux nouveaux opcodes :
AUTH : un EOA peut appeler AUTH pour autoriser un contrat intelligent donné à effectuer des opérations au nom de son EOA ;
AUTHCALL : les contrats intelligents autorisés peuvent utiliser AUTHCALL pour exécuter des transactions pour l'EOA ;
Cela permet bon nombre des mêmes cas d'utilisation qu'EIP-4337 sans obliger chaque utilisateur à déployer un nouveau contrat intelligent. Une différence clé est que la transaction provient de l'EOA de l'utilisateur, plutôt que d'un nouveau contrat sans aucun historique du compte de l'utilisateur, ETH, NFT, jetons, etc.
Une réponse courante à l'EIP-3074 est « Et si quelqu'un conclut un contrat malveillant et qu'un utilisateur lui délègue ? Après tout, déléguer à un contrat malveillant pourrait entraîner l'épuisement de tous les actifs cryptographiques du portefeuille de l'utilisateur.
La solution à ce problème est que le fournisseur de services de portefeuille n'autorise même pas les utilisateurs à autoriser un contrat, il peut conserver une liste blanche de contrats intelligents auxquels les utilisateurs peuvent déléguer l'autorisation, et tout contrat en dehors de cette liste ne sera pas montré à l'utilisateur.
Un point clé de la délégation EIP-3074 est que la délégation n'est pas permanente. "Une seule transaction d'EOA entraînera une augmentation du nonce, invalidant ainsi l'autorisation inachevée."
Essentiellement, une fois que l’utilisateur a effectué une nouvelle transaction, la commande n’est plus valide.
EIP-5003
Nous ne voulons pas non plus donner plus de pouvoir à l’EOA. Après tout, l'objectif de ces propositions est de déplacer les utilisateurs d'EOA vers des comptes de contrats intelligents, alors pourquoi ajoutons-nous des fonctionnalités à EOA ?
Cela nous amène bien à notre prochaine proposition : EIP-5003. EIP-5003 ajoute un autre opcode "AUTHUSURP" qui déploie le code à l'adresse autorisée EIP-3074.
La différence entre EIP-3074 et EIP-5003 est :
EIP-3074 est une délégation temporaire au contrat intelligent et peut être révoquée ;
EIP-5003 est une migration permanente d'EOA et une « conversion » d'EOA vers un compte de contrat intelligent ;
Un gros problème avec EIP-3074 + EIP-5003 est qu'il n'est pas très compatible avec le schéma d'abstraction du compte courant via EIP-4337, donc certains membres de la communauté Ethereum craignent que nous "créions deux écosystèmes de code distincts".
EIP-7702
Cela nous amène aujourd'hui à la proposition de Vitalik Buterin : EIP-7702 - il propose de modifier EIP-3074 pour le rendre plus rationalisé et plus compatible avec EIP-4337, afin que nous ne nous retrouvions pas avec deux écosystèmes d'abstraction de comptes distincts, mais aussi Considérez EIP-5003 comme la prochaine étape de la migration permanente.
EIP-7702 propose un nouveau type de transaction qui accepte à la fois les champs contract_code et signature, qui définit le code de contrat du compte du signataire sur contract_code lors du démarrage de l'exécution de la transaction. À la fin de la transaction, il réinitialise le ticker à vide.
C'est la même chose que l'EIP-3074, qui implémente la fonction de délégation temporaire d'EOA pour les contrats intelligents. Cependant, EIP-7702 n'introduit pas de nouveaux opcodes (ce qui nécessiterait un hard fork), mais définit à la place les fonctions à appeler :
AUTH -> appeler "verify" (vérification)
AUTHCALL -> appeler "exécuter"
Concrètement, il :
Vérifiez si le code de contrat de votre compte est vide ;
S'il est vide, il est défini sur le code du contrat fourni ;
Exécuter la transaction selon la manière dont le contrat intelligent fourni gère la transaction ;
Restaurez le paramètre du code de contrat de compte à vide ;
« Code du contrat » signifie littéralement que le code du contrat intelligent est stocké dans le « code du contrat ». Puisque l’EOA en lui-même n’est pas un contrat, ce champ est généralement vide. L'avantage de l'EIP-7702, cependant, est qu'il remplit temporairement du code de contrat intelligent dans ce champ pendant l'exécution de la transaction.
C'est une façon de donner à votre EOA un nouveau comportement (sous la forme d'un ticker) pour exécuter cette transaction spécifique, l'étape suivante consiste à en faire un changement de comportement permanent, sélectionnez simplement "Ne pas définir le ticker après la clôture de la transaction" null ".
L'un des meilleurs aspects de cette proposition est qu'elle est hautement compatible avec tous les travaux d'abstraction de compte construits à ce jour pour EIP-4337, "le code de contrat que les utilisateurs doivent signer peut en fait être le code de portefeuille EIP-4337 existant".
Une fois ce changement pris en compte, les EOA existants des utilisateurs peuvent exécuter n'importe quel code de contrat intelligent. Avec un EIP supplémentaire, EOA peut également être mis à niveau de manière permanente pour exécuter un code spécifique.
Au fil du temps, cela pourrait révolutionner la façon dont nous interagissons tous avec les applications Web3.