Glamsterdam disparaît du calendrier d'octobre de Hoodi : Ethereum vérifie les risques liés aux contrats

Le test Hoodi du 26 octobre a été annulé, y compris sa limite de gaz prévue de 200 millions. Les développeurs examinent une proposition de réévaluation des prix face aux contrats déjà présents sur le mainnet.

Ethereum a annulé un test qui devait avoir lieu lundi prochain. L’avis du 22 octobre de la Fondation Ethereum indique que Glamsterdam ne s’activera pas sur Hoodi à 17:42:48 UTC le 26 octobre, et aucune nouvelle époque n’a été fixée. L’augmentation associée de la limite de gaz à 200 millions a également été retirée du calendrier du testnet. Il s’agit d’un report d’une configuration future, et non d’une annulation des blocs déjà enregistrés par Hoodi.

Les développeurs ont pris la décision d’examiner comment l’EIP-8037, une modification du prix de création d’un nouvel état Ethereum, interagit avec les contrats sur le mainnet. La Fondation n’a pas déclaré que la mise à niveau avait cassé le mainnet. Elle n’a pas non plus fixé de date pour un fork de production. Le risque opérationnel immédiat concerne Hoodi : les clients ou les configurations personnalisées qui portent encore l’ancienne heure d’activation pourraient être en désaccord avec le calendrier révisé. La question plus profonde est de savoir comment modifier le coût du travail à l’intérieur d’une transaction sans perturber les applications qui ont intégré les anciens chiffres dans leur code.

Le fork Hoodi du 26 octobre est retiré du calendrier

L’annonce Hoodi du 16 octobre spécifiait l’époque 132 352 et le slot 4 235 264. Elle associait les changements Amsterdam de la couche d’exécution aux changements Gloas de la couche de consensus et à une limite de gaz de 200 millions. Le nouvel avis remplace intégralement ces instructions. Les opérateurs doivent lire les dernières notes de version pour les deux types de clients ; une version antérieure décrite comme compatible avec Glamsterdam peut encore contenir l’activation Hoodi désormais annulée.

Ce n’est pas qu’une simple note de calendrier. Un validateur doit suivre les mêmes règles de réseau que ses pairs. Si une partie de son logiciel attend de nouvelles règles d’exécution ou de nouvelles obligations de consensus à l’ancienne époque alors que le réseau ne le fait pas, il peut perdre la capacité de suivre la chaîne canonique. L’infrastructure des constructeurs et des validateurs peut avoir sa propre configuration. La Fondation demande donc aux opérateurs de vérifier les versions révisées des clients et de supprimer les paramètres personnalisés obsolètes avant le 26 octobre, plutôt que de supposer que ne rien faire est sans danger parce qu’un fork a été reporté.

Sepolia a activé Glamsterdam le 6 octobre et a testé une limite de gaz de 200 millions, comme l’a rapporté la couverture de cette activation. L’activation réussie d’un testnet est utile mais n’est pas concluante pour un autre. La répétition restante de Hoodi a été reportée précisément parce que l’enquête sur les contrats nécessite du temps. Il n’existe aucun horodatage de remplacement publié à extrapoler pour une date sur le mainnet.

Glamsterdam s’est activé sur Sepolia le 6 octobre, où les développeurs ont testé une limite de gaz de 200 millions. Le test réussi ne règle pas la question de savoir comment l’EIP-8037 affectera les contrats déjà en cours d’exécution sur le mainnet. La répétition de Hoodi est reportée pendant que les développeurs enquêtent sur ces interactions, et aucune date de remplacement n’a été annoncée.

La séquence a changé plus d'une fois cette année. Le rapport de septembre sur le plan Sepolia décrivait des problèmes de devnet et un problème d'implémentation de l'EIP-8037 avant que le test public ne se poursuive. Ces problèmes antérieurs ne prouvent pas qu'il s'agit de la même cause que l'enquête sur le contrat du 22 octobre. Ils montrent pourquoi les dates ont été conditionnelles, à mesure que les équipes clientes passent des essais privés aux réseaux publics. Des préoccupations distinctes concernant le comportement des builders sur les testnets concernent une autre partie de Glamsterdam et ne doivent pas être confondues avec la revalorisation des prix. Le dernier avis donne une raison précise pour la pause de Hoodi : l'investigation plus approfondie de l'interaction de l'EIP-8037 avec les contrats du réseau principal.

Pourquoi la création d'état coûte plus cher dans la proposition

Une transaction peut exécuter des calculs et elle peut laisser des données que le réseau doit conserver et auxquelles il doit accéder ultérieurement. Créer un nouveau compte, ouvrir un nouvel emplacement de stockage ou déployer du bytecode de contrat ajoute à cet état persistant. L'EIP-8037 propose de facturer davantage ces opérations et de mesurer séparément la partie création d'état. L'objectif est de rapprocher le prix de la charge à plus long terme pesant sur les nœuds, en particulier si les blocs sont autorisés à porter plus de travail.

Le tableau illustratif de la proposition fixe la composante de création d'état d'un nouveau compte à 183 600 de gaz, contre 25 000 actuellement ; un nouvel emplacement de stockage à 97 920, contre 20 000 ; et un déploiement de 24 kilo-octets à 37 784 880, contre 4 947 200. Le tableau n'est pas une prédiction universelle des frais en ETH qu'un utilisateur paiera. Il isole une composante sous une constante proposée, avec d'autres frais d'exécution en sus, et le coût final en devise dépend du prix du gaz au moment considéré. L'ampleur du changement explique pourquoi les contrats aux limites serrées méritent un examen plus attentif.

Une proposition connexe sur l'accès à l'état, l'EIP-8038, revalorise certains coûts de lecture et d'écriture. Le guide d'impact pour les développeurs de la Fondation indique que ces coûts de gaz ont été substantiellement ajustés pour la dernière fois lors du fork Berlin en 2021, tandis que l'état a augmenté. La revalorisation prévue a été conçue parallèlement aux travaux visant à augmenter le débit ; agrandir les blocs sans tenir compte des opérations d'état coûteuses pourrait rendre la validation plus difficile pour les opérateurs de nœuds. La pause touche donc à la fois la compatibilité des applications et le plan de mise à l'échelle, bien que son déclencheur annoncé soit l'interaction avec l'EIP-8037.

Un appel externe montre pourquoi cela peut être difficile à remarquer à l'avance. Un appelant peut délibérément ne transmettre que suffisamment de gaz pour qu'un destinataire effectue une action limitée, en supposant que tout travail supplémentaire échouera en toute sécurité. Si un compte ou un accès au stockage revalorisé consomme désormais cette allocation, le destinataire peut échouer lors d'un paiement de routine, même si l'utilisateur a fourni beaucoup de gaz à la transaction externe. Modifier l'estimation du portefeuille ne réécrit pas l'allocation interne. Les développeurs doivent inspecter le chemin de code et la gestion des échecs qui l'entoure, car certaines applications considèrent un appel externe échoué comme une raison d'annuler, tandis que d'autres continuent et enregistrent un résultat différent.

Les modèles transfer et send de Solidity transfèrent historiquement une allocation de 2 300 de gaz. De nombreuses équipes ont déjà cessé de dépendre de cette allocation, mais les contrats déployés peuvent rester en usage pendant des années. La Fondation identifie les allocations fixes comme une catégorie de risque ; elle ne dit pas que chaque appel les utilisant échouera. Un destinataire qui effectue peu de travail peut rester dans les limites de l'allocation, tandis qu'un contrat qui touche un état nouvellement revalorisé peut la dépasser. Tester les contreparties réelles importe davantage que de traiter la simple présence d'un nom de fonction comme la preuve d'une rupture.

Une deuxième catégorie de problème réside dans l'automatisation. Les portefeuilles, les relayeurs et les dépositaires peuvent stocker des limites de gaz par défaut pour des tâches régulières. Une opération qui a fonctionné avec succès pendant des années pourrait commencer à manquer de gaz même si le contrat d'application lui-même est sain. Augmenter une estimation dans le frontend peut corriger cette voie, mais un agent planifié ou un client utilisant un portefeuille plus ancien pourrait continuer à soumettre la limite précédente. Les développeurs doivent donc identifier non seulement le code concerné, mais aussi les services qui construisent des transactions pour celui-ci.

Quels contrats peuvent rencontrer des problèmes ?

La Fondation a rejoué des transactions historiques du réseau principal selon le calendrier proposé. La plupart n'ont posé aucun problème significatif. Parmi les cas signalés, beaucoup se sont terminés après l'augmentation de leur limite de gaz ; un groupe plus restreint pourrait échouer même avec sensiblement plus de gaz. Une allocation fixe, une quantité de gaz codée en dur envoyée vers un autre contrat, ou une branche basée sur le résultat de gasleft() peuvent modifier le chemin emprunté par une transaction. L'avertissement antérieur sur les contrats décrivait ces catégories avant que Hoodi n'obtienne sa date d'octobre. Le report actuel rend urgents les cas sans réponse, mais il ne démontre pas que tous les contrats Ethereum sont vulnérables.

Prenons une application qui envoie des fonds à un autre contrat tout en fournissant une allocation de gaz fixe. Le contrat destinataire peut avoir besoin de plus de gaz selon le nouveau calendrier pour accéder au stockage. Si l'allocation de l'appelant est intégrée dans le code déployé, le simple fait d'augmenter la limite de la transaction de niveau supérieur peut ne pas donner plus de marge à l'appel destinataire. Un échec pourrait alors nécessiter une correction au niveau du contrat ou un itinéraire différent pour les utilisateurs. En revanche, si le seul problème est qu'un portefeuille a estimé une transaction en utilisant les anciens prix, une estimation mise à jour et une limite fournie plus élevée peuvent suffire. Les deux cas sont opérationnellement distincts.

Un problème particulièrement inhabituel de l'EIP-8037 concerne le code qui mesure le travail en soustrayant deux lectures du gaz restant. La proposition explique que le réservoir de gaz d'état peut faire augmenter gasleft() dans certaines circonstances. Un calcul s'attendant à une diminution non négative pourrait se comporter différemment, et les contrats déployés immuables ne peuvent pas être corrigés sur place. L'impact précis dépend du code et du chemin de la transaction, ce qui explique pourquoi un rejeu de transactions historiques réelles importe davantage qu'un avertissement générique sur des frais plus élevés.

L'outil de recherche de la Fondation permet aux développeurs d'examiner les adresses de contrats affectées et la raison d'une divergence signalée. Il recommande de tester sur un devnet en utilisant le nouveau calendrier et d'inspecter le code qui suppose des limites fixes même lorsqu'un contrat n'apparaît pas dans la liste. Un rejeu historique est un filtre, pas un inventaire complet du comportement futur : un itinéraire qu'aucun utilisateur n'a emprunté pendant l'échantillon pourrait encore contenir une hypothèse vulnérable. Les équipes ont besoin de leurs propres tests pour les branches qu'elles exploitent.

Le résultat d'un rejeu dépend aussi de l'échantillon de transactions. Un contrat peut contenir une allocation de gaz fixe dans une fonction rarement appelée ; si cet itinéraire est absent de l'historique rejoué, l'outil ne peut pas démontrer son échec. La Fondation conseille aux mainteneurs de vérifier le code même lorsque son adresse n'apparaît pas dans la liste des contrats affectés. Une grande application peut avoir plusieurs contrats, des interfaces évolutives et des agents automatisés, chacun fournissant une limite de gaz différente. L'équipe doit tester l'opération telle que ses utilisateurs l'invoquent réellement, y compris un portefeuille ou un bot qui pourrait conserver une ancienne estimation dans un cache.

Pour un contrat dont le comportement change, corriger l'interface qui soumet les transactions ne suffit pas toujours. Si l'allocation de gaz d'un appel interne a été compilée dans un code immuable, son propriétaire peut avoir besoin d'une migration vers un nouveau contrat. Une telle migration peut impliquer de déplacer des soldes, des approbations ou des permissions utilisateur, et de communiquer la nouvelle adresse. La difficulté dépend de la conception du produit ; rien ne prouve que chaque contrat signalé nécessite ce travail. C'est précisément pourquoi la distinction entre un échec corrigeable par la limite et un contrat potentiellement défaillant importe à la fois pour l'équipe et pour ses clients.

Les conseils de test sont particulièrement pertinents pour les applications qui utilisent l'abstraction de compte ou plusieurs appels de contrat pour accomplir une action utilisateur. Un paiement peut approuver un actif, router un échange et régler un marchand en une seule séquence. Si une étape interne utilise une allocation codée en dur, le client peut voir un paiement échoué sans savoir quel contrat a atteint la limite. Rejouer toute la séquence selon les règles proposées est plus informatif que de vérifier la méthode publique de chaque contrat isolément. Les mainteneurs devraient enregistrer la première étape en échec et si une limite de gaz externe plus élevée change réellement le résultat.

Les contrats peuvent également se comporter différemment après un appel échoué plutôt que de simplement s'arrêter. Un fallback qui enregistre un événement, crédite un solde interne ou tente une seconde route peut continuer dans des conditions que ses auteurs originaux n'avaient jamais prévues. Cette divergence explique pourquoi un résultat de test décrit uniquement comme « transaction réussie » peut être inadéquat. L'état de sortie et les événements doivent être comparés à l'ancienne exécution. La catégorie de la Fondation « exécution réussie avec changements » capture cette possibilité sans la déclarer automatiquement nuisible.

Portefeuilles, RPC et usines font face à des travaux différents

Les portefeuilles et les fournisseurs d'appels de procédure distante estiment le gaz nécessaire à une transaction avant que l'utilisateur ne signe. L'EIP-8037 indique que eth_estimateGas et les logiciels de nœud doivent tenir compte à la fois du gaz d'exécution et de la nouvelle dimension de gaz d'état. Une ancienne constante mise en cache peut sous-estimer une transaction lourde en état. Les utilisateurs peuvent alors voir des transactions échouées, même si le contrat fonctionnerait avec une limite correctement estimée. Les mises à jour d'infrastructure font donc partie de la compatibilité, et ne sont pas simplement une commodité superposée au protocole.

Les usines de déploiement déterministe présentent un autre cas étroit. L'EIP-8037 évoque des usines initialement placées à des adresses standard à l'aide de transactions pré-signées avec des limites de gaz codées en dur. Sur un réseau vierge qui adopte le nouveau barème avant que l'usine n'existe, l'ancien déploiement pré-signé pourrait manquer de gaz. La proposition précise explicitement que les instances déjà déployées sur le mainnet existant et les réseaux de couche 2 ne sont pas affectées par ce scénario de genèse particulier. Rapporter cette mise en garde est important : il serait trompeur de suggérer que chaque usine déjà utilisée sur Ethereum est sur le point de disparaître.

Les constructeurs doivent également distinguer un contrat inchangé de coûts inchangés. Une transaction peut réussir mais consommer une quantité de gaz différente. Une entreprise qui regroupe des déploiements ou crée de nombreux emplacements de stockage pourrait faire face à une structure de coûts sensiblement différente même si aucune fonction n'échoue. Son produit pourrait nécessiter des devis de frais différents, une politique de subvention révisée ou un changement dans sa façon de stocker les informations. Les catégories de rejeu de la Fondation séparent l'exécution identique, l'exécution modifiée mais réussie, les échecs corrigeables par la limite et les contrats potentiellement cassés précisément pour cette raison.

Les chiffres de l'EIP-8037 méritent une autre précision. Son exemple convertit le gaz proposé en ETH en utilisant un frais de base supposé de 0,08 gwei. Si les frais de base changent, l'ETH payé pour le même gaz change aussi. Un développeur comparant le tableau à une facture existante doit ajouter les frais d'exécution et les conditions réelles de la transaction, plutôt que de présenter un changement de coût d'état multiplié par sept comme une augmentation de sept fois du paiement complet d'un utilisateur. L'objectif de la proposition est d'attribuer des coûts aux ressources ; les frais finaux d'une personne dépendent de la combinaison de ces ressources dans la transaction.

L'ampleur de la revalorisation proposée doit être lue parallèlement à l'objectif de capacité. Plus d'espace pour les transactions dans un bloc peut rendre le réseau coûteux à valider si ces transactions créent de manière disproportionnée un état persistant. L'EIP-8037 attribue un compteur séparé à cette croissance afin que le coût ne disparaisse pas à l'intérieur d'une limite de gaz globale plus élevée. L'EIP-8038 traite des accès à l'état existant. Ils résolvent différentes parties de la question des ressources, et un constructeur de blocs fonctionnel seul ne peut pas établir que les applications gèrent correctement la revalorisation.

Les listes d'accès de bloc d'Ethereum ont une tâche distincte. Elles indiquent aux clients quels comptes et emplacements de stockage un bloc touche, aidant à organiser une partie du travail de validation en parallèle. Cela peut permettre un débit plus élevé dans des conditions favorables, mais cela n'efface pas le stockage persistant ajouté par les nouveaux comptes et emplacements. Un testnet doit exécuter la mise à niveau combinée sous une activité réaliste, car une amélioration dans une dimension peut exposer une contrainte dans une autre. Le report laisse cet exercice combiné sur Hoodi inachevé pour l'instant.

De nombreux utilisateurs rencontreront d'abord ces changements indirectement, via la limite de gaz indiquée par leur portefeuille ou l'estimation des frais d'une application. Une transaction qui ne crée aucun nouvel état peut avoir un effet différent de celle qui déploie un contrat conséquent. Une interface de trading qui promet un coût de transaction fixe devrait vérifier si sa promesse couvre encore les opérations qu'elle effectue. Les généralisations selon lesquelles tous les frais Ethereum évoluent dans une seule direction seraient prématurées sans un calendrier final pour le mainnet, une demande observée et les paramètres finaux.

Le chiffre de 200 millions était un paramètre de testnet

Glamsterdam combine plus que la revalorisation. La séparation proposant-constructeur inscrite dans le protocole modifie le transfert d'une charge utile de bloc, tandis que les listes d'accès au niveau du bloc aident les clients à identifier les comptes et le stockage qu'un bloc touchera. Les développeurs prévoyaient de tester ces changements avec une limite de gaz Hoodi de 200 millions, correspondant à Sepolia. Ce chiffre était un paramètre de testnet. Il n'a jamais été une promesse que le mainnet Ethereum adopterait immédiatement la même limite ou que les frais des utilisateurs baisseraient d'un certain pourcentage.

La suppression du calendrier de limite de gaz de Hoodi maintient ensemble les composants de la fourche reportée. Les opérateurs ne testeront pas la capacité supérieure prévue sous Glamsterdam sur ce réseau lundi prochain. Les développeurs peuvent toujours utiliser Sepolia et des devnets spécialement conçus pour étudier les effets de la revalorisation. La répétition manquante sur Hoodi affecte la séquence dans laquelle les équipes clientes peuvent gagner en confiance avant de choisir une date pour le mainnet, mais la Fondation n'a pas publié de calendrier de production révisé.

L'économie est moins simple qu'un slogan sur un gaz moins cher. Facturer davantage pour la création d'état durable peut rendre une transaction particulière plus coûteuse au même prix du gaz. Une capacité sûre plus grande, si elle est adoptée et utilisée ultérieurement, pourrait atténuer la congestion dans d'autres conditions. La demande détermine la quantité d'espace de bloc pour laquelle les utilisateurs enchérissent, et les paramètres finaux du protocole déterminent quelles opérations deviennent plus ou moins coûteuses. Ni la pause ni un test réussi ne résoudraient à eux seuls ces variables de marché.

La coordination publique a un coût, mais poursuivre avec une incertitude connue peut en avoir de plus grands. Les opérateurs ont préparé des logiciels pour l'ancienne époque et doivent maintenant supprimer ce calendrier ; les développeurs d'applications doivent continuer à tester contre une proposition dont la forme finale peut changer. Le coût de cette réinitialisation est visible. Une règle du mainnet qui ferait échouer un contrat largement utilisé serait plus difficile à inverser, et les retombées pourraient impliquer des fonds ou des applications dépendantes. L'avis du 22 octobre ne quantifie pas un tel risque, mais il indique clairement que les développeurs considéraient l'interaction comme suffisamment importante pour arrêter la répétition sur Hoodi.

Une proposition révisée pourrait préserver l'objectif de facturer l'état tout en modifiant le fonctionnement du réservoir de gaz ou les règles de transition pour les contrats existants. Elle pourrait plutôt conserver la spécification et exiger des correctifs ciblés des applications. Aucune décision publique entre ces voies n'apparaît dans l'avis de report. Les lecteurs devraient résister à la tentation de traiter une enquête comme un choix de conception final. Les amendements précis, s'il y en a, importeront plus que le nombre de jours pendant lesquels Hoodi attend.

Pourquoi les développeurs ont choisi d'attendre

Le processus d'Ethereum permet aux équipes clientes d'ajuster un plan avant une activation sur un testnet public. La décision du 22 octobre lors de l'appel All Core Devs Execution 248 fait suite à des avertissements antérieurs et à des démarches auprès des constructeurs concernés. L'avis public identifie le domaine faisant l'objet de l'enquête mais ne publie pas de décompte final des contrats à risque, une nouvelle version de l'EIP-8037, ni une date à laquelle l'enquête prendra fin. Qualifier le délai de défaut confirmé dans tous les contrats déployés irait au-delà de la publication ; le qualifier de simple réarrangement de calendrier manquerait sa cause déclarée.

L'ancienne configuration doit être retirée sur les deux couches. Les clients d'exécution traitent les transactions et l'état, tandis que les clients de consensus coordonnent les validateurs et le calendrier de la fourche. Un réseau ne peut tester la mise à niveau que si ces clients s'accordent sur les règles et le calendrier. Les opérateurs de Hoodi qui ont installé des versions spécifiquement pour le 26 octobre doivent rechercher les notes de version révisées. La Fondation indique qu'elle ajoutera des liens vers les nouvelles versions des clients au fur et à mesure de leur confirmation, plutôt que de considérer son tableau de compatibilité initial comme à jour.

Il y a aussi une leçon dans l'ordre des preuves. Le rejeu de l'historique a révélé un petit groupe affecté ; les testnets publics révèlent le comportement des clients et des applications dans un environnement réel ; le mainnet expose les règles finales à un usage économique à grande échelle. Chaque étape répond à quelque chose que la précédente ne peut pas. Un court délai sur Hoodi peut acheter du temps pour le travail sur les contrats, mais il ne prouve pas en soi que les règles finales sont sûres. La décision de poursuivre devrait suivre les résultats des tests et des instructions claires pour les opérateurs.

La portée de l'avis aux opérateurs mérite d'être précisée. Un détenteur ordinaire sur le mainnet n'a pas besoin de changer de portefeuille parce que le calendrier de Hoodi a été retiré. Un opérateur de nœud Hoodi qui s'est préparé pour la fourche doit bel et bien consulter les notes de version. Un ingénieur de protocole enquêtant sur l'EIP doit déterminer si le comportement des contrats découvert lors des rejeux est acceptable, corrigeable par des outils, ou une raison de modifier la proposition. Une équipe d'application doit tester ses propres routes d'exécution. Ce sont des publics différents avec des échéances différentes, et une simple alerte « mise à niveau retardée » ne donne pas à chacun d'eux la bonne instruction.

La prochaine publication de la Fondation peut aussi résoudre la manière dont les développeurs communiqueront avec les équipes concernées. Son guide d'août indiquait que des démarches directes avaient commencé, mais un simple décompte des démarches n'établirait pas qu'un contrat a été réparé. La preuve testable est un contrat mis à jour, une configuration de gaz révisée ou une solution de repli documentée pour un produit particulier. Certains contrats immuables peuvent nécessiter une migration des utilisateurs, ce qui soulève une préoccupation distincte de communication et de sécurité : les clients doivent savoir où réside un remplacement légitime et éviter les adresses frauduleuses. Aucune migration de masse n'a été annoncée, il s'agit donc encore d'une éventualité pour les équipes dont le code ne peut pas être modifié sur place.

Ce qui précède une autre date

Un calendrier révisé devrait indiquer quelles règles de l'EIP-8037 seront testées, ce qui a changé si la proposition est amendée, et quelles versions de client s'accordent sur la nouvelle époque Hoodi. Les mainteneurs d'applications ont besoin de temps pour effectuer des recherches sur les contrats concernés, mettre à jour les estimateurs, relever les limites lorsque cela suffit et examiner les allocations d'appels internes codées en dur lorsque cela ne suffit pas. Si un contrat déployé potentiellement défaillant n'a pas de voie de mise à niveau directe, son équipe devra peut-être expliquer comment les utilisateurs accéderont à un remplacement avant tout fork du réseau principal.

Les preuves publiques comprendraient la méthodologie de rejeu et les conclusions mises à jour sur les contrats concernés, les résultats des devnets avec le calendrier final de gaz, une activation Hoodi avec divers clients en accord, et une annonce distincte pour le réseau principal. Même une activation Hoodi propre ne serait qu'une répétition, et non une garantie d'un prix spécifique de l'ETH ou de frais de transaction finaux. Le message pratique pour les utilisateurs est qu'aucune action sur le réseau principal n'a été annoncée pour le 26 octobre. L'action immédiate incombe aux opérateurs de Hoodi et aux équipes dont les applications font des hypothèses sur le gaz.

Ce qu'il faut surveiller

• Versions des clients : Mises à jour d'exécution et de consensus qui suppriment explicitement l'ancienne activation Hoodi du 26 octobre.
• Résultats de l'EIP-8037 : Nouveaux résultats de rejeu, modifications des règles de gaz proposées et traitement des contrats avec des limites codées en dur ou une logique gasleft().
• Une époque de remplacement : Un plan Hoodi daté qui rétablit une configuration testable après l'enquête.
• Correctifs applicatifs : Rapports des constructeurs concernés expliquant si des limites plus élevées suffisent ou si le code déployé nécessite une autre voie.
• Avis mainnet : Un calendrier de production distinct de la Fondation après la séquence testnet et la coordination des clients.

FAQ