Mise à niveau d'Ethereum Pectra : Analyse approfondie de l'EIP-7702 et guide des meilleures pratiques

Introduction

Ethereum va bientôt accueillir la mise à niveau Pectra, qui représente une mise à jour significative. Parmi celles-ci, l'EIP-7702 a apporté une transformation révolutionnaire aux comptes externes Ethereum (EOA). Cette proposition a flouté la frontière entre les EOA et les comptes de contrats CA, constituant une étape clé vers l'abstraction des comptes natifs et apportant de nouveaux modes d'interaction à l'écosystème Ethereum.

Pectra a terminé son déploiement sur le réseau de test et devrait bientôt être lancé sur le réseau principal. Cet article analysera en profondeur le mécanisme de mise en œuvre de l'EIP-7702, explorera les opportunités et les défis qu'il pourrait apporter, et fournira des guides pratiques pour différents participants.

Analyse du protocole

Aperçu

EIP-7702 introduit un nouveau type de transaction, permettant à un EOA de spécifier une adresse de contrat intelligent et d'y définir du code. Cela permet à un EOA d'exécuter du code comme un contrat intelligent tout en conservant la capacité d'initier des transactions. Cette fonctionnalité confère à l'EOA la programmabilité et la combinabilité, permettant aux utilisateurs d'implémenter des fonctionnalités telles que la récupération sociale, le contrôle des permissions, la gestion multi-signatures, la vérification zk, les paiements par abonnement, le parrainage de transactions et le traitement par lots de transactions. Il convient de noter que l'EIP-7702 est parfaitement compatible avec les portefeuilles de contrats intelligents réalisés par l'EIP-4337, simplifiant ainsi le développement et l'application de nouvelles fonctionnalités.

EIP-7702 a introduit un type de transaction SET_CODE_TX_TYPE (0x04), dont la structure de données est définie comme suit :

rlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, value, data, access_list, authorization_list, signature_y_parity, signature_r, signature_s])

Le champ authorization_list est défini comme :

authorization_list = [[chain_id, address, nonce, y_parity, r, s], ...]

Dans la nouvelle structure de transaction, à l'exception du champ authorization_list, les autres suivent la même sémantique que l'EIP-4844. authorization_list est de type liste et peut contenir plusieurs entrées d'autorisation. Chaque entrée d'autorisation contient :

• chain_id indique la chaîne sur laquelle l'autorisation de délégation prend effet.
• l'adresse indique l'adresse cible de la délégation
• le nonce doit correspondre au nonce du compte autorisé actuel
• y_parity, r, s sont les données de signature autorisées signées par le compte autorisé.

Une liste d'autorisation pour une transaction peut contenir plusieurs comptes autorisés différents. Les entrées d'autorisation signées par ( EOA permettent de réaliser le paiement des frais de gaz pour les opérations d'autorisation.

) réaliser

Lors de la signature des données d'autorisation par le donneur d'autorisation, il est nécessaire de coder d'abord chain_id, address et nonce en RLP. Ensuite, les données codées sont soumises à un calcul de hachage keccak256 avec la valeur MAGIC pour obtenir les données à signer. Enfin, le donneur d'autorisation signe les données hachées avec sa clé privée, obtenant les données y_parity, r, s. MAGIC ###0x05( est utilisé comme séparateur de domaine, garantissant que les résultats des signatures de différents types ne se chevauchent pas.

Lorsque le chain_id autorisé par le donneur d'autorisation est 0, cela signifie que le donneur d'autorisation permet la répétition de l'autorisation sur toutes les chaînes compatibles EVM prenant en charge EIP-7702 (à condition que le nonce corresponde également).

Après que le donneur d'autorisation a signé les données d'autorisation, l'initiateur de la transaction les regroupe dans le champ authorization_list pour les signer et diffuse la transaction via RPC. Avant l'exécution de la transaction, le Proposer effectue d'abord une pré-vérification pour s'assurer que cette transaction n'est pas une transaction de création de contrat, c'est-à-dire que lors de l'envoi d'une transaction de type EIP-7702, l'adresse to de la transaction ne peut pas être vide.

Ce type de transaction exige que le champ authorization_list contienne au moins un élément d'autorisation. Si plusieurs éléments d'autorisation sont signés par le même autorisateur, seul le dernier élément d'autorisation sera effectif.

Lors de l'exécution de la transaction, le nœud augmente d'abord la valeur nonce de l'initiateur de la transaction, puis effectue l'opération applyAuthorization sur chaque entrée d'autorisation dans la authorization_list. Dans l'opération applyAuthorization, le nœud vérifie d'abord le nonce de l'autorisateur, puis augmente le nonce de l'autorisateur. Cela signifie que si l'initiateur de la transaction et l'autorisateur sont le même utilisateur )EOA(, la valeur du nonce lors de la signature de la transaction d'autorisation devrait être augmentée de 1.

Lors de l'application des éléments d'autorisation des nœuds, en cas d'erreur, cet élément sera ignoré, la transaction ne échouera pas, et les autres éléments d'autorisation continueront à s'appliquer, afin d'éviter les risques de DoS dans les scénarios d'autorisation en masse.

Après l'achèvement de l'application d'autorisation, le champ code de l'adresse du donneur d'autorisation sera défini sur 0xef0100 || address, où 0xef0100 est un identifiant fixe et address est l'adresse cible déléguée. La restriction de l'EIP-3541 garantit que de tels identifiants ne peuvent être déployés que par des transactions de type SET_CODE_TX_TYPE )0x04(.

Après avoir terminé l'autorisation, si l'autorisateur souhaite retirer l'autorisation, il suffit de définir l'adresse cible déléguée sur l'adresse 0.

Le nouveau type de transaction introduit par l'EIP-7702 permet à l'autorisateur ) EOA ( d'exécuter du code comme un contrat intelligent tout en conservant la capacité d'initier des transactions. Par rapport à l'EIP-4337, cela offre aux utilisateurs une expérience beaucoup plus proche de l'abstraction de compte natif ) Native AA (, réduisant considérablement le seuil d'utilisation.

Meilleures pratiques

EIP-7702 injecte une nouvelle vitalité dans l'écosystème Ethereum, tout en apportant de nouveaux risques avec de nouveaux cas d'utilisation. Voici les aspects auxquels les participants de l'écosystème doivent faire attention dans leur pratique :

) stockage de clé privée

Même si, après avoir délégué un EOA, il est possible de résoudre les problèmes de perte de fonds dus à une clé privée perdue grâce à des moyens tels que la récupération sociale intégrée dans les contrats intelligents, il est toujours impossible d'éliminer le risque de fuite de la clé privée de l'EOA. Après avoir exécuté la délégation, la clé privée de l'EOA conserve toujours le contrôle maximal sur le compte, et celui qui détient la clé privée peut disposer librement des actifs du compte. Même si les utilisateurs ou les fournisseurs de services de portefeuille suppriment complètement la clé privée stockée localement après avoir effectué la délégation de l'EOA, ils ne peuvent pas complètement éliminer le risque de fuite de la clé privée, en particulier dans des scénarios où il existe un risque d'attaque de la chaîne d'approvisionnement.

Pour les utilisateurs, lors de l'utilisation d'un compte après avoir délégué, la protection des clés privées doit toujours être une priorité, en gardant à l'esprit : Not your keys, not your coins.

Rejeu multi-chaînes

Lors de la signature d'une autorisation de délégation, l'utilisateur peut choisir la chaîne sur laquelle la délégation prendra effet en sélectionnant le chainId, ou choisir un chainId de 0 pour effectuer la délégation, permettant ainsi à la délégation d'être reproduite sur plusieurs chaînes, facilitant ainsi la délégation sur plusieurs chaînes avec une seule signature. Cependant, il convient de noter que dans le même contrat sur plusieurs chaînes, il peut y avoir des codes d'implémentation différents.

Les fournisseurs de services de portefeuille doivent vérifier si la chaîne d'effet de la délégation correspond au réseau actuellement connecté lorsque l'utilisateur effectue une délégation, et rappeler à l'utilisateur les risques que peut entraîner la signature d'une délégation avec un chainId de 0.

Les utilisateurs doivent également noter que les adresses de contrat identiques sur différentes chaînes n'ont pas toujours le même code de contrat, il est donc nécessaire de bien comprendre l'objectif de la délégation.

Impossible d'initialiser

Les portefeuilles intelligents actuellement dominants adoptent souvent un modèle d代理. Lors du déploiement, le代理 du portefeuille appelle la fonction d'initialisation du contrat via DELEGateCALL, réalisant ainsi une opération atomique d'initialisation du portefeuille et de déploiement du portefeuille代理, évitant ainsi le problème d'initialisation anticipée. Cependant, lorsque les utilisateurs utilisent EIP-7702 pour déléguer, seule la mise à jour du champ code de leur adresse est effectuée, sans possibilité d'initialiser en appelant l'adresse déléguée. Cela fait que l'EIP-7702 ne peut pas appeler la fonction d'initialisation lors des transactions de déploiement de contrat comme c'est le cas pour les contrats代理 ERC-1967 courants.

Les développeurs doivent effectuer une vérification des autorisations (par exemple, en utilisant ecrecover pour récupérer l'adresse de signature) lors de l'initialisation du portefeuille en combinant EIP-7702 avec le portefeuille existant EIP-4337, afin d'éviter le risque que l'opération d'initialisation du portefeuille soit devancée.

Gestion de stockage

Lors de l'utilisation de la fonction de délégation EIP-7702, les utilisateurs peuvent avoir besoin de se déléguer à une adresse de contrat différente en raison de changements dans les besoins fonctionnels, de mises à jour de portefeuille, etc. Cependant, la structure de stockage des différents contrats peut varier (par exemple, le slot0 de différents contrats peut représenter des types de données différents), et la nouvelle délégation peut entraîner une réutilisation accidentelle des données de l'ancien contrat, ce qui peut entraîner des conséquences néfastes telles que le blocage du compte et des pertes de fonds.

Les utilisateurs doivent traiter avec prudence les situations de réaffectation.

Les développeurs doivent suivre la Namespace Formula proposée par l'ERC-7201 au cours du processus de développement, en attribuant des variables à des emplacements de stockage indépendants désignés pour atténuer le risque de conflits de stockage. De plus, l'ERC-7779 ###draft( fournit également un processus standard de réaffectation spécialement conçu pour l'EIP-7702 : y compris l'utilisation de l'ERC-7201 pour prévenir les conflits de stockage, et la vérification de la compatibilité du stockage avant la réaffectation, ainsi que l'appel de l'interface de l'ancienne affectation pour nettoyer les anciennes données de stockage.

) Faux rechargement

Après que l'utilisateur ait effectué un mandat, l'EOA pourra également être utilisé comme un contrat intelligent. Ainsi, les échanges centralisés ###CEX( pourraient faire face à une généralisation des dépôts via contrats intelligents.

CEX doit vérifier l'état de chaque transaction de recharge par trace, pour prévenir les risques de fausse recharge des contrats intelligents.

) Conversion de compte

Après l'implémentation de l'EIP-7702, le type de compte utilisateur peut être librement converti entre EOA et SC, le compte peut initier des transactions et être appelé. Cela signifie que lorsque le compte s'appelle lui-même et effectue un appel externe, son msg.sender sera également tx.origin, ce qui remet en question certaines hypothèses de sécurité qui ne concernent que la participation des EOA aux projets.

Les développeurs de contrats ne devraient plus supposer que tx.origin est toujours un EOA. De même, la vérification via msg.sender == tx.origin pour se protéger contre les attaques de réentrées sera également inefficace.

Les développeurs doivent supposer que les futurs participants pourraient tous être des contrats intelligents.

compatibilité des contrats

Les jetons ERC-721 et ERC-777 existants ont une fonction Hook lors du transfert de contrats, ce qui signifie que le destinataire doit implémenter la fonction de rappel correspondante pour recevoir les jetons avec succès.

Les développeurs doivent s'assurer que le contrat cible délégué par l'utilisateur implémente les fonctions de rappel appropriées pour garantir la compatibilité avec les jetons majeurs.

Vérification de la pêche

Après la mise en œuvre de EIP-7702, les actifs dans le compte utilisateur pourraient être contrôlés par des contrats intelligents. Si un utilisateur délègue son compte à un contrat malveillant, il sera facile pour l'attaquant de voler des fonds.

Les fournisseurs de services de portefeuille doivent rapidement prendre en charge les transactions de type EIP-7702 et, lors de la signature déléguée par l'utilisateur, présenter clairement le contrat cible de la délégation afin de réduire le risque que l'utilisateur soit victime d'une attaque par hameçonnage.

De plus, une analyse automatique plus approfondie des contrats cibles délégués aux comptes (vérification open source, vérification des autorisations, etc.) peut mieux aider les utilisateurs à éviter de tels risques.

Résumé

Cet article explore la proposition EIP-7702 dans la mise à niveau Pectra imminente d'Ethereum. L'EIP-7702 introduit de nouveaux types de transactions, permettant ainsi aux EOA d'avoir une programmabilité et une combinabilité, floutant ainsi la frontière entre les EOA et les comptes de contrat. Étant donné qu'il n'existe actuellement aucune norme de contrat intelligent compatible avec le type EIP-7702 éprouvée en situation réelle, les différents participants de l'écosystème, tels que les utilisateurs, les fournisseurs de services de portefeuille, les développeurs, les CEX, etc., font face à de nombreux défis et opportunités dans l'application pratique. Le contenu des meilleures pratiques exposé dans cet article ne peut pas couvrir tous les risques potentiels, mais il vaut néanmoins la peine d'être pris en compte par les différentes parties dans la pratique.