Mise à niveau Pectra d'Ethereum : 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, avec l'introduction de plusieurs propositions d'amélioration importantes pour Ethereum. Parmi celles-ci, l'EIP-7702 a effectué une transformation révolutionnaire des comptes externes Ethereum (EOA). Cette proposition floute 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 un tout nouveau mode 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 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 de protocole

Aperçu

EIP-7702 introduit un tout nouveau type de transaction qui permet à un EOA de spécifier une adresse de contrat intelligent, et ainsi de définir du code pour celui-ci. De cette manière, l'EOA peut exécuter du code comme un contrat intelligent, tout en conservant la capacité d'initier des transactions. Cette caractéristique confère à l'EOA la programmabilité et la combinabilité, permettant aux utilisateurs de réaliser des fonctions telles que la récupération sociale, le contrôle des accès, la gestion multi-signatures, la vérification zk, le paiement 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 grâce à EIP-4337, l'intégration transparente des deux simplifiant considérablement le processus de développement et d'application des nouvelles fonctionnalités.

La mise en œuvre spécifique de l'EIP-7702 consiste à introduire 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, à part le champ authorization_list, les autres suivent la même sémantique que l'EIP-4844. Ce champ est de type liste, la liste peut contenir plusieurs entrées d'autorisation, et dans chaque entrée d'autorisation :

• Le champ chain_id indique la chaîne sur laquelle cette délégation d'autorisation est effective.
• Le champ d'adresse représente l'adresse cible de la délégation
• Le champ nonce doit correspondre au nonce du compte autorisé actuel
• les champs y_parity, r, s sont les données de signature autorisées signées par le compte autorisé.

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

réalisation

Lors de la signature des données d'autorisation, le donneur d'autorisation 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, afin d'obtenir les données à signer. Enfin, le donneur d'autorisation utilise sa clé privée pour signer les données hachées, obtenant ainsi les données y_parity, r, s. Parmi eux, MAGIC (0x05) est utilisé comme séparateur de domaine, son objectif étant de garantir qu'il n'y ait pas de conflit dans les résultats de signatures de différents types.

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

Lorsque 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 les diffuse par RPC. Avant que la transaction ne soit exécutée dans un bloc, le Proposer effectue d'abord un précontrôle de la transaction, en vérifiant de manière stricte l'adresse to 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.

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

Ensuite, lors 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 sur chaque entrée d'autorisation dans 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 nonce devrait être augmentée de 1 lors de la signature de la transaction d'autorisation.

Lorsqu'un nœud applique un élément d'autorisation, si une erreur se produit, cet élément d'autorisation sera ignoré, la transaction ne échouera pas et les autres éléments d'autorisation continueront à être appliqués, afin de garantir 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 autorisée, 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 du mandat. 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 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).

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 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), ce qui réduit 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 être attentifs dans le cadre de leur pratique :

stockage de clé privée

Bien que l'EOA puisse, après délégation, 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, il ne peut toujours pas éviter le risque de divulgation 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 maximum sur le compte, et détenir la clé privée permet de disposer librement des actifs du compte. Même si l'utilisateur ou le fournisseur de services de portefeuille supprime complètement la clé privée stockée localement après avoir réalisé la délégation pour l'EOA, cela ne peut pas complètement éliminer le risque de divulgation de la clé privée, en particulier dans les scénarios où il existe un risque d'attaque par chaîne d'approvisionnement.

Pour les utilisateurs, lors de l'utilisation de leur compte après avoir effectué une délégation, ils doivent toujours donner la priorité à la protection de leur clé privée et garder à l'esprit : Not your keys, not your coins.

Multi-chaînes de rediffusion

Lors de la signature d'une autorisation de délégation, l'utilisateur peut choisir la chaîne sur laquelle la délégation peut être effective via le chainId. Bien sûr, l'utilisateur peut également choisir d'utiliser un chainId de 0 pour la délégation, ce qui permet à 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, sur le même adresse de contrat dans 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 est conforme au réseau actuellement connecté, et d'avertir les utilisateurs des risques potentiels liés à la signature d'une délégation avec un chainId égal à 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 important de bien comprendre l'objectif de la délégation.

impossible à initialiser

La plupart des portefeuilles de contrats intelligents courants utilisent un modèle de proxy. Lors du déploiement, le proxy 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 proxy, évitant ainsi le problème d'initialisation prématurée. Cependant, lorsque l'utilisateur utilise EIP-7702 pour déléguer, il ne mettra à jour que le champ code de son adresse, ne pouvant pas initialiser en appelant l'adresse déléguée. Cela fait que EIP-7702 ne peut pas appeler la fonction d'initialisation pour initier le portefeuille dans la transaction de déploiement du contrat, comme le font les contrats proxy ERC-1967 courants.

Pour les développeurs, lors de la combinaison de l'EIP-7702 avec les portefeuilles existants de l'EIP-4337, il est important d'effectuer une vérification des autorisations dans l'opération d'initialisation du portefeuille (, par exemple en utilisant ecrecover pour récupérer l'adresse de signature afin de procéder à la vérification des autorisations ), 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, en raison de changements de besoins fonctionnels ou de mises à niveau de portefeuille, avoir besoin de se déléguer à une adresse de contrat différente. Cependant, la structure de stockage des différents contrats peut présenter des différences, par exemple, le slot0 de différents contrats peut représenter différents types de données. Dans le cas d'une nouvelle délégation, cela peut entraîner la réutilisation accidentelle des données de l'ancien contrat par le nouveau contrat, ce qui pourrait provoquer un verrouillage de compte, une perte de fonds et d'autres conséquences indésirables.

Pour les utilisateurs, il convient de traiter avec prudence les situations de rédelegation.

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

( Rechargement fictif

Après avoir effectué un ordre, l'EOA pourra également être utilisé comme un contrat intelligent. Par conséquent, les échanges centralisés )CEX### pourraient faire face à une généralisation des recharges par contrat intelligent.

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

( 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 au compte d'initier des transactions ainsi que d'être appelé. Cela signifie que lorsque le compte s'appelle lui-même et effectue des appels externes, son msg.sender sera également tx.origin, ce qui brisera certaines hypothèses de sécurité réservées aux projets impliquant uniquement des 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 devraient supposer que les futurs participants peuvent tous être des contrats intelligents durant le processus de développement.

) compatibilité des contrats

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

Pour les développeurs, les contrats cibles délégués par les utilisateurs devraient mettre en œuvre les fonctions de rappel appropriées pour garantir la compatibilité avec les jetons principaux.

Vérification de la pêche

Après la mise en œuvre de la délégation EIP-7702, les actifs dans le compte de l'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 déléguée par les utilisateurs, il convient de mettre en avant le contrat cible délégué pour atténuer le risque d'attaques de phishing auxquelles les utilisateurs pourraient être confrontés.

De plus, une analyse automatique plus approfondie des contrats cibles de la délégation de compte, y compris l'examen open source et la vérification des autorisations, 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, en introduisant de nouveaux types de transactions, permet aux EOA d'avoir une programmabilité et une modularité, floutant ainsi la frontière entre les EOA et les comptes de contrat. Étant donné qu'il n'existe actuellement aucun standard de contrat intelligent compatible avec le type EIP-7702 ayant été éprouvé en pratique, différents participants à l'écosystème, tels que les utilisateurs, les fournisseurs de services de portefeuille, les développeurs, les CEX, etc., rencontrent de nombreux défis et opportunités dans les applications pratiques. Les meilleures pratiques décrites dans cet article ne peuvent couvrir tous les risques potentiels, mais elles méritent néanmoins d'être prises en compte et appliquées par toutes les parties lors de l'opération réelle.