Mise à niveau Pectra d'Ethereum : EIP-7702 apporte une transformation révolutionnaire aux EOA
Introduction
Ethereum va bientôt accueillir la mise à niveau Pectra, une mise à jour significative qui introduira plusieurs propositions d'amélioration importantes. Parmi elles, l'EIP-7702 a apporté une transformation révolutionnaire aux comptes externes Ethereum (EOA). Cette proposition floute la distinction entre EOA et comptes de contrats CA, constituant un pas clé vers l'abstraction native des comptes, après l'EIP-4337, et apportant un tout nouveau mode d'interaction à 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, 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 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 la programmabilité et la 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 lots de transactions. Il convient de noter que l'EIP-7702 est parfaitement compatible avec le portefeuille de contrat intelligent réalisé par l'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 :
Dans la nouvelle structure de transaction, à l'exception du 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 représente la chaîne sur laquelle cette délégation d'autorisation est effective.
l'adresse indique l'adresse cible de la délégation
nonce doit correspondre au nonce du compte autorisé actuel
y_parity, r, s sont les données de signature signées par le compte autorisé.
Le champ authorization_list d'une transaction peut contenir plusieurs comptes d'autorisation différents, avec ( signant les entrées d'autorisation EOA ), c'est-à-dire que l'initiateur de la transaction peut être différent de l'autorisateur, permettant ainsi à l'autorisateur de payer le gas pour l'opération d'autorisation.
réalisation
Lorsque le donneur d'autorisation signe les données d'autorisation, il doit d'abord effectuer un codage RLP de chain_id, address et nonce. Ensuite, les données codées sont combinées avec le nombre MAGIC pour effectuer un calcul de hachage keccak256, afin d'obtenir les données à signer. Enfin, en utilisant la clé privée du donneur d'autorisation, les données hachées sont signées pour obtenir les données y_parity, r et s. MAGIC (0x05) est utilisé comme séparateur de domaine, afin de garantir que les résultats de différentes signatures ne créent 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 de reproduire 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 regrouper dans le champ authorization_list pour les signer et diffuser la transaction via RPC. Avant que la transaction ne soit exécutée dans un bloc, le Proposer effectuera d'abord un pré-contrôle de la transaction, notamment un contrôle obligatoire de 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 doit 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 d'une 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), lors de la signature de la transaction d'autorisation, la valeur du nonce devrait être augmentée de 1.
Lorsque le 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 à s'appliquer, afin de garantir qu'il n'y ait pas de risque de DoS dans un scénario 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 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).
Une fois l'autorisation terminée, si l'autorisateur souhaite révoquer 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 prêter attention dans leur pratique :
stockage de clé privée
Bien que l'EOA puisse résoudre les problèmes de perte de fonds causés par la perte de clé privée grâce aux moyens intégrés de récupération sociale de contrats intelligents après délégation, 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, et détenir la clé privée permet de disposer librement des actifs du compte. Même après que l'utilisateur ou le fournisseur de services de portefeuille ait effectué la délégation pour l'EOA, il ne peut pas complètement éliminer le risque de fuite de la clé privée, même s'il supprime complètement la clé privée stockée localement, surtout dans les scénarios où il existe un risque d'attaque par la chaîne d'approvisionnement.
Pour les utilisateurs, lors de l'utilisation d'un compte après avoir effectué un dépôt, la protection de la clé privée doit toujours être la priorité, en gardant à l'esprit : Not your keys, not your coins.
multi-chaînes replay
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, et peut également choisir d'utiliser le chainId égal à 0 pour effectuer une délégation, permettant à la délégation d'être reproduite et effective sur plusieurs chaînes, facilitant ainsi une seule signature pour effectuer une délégation sur plusieurs chaînes. Cependant, il convient de noter que dans le même contrat sur plusieurs chaînes, il peut exister différents codes de mise en œuvre.
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 faire attention au fait que les mêmes adresses de contrat sur différentes chaînes n'ont pas toujours le même code de contrat, et ils doivent d'abord comprendre clairement l'objectif de la délégation.
impossible à initialiser
La plupart des portefeuilles intelligents populaires utilisent un modèle de proxy. Lors du déploiement, le proxy du portefeuille appelle la fonction d'initialisation du contrat via DELEGateCALL pour réaliser une opération atomique entre l'initialisation du portefeuille et le déploiement du portefeuille proxy, évitant ainsi le problème d'une initialisation prématurée. Cependant, lors de l'utilisation de l'EIP-7702 pour la délégation, seul le champ code de son adresse sera mis à jour, et il ne sera pas possible d'initialiser en appelant l'adresse de délégation. Cela signifie que l'EIP-7702 ne peut pas appeler la fonction d'initialisation pour le portefeuille lors d'une transaction de déploiement de contrat, comme c'est le cas pour les contrats proxy ERC-1967 courants.
Pour les développeurs, lors de la combinaison de l'EIP-7702 avec le portefeuille EIP-4337 existant, il convient de prêter attention à la vérification des autorisations lors de l'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
Lorsque les utilisateurs utilisent la fonction de délégation EIP-7702, il peut être nécessaire de se déléguer à 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 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 une réutilisation accidentelle des données de l'ancien contrat par le nouveau contrat, ce qui peut entraîner le verrouillage du compte, la perte de fonds et d'autres conséquences néfastes.
Pour les utilisateurs, il est conseillé de traiter avec prudence les situations de réattribution.
Pour les développeurs, il est important de suivre la Namespace Formula proposée par l'ERC-7201 durant le processus de développement, afin d'attribuer les variables à des emplacements de stockage indépendants spécifiés, réduisant ainsi 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 : cela inclut l'utilisation de l'ERC-7201 pour éviter les conflits de stockage, la vérification de la compatibilité du stockage avant la réaffectation, ainsi que l'appel à l'interface de l'ancienne affectation pour nettoyer les anciennes données de stockage.
Faux rechargement
Après que les utilisateurs ont effectué un mandat, 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 dépôts via des contrats intelligents.
CEX devrait vérifier l'état de chaque transaction de recharge par trace, afin de prévenir les risques de fausses recharges de 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 limitent la participation aux projets uniquement aux 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 échouera également.
Les développeurs doivent supposer que les futurs participants seront tous des contrats intelligents.
compatibilité des contrats
Les tokens ERC-721 et ERC-777 existants possèdent tous une fonction Hook lors du transfert de contrats, ce qui signifie que le destinataire doit implémenter la fonction de rappel correspondante pour recevoir avec succès les tokens.
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 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 un contrat intelligent. 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 supporter rapidement les transactions de type EIP-7702. De plus, lors de la signature d'une délégation par l'utilisateur, il convient de mettre en avant le contrat cible de la délégation afin de réduire le risque de phishing auquel l'utilisateur pourrait être exposé.
De plus, une analyse automatique plus approfondie des contrats cibles des comptes délégués, y compris des vérifications de code source, des vérifications de permissions, etc., ( peut mieux aider les utilisateurs à éviter de tels risques.
Résumé
Cet article explore la proposition EIP-7702 dans le cadre de la prochaine mise à niveau Pectra d'Ethereum. EIP-7702 introduit de nouveaux types de transactions, permettant aux EOA d'avoir une programmabilité et une combinabilité, brouillant ainsi la ligne 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 testée en conditions réelles, divers 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 dans l'application pratique. Les meilleures pratiques décrites 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 pratiques.
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.
17 J'aime
Récompense
17
9
Reposter
Partager
Commentaire
0/400
notSatoshi1971
· 07-26 08:08
Avant d'ouvrir le marché à la vente, il faut d'abord tendre une embuscade. 7702 doit To the moon.
Voir l'originalRépondre0
0xSunnyDay
· 07-24 10:37
Cette mise à niveau est vraiment sévère 8 a foncé
Voir l'originalRépondre0
BasementAlchemist
· 07-23 13:37
Encore une vague d'innovation des comptes de contrats ? C'est vraiment incroyable.
Voir l'originalRépondre0
MEVHunterX
· 07-23 13:21
C'est déjà la prochaine histoire du 4337~ Ça sent bon, allons-y à fond!
Voir l'originalRépondre0
PanicSeller69
· 07-23 13:20
Une fois qu'on voit, il faut pump. À quel moment commencer à buy the dip v神.
Voir l'originalRépondre0
FastLeaver
· 07-23 13:14
Encore une mise à jour ?? Rug Pull
Voir l'originalRépondre0
PerennialLeek
· 07-23 13:12
A augmenté plusieurs fois, ceux qui comprennent comprennent.
Voir l'originalRépondre0
WinterWarmthCat
· 07-23 13:12
Le distributeur automatique parle ! Nouvelle mise à jour ? On parlera de l'encaissement plus tard.
Voir l'originalRépondre0
Web3ExplorerLin
· 07-23 13:07
fascinant... l'eip-7702 pourrait bien être le saut quantique dont eth a besoin en ce moment
Mise à niveau Pectra d'Ethereum : EIP-7702 floute les frontières entre EOA et CA, ouvrant une nouvelle ère d'abstraction de compte natif.
Mise à niveau Pectra d'Ethereum : EIP-7702 apporte une transformation révolutionnaire aux EOA
Introduction
Ethereum va bientôt accueillir la mise à niveau Pectra, une mise à jour significative qui introduira plusieurs propositions d'amélioration importantes. Parmi elles, l'EIP-7702 a apporté une transformation révolutionnaire aux comptes externes Ethereum (EOA). Cette proposition floute la distinction entre EOA et comptes de contrats CA, constituant un pas clé vers l'abstraction native des comptes, après l'EIP-4337, et apportant un tout nouveau mode d'interaction à 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, 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 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 la programmabilité et la 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 lots de transactions. Il convient de noter que l'EIP-7702 est parfaitement compatible avec le portefeuille de contrat intelligent réalisé par l'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 :
authorization_list = [[chain_id, address, nonce, y_parity, r, s], ...]
Dans la nouvelle structure de transaction, à l'exception du 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 :
Le champ authorization_list d'une transaction peut contenir plusieurs comptes d'autorisation différents, avec ( signant les entrées d'autorisation EOA ), c'est-à-dire que l'initiateur de la transaction peut être différent de l'autorisateur, permettant ainsi à l'autorisateur de payer le gas pour l'opération d'autorisation.
réalisation
Lorsque le donneur d'autorisation signe les données d'autorisation, il doit d'abord effectuer un codage RLP de chain_id, address et nonce. Ensuite, les données codées sont combinées avec le nombre MAGIC pour effectuer un calcul de hachage keccak256, afin d'obtenir les données à signer. Enfin, en utilisant la clé privée du donneur d'autorisation, les données hachées sont signées pour obtenir les données y_parity, r et s. MAGIC (0x05) est utilisé comme séparateur de domaine, afin de garantir que les résultats de différentes signatures ne créent 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 de reproduire 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 regrouper dans le champ authorization_list pour les signer et diffuser la transaction via RPC. Avant que la transaction ne soit exécutée dans un bloc, le Proposer effectuera d'abord un pré-contrôle de la transaction, notamment un contrôle obligatoire de 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 doit 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 d'une 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), lors de la signature de la transaction d'autorisation, la valeur du nonce devrait être augmentée de 1.
Lorsque le 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 à s'appliquer, afin de garantir qu'il n'y ait pas de risque de DoS dans un scénario 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 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).
Une fois l'autorisation terminée, si l'autorisateur souhaite révoquer 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 prêter attention dans leur pratique :
stockage de clé privée
Bien que l'EOA puisse résoudre les problèmes de perte de fonds causés par la perte de clé privée grâce aux moyens intégrés de récupération sociale de contrats intelligents après délégation, 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, et détenir la clé privée permet de disposer librement des actifs du compte. Même après que l'utilisateur ou le fournisseur de services de portefeuille ait effectué la délégation pour l'EOA, il ne peut pas complètement éliminer le risque de fuite de la clé privée, même s'il supprime complètement la clé privée stockée localement, surtout dans les scénarios où il existe un risque d'attaque par la chaîne d'approvisionnement.
Pour les utilisateurs, lors de l'utilisation d'un compte après avoir effectué un dépôt, la protection de la clé privée doit toujours être la priorité, en gardant à l'esprit : Not your keys, not your coins.
multi-chaînes replay
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, et peut également choisir d'utiliser le chainId égal à 0 pour effectuer une délégation, permettant à la délégation d'être reproduite et effective sur plusieurs chaînes, facilitant ainsi une seule signature pour effectuer une délégation sur plusieurs chaînes. Cependant, il convient de noter que dans le même contrat sur plusieurs chaînes, il peut exister différents codes de mise en œuvre.
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 faire attention au fait que les mêmes adresses de contrat sur différentes chaînes n'ont pas toujours le même code de contrat, et ils doivent d'abord comprendre clairement l'objectif de la délégation.
impossible à initialiser
La plupart des portefeuilles intelligents populaires utilisent un modèle de proxy. Lors du déploiement, le proxy du portefeuille appelle la fonction d'initialisation du contrat via DELEGateCALL pour réaliser une opération atomique entre l'initialisation du portefeuille et le déploiement du portefeuille proxy, évitant ainsi le problème d'une initialisation prématurée. Cependant, lors de l'utilisation de l'EIP-7702 pour la délégation, seul le champ code de son adresse sera mis à jour, et il ne sera pas possible d'initialiser en appelant l'adresse de délégation. Cela signifie que l'EIP-7702 ne peut pas appeler la fonction d'initialisation pour le portefeuille lors d'une transaction de déploiement de contrat, comme c'est le cas pour les contrats proxy ERC-1967 courants.
Pour les développeurs, lors de la combinaison de l'EIP-7702 avec le portefeuille EIP-4337 existant, il convient de prêter attention à la vérification des autorisations lors de l'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
Lorsque les utilisateurs utilisent la fonction de délégation EIP-7702, il peut être nécessaire de se déléguer à 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 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 une réutilisation accidentelle des données de l'ancien contrat par le nouveau contrat, ce qui peut entraîner le verrouillage du compte, la perte de fonds et d'autres conséquences néfastes.
Pour les utilisateurs, il est conseillé de traiter avec prudence les situations de réattribution.
Pour les développeurs, il est important de suivre la Namespace Formula proposée par l'ERC-7201 durant le processus de développement, afin d'attribuer les variables à des emplacements de stockage indépendants spécifiés, réduisant ainsi 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 : cela inclut l'utilisation de l'ERC-7201 pour éviter les conflits de stockage, la vérification de la compatibilité du stockage avant la réaffectation, ainsi que l'appel à l'interface de l'ancienne affectation pour nettoyer les anciennes données de stockage.
Faux rechargement
Après que les utilisateurs ont effectué un mandat, 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 dépôts via des contrats intelligents.
CEX devrait vérifier l'état de chaque transaction de recharge par trace, afin de prévenir les risques de fausses recharges de 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 limitent la participation aux projets uniquement aux 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 échouera également.
Les développeurs doivent supposer que les futurs participants seront tous des contrats intelligents.
compatibilité des contrats
Les tokens ERC-721 et ERC-777 existants possèdent tous une fonction Hook lors du transfert de contrats, ce qui signifie que le destinataire doit implémenter la fonction de rappel correspondante pour recevoir avec succès les tokens.
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 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 un contrat intelligent. 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 supporter rapidement les transactions de type EIP-7702. De plus, lors de la signature d'une délégation par l'utilisateur, il convient de mettre en avant le contrat cible de la délégation afin de réduire le risque de phishing auquel l'utilisateur pourrait être exposé.
De plus, une analyse automatique plus approfondie des contrats cibles des comptes délégués, y compris des vérifications de code source, des vérifications de permissions, etc., ( peut mieux aider les utilisateurs à éviter de tels risques.
Résumé
Cet article explore la proposition EIP-7702 dans le cadre de la prochaine mise à niveau Pectra d'Ethereum. EIP-7702 introduit de nouveaux types de transactions, permettant aux EOA d'avoir une programmabilité et une combinabilité, brouillant ainsi la ligne 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 testée en conditions réelles, divers 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 dans l'application pratique. Les meilleures pratiques décrites 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 pratiques.