L'abstraction de compte (Account Abstraction, AA) est une direction importante d'exploration à long terme dans l'écosystème Ethereum, visant à briser la frontière entre les comptes externes (EOA) et les comptes de contrat, permettant aux portefeuilles d'avoir une plus grande programmabilité, sécurité et évolutivité. L'EIP-4337, étant la solution AA la plus répandue actuellement, a été largement adoptée dans un certain nombre de portefeuilles de contrats intelligents basés sur EntryPoint (comme Safe, Stacks, Argent). Cependant, l'EIP-4337, en raison de l'introduction d'un pool de transactions indépendant et d'un mécanisme de contrat d'entrée, présente encore certaines limitations en termes de nativité sur la chaîne, de complexité opérationnelle et de compatibilité écologique.
Afin de réduire davantage la barrière à l’entrée et d’améliorer la prise en charge native des abstractions de compte, Vitalik a proposé l’EIP-7702 en 2024 et l’a inclus dans la mise à niveau de Pectra. L’idée centrale de l’EIP-7702 est de permettre à un EOA original d’exécuter le code du contrat (contrat_code) à une adresse spécifiée lors de l’initiation d’une transaction, et d’utiliser ce code pour définir la logique d’exécution de la transaction.
L’EIP-7702 introduit un nouveau mécanisme d'« injection de code au niveau de la transaction », qui permet aux comptes d’utilisateurs de spécifier dynamiquement la logique d’exécution dans chaque transaction, plutôt que de s’appuyer sur du code contractuel pré-déployé. Cela rompt avec le modèle traditionnel d’autorisation basé sur le code statique, apporte une plus grande flexibilité et introduit de nouveaux défis de sécurité : les contrats qui reposent sur une logique de jugement telle que isContract et extcodehash peuvent devenir invalides, et certains systèmes qui supposent que l’appelant est un pur EOA peuvent être contournés. Pour les auditeurs, il est important non seulement de vérifier la sécurité du code injecté lui-même, mais aussi d’évaluer son impact potentiel sur d’autres systèmes contractuels dans un contexte dynamique.
Dans cet article, l'équipe de sécurité de Beosin examinera les principes de conception et les caractéristiques clés de l'EIP-7702. Ils dresseront un tableau systématique des risques de sécurité auxquels pourrait faire face un portefeuille AA construit sur cette base lors d'un audit, et proposeront des processus et des recommandations d'audit en se basant sur une perspective pratique, afin d'aider les chercheurs en sécurité à mieux faire face aux défis techniques posés par cette nouvelle paradigme.
I. Introduction à l'EIP-7702
Aperçu technique de l'EIP-7702
EIP-7702 a introduit un nouveau type de transaction 0x04 (SetCode), qui permet à un EOA d'autoriser le code de contrat à exécuter via cette transaction. La structure de la transaction est la suivante :
La liste authorization_list contient plusieurs listes d'autorisation, et peut également inclure des comportements d'autorisation de non-initiateurs de transactions. La structure interne est :
où chain_id représente la chaîne dans laquelle l’autorisation de l’utilisateur prend effet, et sa valeur doit être égale à l’ID de la chaîne en cours d’exécution ou être 0. Lorsque chain_id vaut 0, l’autorisation prend effet sur toutes les chaînes EVM qui prennent en charge EIP-7702, mais uniquement si d’autres paramètres (tels que nonce) correspondent. Adresse Indique l’adresse du contrat cible autorisée par l’utilisateur.
Après l'autorisation, le système modifiera le champ code de l'utilisateur autorisé en 0xef0100 || address, où address est l'adresse du contrat autorisé. Si vous souhaitez annuler l'autorisation, il vous suffit de lancer une transaction SetCode en définissant address sur 0.
Les avantages de l'EIP7702
(1) Flexibilité et personnalisation
Les comptes abstraits permettent de personnaliser les fonctionnalités en fonction des besoins en intégrant la logique des comptes dans des contrats intelligents. Par exemple, les utilisateurs peuvent configurer des signatures multiples, une récupération sociale, un contrôle des limites, etc., pour répondre aux différents besoins des particuliers ou des entreprises. Cette conception améliore considérablement l'extensibilité des fonctionnalités des comptes et surmonte les limitations des comptes externes traditionnels (EOA).
(2) Améliorer la sécurité
Les comptes abstraits offrent plusieurs mécanismes de sécurité, y compris l'authentification multiple, les limites de transaction et la récupération sociale. Même si un utilisateur perd sa clé privée, il peut récupérer son compte via des contacts de confiance ou une vérification multiple, évitant ainsi la perte permanente d'actifs due à la perte de la clé privée dans les comptes traditionnels. De plus, des fonctionnalités telles que le contrôle des limites peuvent également prévenir le vol malveillant de gros montants.
(3) Optimisation de Gas
Le compte abstrait prend en charge un mécanisme d'abstraction de Gas flexible, permettant aux utilisateurs de payer le Gas par des tiers, voire d'utiliser directement d'autres jetons pour payer les frais de transaction. Ce mécanisme réduit non seulement le coût d'opération pour les utilisateurs, mais simplifie également le processus d'utilisation de la blockchain, en particulier pour les utilisateurs novices ou les scénarios de transactions complexes en plusieurs étapes.
(4) Aider à la vulgarisation de Web3
En optimisant l’expérience et la sécurité, les comptes abstraits cachent la complexité de la blockchain là où les utilisateurs ne peuvent pas la voir, offrant ainsi un fonctionnement pratique plus proche du Web2. Cette conception réduit le coût d’apprentissage pour les utilisateurs ordinaires, permet à davantage de personnes de participer aux applications Web3 sans barrières et favorise la popularisation de la technologie décentralisée.
II. Analyse des risques de sécurité de l'EIP-7702 dans la pratique
Bien que l'EIP-7702 ait injecté une nouvelle dynamique dans l'écosystème Ethereum et élargi les scénarios d'application, il a également inévitablement introduit certaines nouvelles vulnérabilités de sécurité :
Attaque par répétition autorisée
Dans le modèle EIP-7702, si un utilisateur définit le champ chain_id dans l'autorisation sur 0, cela signifie que cette autorisation est valable sur plusieurs chaînes. Bien que ce design de « permission transversale » améliore la flexibilité dans certaines situations, il introduit également des risques de sécurité évidents.
Il est particulièrement important de noter que même si l'identifiant de compte à la même adresse sur différentes chaînes est identique, la mise en œuvre des contrats sous-jacents peut être complètement différente. Cela signifie qu'un attaquant pourrait déployer une version malveillante d'un contrat sur une autre chaîne, exploitant le comportement d'autorisation à la même adresse sur la chaîne pour effectuer des opérations non prévues, ce qui peut mettre en danger les actifs des utilisateurs.
Ainsi, pour les fournisseurs de services de portefeuille ou les plateformes d'interaction frontale, lorsqu'un utilisateur effectue ce type d'opération d'autorisation, il est important de vérifier clairement si le chainId déclaré dans l'autorisation de l'utilisateur correspond au réseau actuellement connecté ; si l'utilisateur définit le chainId sur 0, un avertissement clair sur les risques doit être donné, informant l'utilisateur que cette autorisation sera effective sur toutes les chaînes compatibles avec EVM et pourrait être abusée par des contrats malveillants.
De plus, le prestataire de services doit également évaluer s'il convient de limiter ou d'interdire par défaut l'autorisation avec un chainId de 0 au niveau de l'interface utilisateur, afin de réduire le risque d'erreurs d'opération ou d'attaques de phishing.
Problèmes de compatibilité des contrats
(1) Compatibilité de rappel de contrat
Les contrats de tokens tels que ERC-721, ERC-777 et ERC1155, lorsqu'ils effectuent un transfert vers une adresse de contrat, appellent l'interface de rappel standard (comme onERC721Received, tokensReceived) pour finaliser l'opération de transfert. Si l'adresse de réception n'implémente pas l'interface correspondante, le transfert échouera et pourra même entraîner le blocage des actifs.
Dans l'EIP-7702, une adresse utilisateur peut se voir attribuer un code de contrat via l'opération « set_code », devenant ainsi un compte de contrat. À ce moment-là :
L'adresse de l'utilisateur sera considérée comme un contrat ;
Si le contrat n'implémente pas l'interface de rappel nécessaire, cela entraînera l'échec du transfert de jetons ;
Les utilisateurs peuvent ne pas être en mesure de recevoir des jetons majeurs sans le savoir.
Par conséquent, les développeurs doivent s'assurer que le contrat cible délégué par l'utilisateur implémente les interfaces de rappel pertinentes afin de garantir la compatibilité avec les jetons principaux.
(2) L'échec de la vérification de « tx.origin »
Dans les contrats traditionnels, « tx.origin » est souvent utilisé pour déterminer si la transaction a été initiée directement par l'utilisateur, afin de prévenir les appels de contrat et autres contrôles de sécurité.
Mais dans le cadre de l'EIP-7702 :
L'utilisateur signe une transaction autorisée, qui est en réalité diffusée par un relais ou un service de regroupement (bundler) ; lors de l'exécution de la transaction, « tx.origin » est l'adresse du relais, et non l'adresse de l'utilisateur.
« msg.sender » est le contrat de portefeuille qui représente l'identité de l'utilisateur.
Ainsi, une vérification des autorisations basée sur « tx.origin == msg.sender » conduira à un refus d'opérations pour les utilisateurs légitimes, entraînant une perte de fiabilité. De même, l'utilisation de restrictions telles que « tx.origin == user » pour les appels de contrats sera également inefficace. Il est recommandé d'abandonner « tx.origin » comme critère de sécurité et de privilégier la vérification par signature ou les mécanismes d'autorisation.
(3) "isContract" erreur de jugement
De nombreux contrats empêchent les comptes de contrat de participer à certaines opérations, telles que des airdrops, des achats rapides, etc., via « isContract (address) » (vérification de la longueur du code d'adresse) :
Sous le mécanisme EIP-7702, l'adresse de l'utilisateur peut devenir un compte de contrat via la transaction « set_code », « isContract » renvoie true, le contrat peut mal interpréter un utilisateur légitime comme un compte de contrat, refusant sa participation aux opérations, ce qui empêche l'utilisateur d'accéder à certains services et entrave son expérience.
Avec la popularité croissante des portefeuilles de contrats, la conception reposant sur « isContract » pour déterminer « si l'utilisateur est humain » n'est plus sécurisée. Il est recommandé d'adopter des méthodes d'identification des utilisateurs plus précises, telles que la vérification par signature.
Attaque par hameçonnage
Après la mise en œuvre du mécanisme de délégation EIP-7702, les actifs du compte utilisateur seront entièrement contrôlés par le contrat intelligent délégué. Une fois qu'un utilisateur a autorisé un contrat malveillant, un attaquant peut ainsi obtenir un contrôle total sur les actifs du compte, entraînant un transfert ou un vol rapide des fonds, ce qui présente un risque de sécurité très élevé.
Par conséquent, il est important que les fournisseurs de services de portefeuille prennent en charge les mécanismes de résolution des transactions et d’identification des risques EIP-7702 dès que possible. Lorsqu’un utilisateur signe une transaction de mandat, le front-end doit afficher clairement et bien en évidence l’adresse du contrat cible et combiner des informations complémentaires telles que la source du contrat et les informations de déploiement pour aider les utilisateurs à identifier les comportements potentiels d’hameçonnage ou de fraude, réduisant ainsi le risque de mauvaise signature. En outre, le service de portefeuille doit intégrer des fonctionnalités d’analyse de sécurité automatisée pour le contrat cible, telles que la vérification du statut open source du code du contrat, l’analyse du modèle d’autorisation et l’identification des opérations potentiellement dangereuses, afin d’aider les utilisateurs à prendre des décisions plus sûres avant l’autorisation.
Il est particulièrement important de noter que le format de signature déléguée introduit par l'EIP-7702 n'est pas compatible avec les normes de signature existantes EIP-191 et EIP-712. Cette signature peut facilement contourner les alertes de signature et les messages d'interaction d'origine du portefeuille, augmentant ainsi le risque que l'utilisateur soit trompé et signe des opérations malveillantes. Par conséquent, l'introduction d'un mécanisme de reconnaissance et de traitement de cette structure de signature dans la mise en œuvre du portefeuille sera une étape clé pour garantir la sécurité des utilisateurs.
Risque de contrat de portefeuille
(1) Gestion des autorisations de contrat de portefeuille
De nombreux contrats de portefeuille EIP-7702 utilisent une architecture de proxy ( ou des autorisations de gestion intégrées ) pour prendre en charge les mises à niveau logiques. Cependant, cela entraîne également un risque accru en matière de gestion des autorisations. Si les droits de mise à niveau ne sont pas strictement limités, des attaquants pourraient remplacer le contrat d'implémentation et injecter du code malveillant, entraînant la compromission des comptes utilisateurs ou le vol de fonds.
Conseils de sécurité :
Utiliser la signature multiple, l'authentification à facteurs multiples ou un mécanisme de verrouillage temporel pour contrôler les droits de mise à niveau.
Les modifications de code et de droits doivent être soumises à un audit rigoureux et à une validation de sécurité.
Processus de mise à niveau ouvert et transparent, garantissant le droit à l'information et à la participation des utilisateurs.
(2) Risque de conflit de stockage et isolement des données
Les versions de contrat de portefeuille ou différents fournisseurs de services de portefeuille peuvent réutiliser le même emplacement de stockage (storage slot). Si un utilisateur change de fournisseur de services de portefeuille ou met à niveau la logique du portefeuille, la réutilisation de l'emplacement de stockage peut entraîner des conflits de variables d'état, des problèmes de surcharge de données et de lecture anormale. Cela peut non seulement perturber le bon fonctionnement du portefeuille, mais également entraîner des pertes de fonds ou des anomalies de droits.
Conseils de sécurité :
Utiliser des solutions d'isolement de stockage spécialisées (comme la norme EIP-1967) ou tirer parti d'un espace de noms unique pour gérer les emplacements de stockage.
Lors de la mise à niveau du contrat, assurez-vous que la disposition du stockage est compatible et évitez les chevauchements de variables.
Tester rigoureusement la rationalité de l'état de stockage dans le processus de mise à niveau.
(3) Gestion du nonce interne du portefeuille
Les contrats de portefeuille définissent généralement un nonce en interne et le gèrent eux-mêmes pour garantir l'ordre d'exécution des opérations des utilisateurs et prévenir les attaques par rejeu. Si le nonce est mal utilisé, cela peut entraîner des échecs dans l'exécution normale des opérations des utilisateurs.
Conseils de sécurité :
Le nonce doit être vérifié pour son équivalent (ou incrémenté), il ne peut pas être sauté.
Il est interdit de modifier directement le nonce dans la fonction, il doit être mis à jour par l'action de l'utilisateur lors de l'exécution.
Concevoir des mécanismes de tolérance aux pannes et de récupération pour les situations anormales de nonce, afin d'éviter le blocage du nonce.
( Vérification des autorisations de l'appelant de la fonction
Pour garantir la sécurité, le contrat du portefeuille doit s'assurer que l'appelant des fonctions clés est le compte propriétaire du portefeuille. Les deux méthodes courantes incluent :
Autorisation de signature hors chaîne
L'utilisateur signe un ensemble d'opérations avec une clé privée, et le contrat de portefeuille vérifie sur la chaîne si la signature est valide, si elle a expiré et si elle satisfait au nonce correspondant. Cette méthode est adaptée au modèle de transaction relais promu par l'EIP-7702 (signature hors ligne de l'utilisateur + envoi de transactions par un relais).
Appel de contrainte (msg.sender == adresse )this()
La fonction d'opération utilisateur ne peut être déclenchée que par l'appel de son propre contrat, ce qui est essentiellement un mécanisme de contrôle des chemins d'appel, garantissant que l'initiateur externe doit être le compte lui-même. Cela équivaut en réalité à exiger que l'appelant soit le EOA d'origine, car à ce stade, l'adresse du contrat est en fait l'adresse EOA.
Trois, Perspectives : EIP-7702 et la future norme de portefeuille AA
La proposition de l'EIP-7702 représente non seulement une innovation par rapport au modèle de compte traditionnel, mais aussi un important coup de pouce à l'écosystème de l'abstraction de compte. La capacité qu'il introduit permettant aux utilisateurs de charger le code des contrats ouvre un large espace d'exploration pour la conception des portefeuilles et le système des contrats à l'avenir, tout en posant de nouvelles exigences pour les normes d'audit de sécurité.
Évolution collaborative avec EIP-4337 : vers une compatibilité bimodale
Bien que l'EIP-7702 et l'EIP-4337 aient des objectifs différents en termes de conception, le premier reconstruit le mécanisme de chargement du code des comptes, tandis que le second construit une entrée de transaction complète et un écosystème d'emballage. Cependant, les deux ne sont pas en conflit, mais au contraire, présentent une forte complémentarité :
EIP-4337 propose un « canal de transaction général » et une « interface d'exécution de compte abstrait » ;
EIP-7702 permet aux comptes utilisateurs d'attribuer dynamiquement des capacités logiques de contrat sans changer d'adresse ;
Ainsi, le portefeuille futur pourrait adopter une « architecture de support double » : utiliser EIP-7702 comme alternative allégée sur les chaînes qui ne prennent pas en charge EIP-4337, tandis que dans les scénarios nécessitant un emballage hors chaîne et une agrégation multi-utilisateurs, continuer à s'appuyer sur la pile de protocoles complète d'EIP-4337.
Ce mécanisme bimodal encouragera également les portefeuilles à supporter un modèle de permissions de compte plus flexible au niveau du noyau, ainsi que des mécanismes de dégradation et des solutions de retour en arrière.
Support et inspiration pour les nouvelles logiques de portefeuille telles que MPC, ZK.
Le mécanisme de contractualisation des comptes proposé par l'EIP-7702 présente un potentiel d'intégration naturel avec les nouvelles architectures populaires telles que les portefeuilles MPC, les portefeuilles ZK et les portefeuilles modulaires.
Dans le mode MPC, le comportement de signature ne dépend plus d'une seule clé privée, mais plutôt d'une décision collaborative de plusieurs parties. Les signatures générées par la fusion de l'EIP-7702 et du MPC peuvent contrôler la logique contractuelle chargée dynamiquement, permettant ainsi des stratégies d'exécution plus flexibles.
Le portefeuille ZK vérifie l'identité ou l'autorisation de l'utilisateur via des preuves à divulgation nulle, sans avoir besoin de révéler les informations de clé privée. En combinaison avec EIP-7702, le portefeuille ZK peut injecter temporairement des contrats logiques spécifiques après la validation, permettant ainsi le déploiement de comportements personnalisés après un calcul privé, comme l'exécution automatique d'une certaine logique uniquement lorsque certaines conditions de confidentialité sont remplies.
Les portefeuilles modulaires (Modular Wallets) peuvent décomposer la logique des comptes en plusieurs modules grâce à l'EIP-7702, qui peuvent être chargés dynamiquement en cas de besoin.
Par conséquent, l’EIP-7702 fournit un « conteneur d’exécution » plus natif pour les portefeuilles avancés mentionnés ci-dessus : différentes logiques de contrat peuvent être injectées avec la même adresse utilisateur, évitant ainsi le problème de dépendance d’adresse dans le processus de déploiement de contrat traditionnel, et il n’y a pas besoin de pré-déploiement, ce qui améliore considérablement la flexibilité et la capacité de combinaison du comportement du compte.
Les enseignements pour les développeurs de contrats et les auditeurs
EIP-7702 va entraîner une transformation profonde du paradigme de développement. Les développeurs de contrats ne considèrent plus simplement l'appelant comme un EOA traditionnel ou un compte de contrat fixe, mais doivent s'adapter à un tout nouveau mécanisme : l'identité de l'appelant peut basculer dynamiquement entre EOA et état de contrat au cours du processus de transaction, la logique de comportement des comptes n'est plus figée de manière statique, mais peut changer de manière flexible en fonction des besoins. Cela exige que les développeurs et les auditeurs possèdent :
Introduction de logiques de validation et de contrôle d'accès des appelants plus strictes ;
Vérifiez si le chemin d'appel est affecté par la logique du contrat dynamique.
Identifier les vulnérabilités potentielles des comportements tels que msg.sender.code.length == 0, isContract )( ;
Clarifiez la "dépendance au contexte" de la logique des contrats, par exemple le contrôle des limites des appels statiques et de deleGatecall ;
Support de la simulation et de l'analyse de restauration du scénario setCode au niveau de la chaîne d'outils.
En d'autres termes, la sécurité du code n'est plus simplement un « problème avant le déploiement », mais devient un « processus dynamique qui doit également être vérifié pendant l'appel et la transaction ».
Quatre, résumé
L’EIP-7702 introduit une implémentation plus légère, native et flexible de l’abstraction de compte (AA), qui permet à l’EOA ordinaire de porter la logique contractuelle et de l’exécuter en une seule transaction. Ce mécanisme brise les hypothèses statiques traditionnelles sur le comportement du compte, et les développeurs ne peuvent plus se fier simplement à l’état du code de l’adresse du compte pour juger de son modèle de comportement, mais doivent reconstruire la compréhension de l’identité et de la limite d’autorité de l’appelant. Cela s’accompagne d’un changement de paradigme dans l’analyse de la sécurité. L’audit ne se limite plus à « la question de savoir si une adresse dispose d’autorisations », mais se déplace vers « ce que la logique contractuelle portée dans la transaction peut faire dans le contexte actuel ». Chaque transaction peut comporter une définition indépendante du comportement, ce qui donne au compte une plus grande fonctionnalité et met en avant des exigences plus élevées pour les audits de sécurité.
Le contenu est fourni à titre de référence uniquement, il ne s'agit pas d'une sollicitation ou d'une offre. Aucun conseil en investissement, fiscalité ou juridique n'est fourni. Consultez l'Avertissement pour plus de détails sur les risques.
Beosin : Analyse de l'audit de sécurité du portefeuille AA de prochaine génération EIP-7702
Rédigé par : Beosin
L'abstraction de compte (Account Abstraction, AA) est une direction importante d'exploration à long terme dans l'écosystème Ethereum, visant à briser la frontière entre les comptes externes (EOA) et les comptes de contrat, permettant aux portefeuilles d'avoir une plus grande programmabilité, sécurité et évolutivité. L'EIP-4337, étant la solution AA la plus répandue actuellement, a été largement adoptée dans un certain nombre de portefeuilles de contrats intelligents basés sur EntryPoint (comme Safe, Stacks, Argent). Cependant, l'EIP-4337, en raison de l'introduction d'un pool de transactions indépendant et d'un mécanisme de contrat d'entrée, présente encore certaines limitations en termes de nativité sur la chaîne, de complexité opérationnelle et de compatibilité écologique.
Afin de réduire davantage la barrière à l’entrée et d’améliorer la prise en charge native des abstractions de compte, Vitalik a proposé l’EIP-7702 en 2024 et l’a inclus dans la mise à niveau de Pectra. L’idée centrale de l’EIP-7702 est de permettre à un EOA original d’exécuter le code du contrat (contrat_code) à une adresse spécifiée lors de l’initiation d’une transaction, et d’utiliser ce code pour définir la logique d’exécution de la transaction.
L’EIP-7702 introduit un nouveau mécanisme d'« injection de code au niveau de la transaction », qui permet aux comptes d’utilisateurs de spécifier dynamiquement la logique d’exécution dans chaque transaction, plutôt que de s’appuyer sur du code contractuel pré-déployé. Cela rompt avec le modèle traditionnel d’autorisation basé sur le code statique, apporte une plus grande flexibilité et introduit de nouveaux défis de sécurité : les contrats qui reposent sur une logique de jugement telle que isContract et extcodehash peuvent devenir invalides, et certains systèmes qui supposent que l’appelant est un pur EOA peuvent être contournés. Pour les auditeurs, il est important non seulement de vérifier la sécurité du code injecté lui-même, mais aussi d’évaluer son impact potentiel sur d’autres systèmes contractuels dans un contexte dynamique.
Dans cet article, l'équipe de sécurité de Beosin examinera les principes de conception et les caractéristiques clés de l'EIP-7702. Ils dresseront un tableau systématique des risques de sécurité auxquels pourrait faire face un portefeuille AA construit sur cette base lors d'un audit, et proposeront des processus et des recommandations d'audit en se basant sur une perspective pratique, afin d'aider les chercheurs en sécurité à mieux faire face aux défis techniques posés par cette nouvelle paradigme.
I. Introduction à l'EIP-7702
EIP-7702 a introduit un nouveau type de transaction 0x04 (SetCode), qui permet à un EOA d'autoriser le code de contrat à exécuter via cette transaction. La structure de la transaction est la suivante :
La liste authorization_list contient plusieurs listes d'autorisation, et peut également inclure des comportements d'autorisation de non-initiateurs de transactions. La structure interne est :
où chain_id représente la chaîne dans laquelle l’autorisation de l’utilisateur prend effet, et sa valeur doit être égale à l’ID de la chaîne en cours d’exécution ou être 0. Lorsque chain_id vaut 0, l’autorisation prend effet sur toutes les chaînes EVM qui prennent en charge EIP-7702, mais uniquement si d’autres paramètres (tels que nonce) correspondent. Adresse Indique l’adresse du contrat cible autorisée par l’utilisateur.
Après l'autorisation, le système modifiera le champ code de l'utilisateur autorisé en 0xef0100 || address, où address est l'adresse du contrat autorisé. Si vous souhaitez annuler l'autorisation, il vous suffit de lancer une transaction SetCode en définissant address sur 0.
(1) Flexibilité et personnalisation
Les comptes abstraits permettent de personnaliser les fonctionnalités en fonction des besoins en intégrant la logique des comptes dans des contrats intelligents. Par exemple, les utilisateurs peuvent configurer des signatures multiples, une récupération sociale, un contrôle des limites, etc., pour répondre aux différents besoins des particuliers ou des entreprises. Cette conception améliore considérablement l'extensibilité des fonctionnalités des comptes et surmonte les limitations des comptes externes traditionnels (EOA).
(2) Améliorer la sécurité
Les comptes abstraits offrent plusieurs mécanismes de sécurité, y compris l'authentification multiple, les limites de transaction et la récupération sociale. Même si un utilisateur perd sa clé privée, il peut récupérer son compte via des contacts de confiance ou une vérification multiple, évitant ainsi la perte permanente d'actifs due à la perte de la clé privée dans les comptes traditionnels. De plus, des fonctionnalités telles que le contrôle des limites peuvent également prévenir le vol malveillant de gros montants.
(3) Optimisation de Gas
Le compte abstrait prend en charge un mécanisme d'abstraction de Gas flexible, permettant aux utilisateurs de payer le Gas par des tiers, voire d'utiliser directement d'autres jetons pour payer les frais de transaction. Ce mécanisme réduit non seulement le coût d'opération pour les utilisateurs, mais simplifie également le processus d'utilisation de la blockchain, en particulier pour les utilisateurs novices ou les scénarios de transactions complexes en plusieurs étapes.
(4) Aider à la vulgarisation de Web3
En optimisant l’expérience et la sécurité, les comptes abstraits cachent la complexité de la blockchain là où les utilisateurs ne peuvent pas la voir, offrant ainsi un fonctionnement pratique plus proche du Web2. Cette conception réduit le coût d’apprentissage pour les utilisateurs ordinaires, permet à davantage de personnes de participer aux applications Web3 sans barrières et favorise la popularisation de la technologie décentralisée.
II. Analyse des risques de sécurité de l'EIP-7702 dans la pratique
Bien que l'EIP-7702 ait injecté une nouvelle dynamique dans l'écosystème Ethereum et élargi les scénarios d'application, il a également inévitablement introduit certaines nouvelles vulnérabilités de sécurité :
Dans le modèle EIP-7702, si un utilisateur définit le champ chain_id dans l'autorisation sur 0, cela signifie que cette autorisation est valable sur plusieurs chaînes. Bien que ce design de « permission transversale » améliore la flexibilité dans certaines situations, il introduit également des risques de sécurité évidents.
Il est particulièrement important de noter que même si l'identifiant de compte à la même adresse sur différentes chaînes est identique, la mise en œuvre des contrats sous-jacents peut être complètement différente. Cela signifie qu'un attaquant pourrait déployer une version malveillante d'un contrat sur une autre chaîne, exploitant le comportement d'autorisation à la même adresse sur la chaîne pour effectuer des opérations non prévues, ce qui peut mettre en danger les actifs des utilisateurs.
Ainsi, pour les fournisseurs de services de portefeuille ou les plateformes d'interaction frontale, lorsqu'un utilisateur effectue ce type d'opération d'autorisation, il est important de vérifier clairement si le chainId déclaré dans l'autorisation de l'utilisateur correspond au réseau actuellement connecté ; si l'utilisateur définit le chainId sur 0, un avertissement clair sur les risques doit être donné, informant l'utilisateur que cette autorisation sera effective sur toutes les chaînes compatibles avec EVM et pourrait être abusée par des contrats malveillants.
De plus, le prestataire de services doit également évaluer s'il convient de limiter ou d'interdire par défaut l'autorisation avec un chainId de 0 au niveau de l'interface utilisateur, afin de réduire le risque d'erreurs d'opération ou d'attaques de phishing.
(1) Compatibilité de rappel de contrat
Les contrats de tokens tels que ERC-721, ERC-777 et ERC1155, lorsqu'ils effectuent un transfert vers une adresse de contrat, appellent l'interface de rappel standard (comme onERC721Received, tokensReceived) pour finaliser l'opération de transfert. Si l'adresse de réception n'implémente pas l'interface correspondante, le transfert échouera et pourra même entraîner le blocage des actifs.
Dans l'EIP-7702, une adresse utilisateur peut se voir attribuer un code de contrat via l'opération « set_code », devenant ainsi un compte de contrat. À ce moment-là :
L'adresse de l'utilisateur sera considérée comme un contrat ;
Si le contrat n'implémente pas l'interface de rappel nécessaire, cela entraînera l'échec du transfert de jetons ;
Les utilisateurs peuvent ne pas être en mesure de recevoir des jetons majeurs sans le savoir.
Par conséquent, les développeurs doivent s'assurer que le contrat cible délégué par l'utilisateur implémente les interfaces de rappel pertinentes afin de garantir la compatibilité avec les jetons principaux.
(2) L'échec de la vérification de « tx.origin »
Dans les contrats traditionnels, « tx.origin » est souvent utilisé pour déterminer si la transaction a été initiée directement par l'utilisateur, afin de prévenir les appels de contrat et autres contrôles de sécurité. Mais dans le cadre de l'EIP-7702 :
L'utilisateur signe une transaction autorisée, qui est en réalité diffusée par un relais ou un service de regroupement (bundler) ; lors de l'exécution de la transaction, « tx.origin » est l'adresse du relais, et non l'adresse de l'utilisateur.
« msg.sender » est le contrat de portefeuille qui représente l'identité de l'utilisateur.
Ainsi, une vérification des autorisations basée sur « tx.origin == msg.sender » conduira à un refus d'opérations pour les utilisateurs légitimes, entraînant une perte de fiabilité. De même, l'utilisation de restrictions telles que « tx.origin == user » pour les appels de contrats sera également inefficace. Il est recommandé d'abandonner « tx.origin » comme critère de sécurité et de privilégier la vérification par signature ou les mécanismes d'autorisation.
(3) "isContract" erreur de jugement
De nombreux contrats empêchent les comptes de contrat de participer à certaines opérations, telles que des airdrops, des achats rapides, etc., via « isContract (address) » (vérification de la longueur du code d'adresse) :
Sous le mécanisme EIP-7702, l'adresse de l'utilisateur peut devenir un compte de contrat via la transaction « set_code », « isContract » renvoie true, le contrat peut mal interpréter un utilisateur légitime comme un compte de contrat, refusant sa participation aux opérations, ce qui empêche l'utilisateur d'accéder à certains services et entrave son expérience. Avec la popularité croissante des portefeuilles de contrats, la conception reposant sur « isContract » pour déterminer « si l'utilisateur est humain » n'est plus sécurisée. Il est recommandé d'adopter des méthodes d'identification des utilisateurs plus précises, telles que la vérification par signature.
Après la mise en œuvre du mécanisme de délégation EIP-7702, les actifs du compte utilisateur seront entièrement contrôlés par le contrat intelligent délégué. Une fois qu'un utilisateur a autorisé un contrat malveillant, un attaquant peut ainsi obtenir un contrôle total sur les actifs du compte, entraînant un transfert ou un vol rapide des fonds, ce qui présente un risque de sécurité très élevé.
Par conséquent, il est important que les fournisseurs de services de portefeuille prennent en charge les mécanismes de résolution des transactions et d’identification des risques EIP-7702 dès que possible. Lorsqu’un utilisateur signe une transaction de mandat, le front-end doit afficher clairement et bien en évidence l’adresse du contrat cible et combiner des informations complémentaires telles que la source du contrat et les informations de déploiement pour aider les utilisateurs à identifier les comportements potentiels d’hameçonnage ou de fraude, réduisant ainsi le risque de mauvaise signature. En outre, le service de portefeuille doit intégrer des fonctionnalités d’analyse de sécurité automatisée pour le contrat cible, telles que la vérification du statut open source du code du contrat, l’analyse du modèle d’autorisation et l’identification des opérations potentiellement dangereuses, afin d’aider les utilisateurs à prendre des décisions plus sûres avant l’autorisation.
Il est particulièrement important de noter que le format de signature déléguée introduit par l'EIP-7702 n'est pas compatible avec les normes de signature existantes EIP-191 et EIP-712. Cette signature peut facilement contourner les alertes de signature et les messages d'interaction d'origine du portefeuille, augmentant ainsi le risque que l'utilisateur soit trompé et signe des opérations malveillantes. Par conséquent, l'introduction d'un mécanisme de reconnaissance et de traitement de cette structure de signature dans la mise en œuvre du portefeuille sera une étape clé pour garantir la sécurité des utilisateurs.
(1) Gestion des autorisations de contrat de portefeuille
De nombreux contrats de portefeuille EIP-7702 utilisent une architecture de proxy ( ou des autorisations de gestion intégrées ) pour prendre en charge les mises à niveau logiques. Cependant, cela entraîne également un risque accru en matière de gestion des autorisations. Si les droits de mise à niveau ne sont pas strictement limités, des attaquants pourraient remplacer le contrat d'implémentation et injecter du code malveillant, entraînant la compromission des comptes utilisateurs ou le vol de fonds.
Conseils de sécurité :
Utiliser la signature multiple, l'authentification à facteurs multiples ou un mécanisme de verrouillage temporel pour contrôler les droits de mise à niveau.
Les modifications de code et de droits doivent être soumises à un audit rigoureux et à une validation de sécurité.
Processus de mise à niveau ouvert et transparent, garantissant le droit à l'information et à la participation des utilisateurs.
(2) Risque de conflit de stockage et isolement des données
Les versions de contrat de portefeuille ou différents fournisseurs de services de portefeuille peuvent réutiliser le même emplacement de stockage (storage slot). Si un utilisateur change de fournisseur de services de portefeuille ou met à niveau la logique du portefeuille, la réutilisation de l'emplacement de stockage peut entraîner des conflits de variables d'état, des problèmes de surcharge de données et de lecture anormale. Cela peut non seulement perturber le bon fonctionnement du portefeuille, mais également entraîner des pertes de fonds ou des anomalies de droits.
Conseils de sécurité :
Utiliser des solutions d'isolement de stockage spécialisées (comme la norme EIP-1967) ou tirer parti d'un espace de noms unique pour gérer les emplacements de stockage.
Lors de la mise à niveau du contrat, assurez-vous que la disposition du stockage est compatible et évitez les chevauchements de variables.
Tester rigoureusement la rationalité de l'état de stockage dans le processus de mise à niveau.
(3) Gestion du nonce interne du portefeuille
Les contrats de portefeuille définissent généralement un nonce en interne et le gèrent eux-mêmes pour garantir l'ordre d'exécution des opérations des utilisateurs et prévenir les attaques par rejeu. Si le nonce est mal utilisé, cela peut entraîner des échecs dans l'exécution normale des opérations des utilisateurs.
Conseils de sécurité :
Le nonce doit être vérifié pour son équivalent (ou incrémenté), il ne peut pas être sauté.
Il est interdit de modifier directement le nonce dans la fonction, il doit être mis à jour par l'action de l'utilisateur lors de l'exécution.
Concevoir des mécanismes de tolérance aux pannes et de récupération pour les situations anormales de nonce, afin d'éviter le blocage du nonce.
( Vérification des autorisations de l'appelant de la fonction
Pour garantir la sécurité, le contrat du portefeuille doit s'assurer que l'appelant des fonctions clés est le compte propriétaire du portefeuille. Les deux méthodes courantes incluent :
Autorisation de signature hors chaîne
L'utilisateur signe un ensemble d'opérations avec une clé privée, et le contrat de portefeuille vérifie sur la chaîne si la signature est valide, si elle a expiré et si elle satisfait au nonce correspondant. Cette méthode est adaptée au modèle de transaction relais promu par l'EIP-7702 (signature hors ligne de l'utilisateur + envoi de transactions par un relais).
Appel de contrainte (msg.sender == adresse )this()
La fonction d'opération utilisateur ne peut être déclenchée que par l'appel de son propre contrat, ce qui est essentiellement un mécanisme de contrôle des chemins d'appel, garantissant que l'initiateur externe doit être le compte lui-même. Cela équivaut en réalité à exiger que l'appelant soit le EOA d'origine, car à ce stade, l'adresse du contrat est en fait l'adresse EOA.
Trois, Perspectives : EIP-7702 et la future norme de portefeuille AA
La proposition de l'EIP-7702 représente non seulement une innovation par rapport au modèle de compte traditionnel, mais aussi un important coup de pouce à l'écosystème de l'abstraction de compte. La capacité qu'il introduit permettant aux utilisateurs de charger le code des contrats ouvre un large espace d'exploration pour la conception des portefeuilles et le système des contrats à l'avenir, tout en posant de nouvelles exigences pour les normes d'audit de sécurité.
Bien que l'EIP-7702 et l'EIP-4337 aient des objectifs différents en termes de conception, le premier reconstruit le mécanisme de chargement du code des comptes, tandis que le second construit une entrée de transaction complète et un écosystème d'emballage. Cependant, les deux ne sont pas en conflit, mais au contraire, présentent une forte complémentarité :
EIP-4337 propose un « canal de transaction général » et une « interface d'exécution de compte abstrait » ;
EIP-7702 permet aux comptes utilisateurs d'attribuer dynamiquement des capacités logiques de contrat sans changer d'adresse ;
Ainsi, le portefeuille futur pourrait adopter une « architecture de support double » : utiliser EIP-7702 comme alternative allégée sur les chaînes qui ne prennent pas en charge EIP-4337, tandis que dans les scénarios nécessitant un emballage hors chaîne et une agrégation multi-utilisateurs, continuer à s'appuyer sur la pile de protocoles complète d'EIP-4337.
Ce mécanisme bimodal encouragera également les portefeuilles à supporter un modèle de permissions de compte plus flexible au niveau du noyau, ainsi que des mécanismes de dégradation et des solutions de retour en arrière.
Le mécanisme de contractualisation des comptes proposé par l'EIP-7702 présente un potentiel d'intégration naturel avec les nouvelles architectures populaires telles que les portefeuilles MPC, les portefeuilles ZK et les portefeuilles modulaires.
Dans le mode MPC, le comportement de signature ne dépend plus d'une seule clé privée, mais plutôt d'une décision collaborative de plusieurs parties. Les signatures générées par la fusion de l'EIP-7702 et du MPC peuvent contrôler la logique contractuelle chargée dynamiquement, permettant ainsi des stratégies d'exécution plus flexibles.
Le portefeuille ZK vérifie l'identité ou l'autorisation de l'utilisateur via des preuves à divulgation nulle, sans avoir besoin de révéler les informations de clé privée. En combinaison avec EIP-7702, le portefeuille ZK peut injecter temporairement des contrats logiques spécifiques après la validation, permettant ainsi le déploiement de comportements personnalisés après un calcul privé, comme l'exécution automatique d'une certaine logique uniquement lorsque certaines conditions de confidentialité sont remplies.
Les portefeuilles modulaires (Modular Wallets) peuvent décomposer la logique des comptes en plusieurs modules grâce à l'EIP-7702, qui peuvent être chargés dynamiquement en cas de besoin.
Par conséquent, l’EIP-7702 fournit un « conteneur d’exécution » plus natif pour les portefeuilles avancés mentionnés ci-dessus : différentes logiques de contrat peuvent être injectées avec la même adresse utilisateur, évitant ainsi le problème de dépendance d’adresse dans le processus de déploiement de contrat traditionnel, et il n’y a pas besoin de pré-déploiement, ce qui améliore considérablement la flexibilité et la capacité de combinaison du comportement du compte.
EIP-7702 va entraîner une transformation profonde du paradigme de développement. Les développeurs de contrats ne considèrent plus simplement l'appelant comme un EOA traditionnel ou un compte de contrat fixe, mais doivent s'adapter à un tout nouveau mécanisme : l'identité de l'appelant peut basculer dynamiquement entre EOA et état de contrat au cours du processus de transaction, la logique de comportement des comptes n'est plus figée de manière statique, mais peut changer de manière flexible en fonction des besoins. Cela exige que les développeurs et les auditeurs possèdent :
Introduction de logiques de validation et de contrôle d'accès des appelants plus strictes ;
Vérifiez si le chemin d'appel est affecté par la logique du contrat dynamique.
Identifier les vulnérabilités potentielles des comportements tels que msg.sender.code.length == 0, isContract )( ;
Clarifiez la "dépendance au contexte" de la logique des contrats, par exemple le contrôle des limites des appels statiques et de deleGatecall ;
Support de la simulation et de l'analyse de restauration du scénario setCode au niveau de la chaîne d'outils.
En d'autres termes, la sécurité du code n'est plus simplement un « problème avant le déploiement », mais devient un « processus dynamique qui doit également être vérifié pendant l'appel et la transaction ».
Quatre, résumé
L’EIP-7702 introduit une implémentation plus légère, native et flexible de l’abstraction de compte (AA), qui permet à l’EOA ordinaire de porter la logique contractuelle et de l’exécuter en une seule transaction. Ce mécanisme brise les hypothèses statiques traditionnelles sur le comportement du compte, et les développeurs ne peuvent plus se fier simplement à l’état du code de l’adresse du compte pour juger de son modèle de comportement, mais doivent reconstruire la compréhension de l’identité et de la limite d’autorité de l’appelant. Cela s’accompagne d’un changement de paradigme dans l’analyse de la sécurité. L’audit ne se limite plus à « la question de savoir si une adresse dispose d’autorisations », mais se déplace vers « ce que la logique contractuelle portée dans la transaction peut faire dans le contexte actuel ». Chaque transaction peut comporter une définition indépendante du comportement, ce qui donne au compte une plus grande fonctionnalité et met en avant des exigences plus élevées pour les audits de sécurité.