Mise à niveau d'Ethereum Pectra : les transformations et les défis apportés par l'EIP-7702

Introduction

Ethereum va bientôt accueillir la mise à jour Pectra, qui représente une mise à jour significative, avec l'introduction de plusieurs propositions d'amélioration importantes d'Ethereum. Parmi celles-ci, l'EIP-7702 a apporté une transformation révolutionnaire aux comptes externes Ethereum (EOA). Cette proposition a floué la frontière entre les EOA et les comptes de contrat CA, constituant une étape clé vers l'abstraction native des comptes après l'EIP-4337, et apportant de nouveaux modes d'interaction au sein de l'écosystème Ethereum.

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

Analyse de protocole

Aperçu

EIP-7702 a introduit un nouveau type de transaction, permettant à un EOA de spécifier une adresse de contrat intelligent et de définir son 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 programmabilité et combinaisons, permettant aux utilisateurs d'implémenter des fonctionnalités telles que la récupération sociale, le contrôle des autorisations, 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 qu'EIP-7702 est parfaitement compatible avec les portefeuilles de contrats intelligents réalisés par EIP-4337, et l'intégration transparente des deux simplifie considérablement 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 suit :

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, chacune contenant :

• chain_id indique la chaîne sur laquelle cette délégation d'autorisation est effective
• 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é

Le champ authorization_list dans une transaction peut contenir plusieurs éléments d'autorisation signés par différents comptes autorisés ( EOA ), c'est-à-dire que l'initiateur de la transaction peut être différent de l'autorisateur, permettant ainsi le paiement des frais de gaz pour les opérations d'autorisation.

réalisation

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 soumises à un calcul de hachage keccak256 avec le nombre MAGIC, obtenant ainsi les données à signer. Enfin, l'autorisateur utilise sa clé privé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 qu'il n'y a pas de conflit dans les résultats de signatures de différents types.

Il convient de noter que lorsque le chain_id autorisé par le donneur d'autorisation est 0, cela signifie que le donneur d'autorisation permet de répéter 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 ait signé les données d'autorisation, l'initiateur de la transaction va les rassembler dans le champ authorization_list pour les signer et les diffuser via RPC. Avant que la transaction ne soit exécutée et incluse dans un bloc, le Proposer effectuera d'abord une pré-vérification de la transaction, qui inclut une vérification stricte de l'adresse 'to' pour s'assurer que cette transaction n'est pas une transaction de création de contrat.

En même temps, ce type de transaction exige que le champ authorization_list contienne au moins une entrée d'autorisation. Si plusieurs entrées d'autorisation sont signées par le même autorisateur, seule la dernière entrée d'autorisation sera effective.

Au cours de l'exécution de la transaction, le nœud augmentera d'abord la valeur nonce de l'initiateur de la transaction, puis effectuera l'opération applyAuthorization pour chaque entrée d'autorisation dans authorization_list. Lors de 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 devrait être augmentée de 1 lors de la signature de la transaction d'autorisation.

Lorsqu'un nœud applique un certain élément d'autorisation, si une erreur se produit, cet élément d'autorisation sera ignoré, la transaction ne sera pas échouée, et les autres éléments d'autorisation continueront d'être appliqués, garantissant ainsi qu'il n'y a pas de risque 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 de l'autorisateur sera défini sur 0xef0100 || address, où 0xef0100 est un identifiant fixe et address est l'adresse cible déléguée. En raison des limitations de l'EIP-3541, les utilisateurs ne peuvent pas déployer de code de contrat commençant par les octets 0xef de manière conventionnelle, ce qui garantit que de tels identifiants ne peuvent être déployés que par des transactions de type SET_CODE_TX_TYPE ( 0x04).

Une fois l'autorisation terminée, si l'autorisateur souhaite retirer l'autorisation, il lui suffit de définir l'adresse cible de la délégation 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 pour les utilisateurs.

Meilleures pratiques

Bien que l'EIP-7702 ait insufflé une nouvelle vitalité à 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 prêter attention dans la pratique :

stockage de la clé privée

Bien que l'EOA puisse résoudre les problèmes de perte de fonds dus à la perte de la clé privée grâce à des moyens tels que la récupération sociale intégrée dans les contrats intelligents, 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 l'exécution de la délégation, la clé privée de l'EOA conserve le contrôle maximal sur le compte, et qu'avoir 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 terminé la délégation pour l'EOA, cela ne peut pas éliminer totalement le risque de fuite de la clé privée, surtout dans des scénarios exposés au risque d'attaques de la chaîne d'approvisionnement.

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

replays multi-chaînes

L'utilisateur, lors de la signature d'une autorisation de délégation, peut choisir la chaîne sur laquelle la délégation peut être effective en utilisant le chainId, ou choisir d'utiliser le chainId 0 pour déléguer, permettant ainsi à la délégation d'être reproduite et effective sur plusieurs chaînes, ce qui facilite la délégation avec une seule signature. Cependant, il est important de noter que dans le même adresse de contrat sur plusieurs chaînes, il peut également exister différents codes d'implémentation.

Pour les fournisseurs de services de portefeuille, lors de la délégation par les utilisateurs, il convient de vérifier si la chaîne de délégation en vigueur correspond au réseau actuellement connecté et d'avertir les utilisateurs des risques pouvant découler de 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 ne contiennent pas toujours le même code de contrat, il est donc important de bien comprendre l'objectif de la délégation.

impossible à initialiser

La plupart des portefeuilles de contrats intelligents actuellement populaires adoptent un modèle d代理. Lors du déploiement, le portefeuille代理 appelle la fonction d'initialisation du contrat via DELEGateCALL pour réaliser une opération atomique d'initialisation du portefeuille et de déploiement du portefeuille代理, évitant ainsi les problèmes d'initialisation prématurée. Cependant, lorsque les utilisateurs utilisent EIP-7702 pour déléguer, seuls le champ code de leur adresse est mis à jour, et il n'est pas possible d'initialiser en appelant l'adresse déléguée. Cela empêche EIP-7702 d'appeler la fonction d'initialisation pour l'initialisation du portefeuille dans la transaction de déploiement du contrat, comme le font les contrats代理 ERC-1967 courants.

Pour les développeurs, lors de la combinaison de l'EIP-7702 avec un portefeuille EIP-4337 existant, une vérification des autorisations doit être effectuée lors de l'initialisation du portefeuille (par exemple, en utilisant ecrecover pour récupérer l'adresse de signature pour la vérification des autorisations), afin d'éviter le risque que l'opération d'initialisation du portefeuille soit devancée.

Gestion de stockage

Lorsque les utilisateurs utilisent la fonction de délégation EIP-7702, ils peuvent avoir besoin de redéléguer vers 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 différents types de données). Dans le cas d'une redélégation, cela peut entraîner une réutilisation involontaire des données de l'ancien contrat par le nouveau contrat, ce qui peut provoquer des conséquences néfastes telles que le blocage de comptes ou la perte de fonds.

Pour les utilisateurs, il est important de traiter avec prudence la situation de la délégation de nouveau.

Pour les développeurs, il est conseillé de suivre la Namespace Formula proposée par l'ERC-7201 lors du développement, en allouant des variables à des emplacements de stockage indépendants désignés, afin d'atténuer le risque de conflits de stockage. De plus, l'ERC-7779 (draft) a également fourni un processus standard de réaffectation spécifiquement 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é de 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 avoir effectué une délégation, l'EOA pourra également être utilisé comme un contrat intelligent, donc certaines bourses pourraient faire face à une généralisation des dépôts via des contrats intelligents.

L'échange doit vérifier l'état de chaque transaction de recharge via trace pour prévenir le risque de fausse recharge des contrats intelligents.

Conversion de compte

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

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 devraient supposer que les futurs participants pourraient tous être des contrats intelligents.

compatibilité des contrats

Les jetons ERC-721 et ERC-777 existants possèdent une fonction Hook lors des transferts de contrats, 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 implémenter les fonctions de rappel appropriées pour garantir la compatibilité avec les principaux jetons.

Vérification de phishing

Après avoir mis en œuvre la délégation EIP-7702, les actifs du 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 alors 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 déléguée par les utilisateurs, il est essentiel de mettre en avant le contrat cible délégué pour atténuer le risque de phishing auquel les utilisateurs pourraient être confrontés.

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

Résumé

Cet article traite de la proposition EIP-7702 dans la mise à niveau Pectra imminente d'Ethereum. EIP-7702 introduit de nouveaux types de transactions, permettant aux EOA d'avoir des capacités programmables et composables, brouillant ainsi la frontière entre EOA et comptes de contrat. Étant donné qu'il n'existe actuellement pas de norme de contrat intelligent compatible avec le type EIP-7702 éprouvée sur le terrain, différents participants de l'écosystème, tels que les utilisateurs, les prestataires de services de portefeuille, les développeurs, les échanges, etc., sont confrontés à de nombreux défis et opportunités dans la pratique. Les meilleures pratiques décrites dans cet article ne peuvent couvrir tous les risques potentiels, mais elles méritent d'être considérées et appliquées par toutes les parties dans leurs opérations réelles.