Glamsterdam Hoodi Reporté Auditeurs Gaz Ethereum

Imaginez un réseau qui promet de moderniser en profondeur la façon dont il facture l’utilisation de son état, puis qui freine brutalement un testnet prévu de longue date. C’est exactement ce qui vient de se produire avec Ethereum. Le fork Hoodi de la mise à niveau Glamsterdam, initialement calé au 26 octobre, reste en suspens. Les développeurs ont découvert que certaines modifications de la comptabilité du gaz peuvent transformer le comportement de contrats déjà déployés, parfois de manière inattendue. Ce n’est plus seulement une question de clients ou de spécifications. C’est une affaire d’applications qui, sans avoir changé une seule ligne de code, pourraient se retrouver à prendre des chemins différents.

Pourquoi Ethereum A Mis Le Fork Hoodi En Pause

Tout a commencé avec une ambition claire. Glamsterdam devait faire évoluer la manière dont le protocole comptabilise les opérations qui touchent ou étendent l’état de la blockchain. Deux propositions, EIP-8037 et EIP-8038, se trouvent au cœur de cette transformation. L’une traite de la création d’état, l’autre de l’accès aux données déjà existantes. Sur le papier, l’idée paraît élégante. Séparer certains coûts, introduire un réservoir dédié, ajuster les prix pour mieux refléter le fardeau réel supporté par les nœuds. En pratique, les auditeurs ont mis le doigt sur des interactions délicates.

Le 6 novembre, Marius van der Wijden, développeur de la Ethereum Foundation, a confirmé que le test restait en attente. Les équipes continuent d’examiner les résultats des revues de gaz. ChainSecurity, Dedaub et des relecteurs internes ont contribué à ce travail. Leur constat principal est simple et inquiétant à la fois. Même des contrats écrits bien avant Glamsterdam peuvent se comporter différemment sous les nouvelles règles. Une transaction qui échouait auparavant peut maintenant réussir, ou l’inverse, selon la quantité de gaz restante à un moment précis.

Cette situation n’est pas anodine. Elle touche directement la confiance que les développeurs d’applications placent dans la stabilité des règles d’exécution. Quand un contrat décide de continuer après un appel échoué, ou au contraire de tout faire revenir en arrière, il s’appuie sur des hypothèses de gaz. Si ces hypothèses changent sans que le code bouge, le résultat final peut surprendre.

Ce Que Changent Exactement Les Propositions

EIP-8037 modifie la façon dont le protocole compte les opérations qui créent de l’état. L’état d’Ethereum, ce sont ces enregistrements persistants comme le stockage des contrats. Une écriture qui reste après la transaction a un coût pour les nœuds bien au-delà de l’exécution immédiate. La proposition introduit un réservoir séparé pour certaines opérations éligibles. Ce budget distinct n’est pas toujours visible de la même manière pour le code qui interroge le gaz restant.

EIP-8038, de son côté, revalorise les accès à l’état existant. Ensemble, ces deux changements touchent des moments différents d’une même exécution. Un contrat peut lire une valeur, appeler un autre contrat, puis écrire un résultat. Regarder uniquement le prix de la dernière écriture ne suffit pas. Les lectures et les appels antérieurs ont déjà grignoté le budget disponible.

Le résultat est parfois contre-intuitif. Une application familière, avec les mêmes entrées, peut produire un état final différent. La question centrale devient alors de distinguer les différences voulues par le re-pricing de celles qui révèlent une hypothèse fragile dans le code existant.

Quand Un Appel Échoué Ne Fait Plus Tout Revenir En Arrière

Prenons un exemple concret. Un contrat appelle un second contrat pour réaliser une étape. Si ce second appel échoue, le premier peut choisir d’arrêter toute l’opération ou de gérer l’échec et de continuer. Un processeur de lots peut simplement enregistrer l’échec d’un élément et passer au suivant. Une autre application peut attendre que toute la transaction soit annulée si l’appel a consommé trop de gaz.

ChainSecurity a montré comment la nouvelle comptabilité modifie cette distinction. Ethereum limite déjà, via la règle EIP-150, la quantité de gaz qu’un appelant peut transmettre. Environ un soixante-quatrième reste avec l’appelant dans le cas pertinent. La question devient alors de savoir combien de gaz l’appelant possède réellement au moment du retour, et combien il lui en coûte pour terminer les instructions de son chemin d’échec.

Sous les nouvelles règles, un appel peut échouer tandis que le contrat qui l’a lancé parvient tout de même à terminer son gestionnaire d’échec. Avec l’ancien barème, le même chemin aurait pu faire revenir toute la transaction en arrière.

Synthèse des constats de ChainSecurity

Cette nuance change tout. 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 gaz pour finir ce traitement, la transaction externe est annulée. Les deux situations partent du même échec interne, mais laissent des traces différentes sur la chaîne.

Les vérifications basées sur gasleft() sont également concernées. Un contrat peut comparer son budget restant à un minimum codé en dur. Un seuil calibré sous l’ancien barème devient un mauvais prédicteur sous le nouveau, surtout quand des opérations d’état ou des transferts de gaz interviennent. Le contrat n’a aucun moyen automatique de mettre à jour un chiffre inscrit au moment du déploiement.

Les Huit Hypothèses Passées Au Crible

La mise à jour de novembre de la Foundation évoque huit hypothèses en cours d’examen. Deux questions distinctes se posent pour les tests. Les clients qui implémentent les nouvelles règles doivent arriver au même résultat pour une transaction donnée. Les relecteurs d’applications doivent aussi repérer les cas où ce résultat partagé diffère de ce que les contrats existants attendaient.

Un test pour la première question consiste à exécuter la même transaction sur plusieurs clients et à comparer l’état et les consommations de gaz. Pour la seconde, il faut suivre la logique propre de l’application. Est-ce que le contrat traite un callback échoué comme un signal pour continuer ? Est-ce qu’il enregistre un changement d’état avant l’appel ? Est-ce qu’il distingue un rejet métier d’un appel qui n’avait jamais assez de gaz ?

Ces chemins passent facilement à côté d’un test de déploiement classique. Un budget de transaction généreux peut masquer la différence. Un budget volontairement serré la révèle. Les tests aux frontières doivent donc inclure des appels échoués et des situations proches de la quantité exacte de gaz nécessaire pour entrer ou terminer le gestionnaire d’échec.

Le Rôle Crucial Du Testnet Hoodi

Glamsterdam a déjà été activé sur Sepolia, où les développeurs ont testé une limite de gaz de 200 millions. Hoodi devait offrir un second environnement partagé pour exercer la version révisée de la mise à niveau. Un fork public permet aux équipes clients et aux opérateurs d’applications de travailler sur un calendrier commun, de comparer leurs résultats et de tester leurs outils face aux nouvelles règles.

Un fork Hoodi réussi apporterait des preuves concrètes sur les versions et les transactions testées. La question de fond reste cependant ce que font les applications représentatives aux limites de leur budget de gaz. Une nouvelle date de fork sera plus facile à évaluer si elle s’accompagne d’un historique clair des cas reproduits, des changements apportés et des méthodes de test utilisées.

Le travail sur le gaz se déroule en parallèle d’autres correctifs. Les développeurs ont notamment révisé la spécification des dépôts de validateurs pendant que la revue de gaz avançait. Ces correctifs nécessitent leurs propres tests car ils touchent une autre partie du fork.

Comment Les Limites De Gaz Et Les Coûts D’État S’Emboîtent

Une limite de gaz de bloc plus élevée donne à Ethereum davantage de place pour du travail sous son système de comptabilité. Le prix assigné à chaque opération détermine combien de cette place l’opération occupe. Une modification de la limite et une modification des prix peuvent donc affecter des parties différentes de la même transaction.

Certaines opérations se terminent avec la transaction. Créer de l’état est différent. Les données persistent et laissent aux opérateurs de nœuds quelque chose à stocker et traiter plus tard. Un nouvel emplacement de stockage, un compte ou un contrat ajoute à cette charge même si l’application qui l’a créé reçoit peu de trafic ensuite.

EIP-8037 change la façon dont le coût de certaines créations d’état est comptabilisé. EIP-8038 revalorise l’accès à l’état, y compris pour des enregistrements déjà existants. Une transaction qui lit une valeur, appelle un autre contrat et crée une entrée de stockage peut rencontrer les deux changements au cours d’une seule exécution.

Une limite de bloc plus élevée ne dit pas à elle seule si cette séquence coûtera plus ou moins cher. Elle décrit l’espace disponible pour le bloc dans son ensemble. Le chemin de la transaction et le prix de chaque opération déterminent si elle tient dans le gaz fourni par l’expéditeur.

Pourquoi Un Seuil De Gaz Fixe Peut Devenir Un Piège

Un seuil codé en dur offre au contrat une façon simple de vérifier qu’il dispose encore d’assez de gaz avant un appel. Le développeur a souvent testé ce seuil avec des transactions courantes et laissé une marge pour le travail qui suit. Ce chiffre devient alors une dépendance au barème sous lequel il a été choisi.

Une opération peut aussi coûter des montants différents selon qu’elle met à jour un enregistrement existant ou qu’elle 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 le plus coûteux.

Le moment où le contrat mesure le gaz compte. Une lecture juste avant l’appel n’est pas la même qu’une lecture après plusieurs accès d’état et l’appel lui-même. Un contrat qui déduit la raison d’un échec de la seconde lecture suppose qu’il comprend tout ce qui a pu être facturé ou rendu entre-temps.

Modifier une allocation de gaz a ses propres conséquences. Cela peut permettre à un chemin qui échouait auparavant de se terminer, et cela peut aussi donner au destinataire assez de gaz 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.

Ce Qu’Une Reproduction Convaincante Doit Montrer

Un test solide part de la même transaction, du même état et de la même limite de gaz sous les anciennes et les nouvelles règles. La 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 de repérer 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. Une différence reproduite 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 réessayable. 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 celui où tous les clients produisent de façon cohérente un résultat qu’une application n’avait pas anticipé.

Ce Que Les Testnets Publics Apportent 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 mise à niveau et de comparer son comportement dans des conditions partagées. Il offre aussi aux équipes de portefeuilles et d’infrastructures un endroit pour tester leur propre logiciel face aux 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 gaz configurée. Hoodi devait leur donner un déploiement supplémentaire après avoir traité les constats devenus importants pendant la revue.

Les applications, le trafic et l’état historique d’un testnet diffèrent de ceux du mainnet. Un fork fluide peut apporter des preuves d’accord entre clients et de transactions routinières sans exercer tous les modèles de contrats sur lesquels les utilisateurs s’appuient. Une reproduction ciblée fournit des preuves sur un cas limite qui peut être absent du trafic ordinaire du testnet.

Quand Un Portefeuille Affiche Un Succès Alors Qu’Une Action A Échoué

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

Une transaction qui revient en arrière peut malgré tout coûter du gaz à l’expéditeur. Une transaction externe qui se termine après avoir capturé un échec interne est 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 relais et les sponsors de transactions affrontent un problème voisin. 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 voient l’effet après l’exécution. Un chemin d’échec qui se termine maintenant peut produire des logs ou des changements d’état que le système en aval ne voyait pas auparavant. L’indexeur suit toujours l’état réel de la chaîne. Une application qui s’appuie sur l’indexeur peut devoir modifier la façon dont elle interprète l’enregistrement résultant.

Ce Qui Pourrait Lever Le Gel De Hoodi

La Foundation 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 pourront être traités par des modifications des règles de gaz proposées. D’autres demanderont à une application ou à un fournisseur d’infrastructure de réviser la façon dont il gère le nouveau comportement.

Si les spécifications changent, le test pertinent consiste à vérifier si un cas qui divergeait auparavant atteint maintenant le résultat prévu. 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 précise de l’appel concerné et de ce qui persiste après lui.

Une spécification révisée doit aussi atteindre les builds clients que les opérateurs font tourner. Une build 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 se poursuit en parallèle. Cela signifie que le gel 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.

Ce Que Les Chiffres Proposés Révèlent Sur Les Différents Chemins

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

La différence peut concerner deux utilisateurs qui formulent apparemment la même demande à l’application. L’un a déjà utilisé le service, le contrat met donc à jour une entrée existante. L’autre a besoin d’un enregistrement frais. Une allocation de gaz qui fonctionne pour le premier peut échouer pour le second.

Le dépôt précise aussi qu’un réservoir séparé n’est disponible qu’au-dessus d’une limite de gaz 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 le réservoir se comporte de la même façon pour chaque appel.

Le code qui lit le gaz 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 Signaux À Surveiller Dans Les Prochaines Semaines

Plusieurs indicateurs permettront de jauger si la situation évolue favorablement. Un calendrier Hoodi révisé devrait identifier les versions clients et la configuration de fork que les opérateurs sont censés faire tourner. Des tests croisés entre clients peuvent montrer s’ils atteignent les mêmes résultats d’état et de gaz autour des nouvelles frontières.

Les reproductions de comportement de contrats devraient indiquer quand un appel externe échoué laisse à l’appelant assez de gaz pour terminer et ce que la transaction externe enregistre. Des changements apportés à EIP-8037 ou EIP-8038 aideront à voir quels constats de revue ont nécessité une modification de protocole. Enfin, les résultats de simulation et d’estimation de gaz montreront si les portefeuilles et les fournisseurs d’infrastructure reflètent correctement les règles du fork.

Ce Que Les Développeurs D’Applications Doivent Faire Dès Maintenant

Même si le fork Hoodi est en pause, le travail de revue ne l’est pas. Les équipes qui maintiennent des contrats critiques ont intérêt à identifier les endroits où elles s’appuient sur des quantités de gaz fixes, des mesures de gasleft() ou des hypothèses sur ce qui se passe après un appel échoué. Les cas de lots, de callbacks et de délégations sont particulièrement exposés.

Tester avec des budgets volontairement serrés reste l’un des moyens les plus efficaces de faire apparaître les divergences. Comparer l’état final sous l’ancien et le nouveau barème, pour la même transaction, apporte des informations concrètes. Documenter précisément le chemin qui diverge aide ensuite les équipes de la Foundation à prioriser les correctifs ou les clarifications.

Les contrats immuables posent un défi supplémentaire. Quand le code ne peut plus être modifié, la seule marge de manœuvre réside parfois dans les outils qui l’entourent : estimation de gaz, relais, indexeurs ou interfaces utilisateur. Une communication claire sur le nouveau comportement devient alors essentielle pour éviter les mauvaises surprises côté utilisateurs.

Une Pause Qui Révèle La Maturité Du Processus

Reporter un testnet n’est jamais anodin. Cela retarde le calendrier et peut créer de l’incertitude. Dans le cas présent, la décision montre aussi que les équipes prennent au sérieux les interactions entre les nouvelles règles et le code déjà déployé. Ethereum a déjà connu des mises à niveau majeures. Chacune a appris aux développeurs que les détails de gaz et d’état sont parmi les plus délicats à faire évoluer sans friction.

La présence d’auditeurs externes comme ChainSecurity et Dedaub renforce la crédibilité de la revue. Leur travail ne se limite pas à chercher des failles de sécurité classiques. Il s’agit aussi de cartographier les hypothèses implicites que le code existant a intégrées au fil des années. Ces hypothèses sont souvent invisibles tant que le barème de gaz ne change pas.

Le fait que le travail sur Hegota se poursuive en parallèle indique que le gel de Hoodi n’immobilise pas toute la feuille de route. Les équipes continuent d’avancer sur d’autres fronts tout en traitant les questions soulevées par Glamsterdam. Cette capacité à paralléliser les efforts est un signe de maturité organisationnelle.

Les Enjeux Pour L’Écosystème Au-Delà Du Testnet

Au-delà de Hoodi, la question touche la confiance des développeurs d’applications dans la stabilité des règles d’exécution. Ethereum se veut un environnement prévisible. Quand un changement de protocole peut faire basculer le comportement d’un contrat sans modification de son code, cette prévisibilité est mise à l’épreuve.

Les applications DeFi, les protocoles de lots, les systèmes de callbacks et les mécanismes de délégation sont particulièrement concernés. Beaucoup d’entre eux ont été conçus et audités sous l’ancien barème. Une revue systématique de leurs chemins critiques devient une précaution raisonnable, même si le fork n’est pas encore activé sur le mainnet.

Les fournisseurs d’infrastructures ont aussi un rôle à jouer. Les estimateurs de gaz, les simulateurs et les relais doivent intégrer les nouvelles règles dès qu’elles se stabilisent. Un décalage entre la simulation et l’exécution réelle peut générer des transactions qui échouent ou, pire, qui réussissent d’une façon non intentionnelle.

Vers Une Meilleure Compréhension Collective Des Coûts D’État

Au fond, Glamsterdam touche une question structurelle. L’état d’Ethereum a un coût à long terme pour les nœuds. Les propositions tentent de mieux aligner le prix payé par les utilisateurs avec ce fardeau. Cette intention est saine. Sa mise en œuvre révèle cependant la complexité des interactions entre le gaz d’exécution, le gaz d’état et les chemins de contrôle des contrats.

Les exemples fournis par le dépôt de la Foundation montrent que la différence entre créer et mettre à jour un emplacement peut être significative. Ils montrent aussi que le réservoir séparé ne s’active pas de la même façon selon la taille de la transaction. Ces nuances demandent des tests minutieux plutôt qu’une simple règle de trois appliquée aux estimations existantes.

Plus les équipes partagent des reproductions claires, plus il devient possible d’ajuster soit les spécifications, soit les pratiques de développement. La transparence de la revue actuelle contribue à cet effort collectif. Elle transforme un retard de testnet en opportunité d’améliorer la robustesse de l’écosystème.

Ce Que Révèle Cette Situation Sur L’Évolution D’Ethereum

Ethereum n’est plus un protocole jeune qui peut se permettre des changements brusques. Chaque modification de la machine virtuelle ou de la comptabilité du gaz touche désormais un ensemble immense de contrats et d’outils. La prudence affichée autour de Hoodi reflète cette réalité. Mieux vaut un testnet retardé qu’une activation qui créerait des divergences de comportement difficiles à anticiper.

Les auditeurs ont joué leur rôle en cartographiant les hypothèses fragiles. Les développeurs de clients doivent maintenant s’assurer que toutes les implémentations convergent. Les équipes d’applications doivent vérifier leurs propres chemins critiques. Cette répartition des responsabilités est saine. Elle montre que la sécurité et la prévisibilité reposent sur un effort partagé plutôt que sur une seule équipe centrale.

Le prochain avis concernant Hoodi sera attendu avec attention. Il devra préciser non seulement une date, mais aussi les versions exactes et les cas qui ont été couverts. C’est à ces détails que l’écosystème jugera si les constats ont été correctement traités.

Une Leçon Pour Les Prochaines Mises À Niveau

Cette pause offre déjà une leçon utile. Les changements de prix de gaz, même motivés par de bonnes intentions, peuvent avoir des effets de second ordre sur la logique des contrats. Les tests doivent donc inclure systématiquement des scénarios de gaz bas, des appels échoués et des mesures de gasleft() autour des points critiques.

Les développeurs qui conçoivent de nouveaux contrats peuvent également tirer des enseignements. Éviter les seuils trop rigides, documenter les hypothèses de gaz et prévoir des mécanismes de mise à jour quand c’est possible restent des bonnes pratiques. Pour les contrats déjà déployés, la vigilance et les tests ciblés sont pour l’instant les meilleurs outils disponibles.

Glamsterdam n’est pas abandonné. Il est simplement soumis à un examen plus approfondi que prévu. Dans un écosystème où des milliards de valeur dépendent de la prévisibilité des règles, cette rigueur est plutôt rassurante que préoccupante.

Les semaines qui viennent diront si les équipes parviennent à résoudre les points soulevés tout en maintenant le rythme sur les autres chantiers. En attendant, le message est clair. Le gaz n’est pas seulement un compteur. C’est un élément qui structure le comportement des applications. Toute évolution de sa comptabilité mérite d’être examinée avec la plus grande attention.