Les développeurs d'Ethereum retardent Glamsterdam, huit invariants en cause

Glamsterdam, la prochaine mise à jour d'Ethereum, est actuellement testée sur des réseaux de test (testnets), indique l'Ethereum Foundation dans une publication datée du 6 novembre 2026. Au cours de ces tests, la société d'audit Chainsecurity a trouvé « quelques projets » qui seraient vulnérables après Glamsterdam, parce qu'ils reposent sur certains invariants, c'est-à-dire des propriétés que leur code suppose toujours vraies. La fondation n'indique ni le nom ni le nombre de ces projets.¹

D'après l'Ethereum Foundation, deux propositions d'amélioration intégrées à la mise à jour rompent ces invariants : EIP-8037 et EIP-8038. Elles revoient la quantité de gas facturée pour certaines opérations et la façon dont le gas est facturé pour l'état (state) du réseau. Les détails de ces problèmes potentiels sont exposés dans un article de blog de Chainsecurity et dans un outil mis à disposition, auxquels renvoie la fondation. Concrètement, un contrat qui suppose que le coût en gas de certaines opérations reste celui d'aujourd'hui pourrait, après la mise à jour, se retrouver dans une situation que ses concepteurs n'avaient pas prévue.¹

Un calendrier suspendu à l'inventaire des risques

Au vu de ces constats, ACD (les réunions AllCoreDev des développeurs du protocole) a décidé de retarder le processus de hard fork et de ne pas forker Hoodi tant que les problèmes ne sont pas résolus, écrit l'Ethereum Foundation. La publication ne donne aucune nouvelle date. Le report est donc décidé, mais sa durée n'est pas connue : elle dépendra, d'après le texte, de la résolution des problèmes relevés.¹

La fondation précise que le report ne touche pas les travaux sur Hegota, présentée comme une autre étape du développement, qui « se poursuivent en parallèle à plein régime ». Le texte ne décrit pas le contenu de Hegota. Ce qui signifie que, d'après la fondation, le retard est limité à Glamsterdam et ne repousse pas pour l'instant la suite de la feuille de route.¹

Pour prendre une décision qu'elle qualifie de « pragmatique » lors des prochaines réunions AllCoreDev, la fondation explique avoir besoin de savoir ce qui pourrait ne plus fonctionner après Glamsterdam, et si des changements de la spécification permettraient d'éviter ces problèmes. Deux suites sont donc possibles d'après le texte : soit la mise à jour avance une fois les projets concernés corrigés, soit la spécification d'EIP-8037 et d'EIP-8038 est modifiée. Reste à savoir laquelle les développeurs du protocole retiendraient, et dans quel délai.¹

Un appel aux développeurs de contrats

L'Ethereum Foundation dit faire appel aux sociétés d'audit Chainsecurity et Dedaub et mener des audits internes. Elle reconnaît toutefois ne pas pouvoir examiner tous les projets construits sur Ethereum, « en particulier leur code on-chain et off-chain ». Elle présente donc sa publication comme un « appel à l'action » aux développeurs de contrats et aux auditeurs pour qu'ils vérifient si leurs projets reposent sur l'un des huit invariants en cause. Ce qui signifie qu'une partie du travail de détection revient aux équipes des projets elles-mêmes.¹

Pour cela, la fondation a créé un dépôt qui recense les invariants rompus par Glamsterdam. Pour chacun, il contient une courte explication, des exemples et des prompts permettant aux équipes de vérifier leurs propres projets. Les projets concernés sont invités à écrire à l'adresse glamsterdam@ethereum.org. À ce stade, la publication ne dit pas combien de projets se sont déjà signalés, ni à quelle date l'inventaire serait jugé suffisant pour reprendre le calendrier.¹

Cet article est volontairement court : la seule source disponible sur ce sujet est la publication de l'Ethereum Foundation. L'autre article consulté, publié le même jour par le média singapourien e27, porte sur l'Enterprise Innovation Platform (EIP) de l'opérateur malaisien U Mobile et sur la 5G-Advanced. Il partage le sigle « EIP » mais n'a pas de rapport avec les propositions d'amélioration d'Ethereum, et ne permet donc aucune comparaison.^1,2