Qu’est-ce que l’EIP-7702 ?

L’EIP-7702 est une proposition centrale du protocole qui modifie les capacités des comptes Ethereum. EIP signifie Ethereum Improvement Proposal, soit « proposition d’amélioration d’Ethereum » ; 7702 est le numéro de la proposition. Elle permet à un compte externe de déléguer l’exécution de son code à un code de contrat intelligent déjà déployé, tout en conservant son adresse, son solde et le contrôle par sa clé privée.

Un compte externe (Externally Owned Account, EOA) est un compte Ethereum contrôlé par une clé privée, généralement utilisé par un portefeuille individuel. Un EOA traditionnel peut signer et lancer des transactions, mais il ne peut pas intégrer lui-même des opérations groupées, des règles d’autorisation ou une logique de récupération comme le ferait un compte de contrat intelligent. L’EIP-7702 relie ces deux modèles : un EOA peut exécuter un code de contrat désigné dans le contexte de son propre compte, sans déplacer ses actifs vers une nouvelle adresse.

La proposition a atteint le statut Final et a été activée sur le réseau principal Ethereum le 7 mai 2025 dans le cadre de la mise à niveau Pectra. Elle définit un mécanisme de délégation sous-jacent, et non un produit de portefeuille complet. La disponibilité de fonctions comme les opérations groupées, la prise en charge du gas, les autorisations de session ou la récupération de compte dépend du contrat délégué choisi par le portefeuille et de son implémentation.

Quel problème résout-elle ?

Un EOA traditionnel est simple : toute personne capable d’utiliser la clé privée correspondante peut signer et contrôler le compte. Mais ce compte ne contient pas de logique programmable. Si un utilisateur veut autoriser un token, échanger un actif puis déposer le résultat dans un autre protocole, il doit généralement confirmer plusieurs transactions séparément. Les frais de gas sont aussi habituellement payés avec l’ETH, l’actif natif d’Ethereum, détenu par le compte.

Un compte de contrat intelligent peut ajouter des règles de validation et d’exécution plus complexes. Toutefois, créer un nouveau compte de contrat peut imposer une nouvelle adresse et nécessiter de gérer la migration des actifs, la compatibilité avec les applications ainsi que la continuité de l’historique ou de l’identité du compte.

L’EIP-7702 permet à un EOA existant de pointer vers un code de contrat. Un portefeuille peut ainsi ajouter des capacités définies par du code sans changer l’adresse du compte. La proposition ne supprime pas le contrôle existant par clé privée et ne met pas automatiquement à niveau tous les EOA. La délégation n’est inscrite dans l’état d’Ethereum qu’après la signature et la soumission d’une autorisation valide par le compte.

Comment une autorisation prend-elle effet ?

L’EIP-7702 introduit le type de transaction 0x04. Cette transaction peut contenir une ou plusieurs autorisations, chacune indiquant qu’un EOA accepte de déléguer l’exécution du code à une adresse cible.

Du point de vue de l’utilisateur, le processus comporte cinq étapes :

1. Le portefeuille sélectionne le code du contrat délégué qu’il prévoit d’utiliser et présente l’autorisation à l’utilisateur.
2. L’EOA signe l’autorisation et confirme le réseau cible, l’adresse déléguée ainsi que le numéro de séquence actuel du compte, appelé nonce.
3. Une transaction de type 4 soumet l’autorisation au réseau. Son émetteur peut être l’EOA ou un autre compte qui paie les frais de gas à sa place.
4. Après validation de la signature et du nonce, les nœuds du réseau inscrivent sur l’EOA un marqueur de délégation qui pointe vers le code cible.
5. Lorsqu’un autre compte ou contrat appelle ensuite l’EOA, le code du contrat cible traite l’appel en utilisant l’adresse, le solde et le contexte de stockage propres à l’EOA.

Plusieurs champs de l’autorisation limitent des risques différents :

La délégation ne transfère pas les actifs à l’adresse cible. Le code cible s’exécute dans le contexte de l’EOA qui l’a autorisé : il lit et modifie donc le stockage de cet EOA, et utilise son adresse et son solde. C’est aussi pour cette raison que le code délégué peut disposer d’un contrôle très étendu sur le compte.

Que change l’autorisation pour le compte ?

Le compte conserve la même adresse après la délégation, son solde existant n’est pas transféré automatiquement et sa clé privée peut toujours signer des transactions. Le changement est ailleurs : le champ de code du compte contient un marqueur spécial qui pointe vers le code du contrat cible. Les appels adressés au compte sont ensuite traités selon le code référencé par ce marqueur.

La délégation persiste. Elle ne disparaît pas automatiquement après une transaction. Elle reste active jusqu’à ce que le compte utilise une nouvelle autorisation valide pour pointer vers un autre code ou qu’il l’efface. Un utilisateur ne doit donc pas supposer que l’autorisation a pris fin simplement parce qu’une opération groupée donnée est terminée.

La mise en place de l’autorisation et l’exécution de l’appel qui suit constituent aussi deux étapes distinctes. Selon les règles de traitement de l’EIP-7702, une délégation déjà traitée n’est pas automatiquement annulée si l’exécution ultérieure de la transaction de type 4 échoue. Le portefeuille doit présenter et vérifier séparément « la délégation a été inscrite » et « l’action prévue a réussi ».

Quelles fonctions de compte peut-elle prendre en charge ?

L’EIP-7702 fournit un outil de base aux portefeuilles. Des conceptions courantes peuvent utiliser le code délégué pour proposer :

• une seule procédure de signature pour plusieurs opérations, comme l’autorisation, l’échange et le dépôt ;
• la soumission et le paiement du gas par un autre compte ou service ;
• des autorisations précises, comme des clés de session, des plafonds par utilisation ou des cibles limitées ;
• des méthodes d’authentification autres que la signature d’une seule clé privée ;
• des fonctions de récupération, de pause ou de contrôle des dépenses ;
• une compatibilité avec l’infrastructure de compte intelligent fondée sur la norme d’abstraction de compte ERC-4337.

L’EIP-7702 ne garantit aucune de ces fonctions. Elle définit comment autoriser et inscrire une délégation, puis exécuter le code référencé. Le contrat délégué et l’interface du portefeuille déterminent les fonctions disponibles, la manière dont une action est validée et la procédure de récupération en cas de problème.

La prise en charge du gas ne signifie pas qu’Ethereum cesse de facturer du gas. Une transaction de type 4 permet à un autre compte d’être l’émetteur de la transaction externe, d’y inclure l’autorisation de l’EOA et d’en payer les frais de gas. La décision d’un service de prendre ces frais en charge, leur mode de règlement et le payeur des appels ultérieurs relèvent du portefeuille ou du service.

En quoi diffère-t-elle d’un compte intelligent ?

« Compte intelligent » est une expression générale qui désigne une expérience de compte dans laquelle du code programmable définit les règles de validation et d’exécution. L’EIP-7702 est un mécanisme au niveau du protocole permettant cette expérience, mais elle ne se confond pas avec toutes les conceptions de compte intelligent.

L’ERC-4337 est une autre norme d’abstraction de compte. Elle organise les actions au moyen d’un objet de données UserOperation qui décrit l’intention de l’utilisateur, de bundlers qui regroupent les opérations et d’un contrat EntryPoint qui les valide et les exécute. Elle n’exige pas que la couche de consensus d’Ethereum ajoute une règle de transaction pour chaque conception de compte. L’EIP-7702 permet au contraire à un EOA de définir une délégation de code directement dans l’état du protocole. Les deux mécanismes peuvent fonctionner ensemble : l’ERC-4337 définit comment son flux d’opérations utilisateur peut inclure une autorisation EIP-7702.

L’EIP-7702 ne transforme pas non plus automatiquement un EOA ordinaire en compte exclusivement contrôlé par une véritable règle multisignature. Même si le code délégué exige plusieurs approbations, la clé privée d’origine peut toujours remplacer ou effacer la délégation et contourner une règle durable imposée uniquement par le délégué actuel. Si une application exige un modèle de contrôle qu’une seule clé privée d’origine ne peut pas remplacer, elle ne peut pas conclure que ce modèle existe du seul fait qu’une délégation EIP-7702 a été définie.

Comment remplacer ou révoquer la délégation ?

Le compte peut signer une nouvelle autorisation pointant vers une autre adresse cible. Pour effacer la délégation, il peut définir l’adresse zéro comme cible de l’autorisation. La nouvelle autorisation doit encore satisfaire aux contrôles du réseau, de la signature et du nonce, puis être inscrite sur la chaîne par une transaction de type 4.

Effacer la délégation supprime le pointeur de code, mais n’efface pas automatiquement les données que le code délégué précédent a écrites dans le stockage du compte. Si le compte utilise ensuite un autre code, celui-ci peut lire les anciennes données ou interpréter différemment le même emplacement de stockage. La conception du contrat délégué doit tenir compte de l’initialisation, des mises à niveau et de la compatibilité du stockage. Avant de changer d’implémentation, l’utilisateur doit aussi vérifier si son portefeuille propose une procédure adaptée de migration et de récupération.

Révoquer la délégation ne remplace pas la protection de la clé privée. Si la clé est compromise, un attaquant peut toujours signer une nouvelle autorisation, remplacer le délégué ou contrôler directement le compte. Le code délégué peut ajouter des règles opérationnelles, mais la clé d’origine reste un identifiant de contrôle essentiel.

Principaux risques et points à vérifier

Code délégué malveillant ou défectueux

Le code délégué s’exécute dans le contexte propre à l’EOA et peut appeler d’autres contrats, transférer des actifs ou modifier le stockage. Un code malveillant ou vulnérable peut obtenir un contrôle opérationnel presque complet du compte. Un portefeuille doit vérifier le code cible et ses droits de mise à niveau, et ne doit pas demander aux utilisateurs de signer pour une adresse déléguée inconnue.

Hameçonnage par autorisation

Une autorisation EIP-7702 peut affecter de nombreuses transactions futures et possède donc une portée plus large qu’une signature de transfert unique. Si une interface affiche seulement « se connecter » ou « activer une fonction » sans montrer clairement le réseau cible, le code délégué et la persistance, l’utilisateur peut sous-estimer l’autorisation. Les recommandations officielles d’Ethereum préconisent que les portefeuilles gèrent les interactions de délégation et vérifient le code cible, plutôt que de laisser une page web ordinaire demander des autorisations arbitraires.

Rejeu interchaîne et différences d’adresse

Le champ chain_id limite l’autorisation à un réseau. La valeur 0 peut permettre d’utiliser la même autorisation sur plusieurs chaînes, alors qu’une même adresse ne contient pas nécessairement le même code sur tous les réseaux. Même si le texte de l’adresse est identique, le code et l’état du compte peuvent différer. Le portefeuille doit vérifier ensemble le réseau, l’adresse cible et le code réellement déployé sur ce réseau.

Initialisation et conflits de stockage

Un nouveau code délégué peut d’abord devoir enregistrer un propriétaire, des autorisations ou d’autres données initiales. Si une autre partie peut exécuter l’initialisation en premier, le compte risque d’être mal configuré. Lorsque la délégation change, des implémentations qui réutilisent les mêmes emplacements de stockage peuvent aussi créer des conflits de données ou d’autorisations.

Les anciennes hypothèses des applications ne tiennent plus

Certaines applications ont considéré que « le compte ne contient actuellement aucun code » prouvait qu’il s’agissait d’un compte utilisateur ordinaire, ou ont utilisé tx.origin pour déduire l’origine d’un appel. L’EIP-7702 permet à un EOA d’exécuter du code délégué : ces hypothèses ne sont donc plus fiables et peuvent aussi créer des risques de réentrance. Les applications doivent valider les autorisations à partir du modèle réel d’appel et d’autorisation, et non des anciennes caractéristiques de type du compte.

Questions fréquentes

La délégation change-t-elle l’adresse du portefeuille ?

Non. L’EOA conserve son adresse après la délégation, et son solde ainsi que son historique restent associés à cette adresse. Le nouvel élément est un marqueur de délégation de code.

La délégation ne dure-t-elle qu’une transaction ?

Non. Une fois inscrite, elle persiste jusqu’à ce qu’une nouvelle autorisation la remplace ou l’efface. L’échec d’une action prévue n’annule pas nécessairement une délégation déjà traitée.

La clé privée reste-t-elle valide après la délégation ?

Oui. La clé privée d’origine peut toujours signer des transactions, remplacer la délégation ou l’effacer. Le code délégué ne supprime pas la nécessité de protéger la clé.

Fournit-elle automatiquement les opérations groupées et la prise en charge du gas ?

Non. Elle fournit le mécanisme de délégation sous-jacent nécessaire pour implémenter ces fonctions. Le code délégué implémente le groupement, tandis que la prise en charge du gas exige aussi un émetteur ou un service externe disposé à soumettre la transaction et à payer ses frais.

Un compte peut-il déléguer à n’importe quel contrat ?

Le protocole permet à une autorisation de pointer vers une adresse de code, mais cette possibilité technique ne signifie pas que le code est adapté. Comme le code cible s’exécute dans le contexte du compte, l’utilisateur doit s’appuyer sur un portefeuille de confiance pour vérifier la fonction du code, les informations d’audit, les droits de mise à niveau et la méthode de révocation. Il ne doit pas signer une autorisation qu’il ne peut pas identifier.

Concepts associés

Poursuis avec Ethereum, les contrats intelligents et la machine virtuelle Ethereum, ou reviens au glossaire des cryptomonnaies. Cette entrée ne sera pas liée depuis le glossaire A–Z avant la publication des sept versions linguistiques.

Sources

• EIP-7702 : Set Code for EOAs — type de transaction, champs d’autorisation, exécution déléguée, révocation et considérations de sécurité.
• Ethereum.org : guide de l’EIP-7702 — intégration aux portefeuilles, contrôle du compte, autorisation interchaîne, risques de délégation et recommandations d’interaction.
• Ethereum Foundation : annonce du lancement de Pectra sur le réseau principal — date d’activation sur le réseau principal et contexte des fonctions utilisateur de l’EIP-7702.
• ERC-4337 : abstraction de compte avec un mempool alternatif — prise en charge des autorisations EIP-7702 par l’ERC-4337.