Ethereum Suspend Glamsterdam Hoodi Après Audit Gaz

Imaginez un réseau qui devait avancer sans friction, et qui soudain s’arrête net parce qu’une simple question de gaz a révélé des failles invisibles jusqu’alors. C’est exactement ce qui vient de se produire avec Ethereum. Les développeurs ont décidé de suspendre le fork Hoodi prévu dans le cadre de l’upgrade Glamsterdam. Derrière ce report se cachent des découvertes d’auditeurs qui changent la façon dont les contrats intelligents se comportent lorsqu’une transaction manque de ressources. Cette décision, prise après des semaines de tests intensifs, soulève des interrogations majeures pour toute la communauté.

Pourquoi Ethereum a freiné Glamsterdam sur Hoodi

Tout avait l’air de bien se dérouler. Le 26 octobre, le fork sur le testnet Hoodi devait marquer une étape importante. Les équipes avaient déjà testé certaines parties sur Sepolia, où une limite de gas de 200 millions avait même été expérimentée. Pourtant, le 6 novembre, un message clair est tombé : le processus reste en pause. Marius van der Wijden, développeur de la Fondation Ethereum, a confirmé que les équipes continuaient d’examiner des points soulevés lors de la revue approfondie du mécanisme de gas.

Ce n’est pas un simple retard technique. Les propositions EIP-8037 et EIP-8038 modifient en profondeur la manière dont le réseau facture certaines opérations liées à l’état. Créer de nouvelles données ou accéder à des informations déjà stockées n’a plus exactement le même coût. Et c’est là que le bât blesse. Même des contrats écrits bien avant cette upgrade peuvent soudain se comporter différemment. Un appel qui échouait auparavant pouvait faire tout reverter. Désormais, le contrat appelant peut parfois terminer son gestionnaire d’erreur et laisser une trace différente sur la chaîne.

Les auditeurs de ChainSecurity, Dedaub et les équipes internes ont mis le doigt sur plusieurs scénarios critiques. Huit hypothèses sont actuellement sous le microscope. Le but n’est pas de freiner l’innovation, mais d’éviter que des applications existantes ne produisent des résultats inattendus une fois les nouvelles règles actives.

Ce que changent réellement EIP-8037 et EIP-8038

EIP-8037 s’attaque au coût de création d’état. Quand un contrat crée un nouvel emplacement de stockage, un compte ou un autre élément durable, ce coût ne se limite plus au gas d’exécution classique. Une réserve séparée entre en jeu pour certaines opérations éligibles. Cela change la façon dont le budget global d’une transaction est consommé.

EIP-8038, de son côté, revoit le prix des accès à l’état existant. Lire une valeur, appeler un autre contrat puis écrire un résultat devient une séquence dont chaque étape pèse différemment sur le compteur de gas. Un développeur qui n’examine que le coût final d’écriture rate complètement l’impact cumulé des lectures et appels précédents.

Résultat concret : une application familière peut produire un résultat totalement différent avec exactement les mêmes entrées. La question centrale devient alors de distinguer les différences voulues par le nouveau tarifage de celles qui exposent une hypothèse fragile dans le code d’un client ou d’un contrat.

Quand un appel échoué ne fait plus tout reverter

Voici le point le plus délicat. Un contrat appelle un second contrat pour réaliser une étape. Si ce second contrat échoue, le premier peut choisir d’arrêter complètement l’opération ou de gérer l’échec et de continuer. Un processeur de lots, par exemple, peut enregistrer un élément raté et passer au suivant. Une autre application peut attendre que toute l’opération reverte si l’appel a consommé trop de gas.

ChainSecurity a montré comment la nouvelle comptabilité perturbe cette distinction. La règle EIP-150 limite déjà la quantité de gas qu’un appelant peut transmettre. Environ un soixante-quatrième reste avec l’appelant dans le cas concerné. Le problème réside dans la quantité réellement disponible au retour de l’exécution et dans le coût des instructions qui suivent.

Si l’application considère l’échec comme un résultat métier ordinaire, elle peut enregistrer quelque chose ou poursuivre. Si elle n’a plus assez de gas pour finir ce gestionnaire, la transaction externe reverte. Deux chemins, deux états finaux, alors que l’appel interne a échoué dans les deux cas.

Les contrôles basés sur gasleft() sont également touchés. Un seuil calibré sous l’ancien barème devient un mauvais prédicteur sous le nouveau. Le contrat n’a aucun moyen automatique de mettre à jour un chiffre codé en dur lors de son déploiement.

Les huit hypothèses actuellement examinées

Le dépôt d’auditeurs de la Fondation regroupe les exemples autour de deux axes : les changements de prix des opérations et les modifications de suivi du gas. Les chiffres reposent sur une version figée de la spécification proposée et peuvent évoluer.

Premier groupe de préoccupations : les allocations fixes et le coût de terminer un travail après un appel. Un développeur a pu fixer une limite de gas pour une opération qui coûte désormais plus cher. Une réserve destinée à payer une écriture finale peut ne plus suffire. Dans un autre cas, la petite fraction retenue par l’appelant peut être suffisante pour terminer un chemin d’échec que l’application s’attendait à voir reverter.

Les changements de comptabilité ouvrent d’autres possibilités. Si une réserve séparée peut encore financer la création d’état éligible, un appelant peut écrire un enregistrement après un appel raté même si son budget d’exécution ordinaire est serré. Le résultat final dépend alors des opérations qui utilisent ce budget distinct.

Effacer un emplacement créé plus tôt dans la même transaction peut renvoyer immédiatement une partie du gas d’état selon la spécification examinée. Un appel qui reverte peut aussi restituer du gas d’état. Un code écrit en supposant que tout le gas consommé avant un revert a disparu peut donc mal interpréter ce qui s’est passé.

Une paire de mesures gasleft() peut donner une vision incomplète. Un contrat qui utilise la différence pour facturer quelqu’un ou calculer un remboursement s’appuie sur des hypothèses fragiles. Les charges tirées d’un pool séparé et le gas d’état restitué pendant l’exécution modifient la relation.

Le huitième cas concerne EIP-7702. Une transaction peut être incluse même si une autorisation de délégation à l’intérieur n’a pas pris effet faute de gas. Un portefeuille ou un service qui se contente de l’inclusion de la transaction pour conclure que la délégation a fonctionné pourrait traiter une action incomplète comme terminée.

Comment un appel raté peut laisser une transaction réussie

Une transaction Ethereum peut contenir plusieurs appels. Un contrat demande à un autre d’effectuer une étape, puis décide de la suite en fonction du résultat. Un échec interne et un échec de transaction sont deux résultats distincts.

Prenez un processeur de lots. Si un élément échoue, il peut enregistrer cet échec et passer au suivant. S’il n’a plus de gas pour enregistrer le résultat, la transaction externe peut reverter et annuler les changements précédents. Le même échec interne laisse donc un état final différent selon ce que l’appelant peut encore faire.

Une autre application peut traiter un appel raté comme une raison de modifier qui peut soumettre une demande ou si elle peut être retentée. Si l’appelant peut terminer un chemin que l’application s’attendait à voir annuler, l’état résultant peut persister. La conséquence de sécurité dépend de ce que ce chemin terminé enregistre réellement.

Un acteur peut choisir la quantité de gas fournie à une transaction. S’il laisse assez de gas pour que le contrat externe entre dans un chemin mais trop peu pour que l’appel interne se termine, l’échec peut être provoqué par le budget de la transaction. Un contrat qui agit sur cet échec doit distinguer ce cas d’un appel qui a atteint le destinataire et a légitimement échoué.

La limite de transmission EIP-150 joue un rôle. Un appelant qui transmet autant de gas que permis conserve environ un soixante-quatrième. Cette quantité retenue doit encore payer les instructions qui suivent. Leur achèvement dépend du barème et de la comptabilité appliquée.

Un contrat peut être vulnérable à une plage étroite de budgets. Donnez assez de gas à l’appel interne et tout fonctionne normalement. Donnez trop peu à toute la transaction et le chemin externe reverte. L’intervalle problématique est celui où l’appel interne échoue alors que l’appelant a encore assez pour exécuter une action non prévue pour cet échec.

Pourquoi modifier un chiffre de gas fixe ne suffit pas toujours

Un seuil codé en dur offre une façon simple de vérifier qu’il reste assez de gas avant un appel. Le développeur a peut-être testé ce seuil avec des transactions courantes et laissé une marge. Ce chiffre devient une dépendance au barème sous lequel il a été choisi.

Une opération peut aussi coûter différemment selon qu’on met à jour un enregistrement existant ou qu’on en crée un. Un transfert vers quelqu’un qui a déjà un solde emprunte un chemin de stockage différent d’un transfert qui crée un premier solde. Un test qui ne couvre que les destinataires répétitifs peut manquer le chemin plus coûteux.

Le moment où le contrat mesure le gas compte. Une lecture juste avant l’appel diffère d’une lecture après plusieurs accès à l’état et l’appel lui-même. Un contrat qui déduit la raison de l’échec de cette dernière lecture suppose qu’il comprend ce qui a pu être facturé ou restitué entre-temps.

Changer une allocation peut avoir ses propres conséquences. Cela peut permettre à un chemin précédemment défaillant de se terminer, et cela peut aussi donner au destinataire assez de gas pour effectuer un travail qu’il ne pouvait pas faire sous l’ancienne allocation. Le développeur doit savoir ce que l’allocation était censée empêcher avant de l’ajuster.

Certains contrats peuvent être modifiés via un processus de gouvernance. D’autres sont immuables ou dépendent de composants qui ne peuvent pas être changés en place. Même quand un contrat peut être révisé, les services qui estiment, sponsorisent ou relaient ses transactions peuvent aussi devoir mettre à jour leurs propres hypothèses.

Ce qu’une reproduction convaincante doit démontrer

Un test peut commencer avec la même transaction, le même état et la même limite de gas sous les anciennes et les nouvelles règles. Une comparaison doit identifier quel appel renvoie un échec, ce que fait l’appelant ensuite et si la transaction enregistre des changements qui ne persistaient pas auparavant.

Tester des budgets juste au-dessus et juste en dessous du seuil aide à voir si l’effet occupe une plage étroite. Cela permet aussi d’identifier où l’exécution diverge. Une vérification de solde précoce, la quantité transmise au destinataire et une écriture dans le gestionnaire d’échec sont des points différents où un changement peut apparaître.

Le relecteur doit ensuite se demander qui peut atteindre ce chemin. Un changement reproduit dans un contrat de test établit une différence d’exécution. Une application réelle peut exiger une autorisation, vérifier une condition séparée ou rendre l’opération concernée retentable. Ces détails déterminent si quelqu’un peut forcer un résultat non désiré.

Il existe aussi un test distinct pour les équipes clients. Tous les clients d’exécution doivent atteindre le même résultat pour une transaction sous la même configuration de fork. Un désaccord entre clients est un problème différent de tous les clients produisant de façon cohérente un résultat qu’une application n’avait pas anticipé.

Une suite de tests a besoin de chemins réussis autant que d’échecs. Forcer chaque appel raté à reverter pourrait empêcher un changement d’état non désiré, mais aussi supprimer une capacité légitime de terminer le reste d’un lot. Le comportement voulu de l’application détermine ce qu’une correction doit préserver.

Une bonne reproduction doit rendre l’état final facile à inspecter. Si un enregistrement d’échec reste après une exécution et disparaît après une autre, le test peut montrer la différence exacte plutôt que de s’appuyer sur un rapport général sur l’utilisation du gas.

Le rôle des testnets publics après une reproduction locale

Un développeur peut tester un cas limite sur un fork local ou dans un environnement client contrôlé. Un testnet public permet ensuite à plusieurs opérateurs de faire tourner la même upgrade et de comparer son comportement dans des conditions partagées. Cela donne aussi aux équipes de portefeuilles et d’infrastructures un endroit pour tester leur propre logiciel contre les règles actives.

Sepolia et Hoodi servent des étapes différentes. L’activation sur Sepolia a montré que les développeurs pouvaient faire tourner le code prévu sur ce réseau et examiner son fonctionnement sous la limite de gas configurée. Hoodi devait offrir un déploiement supplémentaire après le traitement des findings devenus importants pendant la revue.

Les applications, le trafic et l’état historique d’un testnet diffèrent du mainnet. Un fork fluide peut donner des preuves sur l’accord des clients et les transactions routinières sans exercer chaque schéma de contrat sur lequel les utilisateurs s’appuient. Une reproduction ciblée fournit des preuves sur un cas limite qui peut être absent du trafic ordinaire du testnet.

Les instructions d’upgrade font aussi partie du test. Un opérateur a besoin d’une version qui implémente la configuration voulue et d’un point d’activation précis. Une application a besoin de savoir quand ses simulations doivent commencer à utiliser les règles révisées. Une nouvelle date est utile aux côtés de ces détails.

Quand les portefeuilles annoncent un succès alors qu’une action a échoué

Les portefeuilles estiment généralement le gas avant de demander à un utilisateur de signer. L’estimation dépend de l’état et des règles que le nœud applique dans sa simulation. Un service utilisant une configuration de fork plus ancienne peut donner une estimation qui n’est plus adaptée à une transaction que la chaîne actuelle exécute.

Une transaction qui reverte peut toujours coûter du gas à l’expéditeur. Une transaction externe qui se termine après avoir attrapé un échec interne peut être plus difficile à interpréter. La chaîne peut enregistrer la transaction globale comme réussie alors qu’une action à l’intérieur n’a pas eu lieu. Le portefeuille peut avoir besoin des événements ou de l’état de l’application pour expliquer la différence à l’utilisateur.

Les relayeurs et les sponsors de transactions font face à un problème similaire. Ils peuvent choisir le budget ou payer les coûts d’une transaction demandée par quelqu’un d’autre. Si le budget ne couvre plus le chemin prévu, le sponsor peut payer une exécution qui ne livre pas l’action demandée.

Les indexeurs peuvent voir l’effet après l’exécution. Un chemin d’échec qui se termine désormais peut produire des logs ou des changements d’état que le système en aval n’avait pas vus auparavant. L’indexeur suit toujours l’état réel de la chaîne. Une application qui s’appuie sur l’indexeur peut devoir changer la façon dont elle interprète l’enregistrement résultant.

Un test de bout en bout peut comparer l’estimation d’un portefeuille, le budget soumis par un relayeur, le résultat d’exécution du client et l’explication de l’interface. Chaque étape peut réussir isolément tandis que l’utilisateur reçoit encore un compte rendu trompeur des actions qui ont pris effet.

Ce qui pourrait lever la suspension de Hoodi

La Fondation demande aux équipes d’applications d’identifier les hypothèses qu’elles utilisent et de fournir des cas que les développeurs peuvent reproduire. Certains problèmes peuvent être traités par des modifications des règles de gas proposées. D’autres peuvent exiger qu’une application ou un fournisseur d’infrastructure révise sa façon de gérer le nouveau comportement.

Si les spécifications changent, le test pertinent est de savoir si un cas qui divergeait auparavant atteint désormais le résultat voulu. Si les développeurs conservent un changement de comportement, les équipes d’applications ont besoin de suffisamment de détails pour déterminer si leur logiciel s’appuie sur le résultat précédent. Les deux issues dépendent de la description de l’appel concerné et de ce qui persiste après.

Une spécification révisée doit aussi atteindre les builds clients que les opérateurs font tourner. Une version qui supportait une configuration Glamsterdam antérieure peut ne pas contenir les changements ultérieurs. Les numéros de version dans un nouvel avis Hoodi identifieraient quelles versions peuvent être testées ensemble.

La mise à jour de novembre indique que le travail sur Hegota continue en parallèle. Cela signifie que la suspension du fork précédent n’explique pas toutes les décisions de développement sur le suivant. Pour Glamsterdam, le prochain jalon pertinent est un calendrier Hoodi révisé avec une configuration que les développeurs sont prêts à faire tourner publiquement.

Un fork réussi donnerait aux équipes un enregistrement partagé à examiner avant une décision mainnet. Les cas qui ont provoqué le retard restent les tests les plus clairs de la préparation des règles révisées. Ces tests doivent montrer ce qui se passe quand un appel échoue près de sa limite de gas et que la transaction externe a encore du travail à faire.

Ce que révèlent les chiffres de gas proposés

Le dépôt de la Fondation donne un exemple concret de la différence entre créer un état et le mettre à jour. Sous la spécification Glamsterdam figée, une écriture froide qui crée un nouvel emplacement est divisée entre les coûts d’exécution et une charge d’état nettement plus importante. Une écriture sur un emplacement existant est aussi repricée, mais suit un calcul différent.

La différence peut toucher deux utilisateurs faisant ce qui semble être la même demande d’application. L’un a peut-être déjà utilisé le service, donc le contrat met à jour une entrée existante. L’autre a besoin d’un enregistrement frais. Une allocation de gas qui fonctionne pour le premier peut échouer pour le second.

Le dépôt indique aussi qu’une réserve séparée n’est disponible qu’au-dessus d’une limite de gas de transaction spécifiée dans la configuration testée. Dans les transactions plus petites, les coûts d’état viennent du budget ordinaire. Ce seuil rend important de tester plusieurs budgets plutôt que d’assumer que la réserve se comporte de la même façon pour chaque appel.

Un code qui lit le gas restant peut donc n’observer qu’une partie des ressources de la transaction dans certains cas. Les données qu’il lit restent significatives pour le budget que l’instruction expose. Ce qui change, c’est l’inférence que l’application peut tirer sur le total des ressources consommées ou encore disponibles.

Les exemples de gas sont liés à la configuration proposée. Ils ne donnent pas un multiplicateur unique applicable aux estimations existantes d’un portefeuille. Une première écriture de stockage, un appel utilisant une allocation fixe et une délégation échouée nécessitent chacun une vérification séparée parce qu’ils rencontrent des parties différentes des règles.

Les signaux à surveiller dans les prochaines semaines

Plusieurs éléments permettront de mesurer l’avancée réelle. Un calendrier Hoodi révisé devra identifier les versions clients et la configuration de fork que les opérateurs sont censés faire tourner. Des tests croisés entre clients pourront montrer s’ils atteignent les mêmes résultats d’état et de gas autour des nouvelles frontières.

Les reproductions de comportement de contrats devront montrer quand un appel externe raté laisse à l’appelant assez de gas pour terminer et ce que la transaction externe enregistre. Les changements apportés à EIP-8037 ou EIP-8038 indiqueront quels findings de la revue ont nécessité une modification de protocole.

Enfin, les résultats de simulation et d’estimation de gas montreront si les portefeuilles et les fournisseurs d’infrastructure reflètent correctement les règles du fork. Ces indicateurs concrets vaudront bien plus que de simples annonces de dates.

La situation actuelle rappelle une vérité essentielle du développement blockchain. Une upgrade qui semble purement technique peut avoir des répercussions profondes sur le comportement des applications déjà déployées. Ethereum a choisi de ralentir plutôt que de précipiter. Cette prudence, même si elle frustre certains, protège l’ensemble de l’écosystème contre des surprises coûteuses une fois les nouvelles règles actives sur le mainnet.

Les prochaines semaines diront si les équipes parviennent à résoudre les points identifiés ou si d’autres ajustements seront nécessaires. Pour l’instant, le message est clair : mieux vaut un report maîtrisé qu’un déploiement qui laisse des contrats se comporter de façon imprévisible. Les développeurs d’applications ont, de leur côté, tout intérêt à examiner leurs propres hypothèses de gas dès maintenant, avant que le prochain testnet ne soit relancé.

Cette pause forcée offre aussi une opportunité rare. Elle force toute la communauté à regarder de plus près la façon dont le gas influence réellement le flux d’exécution, au-delà des simples estimations affichées par les portefeuilles. Les leçons tirées de cette revue bénéficieront non seulement à Glamsterdam, mais aussi aux upgrades futures qui toucheront encore plus profondément le modèle économique et technique d’Ethereum.

En attendant une nouvelle date pour Hoodi, les yeux restent fixés sur les mises à jour de la Fondation et sur les reproductions que les auditeurs et les équipes d’applications continueront de partager. Le réseau n’a jamais autant eu besoin de transparence sur ces détails techniques apparemment secondaires. Car c’est précisément dans ces détails que se jouent la sécurité et la prévisibilité des milliards de valeur déjà déployés sous forme de contrats intelligents.

L’histoire de Glamsterdam n’est donc pas seulement celle d’un upgrade de plus. C’est celle d’un réseau qui apprend, en temps réel, à anticiper les effets secondaires de ses propres évolutions sur un écosystème déjà mature et complexe. Et c’est peut-être la leçon la plus importante de ce report : la maturité technique se mesure aussi à la capacité de ralentir quand il le faut.