Mise à niveau Pectra d'Ethereum et EIP-7702 : une étape importante pour flouter les distinctions entre les comptes EOA et les comptes de contrat.

Introduction

Ethereum va bientôt accueillir la mise à niveau Pectra, qui est une mise à jour significative, avec de nombreuses propositions d'amélioration importantes d'Ethereum qui seront introduites. Parmi celles-ci, l'EIP-7702 a effectué une transformation révolutionnaire sur le compte externe Ethereum (EOA). Cette proposition floute les frontières entre EOA et le compte de contrat CA, ce qui représente une étape clé vers l'abstraction de compte natif, après l'EIP-4337, apportant un nouveau mode 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, discutera des opportunités et des défis qu'il pourrait apporter, et fournira des guides pratiques pour les différents participants.

Analyse du protocole

Aperçu

EIP-7702 introduit un tout nouveau type de transaction, permettant à un EOA de spécifier une adresse de contrat intelligent pour y définir du code. Cela permet à l'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 une programmabilité et une combinabilité, permettant aux utilisateurs de réaliser des fonctions telles que la récupération sociale, le contrôle d'accès, la gestion multi-signatures, la vérification zk, les paiements par abonnement, le parrainage de transactions et le traitement par lot des transactions. EIP-7702 est parfaitement compatible avec le portefeuille de contrat intelligent réalisé par EIP-4337, l'intégration fluide des deux simplifiant considérablement le développement et l'application de nouvelles fonctionnalités.

EIP-7702 a introduit le 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, à part le champ authorization_list, les autres suivent la même sémantique que l'EIP-4844. Ce champ est de type liste et peut contenir plusieurs entrées d'autorisation, chaque entrée d'autorisation contenant :

• chain_id: La chaîne sur laquelle cette autorisation est valable.
• adresse: l'adresse cible déléguée
• nonce : doit correspondre au nonce du compte autorisé actuel
• y_parity, r, s: compte autorisé pour signer les données de signature autorisées

Le champ authorization_list d'une transaction peut contenir plusieurs comptes autorisés différents signés par (EOA). Le initiateur de la transaction peut être différent de l'autorisé, permettant ainsi au payeur de gaz d'effectuer des opérations d'autorisation pour l'autorisé.

réaliser

Lorsqu'un autorisateur signe des données d'autorisation, il doit d'abord effectuer un encodage RLP de chain_id, address et nonce. Ensuite, les données encodées sont combinées avec MAGIC pour effectuer un hachage keccak256, obtenant ainsi les données à signer. Enfin, la clé privée de l'autorisateur est utilisée pour signer les données hachées, obtenant les données y_parity, r, s. MAGIC (0x05) est utilisé comme séparateur de domaine pour garantir que les résultats de différents types de signatures ne produisent pas de conflits.

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 exactement à ).

Après que le donneur d'autorisation ait signé les données d'autorisation, l'initiateur de la transaction les regroupe dans le champ authorization_list pour les signer et les diffuser via RPC. Avant que la transaction ne soit incluse dans un bloc et exécutée, le Proposer effectue d'abord une pré-vérification de la transaction, en vérifiant de manière contraignante l'adresse to pour s'assurer que cette transaction n'est pas une transaction de création de contrat, c'est-à-dire que lorsque l'on envoie une transaction de type EIP-7702, l'adresse to de la transaction ne peut pas être vide.

En même temps, 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 augmentera d'abord la valeur du nonce de l'initiateur de la transaction, puis effectuera l'opération applyAuthorization sur chaque entrée d'autorisation dans la authorization_list. Dans l'opération applyAuthorization, le nœud vérifiera d'abord le nonce de l'autorisateur, puis augmentera 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.

Lorsqu'un nœud applique un élément d'autorisation, s'il rencontre une erreur, cet élément d'autorisation sera ignoré, la transaction ne échouera pas, et les autres éléments d'autorisation continueront d'être appliqués, afin de garantir qu'il n'y ait pas de risque de DoS dans des scénarios d'autorisation en masse.

Après l'achèvement de l'application d'autorisation, le champ code de l'adresse de l'autorisateur sera réglé sur 0xef0100 || address, où 0xef0100 est un identifiant fixe et address est l'adresse cible déléguée. En raison des restrictions de l'EIP-3541, les utilisateurs ne peuvent pas déployer de code de contrat commençant par des octets 0xef par des moyens conventionnels, ce qui garantit que ce type d'identifiant ne peut être déployé que par des transactions de type SET_CODE_TX_TYPE ( 0x04).

Après 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 plus proche de l'abstraction native de compte ( Native AA ), réduisant considérablement le seuil d'utilisation pour les utilisateurs.

Meilleures pratiques

Bien que l'EIP-7702 ait injecté une nouvelle vitalité dans l'écosystème Ethereum, de nouveaux cas d'utilisation peuvent également entraîner de nouveaux risques. Voici les aspects auxquels les participants de l'écosystème doivent faire attention dans leur pratique :

stockage de clé privée

Bien que l'EOA puisse résoudre les problèmes de perte de fonds dus à la perte de clé privée grâce à des moyens tels que la récupération sociale intégrée dans les contrats intelligents après avoir délégué, il ne peut toujours pas éviter le risque de fuite de la clé privée de l'EOA. Il est important de préciser qu'après avoir exécuté la délégation, la clé privée de l'EOA conserve le contrôle maximal sur le compte ; détenir la clé privée permet de 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 délégué l'EOA, cela ne peut pas éliminer complètement le risque de fuite de la clé privée, surtout 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é, il est toujours important de prioriser la protection de la clé privée et de garder à l'esprit : Not your keys, not your coins.

Multi-chaînes de rediffusion

Lors de la signature de l'autorisation de délégation, l'utilisateur peut choisir la chaîne sur laquelle la délégation peut prendre effet en utilisant le chainId, ou choisir d'utiliser un chainId égal à 0 pour que la délégation puisse être reproduite et prendre effet sur plusieurs chaînes, ce qui permet à l'utilisateur de déléguer sur plusieurs chaînes avec une seule signature. Cependant, il convient de noter que le même adresse de contrat sur plusieurs chaînes peut également avoir des codes d'implémentation différents.

Pour les fournisseurs de services de portefeuille, lors de la délégation par l'utilisateur, il convient de vérifier si la chaîne d'effet de la délégation correspond au réseau actuellement connecté et d'avertir l'utilisateur des risques potentiels liés à la signature d'une délégation avec un chainId de 0.

Les utilisateurs doivent également garder à l'esprit que, pour une même adresse de contrat sur différentes chaînes, le code du contrat n'est pas toujours le même, et il est important de bien comprendre l'objectif de la délégation.

impossible à initialiser

Les portefeuilles de contrat intelligent dominants actuels utilisent principalement un modèle proxy. Lors du déploiement, le proxy du portefeuille appelle la fonction d'initialisation du contrat via DELEGateCALL, permettant ainsi une opération atomique d'initialisation du portefeuille et de déploiement du portefeuille proxy, évitant ainsi le problème d'une initialisation anticipée. Cependant, lorsque les utilisateurs utilisent EIP-7702 pour déléguer, seul le champ code de leur adresse sera mis à jour, sans pouvoir initier l'adresse déléguée. Cela signifie qu'EIP-7702 ne peut pas appeler la fonction d'initialisation pour initialiser le portefeuille dans la transaction de déploiement du contrat, comme le fait un contrat proxy ERC-1967 classique.

Pour les développeurs, lors de la combinaison et de l'adaptation de l'EIP-7702 avec le portefeuille existant EIP-4337, il convient de prêter attention à la vérification des autorisations dans les opérations d'initialisation du portefeuille (, par exemple en vérifiant les autorisations en restaurant l'adresse de signature via ecrecover ), 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 être amenés à redéléguer vers différentes adresses de contrats pour des raisons telles que des changements de besoins fonctionnels ou des mises à jour de portefeuille. Cependant, la structure de stockage des différents contrats peut varier(. Par exemple, le slot0 de différents contrats peut représenter différents types de données). En cas de redélégation, cela pourrait entraîner une réutilisation accidentelle des données de l'ancien contrat par le nouveau contrat, ce qui pourrait entraîner des conséquences indésirables telles que le verrouillage du compte et la perte de fonds.

Les utilisateurs doivent traiter avec prudence la situation de la délégation de leurs fonds.

Pour les développeurs, il est important de suivre la Namespace Formula proposée par l'ERC-7201 lors du processus de développement, en attribuant des variables à des emplacements de stockage indépendants désignés, afin de réduire le risque de conflit de stockage. De plus, l'ERC-7779 (draft) a également fourni un processus standard de réattribution spécifiquement pour l'EIP-7702 : cela inclut l'utilisation de l'ERC-7201 pour éviter les conflits de stockage, la vérification de la compatibilité de stockage avant la réattribution, ainsi que l'appel à l'interface de l'ancienne attribution pour nettoyer les anciennes données de stockage.

recharge fictif

Après avoir passé une commande, l'EOA pourra également être utilisé comme un contrat intelligent, donc l'échange (CEX) pourrait faire face à une généralisation des dépôts via contrats intelligents.

CEX doit vérifier l'état de chaque transaction de recharge via trace, pour prévenir le risque de fausse recharge par contrat intelligent.

conversion de compte

Après la mise en œuvre de la délégation EIP-7702, le type de compte de l'utilisateur peut être librement converti entre EOA et SC, ce qui permet au compte d'initier des transactions et d'ê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 les projets participant à EOA.

Pour les développeurs de contrats, supposer que tx.origin est toujours un EOA ne sera plus viable. De même, la vérification par msg.sender == tx.origin pour se défendre contre les attaques de réentrées ne sera plus efficace.

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

compatibilité des contrats

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

Pour les développeurs, le contrat cible délégué par l'utilisateur devrait mettre en œuvre les fonctions de rappel correspondantes afin de garantir la compatibilité avec les jetons principaux.

vérification de phishing

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

Pour les fournisseurs de services de portefeuille, il est particulièrement important de prendre en charge rapidement les transactions de type EIP-7702. De plus, lors de la signature par délégation des utilisateurs, il convient de mettre en avant le contrat cible de la délégation afin de réduire le risque de phishing auquel les utilisateurs pourraient être exposés.

De plus, une analyse automatique plus approfondie des contrats cibles de compte délégué, comme l'analyse de code source et les vérifications de permissions, peut mieux aider les utilisateurs à éviter de tels risques.

Résumé

Cet article explore la proposition EIP-7702 dans la prochaine mise à niveau Pectra d'Ethereum. EIP-7702 introduit de nouveaux types de transactions, permettant aux EOA d’avoir de la programmabilité et de la composition, brouillant 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 de type EIP-7702 testée en conditions réelles, 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 la pratique. Les meilleures pratiques décrites dans cet article ne peuvent pas couvrir tous les risques potentiels, mais elles valent tout de même la peine d'être prises en compte par toutes les parties dans les opérations réelles.