Le développeur de la Fondation Ethereum Marius van der Wijden a déclaré dans une mise à jour du 6 novembre que les développeurs cœur ne forkeraient pas le testnet Hoodi tant que les problèmes identifiés par la société de sécurité ChainSecurity ne seraient pas résolus. Hoodi est le réseau de test public où Ethereum répète les changements de protocole avant leur déploiement sur le mainnet. Il a demandé aux développeurs de contrats et aux auditeurs de vérifier leurs projets par rapport à huit invariants de gaz que la prochaine mise à niveau Glamsterdam remet en cause. Le gaz est l'unité avec laquelle Ethereum tarife chaque opération effectuée par une transaction ; lorsque ces prix changent, le code écrit selon les anciens chiffres peut se comporter différemment, même si le code lui-même reste inchangé.

Un invariant, dans ce contexte, est une règle que le code considère comme toujours vraie — par exemple, « un budget de gaz fixe suffit pour cet appel » ou « une délégation minée a pris effet ». Le dépôt d'invariants de la Fondation répertorie huit hypothèses qui changent avec Glamsterdam et indique que la plupart des constats à ce jour en concernent deux.

Deux propositions refondent les coûts de gaz

Deux propositions sont à l'origine du changement. L'EIP-8037 augmente le prix de la création d'un nouvel état — nouveaux comptes, emplacements de stockage et code déployé — et le facture séparément de l'exécution ordinaire. L'EIP-8038 augmente le prix de la lecture et de la mise à jour de l'état existant. Selon la spécification testée par le dépôt, l'écriture dans un emplacement de stockage vierge passe de 22 100 gaz à 110 020, la mise à jour d'un emplacement existant « chaud » de 2 900 à 10 100, et le déploiement de code de 200 gaz par octet à 1 530. Ces chiffres évolueront si la spécification change.

La pause des tests de Glamsterdam a suivi la revue du 13 octobre de ChainSecurity, comme précédemment rapporté. Le dépôt élargit ces constats avec le scan réalisé par la Fondation elle-même sur les contrats vérifiés sur Sourcify, un registre public de code source de contrats, ainsi qu'avec des cas hors chaîne tels que les logiciels lisant les reçus de transactions.

Une transaction minée ne prouve plus qu'une délégation a été appliquée

L'EIP-7702 permet à un compte Ethereum ordinaire d'exécuter du code de contrat intelligent en signant une autorisation pointant vers un contrat délégué. Ce mécanisme est entré en vigueur avec la mise à niveau Pectra de 2025 et soutient les fonctionnalités de comptes intelligents déployées depuis par les portefeuilles. L'autorisation est censée n'être utilisée qu'une seule fois. Avant Glamsterdam, son coût intégral était facturé d'avance, de sorte qu'une transaction incapable de le payer était invalide et n'atteignait jamais un bloc. Si une transaction était minée, la délégation avait été appliquée.

L'entrée INV-8 du dépôt explique ce que change l'EIP-8037. Une partie du coût dépend désormais de l'état du compte et n'est facturée que pendant le traitement de l'autorisation. Déléguer depuis un compte vide coûte 235 606 gaz, contre 25 000 auparavant. Une transaction budgétée sur l'ancien chiffre peut être acceptée, épuiser son gaz pendant l'application de l'autorisation et atterrir dans un bloc avec un statut d'échec. La délégation est annulée, ainsi que l'incrément du nonce du compte, le compteur qui marque une autorisation comme utilisée. L'autorisation signée, toutefois, est désormais publique et reste valide.

En soi, cela laisse un portefeuille non configuré plutôt que compromis. Le danger survient lorsque le contrat délégué permet à quiconque d'appeler sa fonction setup. Un attaquant peut alors resoumettre l'autorisation exposée dans sa propre transaction, appeler setup en premier et se désigner propriétaire du compte. Le front-running des autorisations dans le mempool public était déjà possible. Le point du dépôt est qu'une transaction échouée publie désormais elle-même une autorisation valide, de sorte que son routage privé n'offre aucune protection. Le schéma est documenté avec un exemple de code, et aucun portefeuille affecté n'est nommé.

Le changement pratique incombe aux portefeuilles, relayers et indexeurs. Le dépôt recommande de vérifier le code et le nonce du compte après une transaction de délégation plutôt que de se fier au reçu. Toute autorisation échouée doit être traitée comme exposée et annulée, soit en avançant le nonce du compte, soit en déléguant à nouveau vers un contrat sûr. Un changement de spécification qui facturerait le coût du pire cas d'avance a été suggéré mais non adopté, et les développeurs sont invités à concevoir leurs projets comme si le comportement actuel perdurait.

Les budgets de gaz se situent souvent hors du contrat

L'entrée la plus large, INV-4, couvre tout montant de gaz fixé avant le fork. Il peut désormais s'avérer trop faible, où qu'il soit inscrit : dans le code d'un contrat, une valeur de configuration, un message signé ou un logiciel hors chaîne. Cette dernière catégorie comprend les relayers — des services qui soumettent des transactions au nom des utilisateurs — ainsi que les keepers et les systèmes de retrait des plateformes d'échange.

Les destinataires recevant pour la première fois sont le déclencheur le plus courant. L'envoi d'un jeton vers une adresse à solde nul crée un nouvel emplacement de solde, et l'envoi d'ETH vers une adresse vide crée un nouveau compte, deux cas que l'EIP-8037 tarife bien plus cher. Selon le dépôt, un transfert qui tient aujourd'hui dans 65 000 gaz peut en exiger plus de 150 000.

L'endroit où le chiffre fixe est inscrit détermine la gravité du déficit. Dans un logiciel hors chaîne, la transaction entière revient et peut être renvoyée avec plus de gaz. Dans un contrat, sa configuration ou un message signé, seul l'appel interne échoue. Si le contrat externe capture cet échec, le résultat est souvent définitif : un message enregistré comme échoué, un callback ignoré ou des récompenses comptabilisées à tort. Certains de ces chiffres ne peuvent pas être modifiés du tout, notamment les transactions multisig signées avant le fork, les méta-transactions signées et les messages inter-chaînes déjà en cours.

INV-7 applique le même problème au gaz détenu en réserve. Les fonctions transfer et send de Solidity transmettent un montant fixe de 2 300 gaz, mais un contrat destinataire qui écrit un nouvel emplacement de stockage nécessite désormais plus de 110 000. Les portefeuilles intelligents, les répartiteurs de paiements et les coffres avec logique dans leurs fonctions receive sont les candidats évidents.

Des chemins d'échec qui revenaient peuvent désormais s'achever

L'analyse du 13 octobre de ChainSecurity explique pourquoi certaines protections ayant passé des audits antérieurs peuvent cesser de fonctionner. Les contrats capturent souvent un appel externe échoué afin d'enregistrer l'échec, d'ignorer un élément ou de tenter un repli. Cela devient dangereux lorsqu'une personne fournit délibérément trop peu de gaz — une attaque appelée griefing par gaz insuffisant — car une opération qui devrait être réessayable se retrouve marquée comme définitivement échouée.

Les contrats s'en défendent généralement de deux manières. Certains vérifient la quantité de gaz restante après l'appel. D'autres comptent sur le fait que le gestionnaire d'échec est trop coûteux pour s'achever. Glamsterdam affaiblit les deux. L'EIP-8037 dote les transactions dont la limite de gaz dépasse 16 777 216 d'un réservoir séparé pour les coûts de stockage, invisible pour le contrôle gasleft() habituel. Révoquer un appel ou effacer un emplacement fraîchement écrit peut également restituer du gaz dépensé. Selon les mots de ChainSecurity, « même avec un code de contrat inchangé, un chemin d'échec qui revenait auparavant peut désormais s'achever ».

La société recommande désormais de ne pas déduire la raison d'un échec d'appel à partir du gaz restant. Son approche privilégiée consiste à laisser l'ensemble de l'opération revenir lorsque c'est possible, ou à conserver un chemin de récupération plutôt que de prendre une décision irréversible sur la base du gaz restant.

Un audit antérieur ne peut combler seul cet écart, car il a évalué le code au regard des règles de gaz en vigueur à l'époque. La Fondation a mandaté ChainSecurity et Dedaub en complément de ses audits internes, mais son article du 6 novembre reconnaît ne pouvoir passer en revue chaque projet, en particulier le code hors chaîne. Les choix de conception conditionnent aussi la correction : une limite de gaz stockée comme paramètre ajustable peut simplement être augmentée, tandis qu'une limite inscrite en constante fixe peut ne laisser que le redéploiement et la migration comme seules options.

Pourquoi Ethereum maintient le cap sur la refonte tarifaire

L'argument de la Fondation en faveur du changement repose sur l'exactitude de la tarification. Ses recommandations d'août aux développeurs de contrats indiquaient que les prix du gaz pour les opérations d'état avaient été ajustés pour la dernière fois lors du fork Berlin de 2021, le fork qui a établi la tarification actuelle à froid contre à chaud pour la lecture de l'état. L'état d'Ethereum — le registre continu des comptes, soldes et stockages de contrats suivis par les nœuds — a considérablement grandi depuis, et les récentes hausses de la limite de gaz ont accéléré cette croissance. L'article qualifie la refonte tarifaire de prérequis à toute nouvelle hausse de la limite de gaz et indique que le nouveau barème découle d'un objectif de performance soutenant environ un triplement du débit de base.

Le même article rapporte que la relecture des transactions historiques du mainnet aux nouveaux prix a laissé la grande majorité d'entre elles inchangée, et que la plupart des problèmes signalés pouvaient être corrigés en augmentant une limite de gaz. Il a indiqué aux utilisateurs ordinaires qu'aucune action n'était nécessaire, les portefeuilles et infrastructures mis à jour gérant le changement. Les constats de novembre pèsent davantage sur cette dernière clause. La gestion du changement inclut désormais la vérification de l'état du compte après une délégation échouée et le dimensionnement des budgets des relayers pour les destinataires débutants — un travail que les anciennes règles de gaz n'exigeaient jamais.

Ce que décideront les prochains appels des développeurs cœur

Selon le dépôt, la Fondation recueille des retours avant le prochain appel All Core Developers, la tribune permanente où les changements de protocole d'Ethereum sont convenus. Selon la réponse, elle pourrait légèrement modifier l'EIP-8037 et l'EIP-8038 ou les laisser en l'état. Hoodi reste non forké tant que les problèmes ne sont pas résolus, et l'article du 6 novembre ne donne aucune nouvelle date. Selon le même article, les travaux sur Hegota, la mise à niveau prévue après Glamsterdam, se poursuivent en parallèle.

Avant le fork de Hoodi : qui vérifie quoi

• Équipes de contrats : collez les adresses dans l'outil de recherche des contrats affectés de la Fondation, puis examinez tout code qui code en dur des valeurs de gaz ou se branche sur le gaz restant, qu'il soit répertorié ou non.
• Portefeuilles et fournisseurs RPC : mettez à jour l'estimation du gaz pour le nouveau barème. La Fondation avertit que les constantes de gaz en cache sous-estimeront les coûts et provoqueront des transactions échouées.
• Relayers, keepers et bundlers : rendez les limites ajustables et réestimez selon les nouvelles règles avec une marge, en testant des transactions de part et d'autre du seuil du réservoir.
• Auditeurs : le dépôt inclut des instructions pour exécuter ses vérifications avec un agent de codage IA, le code et les résultats restant en local.

Les signaux à suivre sont une date de fork de Hoodi sur le blog de la Fondation, toute révision de la spécification de l'un ou l'autre EIP et la confirmation des corrections par les projets affectés. La Fondation a demandé aux équipes de signaler les problèmes en privé à glamsterdam@ethereum.org plutôt que dans des tickets publics, afin qu'ils soient corrigés avant que les détails ne se propagent.

Cet article est initialement paru sur Coindoo.