Les développeurs d'Ethereum ont suspendu l'activation de la mise à niveau Glamsterdam sur le testnet Hoodi en raison de préoccupations concernant le comportement des contrats intelligents déjà déployés face aux nouvelles règles de tarification du gaz de la mise à niveau. La décision a été prise lors de l'appel All Core Devs Execution #248, a indiqué l'Ethereum Foundation dans son annonce du 22 octobre.

Points clés de la décision :

• Le coût d'état d'un nouvel emplacement de stockage passe de 20 000 à 97 920 de gaz.
• L'augmentation prévue de la limite de gaz de Hoodi à 200 millions a également été retirée.
• Aucune date d'activation de Glamsterdam sur le mainnet n'a été fixée.
• La revue Last Call de l'EIP-8037 se termine le 1er novembre.

La dernière étape du testnet avant le mainnet est suspendue

Glamsterdam devait s'activer sur Hoodi le 26 octobre à 17:42:48 UTC. Le report supprime à la fois les activations d'Amsterdam sur la couche d'exécution et de Gloas sur la couche de consensus — les deux moitiés de la mise à niveau — ainsi que le calendrier qui devait porter la limite de gaz de Hoodi à 200 millions au même moment. Cela modifie la configuration future du testnet sans annuler son historique, et aucune date de remplacement n'a été fixée.

Durant Fusaka, la mise à niveau précédente, Hoodi était le troisième et dernier testnet à forker avant le mainnet, la Foundation avait indiqué que le mainnet suivrait au moins 30 jours plus tard, selon The Block. Dans ce déploiement, le dernier fork du testnet constituait le dernier point de contrôle public avant le mainnet. Glamsterdam a déjà réussi une répétition à 200 millions de gaz sur Sepolia, où la correction consistait en une mise à jour des valeurs par défaut des validateurs de Prysm — un problème de configuration du client. Cette fois, la question est de savoir comment se comportent les contrats déjà déployés. La Foundation n'a pas fixé de date de mainnet pour Glamsterdam et indique que les utilisateurs du mainnet et les détenteurs d'ETH n'ont rien à faire.

Une hausse du prix du stockage qui réduit le gaz d'exécution pour certaines écritures

L'EIP-8037 vise à ralentir la croissance de l'état d'Ethereum, les données que chaque nœud doit stocker. Ses auteurs estiment cet état à environ 390 GiB en janvier 2026. Ils évaluent qu'avec la tarification actuelle, une limite de gaz de 200 millions pourrait le porter au-delà de 650 GiB — le seuil auquel les nœuds commencent à ralentir — en moins d'un an. Leur réponse : facturer 1 530 de gaz par octet de nouvel état, portant le coût d'état d'un nouvel emplacement de stockage de 20 000 à 97 920 de gaz, et celui d'un nouveau compte de 25 000 à 183 600.

Pour que les déploiements de gros contrats restent possibles, la proposition divise le gaz en deux pools. Le gaz d'exécution couvre le calcul, et le gaz d'état couvre le nouveau stockage. Tout gaz fourni par une transaction au-delà de 16 777 216 va dans un réservoir distinct de gaz d'état, sur lequel les frais d'état sont prélevés en priorité. Ce réservoir est intégralement transmis à chaque sous-appel, et les contrats ne peuvent pas le voir via la lecture standard de gasleft().

Gaz d'exécution requis pour une écriture à froid dans un nouvel emplacement de stockage, selon ChainSecurity, à partir des chiffres des EIP-8037 et EIP-8038 :

• Aujourd'hui : 22 100
• Glamsterdam, le réservoir paie les 97 920 de frais d'état : 12 100
• Glamsterdam, réservoir vide : 110 020

Autrement dit, la même écriture à froid peut coûter environ neuf fois plus de gaz d'exécution avec le réservoir vide que lorsque le réservoir couvre les frais d'état.

Le gaz peut également refluer pendant l'exécution. Effacer un emplacement créé plus tôt dans la même transaction remplit immédiatement jusqu'à 97 920 de gaz, et un sous-appel qui revient en arrière peut restituer les frais d'état qu'il a payés. Le solde de gaz visible d'un contrat peut donc augmenter en cours d'exécution. L'EIP lui-même avertit que les contrats mesurant le travail comme la différence entre deux lectures de gaz peuvent obtenir un résultat négatif, et que les contrats déjà déployés avec cette conception ne peuvent pas être corrigés.

Comment un attaquant pourrait exploiter les nouvelles règles

La société de sécurité ChainSecurity a détaillé le risque dans une analyse du 13 octobre. Les contrats interceptent souvent un appel échoué et enregistrent le résultat, ce qui permet à un appelant malveillant de fournir délibérément trop peu de gaz afin qu'une opération valide échoue pendant que le contrat dispose encore de suffisamment de gaz pour enregistrer cet échec. Cette technique est connue sous le nom de griefing par gaz insuffisant, et elle peut bloquer définitivement une nouvelle tentative ou supprimer la revendication d'un utilisateur.

Pour les contrats qui comptent sur l'épuisement du gaz du gestionnaire d'échec lui-même :

• Étape 1 : L'attaquant envoie un appel avec trop peu de gaz.
• Étape 2 : L'opération ciblée manque de gaz.
• Aujourd'hui : Le gestionnaire manque aussi de gaz, tout est annulé et l'utilisateur peut réessayer.
• Glamsterdam : Le réservoir ou le gaz reconstitué permet au gestionnaire de se terminer et d'enregistrer l'échec définitivement.

Les contrats qui vérifient le gaz restant après un appel échoué peuvent être trompés lorsque des reconstitutions de gaz ou un intermédiaire qui annule ramènent le solde au-dessus de leur seuil. Les budgets de gaz fixes peuvent également s'avérer insuffisants, car l'EIP-8038 relève le coût d'accès à l'état existant : la première modification d'un emplacement chaud existant passe de 2 900 à 10 100 de gaz.

Toutes les défenses ne sont pas brisées. ChainSecurity indique qu'une vérification effectuée avant l'appel garantit toujours la livraison du gaz demandé, à condition que le budget couvre tous les chemins d'exécution selon les nouveaux prix sans compter sur le réservoir. Elle déconseille de s'appuyer du tout sur des vérifications de gaz après l'appel. L'avis de la Foundation ne mentionne que l'EIP-8037 et ne cite pas les travaux de la société, qui couvrent également l'EIP-8038.

Ce que les opérateurs et les développeurs doivent faire

Les opérateurs de Hoodi doivent mettre à jour leurs clients d'exécution et de consensus avant le 26 octobre, en utilisant des versions dont les notes confirment explicitement que l'ancienne activation a été retirée. Les tableaux de versions de l'annonce initiale ne constituent pas une confirmation. Au 23 octobre, la Foundation avait répertorié des versions mises à jour pour deux clients et a indiqué que d'autres seraient ajoutées au fur et à mesure de leur confirmation.

Les validateurs doivent mettre à jour à la fois le nœud beacon et le client validateur, et toute personne exploitant une infrastructure externe de construction de blocs doit suivre les instructions de son fournisseur. Les équipes applicatives devraient cesser de planifier les tests sur Hoodi autour de la date initiale.

Pour les développeurs de contrats, la liste de contrôle de ChainSecurity commence par chaque appel permettant à l'exécution de se poursuivre après un échec. Elle comprend le traçage du chemin complet, y compris les proxys ; l'identification des emplacements définis et effacés dans la même transaction, et des intermédiaires qui annulent ; la revérification des budgets fixes ; et le fait de forcer des sous-appels à échouer et de comparer le résultat selon les deux jeux de règles. la mesure du possible, un appel échoué devrait annuler l'ensemble de l'opération. Les portefeuilles et les logiciels de nœud doivent également mettre à jour l'estimation du gaz pour le modèle à deux pools, selon l'EIP.

Les prochaines décisions appartiennent aux développeurs principaux. La revue Last Call de l'EIP-8037 — la dernière fenêtre de revue avant la finalisation d'une proposition dans le processus d'Ethereum — se clôt le 1er novembre, l'enquête pourrait entraîner des changements de spécification, et une nouvelle date pour Hoodi sera fixée lors d'un prochain appel.

Cet article est fourni à titre informatif uniquement et ne constitue pas un conseil financier ou d'investissement. Les calendriers de mise à niveau et les spécifications techniques d'Ethereum peuvent changer pendant les tests.

Source : Coindoo