Glamsterdam Reporté Sur Hoodi Après Analyse EIP-8037

Imaginez un train de mise à niveau qui roule depuis des semaines sur les rails des testnets Ethereum. Tout le monde attendait le prochain arrêt : le 26 octobre sur Hoodi. Puis, d’un coup, les développeurs ont tiré le frein d’urgence. La raison n’est pas une panne technique spectaculaire, mais une question bien plus délicate : comment une simple modification du prix de création d’état peut-elle entrer en collision avec des contrats déjà déployés sur le mainnet depuis des années ?

Pourquoi Glamsterdam a disparu du calendrier Hoodi

Le 22 octobre, la Ethereum Foundation a officiellement retiré l’activation de Glamsterdam prévue sur le testnet Hoodi. L’époque 132 352 et le slot 4 235 264, initialement annoncés le 16 octobre, ne sont plus d’actualité. Aucune nouvelle date n’a été communiquée. La hausse du plafond de gaz à 200 millions, qui devait accompagner l’upgrade, a également été retirée du planning.

Cette décision ne concerne ni le mainnet ni l’historique déjà enregistré sur Hoodi. Il s’agit uniquement d’une reconfiguration future. Pourtant, l’impact opérationnel est immédiat pour tous les opérateurs de nœuds et validateurs qui avaient préparé leurs clients pour lundi prochain.

Les développeurs ont choisi d’attendre afin d’étudier plus en profondeur l’interaction entre EIP-8037 et les contrats intelligents déjà présents sur le réseau principal.

Ethereum Foundation, notice du 22 octobre 2026

Sepolia avait déjà activé Glamsterdam le 6 octobre avec succès, y compris le test de la limite de 200 millions de gaz. Mais un testnet réussi n’est jamais une garantie pour le suivant. Hoodi devait servir de répétition générale. Cette répétition est désormais reportée le temps que les équipes clarifient un point précis : le coût de création d’état.

Ce que change réellement EIP-8037

Sur Ethereum, une transaction ne se contente pas d’exécuter des calculs. Elle peut aussi laisser derrière elle des données que le réseau doit conserver indéfiniment. Créer un nouveau compte, ouvrir un slot de stockage ou déployer du bytecode augmente l’état global. EIP-8037 propose de facturer davantage ces opérations et de les mesurer séparément.

Les chiffres illustratifs de la proposition donnent une idée de l’ampleur du changement. Un nouveau compte passerait d’environ 25 000 gaz à 183 600 pour sa composante de création d’état. Un nouveau slot de stockage grimperait de 20 000 à 97 920. Un déploiement de 24 kilo-octets passerait de près de 5 millions à plus de 37 millions de gaz. Ces valeurs ne représentent pas le coût final en ether. Elles isolent uniquement la partie liée à la création d’état durable.

Une proposition voisine, EIP-8038, revoit quant à elle le prix de certains accès en lecture et écriture. Les coûts de gaz n’avaient pas été profondément ajustés depuis le fork Berlin en 2021, alors que l’état du réseau n’a cessé de grossir. L’objectif affiché est de rapprocher le prix payé par les utilisateurs de la charge réelle supportée par les nœuds, surtout si l’on souhaite augmenter la capacité des blocs.

Pourquoi certains contrats risquent de se coincer

La difficulté ne vient pas seulement du fait que les opérations coûtent plus cher. Elle vient de la façon dont de nombreux contrats ont été écrits. Certains appellent d’autres contrats en leur fournissant une quantité de gaz fixe et limitée. D’autres s’appuient encore sur le fameux stipend de 2 300 gaz hérité des fonctions transfer et send de Solidity. D’autres encore calculent le travail restant à partir de la fonction gasleft().

Si une opération de création d’état consomme désormais davantage que l’allocation prévue, l’appel interne peut échouer même si la transaction globale dispose de gaz en abondance. Le portefeuille ou le relais peut avoir estimé correctement le plafond supérieur, mais le code déployé continue d’appliquer une limite interne trop basse. Dans certains cas, l’échec est géré proprement. Dans d’autres, il provoque un revert ou un comportement inattendu.

La Fondation a rejoué un grand nombre de transactions historiques sous le nouveau barème. La grande majorité n’a montré aucun problème significatif. Une partie des cas problématiques s’est résolue simplement en augmentant la limite de gaz fournie. Un groupe plus restreint a continué à échouer même avec une limite nettement plus élevée. Ce sont ces contrats-là qui préoccupent les équipes.

Un appel externe peut volontairement transmettre juste assez de gaz pour une action limitée. Si le prix change, cette action limitée peut soudainement dépasser le budget.

Un cas particulièrement subtil concerne les contrats qui mesurent le travail effectué en soustrayant deux lectures de gasleft(). Avec le nouveau réservoir de gaz d’état, cette valeur peut parfois augmenter au lieu de diminuer. Un calcul qui s’attendait à une différence toujours positive peut alors produire un résultat incohérent. Et comme ces contrats sont immuables une fois déployés, la seule solution consiste souvent à migrer les utilisateurs vers une nouvelle version.

Ce que doivent faire les opérateurs de Hoodi dès maintenant

Le risque le plus immédiat n’est pas sur le mainnet. Il se situe sur Hoodi. Tout client ou configuration personnalisée qui conserve encore l’ancienne heure d’activation peut se retrouver désynchronisé. Un validateur dont le logiciel d’exécution ou de consensus attend les nouvelles règles à l’époque 132 352 alors que le réseau les ignore risque de ne plus suivre la chaîne canonique.

La recommandation de la Fondation est claire : vérifier les notes de version les plus récentes des clients d’exécution et de consensus. Une version présentée comme compatible avec Glamsterdam peut encore contenir l’ancienne date d’activation Hoodi. Il faut également supprimer toute configuration manuelle qui forcerait le fork au moment prévu initialement.

Les détenteurs de tokens sur le mainnet n’ont rien à faire pour le moment. Aucune activation n’a été annoncée. Le report concerne uniquement un testnet et une phase d’investigation.

Au-delà des contrats : wallets, RPC et usines de déploiement

Les portefeuilles et les fournisseurs de nœuds RPC doivent également s’adapter. La fonction eth_estimateGas devra désormais tenir compte à la fois du gaz d’exécution et de la nouvelle dimension liée à la création d’état. Une constante mise en cache trop ancienne peut sous-estimer une transaction qui crée beaucoup d’état. L’utilisateur voit alors des échecs alors que le contrat lui-même fonctionne correctement dès que la limite est correctement calculée.

Les usines de déploiement déterministes constituent un cas plus étroit. Certaines ont été déployées à des adresses standard via des transactions pré-signées avec des limites de gaz codées en dur. Sur un réseau entièrement neuf qui adopterait le nouveau barème avant l’existence de l’usine, l’ancien déploiement pourrait échouer. En revanche, les instances déjà présentes sur le mainnet et sur les réseaux de couche 2 ne sont pas concernées par ce scénario de genèse.

Même lorsqu’un contrat continue de fonctionner, le coût peut évoluer de façon significative. Une application qui déploie régulièrement de nouveaux contrats ou qui ouvre de nombreux slots de stockage verra sa structure de frais changer. Les devis, les subventions de gaz et les politiques de tarification devront être revus en conséquence.

La limite de 200 millions n’était qu’un paramètre de test

Glamsterdam ne se limite pas à la repricing. Il inclut également l’enshrined proposer-builder separation et les listes d’accès au niveau du bloc. Les développeurs avaient prévu de tester l’ensemble avec une limite de gaz portée à 200 millions sur Hoodi, comme cela avait été fait sur Sepolia. Cette valeur restait un paramètre de testnet. Elle n’a jamais constitué une promesse d’adoption immédiate sur le mainnet ni une garantie de baisse des frais pour les utilisateurs.

Retirer cette hausse du calendrier Hoodi permet de garder l’ensemble des composants de l’upgrade synchronisés. Les équipes continuent de disposer de Sepolia et de devnets dédiés pour poursuivre les investigations. Ce qui manque, c’est la répétition grandeur nature sur Hoodi, étape importante avant de choisir une date de production.

Pourquoi les développeurs ont préféré attendre

Le processus de développement d’Ethereum laisse volontairement la possibilité d’ajuster le plan avant une activation publique sur testnet. La décision du 22 octobre a été prise lors de l’All Core Devs Execution call 248. Elle fait suite à des alertes antérieures et à des contacts avec les équipes dont les contrats avaient été signalés lors des replays.

Le communiqué public identifie le domaine d’investigation sans publier de décompte définitif de contrats à risque, sans nouvelle version d’EIP-8037 et sans date de fin d’enquête. Interpréter ce délai comme la preuve d’une faille généralisée serait excessif. Le présenter comme un simple ajustement de calendrier serait tout aussi inexact. La cause annoncée est précise : l’interaction entre la nouvelle tarification et les contrats existants mérite davantage d’attention.

Chaque étape du processus apporte des informations que la précédente ne peut pas fournir. Le replay historique révèle les cas déjà rencontrés. Les testnets publics montrent le comportement des clients et des applications en conditions réelles. Le mainnet expose enfin les règles à l’usage économique à grande échelle. Un court report sur Hoodi peut permettre d’améliorer la qualité de la proposition ou des outils d’accompagnement, mais il ne constitue pas en lui-même une validation des règles finales.

Ce qu’il faudra surveiller avant la prochaine date

Plusieurs signaux permettront de comprendre où en est réellement le dossier. Les sorties de clients d’exécution et de consensus qui retirent explicitement l’ancienne activation du 26 octobre constituent le premier indicateur. Les résultats actualisés des replays et d’éventuelles modifications de la proposition EIP-8037 seront tout aussi importants. Une nouvelle époque Hoodi, avec une configuration claire et des versions de clients alignées, marquera le retour à un calendrier testable.

Du côté des applications, les retours des équipes concernées indiqueront si une simple hausse des limites de gaz suffit ou si certaines migrations de contrats deviennent nécessaires. Enfin, une annonce distincte de production sera indispensable. Aucune date mainnet n’a été évoquée à ce stade.

Les questions que se posent légitimement les utilisateurs

Beaucoup se demandent si leur portefeuille ou leurs applications vont cesser de fonctionner. La réponse actuelle est non. Le report ne concerne pas le mainnet. La grande majorité des contrats rejoués n’ont montré aucun problème. Seule une minorité présentant des hypothèses de gaz fixes ou des logiques basées sur gasleft() mérite une attention particulière de la part de leurs mainteneurs.

D’autres s’interrogent sur l’impact final sur les frais. Tout dépendra de la composition réelle des transactions, du prix du gaz au moment de l’activation et des paramètres définitifs retenus. Une opération qui crée peu d’état verra un effet différent d’une opération qui déploie un contrat important. Généraliser une hausse ou une baisse globale des frais serait prématuré.

Enfin, certains craignent que ce report ne retarde indéfiniment les progrès de scalabilité. Or le travail se poursuit sur Sepolia et sur des devnets dédiés. Le report de Hoodi ralentit une étape de validation, mais il n’arrête pas l’ensemble du processus de recherche et de développement.

Une leçon de prudence dans un écosystème en expansion

Ethereum a toujours privilégié la prudence lorsqu’il s’agit de modifier des règles qui touchent du code déjà déployé. Les contrats immuables représentent à la fois une force et une contrainte. Ils offrent de la certitude aux utilisateurs, mais ils compliquent toute évolution des coûts internes. Chaque changement de tarification du gaz doit donc être examiné non seulement sous l’angle de l’efficacité économique, mais aussi sous celui de la compatibilité ascendante.

Le report de Glamsterdam sur Hoodi illustre cette tension. Les développeurs veulent augmenter la capacité du réseau tout en s’assurant que les applications existantes ne se retrouvent pas dans des situations d’échec inattendues. Prendre quelques semaines supplémentaires pour clarifier les interactions avec EIP-8037 peut sembler frustrant à court terme. À long terme, cela contribue à maintenir la confiance dans un écosystème où des milliards de dollars reposent sur des contrats qui ne peuvent plus être modifiés.

Pour l’instant, le message est simple. Les opérateurs de Hoodi doivent mettre à jour leurs clients et retirer les anciennes configurations. Les équipes d’applications doivent tester leurs chemins d’exécution critiques sous le nouveau barème. Les utilisateurs du mainnet peuvent continuer leurs activités habituelles. Et tout le monde attend désormais les prochains résultats de l’investigation ainsi qu’une éventuelle nouvelle date de test.

Le train de mise à niveau n’est pas arrêté. Il a simplement marqué un arrêt supplémentaire en gare pour vérifier que tous les wagons, y compris les plus anciens, pourront continuer à rouler sans à-coup.