Ethereum Pectra en cours de mise à niveau EIP-7702 : une transformation majeure pour habiliter les EOA

Introduction

Ethereum va bientôt accueillir la mise à niveau Pectra, une mise à jour significative. Parmi celles-ci, l'EIP-7702 a apporté une transformation révolutionnaire aux comptes externes d'Ethereum (EOA). Cette proposition brouille la frontière entre EOA et le compte de contrat CA, représentant une étape clé vers l'abstraction des comptes natifs, après l'EIP-4337, et introduit de nouveaux modes d'interaction dans 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, explorera les opportunités et les 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, et ainsi de lui attribuer du code. Ce faisant, 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 une programmabilité et une combinabilité, permettant aux utilisateurs d'implémenter des fonctionnalités telles que la récupération sociale, le contrôle des permissions, la gestion des signatures multiples, la vérification zk, les paiements par abonnement, le parrainage de transactions et le traitement par lots des transactions. Il est à noter qu'EIP-7702 est parfaitement compatible avec les portefeuilles de contrats intelligents mis en œuvre par EIP-4337, l'intégration transparente des deux simplifiant considérablement le développement et l'application de 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 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 la liste peut contenir plusieurs entrées d'autorisation, 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 adresse représente l'adresse cible du mandat.
• 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 dans une transaction peut contenir plusieurs entrées d'autorisation signées par différents comptes d'autorisation ( EOA ), c'est-à-dire que le promoteur de la transaction peut être différent de l'autorisateur, permettant ainsi un paiement des frais de gaz pour les opérations d'autorisation.

réalisation

Lorsqu'un autorisant signe les données d'autorisation, il doit d'abord encoder RLP chain_id, address, nonce. Ensuite, les données encodées sont soumises à une opération de hachage keccak256 avec le nombre MAGIC, ce qui donne les données à signer. Enfin, l'autoriser 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 but est d'assurer qu'il n'y ait pas de conflit entre les résultats de différentes signatures.

Il est à noter que lorsque le chain_id autorisé par l'autorisateur est 0, cela signifie que l'autorisateur 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).

Une fois que l'autorisateur a signé les données d'autorisation, l'initiateur de la transaction rassemblera celles-ci 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, y compris une vérification obligatoire de l'adresse to pour s'assurer que cette transaction n'est pas une création de contrat, c'est-à-dire qu'en envoyant 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 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.

Ensuite, au cours de l'exécution de la transaction, le nœud va d'abord augmenter la valeur nonce de l'initiateur de la transaction, puis effectuer l'opération applyAuthorization pour chaque entrée d'autorisation dans authorization_list. Dans l'opération applyAuthorization, le nœud va d'abord vérifier le nonce de l'autorisateur, puis augmenter 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 une entrée d'autorisation, si une erreur est rencontrée, cette entrée d'autorisation sera ignorée, la transaction ne échouera pas, et les autres entrées d'autorisation continueront d'être appliquées, afin de garantir qu'il n'y ait pas de risque de DoS dans un scénario d'autorisation en masse.

Après la fin 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 restrictions de l'EIP-3541, les utilisateurs ne peuvent pas déployer de manière conventionnelle du code de contrat commençant par des octets 0xef, 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.

Un 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 à 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 à l'écosystème doivent prêter attention dans leur pratique :

stockage de clé privée

Même si un EOA peut 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 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 toujours le contrôle maximal sur le compte, et 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 finalisé la délégation pour 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 de comptes après avoir effectué un dépôt, ils doivent toujours mettre la protection de la clé privée en premier, et garder à l'esprit : Not your keys, not your coins.

Multichaînes de relecture

Lors de la signature d'une autorisation de délégation, les utilisateurs peuvent choisir la chaîne sur laquelle la délégation peut entrer en vigueur via le chainId. Bien sûr, les utilisateurs peuvent également choisir d'utiliser un chainId de 0 pour la délégation, ce qui permet à la délégation d'être reproduite et d'entrer en vigueur sur plusieurs chaînes, afin de faciliter la délégation sur plusieurs chaînes avec une seule signature. Cependant, il est important de noter que le même 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 les utilisateurs, 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 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, et il est important de bien comprendre l'objectif de la délégation.

impossible à initialiser

Les portefeuilles de contrats intelligents actuellement dominants adoptent principalement un modèle de proxy. Lors du déploiement, le proxy du portefeuille appelle la fonction d'initialisation du contrat via DELEGateCALL, ce qui permet d'effectuer 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, cela ne fait qu'actualiser le champ code de leur adresse, sans pouvoir initialiser en appelant l'adresse déléguée. Cela signifie que l'EIP-7702 ne peut pas appeler la fonction d'initialisation pour effectuer l'initialisation du portefeuille dans la transaction de déploiement du contrat comme le fait un contrat proxy ERC-1967 classique.

Pour les développeurs, lors de l'adaptation combinée de l'EIP-7702 avec le portefeuille EIP-4337 existant, il convient de prêter attention à la vérification des autorisations dans les opérations d'initialisation du portefeuille (par exemple, vérifier 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 du stockage

Lors de l'utilisation de la fonction de délégation EIP-7702, les utilisateurs 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, il est possible que le nouveau contrat réutilise par inadvertance les données de l'ancien contrat, entraînant ainsi des conséquences négatives telles que le verrouillage de compte ou la perte de fonds.

Pour les utilisateurs, il est conseillé 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 pendant le processus de développement, en assignant des variables à des emplacements de stockage indépendants désignés pour atténuer le risque de conflit de stockage. De plus, l'ERC-7779 (draft) fournit également un processus standard de re-délégation spécifiquement pour l'EIP-7702 : cela inclut l'utilisation de l'ERC-7201 pour prévenir les conflits de stockage et la vérification de la compatibilité de stockage avant la re-délégation, ainsi que l'appel de l'interface de l'ancienne délégation pour nettoyer les anciennes données de stockage.

faux rechargement

Après avoir effectué un mandat, un 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 dépôts via des contrats intelligents.

CEX doit vérifier l'état de chaque transaction de recharge via trace pour prévenir le risque de faux rechargements de contrats intelligents.

conversion de compte

Après l'implémentation 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 de lancer 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 s'appliquent qu'aux projets impliquant 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 sera également inefficace.

Les développeurs doivent supposer que les futurs participants seront tous des contrats intelligents.

compatibilité des contrats

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

Pour les développeurs, le contrat cible délégué par l'utilisateur doit mettre en œuvre la fonction de rappel correspondante, afin de 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 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 deviendra 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, et lors de la signature déléguée par les utilisateurs, il convient de mettre en avant le contrat cible délégué afin de réduire le risque que les utilisateurs subissent des attaques de phishing.

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

Résumé

EIP-7702 introduit un nouveau type de transaction, permettant 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 qui ait été 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., sont confrontés à de nombreux défis et opportunités. Le contenu des meilleures pratiques exposé dans cet article ne peut pas couvrir tous les risques potentiels, mais il mérite néanmoins d'être référencé et appliqué dans la pratique.