Mise à niveau d'Ethereum Pectra : Analyse approfondie de l'EIP-7702
Introduction
Ethereum va bientôt accueillir la mise à niveau Pectra, une mise à jour significative qui introduira plusieurs propositions d'amélioration importantes. Parmi celles-ci, l'EIP-7702 a apporté une transformation révolutionnaire aux comptes externes Ethereum (EOA). Cette proposition floute la frontière entre EOA et le compte de contrat CA, représentant une étape clé vers l'abstraction de compte native après l'EIP-4337, et apporte 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 aux 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 de définir un code pour celle-ci. Cela permet à l'EOA d'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 autorisations, la gestion multi-signatures, la vérification zk, les paiements par abonnement, le parrainage de transactions et le traitement par lots des transactions. Il convient de noter que l'EIP-7702 est parfaitement compatible avec le portefeuille de contrat intelligent mis en œuvre par l'EIP-4337, l'intégration transparente 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 :
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 d'elles contenant :
chain_id indique la chaîne sur laquelle cette délégation d'autorisation est valable
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 d'une transaction peut contenir plusieurs comptes d'autorisation différents signés par (EOA), c'est-à-dire que l'initiateur de la transaction peut être différent de l'autorisateur, permettant ainsi une opération de paiement des frais de gaz au nom de l'autorisateur.
réalisation
Lors de la signature des données d'autorisation, le donneur d'autorisation doit d'abord effectuer un codage RLP de chain_id, address et nonce. Ensuite, les données codées sont soumises à une opération 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 les données y_parity, r, s. MAGIC (0x05) est utilisé comme séparateur de domaine, afin d'assurer que les résultats de signatures de types différents ne produisent pas de conflits.
Il est à noter que lorsque le chain_id autorisé par le donneur d'autorisation est 0, cela signifie que le donneur d'autorisation permet la réplication de l'autorisation ( sur toutes les chaînes compatibles EVM prenant en charge l'EIP-7702, à condition que le nonce corresponde également exactement à ).
Une fois 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 signer et diffuser la transaction via RPC. Avant que la transaction ne soit exécutée dans un bloc, le Proposer effectue d'abord une pré-vérification de la transaction, au cours de laquelle l'adresse to est contrôlée de manière stricte pour s'assurer que cette transaction n'est pas une transaction de 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 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, 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 sur chaque entrée d'autorisation dans la authorization_list. Dans l'opération applyAuthorization, le nœud va d'abord vérifier la nonce de l'autorisateur, puis augmenter la 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 est rencontrée, 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 que l'application autorisée soit terminé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 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 le byte 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 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 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 faire attention dans leur pratique :
stockage de clé privée
Même si un EOA peut résoudre les problèmes de perte de fonds causés par 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 EOA. Il est important de préciser qu'après avoir effectué la délégation, la clé privée EOA conserve le contrôle le plus élevé sur le compte, et celui qui détient la clé privée peut 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 terminé la délégation pour l'EOA, cela ne peut pas complètement éliminer le risque de fuite de 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é, ils doivent toujours placer la protection de la clé privée en premier, en gardant à l'esprit : Not your keys, not your coins.
Relecture 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 peut être effective via 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 et effective sur plusieurs chaînes, facilitant ainsi la délégation sur plusieurs chaînes avec une seule signature. Cependant, il est important de noter que le même adresse de contrat délégué 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'informer l'utilisateur des risques potentiels liés à la signature d'une délégation avec un chainId de 0.
Les utilisateurs doivent également faire attention au fait que les adresses de contrat identiques sur différentes chaînes ne sont pas toujours les mêmes, et il est important de comprendre clairement l'objectif de la délégation.
Impossible d'initialiser
La plupart des portefeuilles intelligents courants adoptent 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 le problème d'initialisation préalable. Cependant, lorsque les utilisateurs utilisent EIP-7702 pour déléguer, ils ne mettent à jour que le champ code de leur adresse, ne pouvant pas initialiser en appelant l'adresse déléguée. Cela rend EIP-7702 incapable d'appeler la fonction d'initialisation pour l'initialisation du portefeuille dans la transaction de déploiement du contrat, comme le fait un contrat代理 ERC-1967 classique.
Pour les développeurs, lors de la combinaison de l'EIP-7702 avec le portefeuille existant EIP-4337, il est important de vérifier les autorisations lors de l'initialisation du portefeuille, par exemple en utilisant ecrecover pour récupérer l'adresse de signature afin d'effectuer 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 avoir besoin de se réaffecter à une adresse de contrat différente en raison de changements d'exigences fonctionnelles, de mises à jour de portefeuille, etc. Cependant, la structure de stockage des différents contrats peut varier) par exemple, le slot0 d'un contrat différent peut représenter différents types de données###, dans le cas d'une nouvelle délégation, cela peut entraîner une réutilisation inattendue des données de l'ancien contrat par le nouveau contrat, ce qui peut provoquer le verrouillage du compte, des pertes de fonds et d'autres conséquences néfastes.
Pour les utilisateurs, il est important de traiter avec prudence les situations de réaffectation.
Pour les développeurs, il est essentiel 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 spécifié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éaffectation spécialement conçu pour l'EIP-7702 : incluant l'utilisation de l'ERC-7201 pour éviter les conflits de stockage, la vérification de la compatibilité de stockage avant la réaffectation, ainsi que l'appel de l'interface de l'ancienne délégation pour nettoyer les anciennes données de stockage.
( Fausse recharge
Après avoir passé une commande, l'EOA pourra également être utilisé comme un contrat intelligent, de sorte que l'échange pourrait faire face à la généralisation des dépôts via des contrats intelligents.
Les échanges doivent vérifier l'état de chaque transaction de recharge via trace, afin de prévenir les risques de faux dépôts liés aux contrats intelligents.
) Conversion de compte
Après l'implémentation 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 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 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 inutile.
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 possèdent une fonctionnalité de 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 correspondantes pour garantir la compatibilité avec les jetons majeurs.
Vérification de phishing
Après l'implémentation de la délégation EIP-7702, les actifs dans le compte utilisateur pourraient être contrôlés par des contrats intelligents. Si l'utilisateur délègue son compte à un contrat malveillant, il sera alors très 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, de mettre en avant le contrat cible délégué afin de réduire le risque que les utilisateurs soient victimes d'attaques de phishing.
De plus, une analyse automatique plus approfondie des contrats cibles des comptes délégués, comme l'examen open source, le contrôle des autorisations, etc., ### 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 un nouveau type de transaction qui confère aux EOA une programmabilité et une combinabilité, brouillant ainsi la frontière entre les EOA et les comptes de contrats. Étant donné qu'il n'existe actuellement aucun standard de contrat intelligent compatible avec le type EIP-7702 ayant été éprouvé dans des conditions réelles, différents participants de l'écosystème, tels que les utilisateurs, les fournisseurs de services de portefeuille, les développeurs et les échanges, sont confrontés à de nombreux défis et opportunités dans l'application pratique. Les meilleures pratiques énoncées dans cet article ne peuvent pas couvrir tous les risques potentiels, mais elles méritent d'être prises en compte par toutes les parties dans leurs opérations réelles.
Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.
6 J'aime
Récompense
6
5
Partager
Commentaire
0/400
PermabullPete
· Il y a 19h
monter à bord vient de commencer, le Carnet d'ordre va encore exploser.
Voir l'originalRépondre0
StablecoinEnjoyer
· Il y a 19h
C'est un peu en avance, j'ai l'impression que Vitalik Buterin est encore en train de faire des choses importantes.
Voir l'originalRépondre0
Token_Sherpa
· Il y a 19h
meh... une autre proposition qui ne résoudra pas les vrais problèmes d'eth à vrai dire
EIP-7702 Analyse approfondie : la mise à niveau Pectra d'Ethereum brouillera les frontières entre EOA et CA
Mise à niveau d'Ethereum Pectra : Analyse approfondie de l'EIP-7702
Introduction
Ethereum va bientôt accueillir la mise à niveau Pectra, une mise à jour significative qui introduira plusieurs propositions d'amélioration importantes. Parmi celles-ci, l'EIP-7702 a apporté une transformation révolutionnaire aux comptes externes Ethereum (EOA). Cette proposition floute la frontière entre EOA et le compte de contrat CA, représentant une étape clé vers l'abstraction de compte native après l'EIP-4337, et apporte 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 aux 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 de définir un code pour celle-ci. Cela permet à l'EOA d'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 autorisations, la gestion multi-signatures, la vérification zk, les paiements par abonnement, le parrainage de transactions et le traitement par lots des transactions. Il convient de noter que l'EIP-7702 est parfaitement compatible avec le portefeuille de contrat intelligent mis en œuvre par l'EIP-4337, l'intégration transparente 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, chacune d'elles contenant :
Le champ authorization_list d'une transaction peut contenir plusieurs comptes d'autorisation différents signés par (EOA), c'est-à-dire que l'initiateur de la transaction peut être différent de l'autorisateur, permettant ainsi une opération de paiement des frais de gaz au nom de l'autorisateur.
réalisation
Lors de la signature des données d'autorisation, le donneur d'autorisation doit d'abord effectuer un codage RLP de chain_id, address et nonce. Ensuite, les données codées sont soumises à une opération 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 les données y_parity, r, s. MAGIC (0x05) est utilisé comme séparateur de domaine, afin d'assurer que les résultats de signatures de types différents ne produisent pas de conflits.
Il est à noter que lorsque le chain_id autorisé par le donneur d'autorisation est 0, cela signifie que le donneur d'autorisation permet la réplication de l'autorisation ( sur toutes les chaînes compatibles EVM prenant en charge l'EIP-7702, à condition que le nonce corresponde également exactement à ).
Une fois 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 signer et diffuser la transaction via RPC. Avant que la transaction ne soit exécutée dans un bloc, le Proposer effectue d'abord une pré-vérification de la transaction, au cours de laquelle l'adresse to est contrôlée de manière stricte pour s'assurer que cette transaction n'est pas une transaction de 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 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, 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 sur chaque entrée d'autorisation dans la authorization_list. Dans l'opération applyAuthorization, le nœud va d'abord vérifier la nonce de l'autorisateur, puis augmenter la 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 est rencontrée, 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 que l'application autorisée soit terminé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 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 le byte 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 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 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 faire attention dans leur pratique :
stockage de clé privée
Même si un EOA peut résoudre les problèmes de perte de fonds causés par 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 EOA. Il est important de préciser qu'après avoir effectué la délégation, la clé privée EOA conserve le contrôle le plus élevé sur le compte, et celui qui détient la clé privée peut 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 terminé la délégation pour l'EOA, cela ne peut pas complètement éliminer le risque de fuite de 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é, ils doivent toujours placer la protection de la clé privée en premier, en gardant à l'esprit : Not your keys, not your coins.
Relecture 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 peut être effective via 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 et effective sur plusieurs chaînes, facilitant ainsi la délégation sur plusieurs chaînes avec une seule signature. Cependant, il est important de noter que le même adresse de contrat délégué 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'informer l'utilisateur des risques potentiels liés à la signature d'une délégation avec un chainId de 0.
Les utilisateurs doivent également faire attention au fait que les adresses de contrat identiques sur différentes chaînes ne sont pas toujours les mêmes, et il est important de comprendre clairement l'objectif de la délégation.
Impossible d'initialiser
La plupart des portefeuilles intelligents courants adoptent 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 le problème d'initialisation préalable. Cependant, lorsque les utilisateurs utilisent EIP-7702 pour déléguer, ils ne mettent à jour que le champ code de leur adresse, ne pouvant pas initialiser en appelant l'adresse déléguée. Cela rend EIP-7702 incapable d'appeler la fonction d'initialisation pour l'initialisation du portefeuille dans la transaction de déploiement du contrat, comme le fait un contrat代理 ERC-1967 classique.
Pour les développeurs, lors de la combinaison de l'EIP-7702 avec le portefeuille existant EIP-4337, il est important de vérifier les autorisations lors de l'initialisation du portefeuille, par exemple en utilisant ecrecover pour récupérer l'adresse de signature afin d'effectuer 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 avoir besoin de se réaffecter à une adresse de contrat différente en raison de changements d'exigences fonctionnelles, de mises à jour de portefeuille, etc. Cependant, la structure de stockage des différents contrats peut varier) par exemple, le slot0 d'un contrat différent peut représenter différents types de données###, dans le cas d'une nouvelle délégation, cela peut entraîner une réutilisation inattendue des données de l'ancien contrat par le nouveau contrat, ce qui peut provoquer le verrouillage du compte, des pertes de fonds et d'autres conséquences néfastes.
Pour les utilisateurs, il est important de traiter avec prudence les situations de réaffectation.
Pour les développeurs, il est essentiel 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 spécifié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éaffectation spécialement conçu pour l'EIP-7702 : incluant l'utilisation de l'ERC-7201 pour éviter les conflits de stockage, la vérification de la compatibilité de stockage avant la réaffectation, ainsi que l'appel de l'interface de l'ancienne délégation pour nettoyer les anciennes données de stockage.
( Fausse recharge
Après avoir passé une commande, l'EOA pourra également être utilisé comme un contrat intelligent, de sorte que l'échange pourrait faire face à la généralisation des dépôts via des contrats intelligents.
Les échanges doivent vérifier l'état de chaque transaction de recharge via trace, afin de prévenir les risques de faux dépôts liés aux contrats intelligents.
) Conversion de compte
Après l'implémentation 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 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 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 inutile.
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 possèdent une fonctionnalité de 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 correspondantes pour garantir la compatibilité avec les jetons majeurs.
Vérification de phishing
Après l'implémentation de la délégation EIP-7702, les actifs dans le compte utilisateur pourraient être contrôlés par des contrats intelligents. Si l'utilisateur délègue son compte à un contrat malveillant, il sera alors très 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, de mettre en avant le contrat cible délégué afin de réduire le risque que les utilisateurs soient victimes d'attaques de phishing.
De plus, une analyse automatique plus approfondie des contrats cibles des comptes délégués, comme l'examen open source, le contrôle des autorisations, etc., ### 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 un nouveau type de transaction qui confère aux EOA une programmabilité et une combinabilité, brouillant ainsi la frontière entre les EOA et les comptes de contrats. Étant donné qu'il n'existe actuellement aucun standard de contrat intelligent compatible avec le type EIP-7702 ayant été éprouvé dans des conditions réelles, différents participants de l'écosystème, tels que les utilisateurs, les fournisseurs de services de portefeuille, les développeurs et les échanges, sont confrontés à de nombreux défis et opportunités dans l'application pratique. Les meilleures pratiques énoncées dans cet article ne peuvent pas couvrir tous les risques potentiels, mais elles méritent d'être prises en compte par toutes les parties dans leurs opérations réelles.