Ethereum : deux brouillons rivaux pour que Glamsterdam ne casse pas les anciens contrats, et aucun n’a été testé

Deux développeurs d’Ethereum ont déposé dimanche 8 novembre des brouillons concurrents qui cherchent à empêcher la mise à jour Glamsterdam de casser les contrats déjà déployés sur le réseau principal. L’EIP-8488, de Leo Glisic, laisserait tous les contrats existants aux prix du gaz actuels et obligerait les nouveaux contrats à utiliser un autre jeu d’opcodes. Un second brouillon, signé Giulio Rebuffo et encore sans numéro définitif, ferait tourner deux compteurs de gaz en parallèle : l’un que voient les contrats, l’autre qui fixe les frais. Les deux textes visent le même problème, la révision des prix du gaz de Glamsterdam portée par les EIP-8037 et EIP-8038, et aucun n’a pour l’instant de code client, de résultats de tests ni de créneau lors d’un appel des développeurs.

Les deux textes ont été ouverts sous forme de pull requests sur le dépôt ethereum/EIPs, celui de Rebuffo à 15 h 58 UTC et celui de Glisic à 19 h 40 UTC, et tous deux sont au statut Draft, en attente de la relecture d’un éditeur, selon GitHub. CoinDesk a rapporté ces deux dépôts tôt lundi matin. Ils arrivent alors que Glamsterdam est enlisé : la répétition de la mise à jour sur le réseau de test Hoodi a été annulée en octobre et n’a plus de date, une histoire racontée en détail sur notre page consacrée à la bifurcation Glamsterdam repoussée sur Hoodi.

Ce que change la révision des prix du gaz de Glamsterdam : EIP-8037 et EIP-8038

Les deux EIP au cœur du différend rendent beaucoup plus coûteuse l’écriture de nouvelles données sur Ethereum. L’EIP-8037, « State Creation Gas Cost Increase », tarife l’état à l’octet : une constante appelée CPSB est fixée à 1 530 gaz par octet, choisie pour que l’état stocké de la chaîne grossisse d’environ 120 GiB par an avec une limite de gaz de 150 millions. Ce gaz d’état est aussi décompté à part du gaz d’exécution ordinaire, dans ce que le texte appelle un réservoir. L’EIP-8038 relève le prix de la lecture et de l’écriture d’un état qui existe déjà.

Les deux propositions sont en « Last Call », l’étape finale de relecture, avec une échéance au 1er novembre 2026. Le 9 novembre, le site des EIP affichait toujours ce statut pour les deux. Les principaux chiffres, tirés des deux textes :

L’EIP-8037 estime qu’un nouveau compte coûtera environ sept fois plus qu’aujourd’hui, un nouvel emplacement de stockage environ cinq fois plus et le déploiement d’un contrat de 24 ko environ huit fois plus. Avec des frais de base de 0,08 gwei, ce déploiement de 24 ko revient à quelque 0,003 ETH, soit un peu plus de 6 $ avec l’ether vers 2 090 $ à 08 h 09 UTC. L’ether perdait alors 6,52 % sur 24 heures, au rythme d’un marché qui cédait 6,68 % ; aucune source ne relie cette baisse au débat.

Ce qui casse : les anciens contrats qui comptent sur un gaz fixe

Des prix plus élevés rendraient seulement les transactions plus chères. Le vrai souci, ce sont les codes qui supposent un prix. De nombreux contrats envoient une quantité fixe de gaz avec un appel vers un autre contrat, et beaucoup ne peuvent plus être modifiés une fois déployés. Si l’appel exige soudain davantage que cette quantité, blockchain that runs exactly as written when it is called, holding and moving funds according to its code, without an intermediary able to change the outcome.">smart contract holding reserves of two or more tokens, supplied by users, that a decentralized exchange uses to execute trades automatically at a price set by a formula.">pool diverge, compared with simply holding the same tokens in a wallet. It becomes permanent when the provider withdraws.">il échoue, a expliqué CoinDesk.

La Fondation Ethereum avait signalé le risque dès août. Ses équipes de recherche, d’EthPandaOps et de spécifications ont rejoué des transactions passées avec le nouveau barème et écrit qu’« un petit ensemble de contrats intelligents reposent sur des hypothèses que le nouveau barème déplace ». Leur billet du 24 août range les résultats en quatre groupes, de « aucun changement » à « potentiellement cassé », et nomme les habitudes à risque : l’allocation de 2 300 gaz des fonctions transfer et send de Solidity, les valeurs de gaz codées en dur dans les appels, la logique qui bifurque selon gasleft() et les transactions présignées avec une limite de gaz fixe. Pour les utilisateurs ordinaires, le billet disait qu’« aucune action n’est nécessaire ».

L’EIP-8037 reconnaît elle-même une rupture. Comme le réservoir de gaz d’état peut regarnir le gaz que voit un contrat, un code qui mesure un travail en lisant deux fois l’opcode GAS puis en soustrayant peut obtenir un nombre négatif. Pour les contrats déjà sur le réseau principal qui suivent ce schéma, l’EIP écrit que le problème ne peut pas être corrigé. Les portefeuilles, l’appel eth_estimateGas des logiciels de nœud et les bundlers ERC-4337 doivent tous être mis à jour pour tarifer les deux dimensions.

Le cabinet d’audit ChainSecurity a ensuite trouvé en octobre une version plus aiguë du risque : les remboursements peuvent laisser juste assez de gaz pour que le gestionnaire d’échec d’un contrat aille au bout, de sorte qu’un échec censé être retenté est inscrit comme définitif. Ses conclusions, les 13 contrats du réseau principal qu’il disait avoir repérés le 22 octobre (non nommés, leurs équipes étant prévenues) et la décision d’octobre de retirer la date de Hoodi sont détaillés dans notre article sur la règle de Glamsterdam que les développeurs ont annulée pour les dépôts de staking et sur la page Hoodi. ChainSecurity n’a pas montré qu’un grand protocole en production puisse être exploité, notait alors CoinDesk.

EIP-8488 : les anciens contrats gardent l’ancienne grille de prix

Le brouillon de Glisic, intitulé « Versioned Opcodes for Gas Repricing », ajoute un second jeu d’instructions à la machine virtuelle d’Ethereum. Chaque opcode dont le coût change avec l’EIP-8037 ou l’EIP-8038 reçoit un jumeau V2, comme SSTORE_V2, CALL_V2 ou CREATE2_V2, tarifé selon le nouveau barème. Les contrats déployés avant la bifurcation continuent de tourner avec l’ancien barème « indéfiniment », selon le mot du brouillon.

Après l’activation, tout nouveau code d’exécution est analysé au moment de son stockage. S’il contient un ancien opcode qui possède un jumeau V2, le déploiement échoue. S’il passe, le compte reçoit un champ code_version fixé à 2. Un nouvel opcode DELEGATECALL_V2 refuse d’exécuter un code dont la version est inférieure à 2, car un delegatecall exécute le code d’autrui dans le stockage de l’appelant. Les simples CALL et STATICCALL peuvent toujours atteindre n’importe quel contrat, ancien ou nouveau.

Le brouillon retire aussi GAS et GASLIMIT du jeu V2, de sorte que les nouveaux contrats ne peuvent plus lire leur gaz restant. L’argument de Glisic : un code qui ne voit pas le compteur de gaz ne peut pas bâtir d’hypothèses qu’une révision ultérieure des prix viendrait briser. Ce qui remplacerait gasleft() pour le code qui en a besoin, comme des signaux standard de manque de gaz ou des reçus de gaz dépensé, est laissé à des propositions complémentaires.

Les protocoles évolutifs passeraient aux nouveaux prix dès qu’ils changent d’implémentation, et la limite de gaz pourrait ensuite monter par paliers à mesure que davantage d’activité tourne sur du code V2, dit la section de motivation. Elle présente cela comme « une troisième option » entre appliquer la révision à tout le monde et l’abandonner.

Lundi à 01 h 06 UTC, abcoathup, qui attribue les numéros d’EIP pour les éditeurs, lui a donné le numéro 8488. Glisic, qui l’avait déposé sous le numéro 8888, a répondu : « Je me contenterai de trois 8 au lieu de quatre, je suppose ». Il a ajouté qu’il ne peut pas ouvrir de fil de discussion sur Ethereum Magicians, le forum où l’on débat des EIP, car son compte y a été supprimé et son adresse IP bloquée. Le motif invoqué était l’usage de faux comptes, ce qu’il dit avoir fait ouvertement. Le lien de discussion de son brouillon renvoie toujours au fil de l’EIP-8038.

Le brouillon de Rebuffo : deux compteurs de gaz, une seule facture

La pull request n° 12637 de Rebuffo, « Separate execution credits and billing credits », ne touche pas aux opcodes et scinde à la place le compteur de gaz. Les deux compteurs démarrent à la limite de gaz de la transaction. Les « crédits » baissent selon l’ancien barème et sont tout ce que voit l’EVM : gasleft() renvoie des crédits, les appels transmettent des crédits, l’allocation de 2 300 est versée en crédits. La « facturation » baisse selon le nouveau barème et décide de ce que paie l’expéditeur.

Un contrat qui envoie 2 300 gaz fixes reçoit donc toujours ses 2 300 habituels. Ce qui change, c’est la fin du parcours. Si la facturation s’épuise avant la charge suivante, toute la transaction avorte avec une nouvelle erreur, BILLING_OUT_OF_GAS. Aucun contrat ne peut l’intercepter ni lancer de gestionnaire d’échec, chaque cadre d’exécution est défait et l’expéditeur paie la limite de gaz entière. Selon le brouillon, cet abandon impossible à intercepter empêche un contrat d’enregistrer un échec une fois la facturation épuisée, soit le schéma contre lequel ChainSecurity a mis en garde. Il ajoute que les risques de griefing et de déni de service demeurent.

Rebuffo ne cache pas ce qui manque. Les barèmes exacts, les points de facturation, les règles de remboursement, les champs des reçus et la comptabilité des blocs restent à écrire, dit la pull request, et « aucune implémentation côté client d’exécution ni aucun test de consensus n’ont été réalisés pour cette conception ». Le texte se présente comme une base de discussion, non comme la preuve qu’il est prêt à être déployé. abcoathup a suggéré lundi le numéro 8487 et demandé l’ouverture d’un fil sur Magicians.

Deux correctifs rivaux et ce que chacun coûte

Pour faire simple, Glisic change la grille de prix sous laquelle tourne un contrat, tandis que Rebuffo garde l’ancienne grille dans l’EVM et ne change que la facture. Chaque approche a un prix, et les brouillons en admettent l’essentiel. Les points qui suivent sont la lecture que fait Coindaro des deux textes ; aucune équipe de client n’a commenté l’une ou l’autre pull request jusqu’ici.

L’EIP-8488 laisserait les clients faire tourner deux tables de gaz pour de bon, plus une V3 plus tard si le schéma se répète, comme le prévoit le brouillon lui-même. Plus grave au regard de l’objectif de la révision, les contrats existants continueraient d’écrire du nouvel état aux prix d’aujourd’hui. Les contrats de jetons, les plateformes d’échange et les marchés de prêt déployés avant la bifurcation feraient grossir l’état de la chaîne à l’ancien rythme tant qu’ils n’ont pas migré. Le brouillon l’accepte et propose de relever progressivement la limite de gaz à mesure que l’usage de la V2 augmente.

Une conséquence n’est pas discutée dans le brouillon, et il s’agit de la lecture de Coindaro, non de celle de l’auteur. Le filtre de déploiement couvre CREATE, CREATE2 « ou tout autre chemin de création de code » et rejette tout nouveau code qui contient encore un opcode hérité doté d’un jumeau V2. Une fabrique déjà déployée, impossible à mettre à jour, qui crée de nouveaux contrats à partir d’un bytecode écrit avant la bifurcation (un pool, un coffre ou un portefeuille par utilisateur, par exemple) verrait donc ces déploiements échouer. Cela cadre mal avec la phrase du brouillon selon laquelle les contrats existants sont « non affectés » : la fabrique continue de tourner, mais l’une de ses tâches principales s’arrête. Quelles fabriques actives seraient touchées, et si une exception est prévue, le brouillon ne le dit pas.

Le schéma de Rebuffo ne conserve l’ancien comportement que tant que la facturation tient, et le brouillon le dit sans détour. Des transactions qui réussissent aujourd’hui « peuvent désormais avorter alors qu’il reste des crédits », avertit sa section sur la compatibilité. Un contrat non fiable au sein d’un lot peut avaler l’enveloppe de facturation partagée et tout faire avorter, y compris des opérations sans rapport. L’estimation des frais et les reçus devraient rapporter deux nombres. Et faire payer plus ne constitue pas une limite de ressources stricte, ajoute le texte : si la révision doit plafonner la croissance de l’état, les règles de bloc doivent l’imposer séparément.

« Ne devrait pas être livré dans sa forme actuelle » : la pression sur Glamsterdam

Les brouillons sont tombés dans un fil de discussion très tendu. Le chercheur en sécurité pcaversaccio a écrit sur X que, à son humble avis, Glamsterdam « ne devrait pas être livré dans sa forme actuelle, point », et dit avoir alerté les développeurs du cœur du protocole sur la hausse du gaz deux semaines plus tôt, selon CoinDesk. Le développeur sous pseudonyme banteg a évoqué « la liste déjà énorme de 200 000 contrats affectés » de l’outil d’impact des révisions de la Fondation et jugé que sa méthode en rate beaucoup d’autres. Il a ajouté, selon CoinDesk, que le problème touche le déploiement et l’exploitation de plusieurs protocoles très en vue.

Ce chiffre de 200 000 compte les contrats que l’outil de rejeu classe comme affectés, pas des contrats dont on a montré qu’ils sont exploitables. La Fondation range les résultats du rejeu en quatre catégories, de « aucun changement » à « potentiellement cassé » en passant par « réussit avec des changements » et « réparable avec une hausse de la limite de gaz », et figurer sur la liste ne place pas un contrat dans la dernière. Les équipes peuvent retrouver leurs propres contrats dans l’outil.

D’autres médias ont rapporté que la Fondation a fait appel à des cabinets d’audit, CoinCentral citant le développeur de Geth Marius van der Wijden sur un travail avec ChainSecurity et Dedaub.

La suite : l’appel ACDC du 12 novembre, ACDE n° 249 le 19 novembre

Deux appels des développeurs du cœur du protocole figurent au calendrier du dépôt ethereum/pm. All Core Devs Consensus n° 191 se tient le jeudi 12 novembre à 14 h 00 UTC, et All Core Devs Execution n° 249 le jeudi 19 novembre à 14 h 00 UTC, quatre semaines après le n° 248 en raison de la Devcon. Les deux ordres du jour listent « Glamsterdam » en premier point. Aucun ne nomme l’EIP-8488 ni le brouillon de Rebuffo, et lundi matin aucun commentaire sur l’une ou l’autre de ces pages ne demande de les y ajouter.

Avant que l’un ou l’autre brouillon soit débattu, les éditeurs d’EIP doivent encore le fusionner, et les deux auteurs ont reçu la demande d’ouvrir un fil sur le forum. Les développeurs avaient estimé le 29 octobre que le prochain test privé de Glamsterdam pourrait avoir lieu entre le 16 et le 20 novembre au plus tôt, a rapporté CoinDesk ; ce plan précède les deux brouillons. Il n’existe aucune nouvelle date pour Hoodi, ni de date pour le réseau principal : les créneaux de décembre évoqués avant le report sont listés sur notre page Hoodi.

D’après le cadrage des brouillons eux-mêmes, les développeurs du cœur ont maintenant quatre options. Ils peuvent appliquer la révision à tout le monde et demander aux projets touchés de s’adapter, mettre les contrats existants à part comme le propose Glisic, ou découpler les frais de l’exécution comme le propose Rebuffo. Ou bien ils peuvent retirer les deux EIP de Glamsterdam, ce qui, selon l’EIP-8488, repousserait les contrôles de croissance de l’état qui soutiennent une limite de gaz plus haute.

Ce que cela change pour les détenteurs d’ETH, les stakers et les développeurs

Rien ne change aujourd’hui sur le réseau principal. Glamsterdam n’est actif que sur le réseau de test Sepolia, où il s’est activé le 6 octobre, et le billet de la Fondation d’octobre sur le report de Hoodi précisait qu’aucune action n’était demandée aux utilisateurs du réseau principal ni aux détenteurs d’ETH. Un investisseur français qui détient ou met en staking de l’ETH, y compris via une plateforme, n’a donc rien à faire.

Les développeurs, eux, ont des devoirs. Un contrat qui transmet une quantité fixe de gaz, utilise transfer ou send, bifurque selon gasleft() ou repose sur des transactions présignées devrait être vérifié dès maintenant avec l’outil de révision, quelle que soit la version du correctif qui l’emporte. Les équipes qui gèrent des portefeuilles ou des bundlers ERC-4337 devront gérer deux dimensions de gaz avec l’EIP-8037 telle qu’écrite, ou deux compteurs avec le brouillon de Rebuffo.

Gaz, révision des prix et bifurcations en deux paragraphes

Chaque opération d’Ethereum a un prix en unités de gaz, et les frais payés par l’utilisateur sont le gaz consommé multiplié par le prix du gaz. Notre entrée de glossaire sur les frais de gaz donne les bases. Une révision des prix change le nombre d’unités que coûte une opération, pas le prix de l’unité.

Modifier ces coûts exige une bifurcation dure : tous les nœuds doivent passer aux nouvelles règles au même bloc, sinon la chaîne se scinde. C’est pourquoi un test sur Hoodi doit bien se passer avant qu’une date soit fixée sur le réseau principal, comme l’explique notre guide sur les soft forks et hard forks. La prochaine étape publique du calendrier est l’appel consensus du 12 novembre.