Qu'est-ce qui a été décidé ?
La Ethereum Foundation a publié le 6 novembre 2026 un billet annonçant que les développeurs du protocole, réunis dans le processus AllCoreDevs, ont choisi de retarder la procédure de hard fork et de ne pas basculer Hoodi, l'un des réseaux de test d'Ethereum, sous les règles de Glamsterdam. Le déploiement attendra que les problèmes identifiés soient résolus. L'origine de ce report est un audit. Pendant les tests sur réseaux de test, la société Chainsecurity a repéré des projets qui deviendraient vulnérables après la mise à jour, parce que leur code repose sur des comportements que deux propositions, EIP-8037 et EIP-8038, modifient. La Fondation précise que les travaux sur Hegota, l'étape suivante, se poursuivent en parallèle sans être affectés.
Que changent EIP-8037 et EIP-8038 ?
Les deux textes réécrivent la tarification du gas pour les opérations qui touchent à l'état d'Ethereum, c'est-à-dire aux données stockées en permanence par les nœuds. EIP-8037 s'attaque à la création d'état et introduit une variable unique, le CPSB, fixée à 1 530 gas par nouvel octet d'état, calibrée pour viser une croissance moyenne de 120 GiB par an avec une limite de gas de référence de 150 millions. Comprendre cette logique suppose de savoir comment les frais de gas sont calculés sur Ethereum. Le texte justifie ce durcissement par des chiffres précis. En janvier 2026, la base de données dédiée à l'état sur un nœud Geth atteignait environ 390 GiB. Après le passage de la limite de gas par bloc de 30 à 60 millions, la quantité d'état créée chaque jour a plus que triplé, de 105 MiB à 326 MiB, soit environ 116 GiB par an. À 200 millions de gas, les auteurs estiment le rythme à 387 GiB par an, ce qui franchirait en moins d'un an le seuil de 650 GiB au-delà duquel les performances des nœuds se dégradent. EIP-8037 sépare aussi la comptabilité du gas en deux dimensions, l'execution-gas et le state-gas. EIP-8038, de son côté, relève le coût de l'accès à l'état : le coût d'accès à froid à un compte passe de 2 600 à 3 000 gas, l'écriture sur un compte de 6 700 à 9 000, et l'écriture modifiant un emplacement de stockage de 2 800 à 10 000, soit 257 % de hausse. Les deux propositions sont en phase de Last Call et leurs valeurs ne sont pas présentées comme définitives.
De combien les coûts augmentent-ils en pratique ?
Le dépôt publié par la Fondation donne des mesures effectuées sur une version figée de la spécification Amsterdam, comparées aux règles actuelles d'Osaka.
| Opération | Osaka | Amsterdam |
|---|---|---|
| SSTORE sur un emplacement neuf, à froid | 22 100 | 110 020 |
| SSTORE sur un emplacement existant, à chaud | 2 900 | 10 100 |
| Transfert vers une adresse vide | 25 000 | 183 600 de state gas, plus l'exécution |
| CREATE vers une adresse vide | 32 000 | 195 600 |
| Dépôt de code | 200 par octet | 1 530 par octet |
| Autorisation EIP-7702 sur une autorité vide | 25 000 | 235 606 |
Créer du stockage, des comptes ou des contrats coûte ainsi cinq à huit fois plus cher, et chaque écriture sur un stockage existant environ 7 200 gas de plus.
Quels comportements du code ne tiennent plus ?
Le dépôt recense huit invariants, c'est-à-dire des règles que les développeurs tenaient pour acquises. Parmi eux :
- un appel qui manque de gas ne faisait plus échouer l'ensemble de la transaction, puisque le state gas peut venir d'un réservoir distinct de `gasleft()`, actif uniquement quand la limite de gas de la transaction dépasse 2^24
- un appel qui échoue rend désormais le state gas consommé, si bien que l'appelant se retrouve avec plus de gas qu'attendu
- le gas restant peut remonter pendant un appel, ce qui invalide le calcul d'un coût par différence entre deux lectures de `gasleft()`
- une délégation EIP-7702, le standard qui transforme un compte en compte programmable, annulée faute de gas reste réutilisable par quiconque détient la signature
La Fondation indique que la majorité des cas remontés concernent deux invariants : les montants de gas codés en dur, devenus insuffisants, et les réserves ou stipends dimensionnés pour les prix actuels. Le stipend de 2 300 gas de `transfer` et `send` ne permet plus de créer un emplacement de stockage.
Qui doit vérifier son code ?
L'appel s'adresse aux développeurs de contrats intelligents déployés sur la chaîne et aux auditeurs. Chainsecurity et Dedaub sont mobilisés, des audits internes sont menés, mais la Fondation reconnaît ne pas pouvoir couvrir tous les projets, en particulier leurs composants hors chaîne, les systèmes de relais ou les services qui lisent les reçus de transaction pouvant aussi casser. Les équipes concernées sont invitées à signaler les problèmes par courriel plutôt que dans un ticket public, afin qu'ils soient corrigés avant d'être connus. Les retours serviront à arbitrer, lors des prochains appels AllCoreDevs, entre un ajustement des spécifications et le maintien du changement de règles du protocole en l'état.
