Mise à niveau Pectra d'Ethereum : Analyse approfondie de l'EIP-7702 et meilleures pratiques
Avant-propos
Ethereum va bientôt accueillir la mise à jour Pectra, une mise à jour d'une grande importance, avec l'introduction de plusieurs propositions d'amélioration d'Ethereum. Parmi celles-ci, l'EIP-7702 a révolutionné le compte externe d'Ethereum (EOA). Cette proposition a flouté la frontière entre les EOA et les comptes de contrat CA, marquant une étape 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 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 différents participants.
Analyse des protocoles
Aperçu
EIP-7702 introduit un 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 une programmabilité et une composabilité, 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 en lot 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, 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, chacune contenant :
chain_id représente la chaîne sur laquelle cette délégation d'autorisation est valable.
l'adresse représente 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 entrées d'autorisation signées par différents comptes autorisés ( EOA ), c'est-à-dire que l'initiateur de la transaction peut être différent de l'autorisateur, afin de permettre le paiement des frais de gas pour les opérations d'autorisation.
réalisation
Lorsque le donneur d'autorisation signe les données d'autorisation, il doit d'abord effectuer un encodage RLP de chain_id, address et nonce. Ensuite, les données encodées sont hachées avec keccak256 en conjonction avec le nombre MAGIC, ce qui donne les données à signer. Enfin, le donneur d'autorisation signe les données hachées avec sa clé privée, obtenant les données y_parity, r, s. MAGIC (0x05) est utilisé comme séparateur de domaine, afin de garantir que les résultats des signatures de différents types ne se chevauchent pas.
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 l'EIP-7702, à condition que le nonce corresponde également exactement à (.
Après que le donneur d'autorisation ait signé les données d'autorisation, l'initiateur de la transaction rassemblera ces données 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, au cours duquel il procédera à une vérification stricte 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 peut 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.
Au cours de l'exécution de la transaction, le nœud augmentera d'abord la valeur nonce de l'initiateur de la transaction, puis effectuera l'opération applyAuthorization sur chaque entrée d'autorisation dans la 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, 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 à ê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 d'autorisation, le champ code de l'adresse du donneur sera défini sur 0xef0100 || address, où 0xef0100 est un identifiant fixe et address est l'adresse cible de la délégation. En raison des limitations 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 ce type d'identifiant ne peut être déployé que par des transactions de type SET_CODE_TX_TYPE )0x04(.
Après avoir terminé 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 l'EIP-7702 permet aux autorisateurs )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 entraîneront également de nouveaux risques. Voici les aspects auxquels les participants de l'écosystème doivent faire attention dans la pratique :
) stockage de clé privée
Même si l'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 effectué 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 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, il ne peut pas complètement éliminer le risque de fuite de la 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é, la protection des clés privées doit toujours être la priorité, 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 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 et effective sur plusieurs chaînes, afin de faciliter une seule signature pour la délégation sur plusieurs chaînes. Cependant, il convient de noter que le même adresse de 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 des 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 de 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 d'initialiser
Les portefeuilles de contrats intelligents les plus courants adoptent principalement un modèle d代理. Lors du déploiement, le代理 du portefeuille appelle la fonction d'initialisation du contrat via DELEGateCALL, permettant ainsi une opération atomique d'initialisation du portefeuille et de déploiement du portefeuille代理, évitant ainsi le problème d'initialisation prématurée. Cependant, lorsque les utilisateurs utilisent EIP-7702 pour déléguer, seul le champ code de leur adresse sera mis à jour, et l'initialisation ne pourra pas être effectuée en appelant l'adresse déléguée. Cela signifie qu'EIP-7702 ne peut pas 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 et de l'adaptation de l'EIP-7702 avec le portefeuille existant EIP-4337, il est important de procéder à une vérification des autorisations lors de l'initialisation du portefeuille ###, par exemple en vérifiant l'adresse de signature récupérée par ecrecover (, 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 être amenés à redéléguer vers différentes adresses de contrat en raison de changements dans les besoins fonctionnels, des mises à jour de portefeuille, etc. Cependant, la structure de stockage des différents contrats peut varier ###, par exemple, le slot0 de différents contrats peut représenter différents types de données (. Dans le cas d'une redélégation, cela peut entraîner la réutilisation accidentelle des données de l'ancien contrat par le nouveau contrat, ce qui peut provoquer des blocages de compte, des pertes de fonds, et d'autres conséquences néfastes.
Pour les utilisateurs, il convient 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 au cours du processus de développement, en attribuant des variables à des emplacements de stockage indépendants désignés, afin de réduire le risque de conflit de stockage. De plus, l'ERC-7779 )draft( fournit également un processus standard de réaffectation spécifiquement pour l'EIP-7702 : cela inclut l'utilisation de l'ERC-7201 pour prévenir les conflits de stockage, ainsi que la vérification de la compatibilité du stockage avant la réaffectation, et l'appel de l'interface de l'ancienne délégation pour nettoyer les anciennes données de stockage.
) Recharge fictif
Après avoir 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 recharges via des contrats intelligents.
CEX devrait vérifier l'état de chaque transaction de recharge par trace, afin de prévenir les risques 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 aux comptes d'initier des transactions et d'être appelés. Cela signifie que lorsque le compte s'appelle lui-même et effectue un appel externe, son msg.sender sera également tx.origin, ce qui rompra certaines hypothèses de sécurité qui limitent la participation au projet 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 défendre contre les attaques de réentrées échouera également.
Les développeurs devraient supposer que les futurs participants pourraient tous être des contrats intelligents lors du processus de développement.
compatibilité des contrats
Les tokens ERC-721 et ERC-777 existants possèdent une fonction Hook lors du transfert de contrats, ce qui signifie que le récepteur doit implémenter la fonction de rappel correspondante pour recevoir avec succès les tokens.
Pour les développeurs, les contrats cibles délégués par les utilisateurs devraient implémenter les fonctions de rappel appropriées pour garantir la compatibilité avec les jetons principaux.
Vérification de la pêche
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. 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 soutenir 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é pour atténuer le risque que les utilisateurs subissent des attaques de phishing.
De plus, une analyse automatique plus approfondie des contrats cibles de délégation de compte, comme l'examen de code open source, la vérification des autorisations, etc., ### peut mieux aider les utilisateurs à éviter de tels risques.
Résumé
Cet article discute de la proposition EIP-7702 dans la prochaine mise à niveau Pectra d'Ethereum. EIP-7702 permet, grâce à l'introduction d'un nouveau type de transaction, de doter les EOA de programmabilité et de modularité, brouillant 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 ayant é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., rencontrent 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 et appliquées par toutes les parties dans la pratique.
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.
14 J'aime
Récompense
14
5
Partager
Commentaire
0/400
ser_ngmi
· 07-21 20:33
Copier les devoirs est devenu ennuyeux. C'est juste pour obtenir un eoa et un ca.
Voir l'originalRépondre0
ParanoiaKing
· 07-20 23:50
Encore une autre pile de mises à niveau incompréhensibles, sans mots.
Voir l'originalRépondre0
YieldHunter
· 07-20 23:49
techniquement parlant, cet eip semble un peu suspect... avez-vous des données sur les coûts de tx testnet ?
Voir l'originalRépondre0
EyeOfTheTokenStorm
· 07-20 23:26
Encore une opportunité de se positionner à l'avance ? D'après les données historiques, après une mise à niveau, l'eth a toujours tendance à connaître une big pump. Cependant, le marché est un peu en bulle.
Voir l'originalRépondre0
SchrodingerPrivateKey
· 07-20 23:23
Il y a encore un nouvel EIP, le compte de contrat de version basique est arrivé.
EIP-7702解析:Ethereum Pectra升级如何赋予EOA Programmabilité
Mise à niveau Pectra d'Ethereum : Analyse approfondie de l'EIP-7702 et meilleures pratiques
Avant-propos
Ethereum va bientôt accueillir la mise à jour Pectra, une mise à jour d'une grande importance, avec l'introduction de plusieurs propositions d'amélioration d'Ethereum. Parmi celles-ci, l'EIP-7702 a révolutionné le compte externe d'Ethereum (EOA). Cette proposition a flouté la frontière entre les EOA et les comptes de contrat CA, marquant une étape 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 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 différents participants.
Analyse des protocoles
Aperçu
EIP-7702 introduit un 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 une programmabilité et une composabilité, 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 en lot 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, 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, chacune contenant :
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 l'initiateur de la transaction peut être différent de l'autorisateur, afin de permettre le paiement des frais de gas pour les opérations d'autorisation.
réalisation
Lorsque le donneur d'autorisation signe les données d'autorisation, il doit d'abord effectuer un encodage RLP de chain_id, address et nonce. Ensuite, les données encodées sont hachées avec keccak256 en conjonction avec le nombre MAGIC, ce qui donne les données à signer. Enfin, le donneur d'autorisation signe les données hachées avec sa clé privée, obtenant les données y_parity, r, s. MAGIC (0x05) est utilisé comme séparateur de domaine, afin de garantir que les résultats des signatures de différents types ne se chevauchent pas.
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 l'EIP-7702, à condition que le nonce corresponde également exactement à (.
Après que le donneur d'autorisation ait signé les données d'autorisation, l'initiateur de la transaction rassemblera ces données 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, au cours duquel il procédera à une vérification stricte 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 peut 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.
Au cours de l'exécution de la transaction, le nœud augmentera d'abord la valeur nonce de l'initiateur de la transaction, puis effectuera l'opération applyAuthorization sur chaque entrée d'autorisation dans la 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, 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 à ê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 d'autorisation, le champ code de l'adresse du donneur sera défini sur 0xef0100 || address, où 0xef0100 est un identifiant fixe et address est l'adresse cible de la délégation. En raison des limitations 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 ce type d'identifiant ne peut être déployé que par des transactions de type SET_CODE_TX_TYPE )0x04(.
Après avoir terminé 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 l'EIP-7702 permet aux autorisateurs )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 entraîneront également de nouveaux risques. Voici les aspects auxquels les participants de l'écosystème doivent faire attention dans la pratique :
) stockage de clé privée
Même si l'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 effectué 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 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, il ne peut pas complètement éliminer le risque de fuite de la 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é, la protection des clés privées doit toujours être la priorité, 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 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 et effective sur plusieurs chaînes, afin de faciliter une seule signature pour la délégation sur plusieurs chaînes. Cependant, il convient de noter que le même adresse de 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 des 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 de 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 d'initialiser
Les portefeuilles de contrats intelligents les plus courants adoptent principalement un modèle d代理. Lors du déploiement, le代理 du portefeuille appelle la fonction d'initialisation du contrat via DELEGateCALL, permettant ainsi une opération atomique d'initialisation du portefeuille et de déploiement du portefeuille代理, évitant ainsi le problème d'initialisation prématurée. Cependant, lorsque les utilisateurs utilisent EIP-7702 pour déléguer, seul le champ code de leur adresse sera mis à jour, et l'initialisation ne pourra pas être effectuée en appelant l'adresse déléguée. Cela signifie qu'EIP-7702 ne peut pas 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 et de l'adaptation de l'EIP-7702 avec le portefeuille existant EIP-4337, il est important de procéder à une vérification des autorisations lors de l'initialisation du portefeuille ###, par exemple en vérifiant l'adresse de signature récupérée par ecrecover (, 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 être amenés à redéléguer vers différentes adresses de contrat en raison de changements dans les besoins fonctionnels, des mises à jour de portefeuille, etc. Cependant, la structure de stockage des différents contrats peut varier ###, par exemple, le slot0 de différents contrats peut représenter différents types de données (. Dans le cas d'une redélégation, cela peut entraîner la réutilisation accidentelle des données de l'ancien contrat par le nouveau contrat, ce qui peut provoquer des blocages de compte, des pertes de fonds, et d'autres conséquences néfastes.
Pour les utilisateurs, il convient 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 au cours du processus de développement, en attribuant des variables à des emplacements de stockage indépendants désignés, afin de réduire le risque de conflit de stockage. De plus, l'ERC-7779 )draft( fournit également un processus standard de réaffectation spécifiquement pour l'EIP-7702 : cela inclut l'utilisation de l'ERC-7201 pour prévenir les conflits de stockage, ainsi que la vérification de la compatibilité du stockage avant la réaffectation, et l'appel de l'interface de l'ancienne délégation pour nettoyer les anciennes données de stockage.
) Recharge fictif
Après avoir 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 recharges via des contrats intelligents.
CEX devrait vérifier l'état de chaque transaction de recharge par trace, afin de prévenir les risques 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 aux comptes d'initier des transactions et d'être appelés. Cela signifie que lorsque le compte s'appelle lui-même et effectue un appel externe, son msg.sender sera également tx.origin, ce qui rompra certaines hypothèses de sécurité qui limitent la participation au projet 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 défendre contre les attaques de réentrées échouera également.
Les développeurs devraient supposer que les futurs participants pourraient tous être des contrats intelligents lors du processus de développement.
compatibilité des contrats
Les tokens ERC-721 et ERC-777 existants possèdent une fonction Hook lors du transfert de contrats, ce qui signifie que le récepteur doit implémenter la fonction de rappel correspondante pour recevoir avec succès les tokens.
Pour les développeurs, les contrats cibles délégués par les utilisateurs devraient implémenter les fonctions de rappel appropriées pour garantir la compatibilité avec les jetons principaux.
Vérification de la pêche
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. 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 soutenir 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é pour atténuer le risque que les utilisateurs subissent des attaques de phishing.
De plus, une analyse automatique plus approfondie des contrats cibles de délégation de compte, comme l'examen de code open source, la vérification des autorisations, etc., ### peut mieux aider les utilisateurs à éviter de tels risques.
Résumé
Cet article discute de la proposition EIP-7702 dans la prochaine mise à niveau Pectra d'Ethereum. EIP-7702 permet, grâce à l'introduction d'un nouveau type de transaction, de doter les EOA de programmabilité et de modularité, brouillant 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 ayant é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., rencontrent 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 et appliquées par toutes les parties dans la pratique.