EIP-7702 : délégation de code d’une EOA et risques

Une EOA classique signe des transactions avec une clé privée et n’a pas de code exécutable à sa propre adresse. EIP-7702 lui permet de pointer vers du code déployé ailleurs. Lorsqu’une opération d’exécution atteint le compte délégué, le client charge le code cible et l’exécute dans le contexte du compte. Le code se trouve à une autre adresse, mais l’adresse, le solde et le stockage utilisés appartiennent au compte qui délègue.

Il ne s’agit ni d’un transfert vers une nouvelle adresse de contrat ni du remplacement de la clé privée. L’adresse et la clé d’origine subsistent. Un marqueur de délégation valide laisse aussi l’EOA émettre des transactions ordinaires. Le changement porte sur le chemin d’exécution des appels ; la norme ne sépare pas automatiquement une clé en rôles plus sûrs.

La spécification EIP-7702 définit une transaction set-code de type 4 et une liste d’autorisations. Le guide Pectra d’Ethereum.org la décrit également comme un pointeur vers du code déployé. La mention « compte intelligent » dans une interface ne précise ni les règles de validation, ni la récupération, ni le code délégué réellement utilisé.

Distinguez la personne qui détient la clé privée de celles qui ont déployé ou peuvent modifier le code délégué. Vérifiez les droits de mise à jour et les effets possibles sur les actifs et le stockage du compte. L’EIP ne répond pas à ces questions de sécurité à votre place.

La transaction set-code porte l’octet de type 0x04. Elle contient les champs habituels de la transaction externe ainsi qu’une liste d’autorisations. Chaque tuple comprend l’identifiant de chaîne, une adresse de code, le nonce du compte autorisant et sa signature. L’autorité signe l’autorisation ; l’expéditeur signe séparément la transaction externe. Il peut s’agir du même compte ou de comptes distincts.

Comme l’expéditeur peut inclure l’autorisation valide d’une autre personne, vérifiez exactement ce que le compte autorisant approuve. L’identifiant de chaîne limite normalement l’autorisation à une chaîne ; la valeur 0 permet un champ plus large parmi les chaînes compatibles. Cela ne signifie pas que la signature fonctionnera partout : la chaîne doit prendre en charge EIP-7702 et le nonce ainsi que l’état du compte doivent correspondre. Un champ large peut toutefois rendre la signature utilisable sur une autre chaîne compatible.

Un tuple peut être ignoré si le nonce ne correspond pas ou si une autre validation échoue. Un caractère erroné dans l’adresse cible peut désigner un autre code. Comparez réseau, compte et adresse complète dans l’écran de signature et un explorateur fiable. Une invite vague parlant de mise à niveau ou d’économie de gas ne décrit pas la permission accordée.

La documentation des transactions d’Ethereum.org précise que le type 4 contient une liste d’autorisations. La transaction externe conserve des conditions de gas et un payeur de frais ; le fait qu’une autre adresse la soumette ne rend pas l’exécution gratuite. Le type 4 est également distinct des UserOperations et paymasters ERC-4337, décrits dans le guide des comptes intelligents.

Après une autorisation valide, le code de l’EOA reçoit un marqueur composé du préfixe 0xef0100 et de l’adresse cible. Le client reconnaît ce marqueur et charge le code de cette adresse lorsqu’il exécute un appel. L’adresse affichée pour le compte peut donc différer de celle du code exécuté. Vérifiez les deux.

Le code est récupéré sur la chaîne où la délégation est utilisée. Une adresse cible sur un autre réseau ne fait pas exécuter ici le code de cet autre réseau. La même adresse de 20 octets peut avoir un code différent, ou aucun code, selon la chaîne. Vérifiez le déploiement et le code source vérifié sur chaque réseau au lieu de vous fier à un nom, une icône ou une adresse identique.

Le code délégué s’exécute dans le contexte du compte autorisant et peut utiliser son stockage. Selon sa logique, il peut transférer l’ETH ou des jetons, appeler des contrats externes et modifier des valeurs stockées. EIP-7702 n’ajoute pas automatiquement de règles telles que « ce jeton uniquement » ou « un appel par jour ». Ces limites doivent être correctement mises en œuvre par le système délégué.

Si la cible est un proxy ou peut être mise à jour, le code vérifié aujourd’hui n’est pas forcément celui de demain. Vérifiez les administrateurs, les droits de changement d’implémentation, les délais et la procédure publique. Un droit de mise à jour inconnu représente un risque tant que la délégation reste active.

Le protocole ne limite pas automatiquement le code délégué à quelques permissions. Une validation défectueuse peut permettre des transferts, des autorisations de jetons, des appels externes arbitraires ou des modifications du stockage. Un badge d’audit ne prouve pas que l’adresse et la version exactes de la demande correspondent au code et au périmètre audités.

Les considérations de sécurité de l’EIP indiquent que la logique déléguée peut devoir lier à la signature la protection contre les rejouements, la cible et les données d’appel, la valeur en ETH et les conditions de gas. Si des champs importants manquent, un sponsor ou un tiers peut soumettre une demande différente de l’intention du signataire ou provoquer un échec. Vérifiez les appels validés et la possibilité pour un appelant externe de contourner ces contrôles.

Par exemple, un portefeuille peut regrouper une autorisation de jeton et un échange dans une seule confirmation. Vérifiez si les deux opérations sont annulées ensemble, si l’autorisation est limitée au montant nécessaire et si elle peut être réduite ensuite. Si un paymaster couvre les frais, vérifiez qui paie et à quelles conditions. Lisez l’aperçu complet pour que l’étiquette « gratuit » ne masque ni les appels ni les droits accordés.

La sécurité dépend des permissions réelles et du contrôle des mises à jour, pas seulement de la réputation de la cible. Vérifiez les contrats que le compte peut appeler, la validation des signatures, les pouvoirs d’urgence ou de mise à jour et la correspondance du code déployé avec sa source vérifiée. En cas d’adresse inconnue ou de lien non sollicité, suspendez l’action et consultez la documentation officielle du portefeuille.

EIP-7702 traite la liste d’autorisations avant l’exécution de la transaction externe. La spécification indique que les marqueurs de délégation déjà traités ne sont pas annulés si l’exécution échoue ou revert ensuite. Ne supposez pas que tout l’état du compte revient au départ parce que le reçu indique un échec. Vérifiez séparément le reçu et le code actuel du compte.

C’est important pour les appels groupés, l’initialisation et les transactions soumises par un sponsor. L’autorisation peut être valide tandis qu’un appel ultérieur échoue ; la délégation peut rester active alors que la configuration ou l’action attendue n’a pas abouti. Si le tuple d’autorisation lui-même était invalide, il peut ne pas avoir été appliqué. Examinez la transaction de type 4, le compte autorisant, son nonce et le pointeur de code actuel plutôt qu’un simple indicateur de réussite ou d’échec.

Le statut « échec » du portefeuille peut résumer une erreur lors du traitement de l’autorisation, d’un appel externe ou d’une autre étape d’exécution. En cas de doute, comparez le hash de transaction, l’autorité et le nonce signés, ainsi que le code du compte via un outil de chaîne fiable. Une nouvelle tentative peut rencontrer un nonce modifié et rendre l’ancienne autorisation inutilisable ; vérifiez d’abord les soumissions répétées ou déjà traitées.

Cette distinction compte lorsqu’une confirmation est censée annuler tous les éléments ensemble. Un compte de test ou de faible valeur permet d’observer le fonctionnement, mais ne prouve pas la sûreté du code. Avant d’utiliser un compte approvisionné, assurez-vous de pouvoir vérifier le champ de chaîne, la cible, les données d’appel et l’état susceptible de subsister après un échec.

Une nouvelle autorisation peut pointer vers un autre code. L’EIP définit aussi la suppression du marqueur par une autorisation à l’adresse nulle, ce qui ramène le code du compte à l’état vide. Cette action supprime le marqueur de délégation ; ce n’est pas une commande générale de nettoyage ou de récupération.

Si le code délégué a écrit dans le stockage du compte, supprimer le marqueur n’efface pas ces valeurs automatiquement. Une autorisation de jeton enregistrée par un contrat ERC-20 est également distincte du code du compte. Une autorisation illimitée antérieure peut devoir être révoquée auprès du contrat du jeton. La suppression n’annule pas les transferts déjà effectués, les changements de contrats externes ou les transactions terminées.

Le nouveau code peut réutiliser le même stockage ; deux versions qui interprètent différemment un même emplacement peuvent entrer en conflit. Vérifiez la disposition et le plan de migration avant de changer. Sans compatibilité, le compte peut être bloqué ou l’ancien état mal interprété ; le protocole ne propose pas d’effacement général du stockage lors du changement de pointeur.

Adaptez la réponse au problème. Si le code semble malveillant, examinez rapidement une procédure de suppression prise en charge par le portefeuille ou un remplacement fiable. Pour les autorisations de jetons, consultez le guide sur les approvals et allowances. Si la clé ou la phrase de récupération est exposée, supprimer le code ne récupère pas cette clé : suivez le guide de récupération de portefeuille et envisagez de transférer les actifs vers un compte sûr.

Confirmez d’abord dans la documentation officielle du portefeuille qu’il prend en charge EIP-7702 sur le réseau choisi. Comparez réseau et identifiant de chaîne, compte, adresse cible exacte, code vérifié et administrateur éventuel de proxy ou de mise à jour. Comprenez si l’identifiant 0 élargit le champ aux chaînes ou si la signature est limitée à une chaîne. Si l’écran de signature manque de clarté, consultez la documentation avant d’approuver.

Distinguez ensuite la signature d’autorisation, l’expéditeur de la transaction externe et le payeur des frais. Un autre expéditeur ne change pas ce que l’autorité a signé. Le sponsoring ne rend pas non plus le code sûr ni limité aux appels attendus. Comparez le type, la liste, les cibles et données d’appel ainsi que toute modification d’allowance avec l’aperçu.

Si une délégation est déjà active, ne vérifiez pas seulement la réussite de la transaction. Inspectez le marqueur actuel et l’adresse du code cible. S’ils ne correspondent pas à vos attentes, suspendez les appels et autorisations supplémentaires ; évitez les tentatives répétées de remplacement au hasard. Pour les frais de la transaction externe, consultez le guide des frais de gas Ethereum ; pour les nonces et transactions en attente d’une EOA, le guide des transactions en attente.

EIP-7702 normalise un format de transaction qui relie une EOA à du code déployé. Le regroupement d’appels, les frais sponsorisés, les permissions de session ou la récupération peuvent être construits dessus, mais dépendent d’un code et de services particuliers. Tous les portefeuilles ou délégués n’appliquent pas les mêmes règles et ne prennent pas en charge les mêmes fonctions.

La mention « compte intelligent » ne dit pas qui détient la clé, qui peut mettre à jour le code ou modifier la récupération. Vérifiez l’implémentation et les paramètres réels. Un portefeuille qui ne prend pas en charge le réseau ou la fonction peut afficher la délégation différemment de vos attentes. Vérifiez la compatibilité avant de modifier un compte approvisionné.

L’annonce Pectra mainnet de l’Ethereum Foundation décrit les EOA pointant vers du code délégué et la possibilité de remplacer ou révoquer l’autorisation. Les capacités de la norme et leur présentation par un portefeuille donné sont deux questions distinctes. Les UserOperations et paymasters ERC-4337 constituent une autre voie d’abstraction de compte, pas l’autorisation de type 4 elle-même.

Ce guide explique le mécanisme des comptes et ne recommande aucun portefeuille ou délégué. Définissez d’abord l’objectif — regrouper des actions, sponsoriser les frais, utiliser des permissions de session ou récupérer l’accès — puis identifiez le code et le service qui le réalisent et le niveau de confiance requis. Le guide des comptes intelligents et d’ERC-4337 présente des mécanismes voisins.