EIP-7702: Grande transformation des comptes externes Ethereum
Ethereum s'apprête à accueillir la mise à niveau Pectra, dont l'EIP-7702 a apporté une transformation révolutionnaire aux comptes externes Ethereum (EOA). Cette proposition brouille la frontière entre les EOA et les comptes de contrat CA, représentant une étape clé vers l'abstraction native des comptes, et apporte de nouveaux modes 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, explorera les opportunités et les défis qu'il pourrait apporter, et fournira des conseils pratiques aux différents participants.
Analyse de protocole
Aperçu
EIP-7702 introduit un nouveau type de transaction, permettant aux EOA de spécifier une adresse de contrat intelligent et d'y définir un code. Cela permet aux EOA d'exécuter un code comme un contrat intelligent, tout en conservant la capacité d'initier des transactions. Cette fonctionnalité confère aux EOA une programmabilité et une combinabilité, permettant aux utilisateurs de mettre en œuvre des fonctionnalités telles que la récupération sociale, le contrôle des autorisations, la gestion de signatures multiples, la vérification zk, le paiement par abonnement, le parrainage de transactions et le traitement par lots de transactions. EIP-7702 est parfaitement compatible avec le portefeuille de contrat intelligent réalisé par l'EIP-4337, simplifiant le développement et l'application de nouvelles fonctionnalités.
EIP-7702 introduit un type de transaction SET_CODE_TX_TYPE (0x04), dont la structure de données contient le champ authorization_list, qui peut inclure plusieurs entrées d'autorisation. Chaque entrée d'autorisation contient chain_id, address, nonce et les données de signature.
réalisation
Lorsque le donneur d'autorisation signe les données d'autorisation, il doit encoder le chain_id, l'adresse et le nonce en RLP, puis effectuer un calcul de hachage keccak256 avec le nombre MAGIC, avant de signer avec la clé privée. MAGIC (0x05) sert de délimiteur de domaine, garantissant que les résultats de signatures de différents types ne se chevauchent pas.
Lorsque le chain_id est 0, cela signifie que l'autorisation peut être répétée sur toutes les chaînes compatibles EVM qui prennent en charge EIP-7702. Avant l'exécution de la transaction, le Proposer effectuera une pré-vérification pour s'assurer que la transaction n'est pas une transaction de création de contrat. Le champ authorization_list dans la transaction doit contenir au moins un élément d'autorisation.
Lorsqu'un nœud exécute une transaction, il augmente d'abord le nonce de l'initiateur, puis effectue l'opération applyAuthorization pour chaque entrée autorisée. En cas d'erreur, cette entrée autorisée sera ignorée et les autres entrées continueront à être appliquées. Une fois l'autorisation terminée, le champ code de l'adresse de l'autorisé sera défini sur 0xef0100||address. L'autorisé peut définir l'adresse cible de la délégation sur l'adresse 0 pour supprimer l'autorisation.
Meilleures pratiques
Bien que l'EIP-7702 apporte une nouvelle vitalité à l'écosystème Ethereum, il entraîne également de nouveaux risques. Voici les aspects auxquels les participants de l'écosystème doivent faire attention :
stockage de la clé privée
Même si le problème de perte de fonds peut être résolu par des moyens tels que la récupération sociale après la délégation EOA, le risque de fuite de clé privée ne peut toujours pas être évité. Les utilisateurs doivent placer la protection de leur clé privée en premier.
relecture multi-chaînes
L'utilisateur peut choisir un chainId de 0 pour déléguer, ce qui le rend effectif sur plusieurs chaînes. Cependant, le même adresse de contrat sur des chaînes différentes peut avoir des implémentations différentes. Les fournisseurs de services de portefeuille doivent vérifier si la chaîne de délégation est en accord avec le réseau actuel et informer l'utilisateur des risques associés.
Impossible d'initialiser
EIP-7702 ne peut pas appeler la fonction d'initialisation lors du déploiement comme le contrat proxy ERC-1967. Les développeurs doivent effectuer une vérification des autorisations lors de l'initialisation du portefeuille pour éviter le risque de course.
Gestion du stockage
La réaffectation à une adresse de contrat différente peut entraîner des différences de structure de stockage, provoquant le verrouillage du compte ou la perte de fonds. Les développeurs doivent suivre la formule d'espace de noms ERC-7201, en attribuant des variables à des emplacements de stockage distincts.
faux rechargement
Les échanges centralisés pourraient faire face à une généralisation des recharges de contrats intelligents, ils devraient vérifier l'état des transactions de recharge par le biais de trace pour prévenir le risque de fausses recharges.
conversion de compte
Le compte peut être librement converti entre EOA et SC, brisant certaines hypothèses de sécurité qui limitaient la participation des projets uniquement aux EOA. Les développeurs doivent supposer que les futurs participants pourraient tous être des contrats intelligents.
compatibilité des contrats
Les développeurs doivent s'assurer que le contrat cible délégué par l'utilisateur implémente les fonctions de rappel appropriées afin de être compatible avec les principaux jetons.
vérification de phishing
Les fournisseurs de services de portefeuille doivent rapidement prendre en charge le type de transaction EIP-7702, mettre en évidence le contrat cible lors de la signature déléguée par l'utilisateur, et procéder à une analyse automatique approfondie pour atténuer les risques de phishing.
Résumé
EIP-7702, grâce à un nouveau type de transaction, permet aux EOA d'avoir une programmabilité et une combinaison, brouillant ainsi la frontière entre les EOA et les comptes de contrat. Différents participants de l'écosystème font face à de nombreux défis et opportunités, les meilleures pratiques proposées dans cet article valent la peine d'être appliquées 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.
8 J'aime
Récompense
8
4
Partager
Commentaire
0/400
liquidation_surfer
· 07-14 22:20
Le frère du搬砖 en Blockchain, un patient atteint de trouble obsessionnel de contrôle des risques ~
Veuillez générer un commentaire en chinois :
L'opportunité de gagner de l'argent arrive !
Voir l'originalRépondre0
Blockblind
· 07-14 03:24
Rug Pull est devenu plus facile.
Voir l'originalRépondre0
consensus_failure
· 07-14 03:22
Si on ne sait pas jouer avec la chaîne, qu'est-ce qu'on fait avec les combinaisons ?
Voir l'originalRépondre0
NeverVoteOnDAO
· 07-14 03:12
Encore une proposition éblouissante à ne pas regarder.
EIP-7702 : Réforme majeure des comptes externes Ethereum apportant de nouvelles opportunités et défis à l'écosystème
EIP-7702: Grande transformation des comptes externes Ethereum
Ethereum s'apprête à accueillir la mise à niveau Pectra, dont l'EIP-7702 a apporté une transformation révolutionnaire aux comptes externes Ethereum (EOA). Cette proposition brouille la frontière entre les EOA et les comptes de contrat CA, représentant une étape clé vers l'abstraction native des comptes, et apporte de nouveaux modes 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, explorera les opportunités et les défis qu'il pourrait apporter, et fournira des conseils pratiques aux différents participants.
Analyse de protocole
Aperçu
EIP-7702 introduit un nouveau type de transaction, permettant aux EOA de spécifier une adresse de contrat intelligent et d'y définir un code. Cela permet aux EOA d'exécuter un code comme un contrat intelligent, tout en conservant la capacité d'initier des transactions. Cette fonctionnalité confère aux EOA une programmabilité et une combinabilité, permettant aux utilisateurs de mettre en œuvre des fonctionnalités telles que la récupération sociale, le contrôle des autorisations, la gestion de signatures multiples, la vérification zk, le paiement par abonnement, le parrainage de transactions et le traitement par lots de transactions. EIP-7702 est parfaitement compatible avec le portefeuille de contrat intelligent réalisé par l'EIP-4337, simplifiant le développement et l'application de nouvelles fonctionnalités.
EIP-7702 introduit un type de transaction SET_CODE_TX_TYPE (0x04), dont la structure de données contient le champ authorization_list, qui peut inclure plusieurs entrées d'autorisation. Chaque entrée d'autorisation contient chain_id, address, nonce et les données de signature.
réalisation
Lorsque le donneur d'autorisation signe les données d'autorisation, il doit encoder le chain_id, l'adresse et le nonce en RLP, puis effectuer un calcul de hachage keccak256 avec le nombre MAGIC, avant de signer avec la clé privée. MAGIC (0x05) sert de délimiteur de domaine, garantissant que les résultats de signatures de différents types ne se chevauchent pas.
Lorsque le chain_id est 0, cela signifie que l'autorisation peut être répétée sur toutes les chaînes compatibles EVM qui prennent en charge EIP-7702. Avant l'exécution de la transaction, le Proposer effectuera une pré-vérification pour s'assurer que la transaction n'est pas une transaction de création de contrat. Le champ authorization_list dans la transaction doit contenir au moins un élément d'autorisation.
Lorsqu'un nœud exécute une transaction, il augmente d'abord le nonce de l'initiateur, puis effectue l'opération applyAuthorization pour chaque entrée autorisée. En cas d'erreur, cette entrée autorisée sera ignorée et les autres entrées continueront à être appliquées. Une fois l'autorisation terminée, le champ code de l'adresse de l'autorisé sera défini sur 0xef0100||address. L'autorisé peut définir l'adresse cible de la délégation sur l'adresse 0 pour supprimer l'autorisation.
Meilleures pratiques
Bien que l'EIP-7702 apporte une nouvelle vitalité à l'écosystème Ethereum, il entraîne également de nouveaux risques. Voici les aspects auxquels les participants de l'écosystème doivent faire attention :
stockage de la clé privée
Même si le problème de perte de fonds peut être résolu par des moyens tels que la récupération sociale après la délégation EOA, le risque de fuite de clé privée ne peut toujours pas être évité. Les utilisateurs doivent placer la protection de leur clé privée en premier.
relecture multi-chaînes
L'utilisateur peut choisir un chainId de 0 pour déléguer, ce qui le rend effectif sur plusieurs chaînes. Cependant, le même adresse de contrat sur des chaînes différentes peut avoir des implémentations différentes. Les fournisseurs de services de portefeuille doivent vérifier si la chaîne de délégation est en accord avec le réseau actuel et informer l'utilisateur des risques associés.
Impossible d'initialiser
EIP-7702 ne peut pas appeler la fonction d'initialisation lors du déploiement comme le contrat proxy ERC-1967. Les développeurs doivent effectuer une vérification des autorisations lors de l'initialisation du portefeuille pour éviter le risque de course.
Gestion du stockage
La réaffectation à une adresse de contrat différente peut entraîner des différences de structure de stockage, provoquant le verrouillage du compte ou la perte de fonds. Les développeurs doivent suivre la formule d'espace de noms ERC-7201, en attribuant des variables à des emplacements de stockage distincts.
faux rechargement
Les échanges centralisés pourraient faire face à une généralisation des recharges de contrats intelligents, ils devraient vérifier l'état des transactions de recharge par le biais de trace pour prévenir le risque de fausses recharges.
conversion de compte
Le compte peut être librement converti entre EOA et SC, brisant certaines hypothèses de sécurité qui limitaient la participation des projets uniquement aux EOA. Les développeurs doivent supposer que les futurs participants pourraient tous être des contrats intelligents.
compatibilité des contrats
Les développeurs doivent s'assurer que le contrat cible délégué par l'utilisateur implémente les fonctions de rappel appropriées afin de être compatible avec les principaux jetons.
vérification de phishing
Les fournisseurs de services de portefeuille doivent rapidement prendre en charge le type de transaction EIP-7702, mettre en évidence le contrat cible lors de la signature déléguée par l'utilisateur, et procéder à une analyse automatique approfondie pour atténuer les risques de phishing.
Résumé
EIP-7702, grâce à un nouveau type de transaction, permet aux EOA d'avoir une programmabilité et une combinaison, brouillant ainsi la frontière entre les EOA et les comptes de contrat. Différents participants de l'écosystème font face à de nombreux défis et opportunités, les meilleures pratiques proposées dans cet article valent la peine d'être appliquées dans la pratique.
Veuillez générer un commentaire en chinois :
L'opportunité de gagner de l'argent arrive !