Qu’est-ce que la délégation EIP-7702 ? Explication des comptes intelligents EOA

La délégation EIP-7702 permet à un compte détenu en externe (EOA) de confier sa logique d’exécution à un autre contrat sans changer d’adresse ni céder sa clé privée. Le champ de code est défini sur 0xef0100 suivi de l’adresse du délégué, et les appels ultérieurs exécutent ce code dans le contexte propre de l’EOA, le solde, le nonce et le stockage restant associés au compte.

Elle s’adresse aux lecteurs qui connaissent déjà les wallets en auto-conservation et le modèle de compte de l’EVM. Ethereum dispose depuis longtemps de deux types de comptes : les EOA contrôlés par clé et les comptes de contrat contenant du code. Seuls les seconds pouvaient comporter une logique de validation personnalisée, au prix d’une nouvelle adresse. Cette fonctionnalité a été introduite avec la mise à niveau Pectra et a déplacé la validation personnalisée de l’ouverture d’un nouveau compte vers l’écriture de code sur une adresse déjà utilisée.

Un tuple d’autorisation comprend six champs, et le désignateur de délégation occupe 23 octets : un préfixe de trois octets suivi d’une adresse de 20 octets. Le chemin d’écriture, les limites des nouvelles capacités, la distinction avec ERC-4337 et la fiabilité du délégué déterminent le degré de contrôle que le compte conserve après cette signature.

Points clés

• La délégation EIP-7702 conserve l’adresse, la clé privée, le solde et le nonce, et fait uniquement pointer le champ de code vers un contrat délégué.

• Une transaction de type 0x04 écrit la délégation via un tuple d’autorisation ; le message signé ne comporte aucun champ de frais, et l’expéditeur ne doit pas nécessairement être le propriétaire.

• Une délégation n’expire pas ; sa révocation efface le code, mais pas le stockage, les approbations de jetons ni les signatures Permit.

• Un délégué sans receive() ni fallback() fait échouer les transferts ETH simples, et tx.origin n’implique plus qu’un compte ne possède pas de code.

• ERC-4337 construit un système de comptes distinct, tandis qu’EIP-7702 ajoute du code aux EOA existants ; les deux approches sont donc complémentaires.

Que change la délégation EIP-7702 pour un compte détenu en externe ?

Ethereum comporte deux types de comptes : un compte détenu en externe, contrôlé par une clé privée, et un compte de contrat, qui contient du code.

Avec EIP-7702, c’est le champ de code qui change, et non l’identité du compte, car un EOA peut pointer temporairement vers du code de contrat sans changer d’adresse. L’adresse, la clé privée, le solde et le nonce restent inchangés ; la différence est que l’adresse contient désormais du code exécutable provenant d’un autre contrat déployé.

Le champ contient un désignateur de délégation de 23 octets : le préfixe 0xef0100 suivi d’une adresse de 20 octets. Lorsqu’un appel cible cet EOA, l’EVM lit le désignateur et charge le code du délégué. Le compte peut donc se comporter comme un smart account, tandis que la clé privée garde le contrôle et que l’expéditeur, le solde et le stockage sont tous lus comme ceux de l’EOA.

Le délégué ne peut pas accéder à son propre état ; sa logique d’exécution est chargée depuis le contrat cible, tandis que le stockage et le contexte de l’expéditeur restent ceux de l’EOA, et les écritures suivent cette même logique dans un stockage que l’EOA n’avait jamais utilisé.

Les signatures proviennent toujours de la clé privée d’origine. Le compte ne devient donc pas un multisig, et cette conception constitue une étape vers l’abstraction de compte, y compris sa variante native, plutôt qu’un changement de type de compte.

Type 0x04 et tuples d’autorisation : comment la délégation accède au code de contrat

L’écriture requiert un nouveau type de transaction, 0x04, dont le corps contient une liste d’autorisations. Chaque tuple est signé par le titulaire du compte, tandis que la transaction elle-même peut être envoyée et financée par n’importe quelle adresse. L’autorisation précise quel code le compte autorise à exécuter.

Le tuple est [chain_id, address, nonce, y_parity, r, s], et le message signé est keccak(0x05 || rlp([chain_id, address, nonce])) ; la spécification EIP-7702 utilise le préfixe 0x05 pour distinguer les signatures d’autorisation des signatures de transaction ordinaires, et le message ne comporte aucun champ de gaz ou de frais.

Ce qui est signé est l’adresse vers laquelle le code doit pointer, et non une transaction spécifique ; certains systèmes associent donc plutôt l’autorisation à une intention. Le compte peut également signer une fois hors ligne pendant qu’un sponsor avance les frais de gaz.

La validation par les nœuds se déroule en six étapes, le lien avec le nonce rendant une autorisation utilisable une seule fois, au nonce correspondant.

La liste d’autorisations est intégrée au corps de la transaction de la même manière qu’une liste d’accès étend le format de transaction : l’ID de chaîne vaut 0 ou correspond à la chaîne locale (0 signifie qu’il est valide sur toute chaîne) ; le nonce est inférieur à 2^64-1 ; ecrecover vérifie la signature ; le code du compte est vide ou déjà délégué ; le nonce correspond à sa valeur actuelle ; puis le code est écrit sous la forme 0xef0100 || address avec incrémentation du nonce.

La révocation suit le même processus, avec l’adresse définie sur zéro, ce qui efface le hash du code sans modifier durablement l’état de l’EOA sous-jacent.

Quelles propriétés du compte restent inchangées ?

Quatre propriétés restent identiques, et seuls le code et le stockage évoluent : le code passe de 0x au désignateur, les emplacements de stockage inutilisés commencent à recevoir des écritures, et ces valeurs subsistent après révocation. La spécification énumère séparément trois invariants on-chain qui ne sont plus respectés, concernant le solde, le nonce et l’identité de l’appelant ; la section sur les risques les aborde.

1. Adresse : inchangée, de sorte que l’historique, les approbations de jetons et les enregistrements de noms continuent de pointer vers une seule adresse.

2. Clé privée : inchangée, et elle signe à la fois les transactions ordinaires et une nouvelle autorisation qui remplace ou révoque la délégation.

3. Solde : inchangé, car la délégation ne déplace aucun actif et le compte les détient toujours directement.

4. Nonce : il continue d’augmenter, car l’autorisation en consomme un, ce qui empêche la réutilisation de la même signature.

Un compte délégué peut-il toujours recevoir des ETH normalement ?

Pas par défaut. Une fois que le compte contient du code, un transfert ETH simple emprunte le chemin d’exécution du code ; si le délégué n’implémente ni receive() ni fallback(), le transfert échoue et les fonds retournent à l’expéditeur.

Ce problème peut survenir dans des flux de paiement courants tels que les retraits depuis une plateforme d’échange, le versement des salaires et les airdrops. Les logiciels de wallet indiquent généralement uniquement un échec, sans préciser que le délégué en est la cause. Avant de signer, vérifiez que la cible implémente une fonction receive, ou acheminez les paiements entrants via un appel contenant des calldata. Les logiciels de wallet devraient également indiquer plus clairement cette cause aux utilisateurs.

Figure 1. Chemin d’écriture EIP-7702 : l’EOA signe le tuple d’autorisation, une transaction de type 0x04 définit le code sur 0xef0100 suivi de l’adresse du délégué, puis les appels ultérieurs exécutent ce code dans le contexte de l’EOA.

Que peut faire un compte délégué ? Regroupement, sponsoring des frais de gaz et récupération

La délégation transforme un EOA, qui ne peut que signer des transactions, en un compte se comportant comme un smart account pour les utilisateurs au quotidien. Les avantages les plus clairs concernent le regroupement, le sponsoring des frais de gaz et la récupération fondée sur des règles.

Le regroupement est l’avantage le plus concret : une approbation et un swap peuvent être réalisés dans une seule transaction. Un sponsor peut également simplifier l’intégration ou le regroupement en aidant à effectuer plusieurs étapes en arrière-plan au bon moment, de sorte qu’une seule signature règle l’ensemble et qu’aucune approbation ne reste inutilisée entre les étapes.

Le sponsoring des frais de gaz repose sur la séparation entre la signature et l’expéditeur : un tiers paie, le compte n’a pas besoin d’ETH au préalable et, avec un paymaster ERC-4337, le coût peut être supporté par l’application. Cela signifie également que certaines applications peuvent couvrir les frais de gaz ou simplifier l’intégration en les gérant en arrière-plan, mais les développeurs devraient éviter de demander une délégation lorsqu’un utilisateur demande simplement une autre fonctionnalité.

La récupération et les clés de session reposent sur le fait que le délégué vérifie lui-même les signatures, par exemple avec une passkey, un ensemble de gardiens ou des limites de dépense à la place d’une seule clé. Le délégué peut également appliquer des fonctions de type politique autour des transferts ou de l’utilisation des signataires.

La limite est claire : toute personne détenant la clé privée peut toujours signer une nouvelle autorisation qui remplace la délégation. La récupération est donc ici moins robuste que dans un smart account natif et réduit seulement le coût associé à la perte d’une clé.

Une délégation n’expire pas. Elle reste active jusqu’à ce qu’une nouvelle autorisation la remplace ou qu’une adresse nulle la révoque. Cette autorisation est donc durable et nécessite une gestion active ; du point de vue de la sécurité, examinez la portée de ce à quoi le code délégué peut accéder et ce qu’il peut contrôler.

En quoi la délégation EIP-7702 diffère-t-elle d’ERC-4337 et de l’abstraction de compte ?

EIP-7702 ajoute du code à un EOA existant, tandis qu’ERC-4337 construit un système de comptes distinct. En tant qu’approches complémentaires de l’abstraction de compte, les deux se combinent plutôt que de se remplacer.

ERC-4337 part d’un nouveau contrat déployé, de sorte que les actifs et les approbations doivent être déplacés. EIP-7702 part de l’adresse d’origine et ajoute du code, évitant la migration en permettant aux comptes existants d’utiliser le comportement d’un smart contract sans devoir d’abord déployer un wallet distinct.

Ensemble, ils permettent à un compte 7702 de servir d’implémentation de compte pour ERC-4337, et les développeurs peuvent créer des flux compatibles avec 4337 au-dessus d’un compte délégué via 7702. Cela réintroduit une course à l’initialisation : entre l’enregistrement de la délégation et la fin de l’initialisation, n’importe qui peut appeler l’initialiseur et se définir comme propriétaire.

Deux solutions existent : initWithSig, qui lie la signature aux arguments d’initialisation, ou la restriction de l’initialisation à EntryPoint.

Le délégué est-il fiable ? Comment vérifier qu’il est immuable

Déléguez uniquement à des contrats immuables déployés depuis un initcode CREATE2 standard ; le mécanisme de vérification doit privilégier des cibles sans voie de mise à niveau, car les contrats proxy, les contrats évolutifs et les contrats disposant d’un chemin d’autodestruction sont tous de mauvaises cibles.

La délégation confère des droits d’exécution à ce code, et le détenteur ne reçoit aucune notification de modification. Une cible évolutive signifie que l’entité pouvant la mettre à niveau détient un pouvoir d’exécution sur chaque compte qui lui délègue des droits. Une cible immuable fixe au moins à l’avance la surface d’attaque, qui peut alors être auditée. L’exposition à la sécurité augmente si le code délégué peut changer après l’autorisation.

Trois critères — code immuable, absence de proxy et déploiement reproductible — deviennent quatre vérifications dans un explorateur de blocs que les wallets et les développeurs devraient effectuer avant d’accorder une délégation :

1. Lisez les emplacements d’implémentation et d’administrateur : un emplacement EIP-1967 non nul commençant par 0x360894 signale un proxy ou un chemin de mise à niveau.

2. Comparez le bytecode on-chain avec le code source vérifié, en confirmant que les arguments du constructeur et le bytecode déployé correspondent.

3. Recherchez selfdestruct et delegatecall, en confirmant qu’aucune branche ne peut effacer le code ou rediriger l’exécution ailleurs.

4. Recalculez l’adresse CREATE2 à partir de l’initcode et du salt, en confirmant que le déployeur ne peut pas substituer un autre contrat à une adresse différente.

Quels sont les risques de la délégation EIP-7702 ?

Les risques se situent à trois niveaux : les bugs du délégué, la sémantique du compte modifiée par la délégation et l’irréversibilité d’une signature unique. Il s’agit autant d’un compromis de sécurité que d’une amélioration fonctionnelle, la principale préoccupation étant l’étendue du contrôle que le code peut exercer sur le compte une fois l’autorisation accordée.

La ligne tx.origin a le rayon d’impact le plus large. Un compte délégué peut exécuter du code dans la pile d’appels ; ainsi, msg.sender == tx.origin ne signifie plus que l’appelant ne possède pas de code, et les gardes fondées sur cette comparaison cessent de protéger. Les verrous nonReentrant ou reposant sur un stockage transitoire ne dépendent pas de l’identité de l’appelant.

En pratique, si les wallets n’affichent pas clairement les détails de l’autorisation, les utilisateurs peuvent approuver un accès qu’ils n’avaient pas l’intention d’examiner. Les instructions EIP-7702 dans la documentation Pectra le mentionnent séparément.

Un chain_id de 0 élargit la troisième catégorie : la même signature est valide sur d’autres chaînes EVM, de sorte qu’un compte peut se voir attribuer du code sur une chaîne que son détenteur n’avait jamais envisagée. Les appareils de signature omettent souvent l’ID de chaîne, ce qui constitue le compromis associé à l’activation de la délégation sur un cold wallet.

Comment vérifier et révoquer une délégation ?

La vérification nécessite une seule lecture de code : eth_getCode renvoyant 0x signifie qu’il n’y a pas de délégation ; 23 octets commençant par 0xef0100 signifient que le compte est un compte détenu en externe délégué ; tout autre bytecode signifie qu’il s’agit d’un compte de contrat.

La délégation est un état au niveau de la chaîne. Une même adresse peut donc être déléguée sur une chaîne et intacte sur une autre, et chaque chaîne nécessite sa propre vérification. Les 20 derniers octets correspondent au délégué, et un wallet ou une plateforme peut automatiser ces vérifications sur plusieurs chaînes tout en conservant des journaux des contrôles ou changements de statut à des fins d’audit et de surveillance.

Pour une vérification manuelle rapide, vérifier et révoquer une délégation présente la procédure.

La révocation se fait dans le wallet : signez une nouvelle autorisation dont le champ d’adresse est défini sur zéro, et le nœud efface le hash du code, ramenant le compte à un EOA simple. Les dApps externes ne peuvent généralement pas le faire à la place du détenteur. Si les équipes de wallet prennent en charge des flux de révocation, toute demande d’action au nom d’un détenteur doit toujours nécessiter l’approbation de celui-ci.

La révocation supprime le code délégué, mais ne retire pas les approbations antérieures de smart contracts ni les autres accès déjà accordés aux applications. Les notes d’OpenZeppelin sur la délégation d’EOA précisent cette limite.

Résumé

EIP-7702 apporte de la programmabilité à un EOA avec une seule signature : l’adresse et la clé restent en place, le champ de code pointe vers un délégué et l’exécution se déroule dans le contexte propre du compte.

En contrepartie, la sémantique change et l’autorisation est durable : les paiements entrants simples peuvent échouer, tx.origin ne correspond plus nécessairement à un EOA, une signature avec chain_id défini sur 0 est valable sur plusieurs chaînes, et la révocation n’efface que le code.

FAQ

EIP-7702 transforme-t-il mon wallet en multisig ?

Non. La délégation modifie uniquement le champ de code, et les signatures proviennent toujours de la clé privée d’origine. Un détenteur d’une seule clé peut donc effectuer des transactions de manière indépendante et remplacer la délégation par une nouvelle autorisation. Un délégué exigeant plusieurs signatures peut également être contourné par cette clé.

Comment vérifier si mon wallet est délégué avec EIP-7702 ?

Appelez eth_getCode sur l’adresse. Un retour de 0x signifie qu’il n’y a pas de délégation ; 23 octets commençant par 0xef0100 signifient que le compte est délégué, les 20 derniers octets désignant le délégué ; tout autre bytecode signifie qu’il s’agit d’un compte de contrat.

La délégation est enregistrée par chaîne, vérifiez donc chacune d’elles. Les wallets ou systèmes d’administration peuvent également conserver des journaux de ces vérifications à des fins de contrôle. En bref, seule l’interface peut varier selon les wallets, mais la vérification sous-jacente du code reste la même.

Comment révoquer une délégation EIP-7702 ?

Signez une nouvelle autorisation depuis le wallet avec le champ d’adresse défini sur zéro, et le nœud efface le hash du code une fois la validation réussie. Seul le titulaire du compte peut la signer, et les dApps externes ne peuvent généralement pas agir en son nom.

Une délégation expire-t-elle, et les approbations de jetons antérieures survivent-elles à la révocation ?

Une délégation n’expire pas et reste active jusqu’à son remplacement ou sa révocation. La révocation efface uniquement le code, sans modifier le stockage, les approbations ERC-20 ni les signatures Permit.

Ma clé n’a jamais été compromise : une autorisation EIP-7702 malveillante peut-elle tout de même vider le compte ?

Oui. La signature constitue un transfert d’autorité : un attaquant qui l’obtient peut écrire une délégation pointant vers un contrat malveillant et accéder largement au compte, en déplaçant des actifs sans jamais toucher à la clé privée.

Vérifiez l’ID de chaîne et l’adresse cible dans le tuple, et signez uniquement pour des contrats immuables. Les équipes de wallet devraient également vérifier le rôle du signataire avant d’accorder, au nom d’une organisation, des approbations internes liées à la délégation.