Lundi prochain aurait dû marquer une étape importante pour Ethereum. Sur le testnet Hoodi, l’activation de Glamsterdam était programmée à 17 h 42 UTC le 26 octobre. Ce rendez-vous vient d’être purement et simplement retiré du calendrier. Aucune nouvelle date n’a été annoncée. Derrière ce report se cache une question technique délicate : comment l’EIP-8037, qui augmente le coût de création d’état sur la chaîne, interagit-elle avec des milliers de contrats déjà présents sur le réseau principal ?
Pourquoi Glamsterdam a été retiré du calendrier Hoodi
Le 22 octobre, la Fondation Ethereum a publié un avis clair. L’activation prévue à l’époque 132 352 et au slot 4 235 264 n’aura pas lieu. Les changements d’exécution Amsterdam et les modifications de consensus Gloas sont tous deux annulés pour ce test. La hausse de la limite de gaz à 200 millions, qui accompagnait l’opération, suit le même sort. Il ne s’agit pas d’un retour en arrière sur des blocs déjà validés. C’est simplement l’arrêt d’une configuration future.
Cette décision n’est pas anodine. Un validateur qui conserve encore l’ancienne date d’activation dans son logiciel risque de se retrouver désynchronisé. Les opérateurs doivent donc vérifier les notes de version de leurs clients d’exécution et de consensus. Une version présentée comme compatible Glamsterdam peut encore contenir l’ancien déclencheur. Mieux vaut supprimer toute configuration personnalisée avant le 26 octobre plutôt que d’espérer que l’inaction suffise.
Sepolia avait déjà activé Glamsterdam le 6 octobre et testé la limite de 200 millions de gaz. Ce succès n’a pas suffi à rassurer complètement les équipes. Hoodi devait servir de répétition supplémentaire. Le report prouve que les développeurs préfèrent prendre le temps d’examiner les interactions avec les contrats mainnet plutôt que de précipiter le calendrier.
Ce que change réellement l’EIP-8037
Une transaction Ethereum peut calculer et laisser des données durables. Créer un nouveau compte, ouvrir un emplacement de stockage ou déployer du bytecode augmente l’état persistant que les nœuds doivent conserver. L’EIP-8037 propose d’augmenter le coût de ces opérations et de les mesurer séparément. L’objectif est de rapprocher le prix de la charge réelle supportée par le réseau sur le long terme, surtout si les blocs deviennent plus volumineux.
Les chiffres illustratifs sont éloquents. Un nouveau compte passerait de 25 000 à 183 600 gaz pour la composante de création d’état. Un nouvel emplacement de stockage grimperait de 20 000 à 97 920. Un déploiement de 24 kilo-octets passerait de 4 947 200 à 37 784 880. Ces montants ne représentent pas le prix final en ether. Ils isolent une partie du coût sous une constante proposée. Le reste des frais d’exécution s’ajoute ensuite, et le prix en ETH dépend du prix du gaz au moment de la transaction.
Une proposition voisine, l’EIP-8038, revoit également certains accès en lecture et en écriture. Les coûts de gaz n’avaient pas été ajustés de façon substantielle depuis le fork Berlin en 2021. Depuis, l’état de la chaîne a considérablement grossi. Relever la capacité sans tenir compte des opérations d’état coûteuses rendrait la validation plus lourde pour les opérateurs de nœuds. Le report touche donc à la fois la compatibilité des applications et le plan de montée en charge.
Les contrats qui risquent de trébucher
Les développeurs ont rejoué des transactions historiques du réseau principal sous le nouveau barème. La grande majorité n’a rencontré aucun problème significatif. Parmi les cas signalés, beaucoup se sont déroulés correctement une fois la limite de gaz augmentée. Un groupe plus restreint pourrait échouer même avec beaucoup plus de gaz. Trois catégories posent particulièrement problème : les stipends fixes, les quantités de gaz codées en dur lors d’appels externes, et les branches conditionnelles basées sur gasleft().
Imaginez un contrat qui envoie des fonds à un autre en ne lui fournissant qu’une quantité limitée de gaz. Le destinataire peut désormais consommer plus que prévu pour toucher le stockage. Si l’allocation est inscrite dans le code déployé, augmenter la limite de la transaction principale ne change rien. L’appel interne reste sous-alimenté. Une migration vers un nouveau contrat peut alors devenir nécessaire, avec tout ce que cela implique pour les soldes, les autorisations et la communication aux utilisateurs.
Point clé : un contrat qui utilisait le pattern historique transfer ou send de Solidity (stipend de 2 300 gaz) n’est pas automatiquement cassé. Tout dépend de ce que fait réellement le destinataire. Certains resteront dans les clous. D’autres dépasseront le plafond.
Un cas encore plus subtil concerne le code qui mesure le travail effectué en soustrayant deux lectures de gaz restant. Avec le nouveau réservoir de gaz d’état, gasleft() peut parfois augmenter. Un calcul qui s’attendait à une diminution non négative peut produire un résultat inattendu. Les contrats immuables ne peuvent pas être patchés. Seuls des tests ciblés sur les chemins d’exécution réels permettent de mesurer l’impact.
Wallets, RPC et usines de déploiement : d’autres fronts ouverts
Les portefeuilles et les fournisseurs de nœuds RPC estiment le gaz avant que l’utilisateur ne signe. Avec l’EIP-8037, eth_estimateGas et les logiciels de nœud doivent prendre en compte à la fois le gaz d’exécution et la nouvelle dimension d’état. Une constante mise en cache peut sous-estimer une transaction lourde en état. L’utilisateur voit alors son opération échouer, même si le contrat fonctionnerait avec une estimation correcte.
Les usines de déploiement déterministes constituent un autre cas particulier. Certaines ont été placées à des adresses standards grâce à des transactions présignées avec des limites de gaz codées en dur. Sur un réseau neuf qui adopterait le nouveau barème avant l’existence de l’usine, le déploiement présigné pourrait manquer de gaz. Les instances déjà déployées sur le réseau principal et les solutions de couche 2 ne sont pas concernées par ce scénario de genèse. Il est important de le préciser pour éviter les amalgames.
Même lorsqu’un contrat reste fonctionnel, le coût peut changer. Une application qui crée beaucoup de comptes ou d’emplacements de stockage verra sa structure de frais évoluer. Les devis, les politiques de subvention ou la façon de stocker les informations devront parfois être revus. Les catégories de rejeu distinguent précisément l’exécution identique, l’exécution réussie mais modifiée, les échecs corrigibles par une limite plus élevée et les contrats potentiellement cassés.
La limite de 200 millions n’était qu’un paramètre de test
Glamsterdam ne se résume pas à la repricing. La séparation enshrined entre proposant et constructeur modifie la transmission de la charge utile d’un bloc. Les listes d’accès au niveau du bloc aident les clients à identifier les comptes et le stockage touchés. Les équipes voulaient tester ces changements avec une limite de 200 millions de gaz sur Hoodi, comme sur Sepolia. Ce chiffre n’était qu’un paramètre de testnet. Il n’a jamais constitué une promesse d’adoption immédiate sur le réseau principal ni une garantie de baisse des frais pour les utilisateurs.
Retirer cette limite du calendrier Hoodi maintient la cohérence des composants reportés. Les opérateurs ne testeront pas la capacité plus élevée sous Glamsterdam le 26 octobre. Les équipes peuvent toujours s’appuyer sur Sepolia et des devnets dédiés pour étudier les effets de la repricing. L’absence de répétition Hoodi ralentit simplement la séquence de confiance avant un éventuel calendrier de production.
Procéder avec une incertitude connue peut coûter plus cher que de retarder un test public. Un contrat largement utilisé qui échouerait sur le réseau principal serait bien plus difficile à corriger.
Ce que doivent faire les différents acteurs
Un détenteur ordinaire de tokens sur le réseau principal n’a rien à changer dans son portefeuille. Un opérateur de nœud Hoodi qui s’était préparé pour le 26 octobre doit en revanche relire les notes de version. Un ingénieur protocole doit déterminer si les comportements observés lors des rejeux sont acceptables, corrigeables par des outils ou justifient une modification de la proposition. Une équipe applicative doit tester ses propres chemins d’exécution, y compris ceux peu utilisés historiquement.
La Fondation a mis à disposition un outil de recherche permettant d’examiner les adresses de contrats concernés et la raison de la divergence. Elle recommande également de tester sur un devnet avec le nouveau barème et d’inspecter tout code qui suppose des limites fixes, même si l’adresse n’apparaît pas dans la liste. Un rejeu historique reste un filtre, pas un inventaire exhaustif des comportements futurs.
Pour les validateurs Hoodi
Vérifier les versions d’exécution et de consensus. Supprimer toute configuration portant l’ancien epoch 132 352.
Pour les développeurs d’applications
Rejouer les séquences complètes utilisées par les clients, y compris les agents automatisés et les anciennes estimations de portefeuille.
Les prochaines étapes à surveiller
Avant qu’une nouvelle date ne soit proposée, plusieurs éléments devront être clarifiés. Les versions de clients qui retirent explicitement l’activation du 26 octobre. Les résultats mis à jour des rejeux et d’éventuelles modifications de l’EIP-8037. Un nouvel epoch Hoodi avec une configuration testable. Les retours des équipes dont les contrats sont concernés. Enfin, une annonce distincte pour le réseau principal, une fois les tests et la coordination des clients terminés.
Même une activation propre sur Hoodi ne garantira ni un prix d’ether particulier ni un niveau de frais définitif. Elle restera une répétition. Pour l’utilisateur final, le message immédiat est simple : aucune action sur le réseau principal n’est prévue pour le 26 octobre. L’urgence concerne les opérateurs Hoodi et les équipes dont les applications font des hypothèses figées sur le gaz.
Une prudence qui s’inscrit dans l’histoire récente
Le calendrier de Glamsterdam a déjà connu plusieurs ajustements cette année. Des problèmes de devnet et une difficulté d’implémentation de l’EIP-8037 avaient été signalés avant l’activation publique sur Sepolia. Ces épisodes antérieurs n’expliquent pas forcément le report actuel. Ils rappellent simplement pourquoi les dates restent conditionnelles tant que les équipes clients passent des essais privés aux réseaux publics.
Ethereum a toujours privilégié la coordination progressive : rejeu historique, testnets publics, puis réseau principal. Chaque étape répond à des questions que la précédente ne peut pas résoudre. Un court délai sur Hoodi peut offrir le temps nécessaire pour traiter les contrats concernés. Il ne prouve pas, à lui seul, que les règles finales seront sûres. La décision d’avancer devra s’appuyer sur des résultats de tests et des instructions claires pour les opérateurs.
En attendant, le réseau principal continue de fonctionner normalement. Aucun changement de règles n’a été activé. Les portefeuilles n’ont pas besoin de mise à jour urgente. Les équipes techniques, elles, ont du travail devant elles : inspecter les chemins de code, mettre à jour les estimateurs, et préparer d’éventuelles migrations pour les contrats immuables qui ne pourraient pas s’adapter. Le report du 26 octobre n’est pas un échec. C’est le choix de ne pas avancer dans le flou.
La suite dépendra des conclusions de l’enquête en cours. Une version révisée de l’EIP-8037 pourrait conserver l’objectif de facturer l’état tout en modifiant le fonctionnement du réservoir de gaz ou les règles de transition. Elle pourrait aussi maintenir la spécification et exiger des corrections ciblées côté applications. Aucune de ces options n’a encore été actée. Les jours ou semaines à venir diront laquelle l’emportera, et avec quel impact concret sur le calendrier de Glamsterdam.
En résumé, le report de Hoodi révèle une tension classique du développement d’Ethereum : comment faire évoluer les coûts internes d’une transaction sans casser les applications qui ont intégré les anciens chiffres dans leur code. Les développeurs ont choisi de résoudre cette tension avant de continuer. C’est un signal de maturité, même s’il allonge temporairement le chemin vers la prochaine grande mise à jour.
