Glamsterdam Ethereum Menace Les Smart Contracts Existants

Imaginez un instant que le réseau qui sécurise des centaines de milliards de dollars se mette soudainement à facturer différemment chaque opération. Des applications DeFi que tout le monde utilise depuis des années risquent de planter purement et simplement. C’est exactement le scénario qui se profile avec l’upgrade Glamsterdam d’Ethereum. Depuis quelques jours, la communauté ne parle plus que de ça.

Pourquoi Glamsterdam Fait Trembler Tout Le Réseau

Le 8 novembre 2026, deux développeurs ont déposé des propositions concurrentes pour tenter de limiter les dégâts. Leo Glisic et Giulio Rebuffo ne disent pas la même chose, mais ils partagent le même constat : les nouvelles règles de gaz prévues dans Glamsterdam peuvent casser des contrats déjà déployés. Et pas seulement quelques vieux codes oubliés. On parle de protocoles majeurs, de réserves de liquidité et d’applications qui gèrent l’argent de milliers d’utilisateurs.

Le problème vient principalement de deux EIP, les EIP-8037 et EIP-8038. Ces propositions modifient profondément la façon dont Ethereum facture la création et l’accès à l’état de la blockchain. Le coût de base pour déployer un smart contract passerait de 32 000 gaz à 183 600 gaz. Une hausse spectaculaire. Pour les nouveaux contrats, ce n’est qu’une question d’adaptation. Pour ceux qui tournent déjà depuis des années, c’est une autre histoire.

Les contrats qui dépendent de valeurs fixes de gaz

Beaucoup de smart contracts ont été écrits avec des hypothèses très précises sur le coût du gaz. Certains réservent une quantité exacte de gaz pour les appels externes. D’autres comptent sur un comportement précis en cas d’échec de transaction. Si le coût change, ces mécanismes se cassent. Une simple opération qui fonctionnait hier peut soudain consommer plus de gaz que prévu et faire échouer toute la transaction.

La société de sécurité ChainSecurity a identifié huit hypothèses courantes qui deviennent invalides avec les nouvelles règles. Ce n’est pas une liste théorique. Ces hypothèses se retrouvent dans des protocoles utilisés quotidiennement. Le développeur pseudonyme banteg a même évoqué une estimation d’environ 200 000 contrats potentiellement touchés. Et selon lui, ce chiffre pourrait être sous-estimé à cause de problèmes méthodologiques dans l’analyse.

Cher Ethereum, s’il vous plaît ne cassez pas la chaîne. Il semble bien que Glamsterdam sous sa forme actuelle conduirait à un autre hard fork d’urgence, avec beaucoup de drame.

Michael Egorov, fondateur de Curve Finance

Ces mots de Michael Egorov résonnent particulièrement fort. Curve Finance est l’un des piliers de la DeFi. Quand son fondateur parle d’urgence hard fork, la communauté écoute. D’autres voix se sont jointes à la critique. Le chercheur en sécurité pcaversaccio a été encore plus direct : selon lui, Glamsterdam ne devrait tout simplement pas être déployé sous sa forme actuelle.

Deux propositions pour limiter la casse

Face à la pression, Leo Glisic a soumis l’EIP-8488. Son idée est relativement simple : créer un double système d’opcodes. Les nouveaux contrats utiliseraient des instructions V2 qui appliquent les nouvelles règles de tarification. Les anciens contrats continueraient à fonctionner avec les anciennes règles. On sépare clairement le passé et le futur.

Giulio Rebuffo propose une approche différente. Dans chaque transaction, on ferait tourner deux comptabilités de gaz en parallèle. La première calcule la consommation selon les anciennes règles pour que le contrat continue de se comporter comme prévu. La seconde calcule les frais réels selon les nouvelles règles. L’utilisateur paie le nouveau prix, mais le contrat voit l’ancien environnement. L’idée est élégante sur le papier. En pratique, aucun client d’exécution n’a encore d’implémentation, et les tests de consensus n’existent pas encore.

Un calendrier déjà chamboulé

Le 26 octobre, l’activation sur le testnet Hoodi a été reportée. Les développeurs ont décidé de freiner des quatre fers après les alertes de sécurité. Le report concerne les changements de la couche d’exécution Amsterdam, les modifications de consensus Gloas et l’augmentation prévue de la limite de gaz à 200 millions sur Hoodi.

Marius van der Wijden, développeur de l’Ethereum Foundation, a indiqué le 6 novembre que l’équipe travaillait avec ChainSecurity et Dedaub pour analyser les applications touchées et recueillir les retours des développeurs. Une fenêtre de test privé avait été évoquée entre le 16 et le 20 novembre. Mais cette discussion date d’avant le dépôt des deux propositions concurrentes. Le calendrier reste donc très fluide.

Pourquoi ces changements de gaz sont nécessaires

Il serait trop simple de présenter Glamsterdam uniquement comme une menace. Les nouvelles règles de gaz cherchent à mieux refléter le coût réel des opérations sur le réseau. Créer un contrat et écrire dans l’état de la blockchain consomme des ressources importantes. Les anciens tarifs sous-estimaient ce coût. À long terme, une tarification plus juste protège la santé du réseau et limite les abus.

Le problème, c’est le timing et la manière. Ethereum a toujours valorisé la rétrocompatibilité autant que possible. Les smart contracts sont censés être immuables. Une fois déployés, ils doivent continuer à fonctionner indéfiniment. C’est l’un des arguments majeurs de la blockchain. Changer les règles du jeu après le déploiement crée une tension philosophique profonde.

Ryan Berckmans, investisseur connu dans l’écosystème, avait d’abord défendu l’idée d’avancer rapidement. Selon lui, Ethereum ne pouvait pas garantir un gaz immuable pour chaque application existante. Après avoir pris connaissance des analyses de sécurité, il a fait marche arrière publiquement. « Nous ne devrions clairement plus avancer vers une activation rapide de Glam. J’avais tort de le dire », a-t-il écrit.

Les protocoles DeFi en première ligne

Les protocoles de finance décentralisée sont particulièrement exposés. Beaucoup d’entre eux utilisent des patterns complexes d’appels externes, de reentrancy checks et de gestion précise du gaz restant. Une modification même minime des coûts peut faire basculer une transaction d’un état de succès à un état d’échec. Dans certains cas, cela peut même créer des situations de blocage de fonds.

Les applications qui ne sont plus maintenues représentent un risque encore plus grand. Leurs développeurs ont parfois disparu ou n’ont plus les moyens de mettre à jour le code. Or un contrat non upgradable ne peut pas être corrigé. Si les nouvelles règles de gaz le cassent, les fonds qui s’y trouvent peuvent devenir inaccessibles. C’est précisément ce scénario que les chercheurs en sécurité redoutent le plus.

Les estimations de 200 000 contrats touchés ne portent pas uniquement sur des expérimentations personnelles. Elles concernent aussi des protocoles établis. Même si seule une fraction de ces contrats contient réellement des fonds importants, le risque systémique existe. Un seul gros protocole qui tombe peut créer un effet domino sur les liquidités et la confiance.

Ce que révèle cette crise sur la gouvernance d’Ethereum

Glamsterdam met en lumière une tension récurrente dans l’écosystème. D’un côté, le besoin d’évoluer techniquement pour rester compétitif face à d’autres blockchains. De l’autre, l’obligation morale et technique de ne pas casser ce qui a déjà été déployé. Les core developers se retrouvent souvent pris entre ces deux feux.

Les discussions se déroulent principalement sur les appels All Core Devs et sur les plateformes de discussion ouvertes. Mais la pression vient aussi des acteurs de la DeFi et des chercheurs indépendants. Cette fois, les alertes sont arrivées suffisamment tôt pour que le calendrier soit modifié. C’est déjà un progrès par rapport à certaines mises à jour passées où les problèmes n’avaient été vraiment compris qu’après le déploiement.

Le fait que deux propositions concurrentes aient émergé en quelques jours montre aussi la vitalité de la communauté technique. Au lieu de simplement critiquer, des développeurs proposent des solutions concrètes. Reste à savoir laquelle, si l’une d’elles, sera retenue, et dans quel délai.

Les leçons des hard forks précédents

Ethereum a déjà connu des situations où des changements de règles ont créé des frictions. Le plus célèbre reste le hard fork de 2016 après le hack de The DAO. À l’époque, la décision de revenir en arrière avait divisé la communauté et donné naissance à Ethereum Classic. Depuis, les développeurs sont beaucoup plus prudents. Ils multiplient les testnets, les audits et les périodes de discussion.

Pourtant, chaque upgrade majeure introduit de nouveaux risques. Les changements de gaz sont particulièrement délicats parce qu’ils touchent au cœur du modèle économique et de l’exécution des contrats. Une erreur d’appréciation peut avoir des conséquences immédiates et irréversibles pour certains utilisateurs.

Le report de Hoodi montre que les mécanismes d’alerte fonctionnent. La communauté de sécurité a su faire entendre sa voix. Les core developers ont accepté de ralentir. C’est un signal positif. Mais ralentir ne suffit pas. Il faut maintenant trouver une solution technique qui préserve à la fois l’évolution du réseau et la stabilité des contrats existants.

Les scénarios possibles dans les semaines à venir

Plusieurs chemins s’ouvrent. Le premier consiste à adopter l’une des deux propositions de compatibilité et à intégrer les changements de gaz de manière progressive. Le second serait de reporter purement et simplement les EIP-8037 et 8038 à une upgrade ultérieure. Un troisième scénario, moins probable mais évoqué, serait de déployer Glamsterdam sans ces changements de tarification et de les revoir plus tard.

Un hard fork d’urgence reste le scénario que tout le monde veut éviter. Il crée de l’incertitude, de la polarisation et peut fragiliser la confiance dans le processus de gouvernance. Michael Egorov l’a rappelé avec force. Personne n’a envie de revivre un moment de tension comparable à celui de 2016.

Les tests privés prévus mi-novembre, s’ils ont lieu, permettront de mieux quantifier les impacts réels. Les analyses croisées de ChainSecurity et Dedaub devraient aussi apporter des données plus précises sur le nombre de contrats réellement critiques. Ces informations seront déterminantes pour la suite des discussions.

Impact potentiel sur les utilisateurs finaux

Pour l’utilisateur moyen qui utilise des applications DeFi via une interface, le risque peut sembler lointain. En réalité, il est très concret. Si un protocole de prêt ou d’échange décentralisé commence à échouer sur certaines transactions, les liquidités peuvent se retirer rapidement. Les prix peuvent devenir instables. Les positions ouvertes peuvent se retrouver dans des situations inattendues.

Les portefeuilles non-custodians et les outils d’analyse on-chain devront aussi s’adapter. Les estimateurs de gaz intégrés dans les wallets pourraient afficher des valeurs incorrectes pendant une période de transition. Les utilisateurs risquent de sous-estimer ou de surestimer le coût des transactions, ce qui peut conduire à des échecs ou à des frais excessifs.

Les projets qui ont déjà anticipé ce type de changements en construisant des contrats upgradables ou en utilisant des proxies sont mieux armés. Ceux qui ont privilégié l’immuabilité pure se retrouvent plus exposés. C’est un rappel brutal que le choix d’architecture a des conséquences à très long terme.

La position des chercheurs en sécurité

Les chercheurs en sécurité jouent un rôle central dans cette affaire. ChainSecurity a été le premier à formaliser les huit hypothèses fragilisées. Dedaub collabore désormais avec l’Ethereum Foundation pour approfondir l’analyse. Ces équipes ne se contentent pas de pointer les problèmes. Elles aident aussi à quantifier les risques et à tester les solutions proposées.

Leur crédibilité repose sur des années d’audits de protocoles majeurs. Quand elles alertent sur un risque systémique, la communauté prend généralement le message au sérieux. Le report de Hoodi en est la preuve directe. Sans ces alertes, le calendrier aurait probablement continué comme prévu.

La suite dépendra en grande partie de la qualité des données qu’elles fourniront dans les semaines à venir. Plus les analyses seront précises, plus les core developers pourront prendre des décisions éclairées plutôt que de réagir sous la pression émotionnelle.

Comparaison avec d’autres blockchains

D’autres chaînes ont choisi des approches différentes face aux problèmes de rétrocompatibilité. Certaines acceptent plus facilement de casser les anciens contrats au nom de l’évolution rapide. D’autres multiplient les couches d’abstraction pour isoler les changements. Ethereum a longtemps privilégié une forme de prudence. Glamsterdam teste les limites de cette prudence.

Le modèle de gouvernance d’Ethereum, plus ouvert et plus lent que celui de certaines blockchains concurrentes, montre ici à la fois ses forces et ses faiblesses. La discussion publique permet de faire émerger les problèmes tôt. Mais elle peut aussi ralentir considérablement les décisions et créer des périodes d’incertitude prolongées.

Dans un contexte où la concurrence entre blockchains s’intensifie, chaque retard ou chaque controverse est scruté. Les utilisateurs et les développeurs comparent les expériences. Une upgrade ratée ou trop douloureuse peut faire basculer certains projets vers d’autres environnements. C’est une réalité que les core developers ont toujours en tête.

Les enjeux de long terme pour Ethereum

Au-delà de Glamsterdam, cette crise pose une question plus large : jusqu’où Ethereum peut-il aller dans la modification des règles de base sans trahir le principe d’immuabilité ? Les smart contracts sont souvent présentés comme des accords numériques inviolables. Si les conditions d’exécution changent après le déploiement, cette promesse s’érode.

Il existe des mécanismes techniques pour gérer cette tension. Les opcodes versionnés, les double comptabilités, les systèmes de migration assistée. Mais chacun de ces mécanismes ajoute de la complexité. Plus le protocole devient complexe, plus le risque d’erreurs futures augmente. C’est un équilibre délicat à trouver.

La manière dont la communauté résoudra le problème Glamsterdam servira de référence pour les upgrades futures. Si une solution propre et largement acceptée émerge, la confiance en sortira renforcée. Si le processus devient chaotique ou si des fonds sont réellement perdus, la cicatrice restera visible pendant longtemps.

Ce que les développeurs de protocoles peuvent faire maintenant

En attendant les décisions finales, les équipes qui maintiennent des protocoles peuvent déjà agir. La première étape consiste à auditer leur code à la lumière des huit hypothèses identifiées par ChainSecurity. Identifier les endroits où le gaz est réservé de manière fixe, où le comportement en cas d’échec est critique, où les appels externes dépendent de quantités précises.

Ensuite, tester les contrats sur les environnements qui intègrent déjà les nouvelles règles de gaz, même de manière expérimentale. Plus tôt les problèmes sont détectés, plus il est facile de préparer des migrations ou des contournements. Pour les contrats non upgradables, la seule option peut être de communiquer clairement aux utilisateurs les risques et d’éventuellement encourager le retrait des fonds avant l’activation.

Les projets qui disposent de mécanismes de gouvernance on-chain peuvent aussi préparer des votes pour autoriser d’éventuelles migrations. Anticiper réduit le stress au moment où les décisions devront être prises rapidement.

Le rôle des testnets dans la suite du processus

Hoodi devait servir de terrain d’essai grandeur nature. Son report a ralenti le processus, mais il a aussi évité de tester en conditions réelles un ensemble de changements potentiellement dangereux. Les prochains tests, qu’ils soient privés ou publics, devront intégrer les propositions de compatibilité si elles sont retenues.

Un testnet n’est utile que si suffisamment de projets y déploient leurs contrats et y effectuent des transactions représentatives. Les protocoles majeurs ont donc intérêt à participer activement. Plus la couverture de tests sera large, plus les risques résiduels diminueront.

L’expérience passée montre que certains bugs n’apparaissent que sous charge réelle ou avec des patterns d’utilisation très spécifiques. Les périodes de test doivent donc être suffisamment longues et variées. Presser le calendrier pour respecter une date symbolique n’a jamais bien fonctionné dans l’histoire d’Ethereum.

Une communauté divisée mais mobilisée

Les réactions sur les réseaux et dans les forums montrent une communauté à la fois inquiète et engagée. D’un côté, ceux qui craignent que les alertes de sécurité freinent trop l’innovation. De l’autre, ceux qui considèrent que la stabilité des contrats existants est non négociable. Les deux positions ont leurs arguments.

Ce qui frappe, c’est la rapidité avec laquelle le débat s’est structuré. En quelques jours, des propositions techniques concrètes ont été formulées, des analyses de sécurité ont circulé, des figures importantes ont pris position publiquement. Ethereum reste un écosystème où les discussions techniques de haut niveau restent accessibles et où les retours du terrain influencent réellement les décisions.

Cette capacité à s’auto-corriger en cours de route est peut-être la plus grande force du réseau. Glamsterdam n’est pas encore déployé. Les problèmes ont été identifiés à temps. Les solutions sont sur la table. Il reste maintenant à choisir le chemin le plus sûr sans renoncer complètement aux améliorations nécessaires.

Vers une solution de compromis ?

Il est possible qu’aucune des deux propositions actuelles ne soit adoptée telle quelle. Les discussions techniques pourraient faire émerger un troisième chemin qui combine des éléments des deux approches. Ou qui reporte purement et simplement les changements de tarification les plus agressifs.

L’Ethereum Foundation a montré par le passé qu’elle savait prendre le temps nécessaire quand les enjeux étaient élevés. Le report de Hoodi s’inscrit dans cette tradition. Les semaines qui viennent seront décisives. Les analyses croisées, les retours des protocoles et les résultats des tests privés dessineront le contour de la solution finale.

En attendant, la vigilance reste de mise. Les utilisateurs qui ont des fonds importants dans des protocoles potentiellement sensibles ont intérêt à suivre de près les annonces. Les développeurs de smart contracts doivent considérer dès maintenant l’impact possible des nouvelles règles de gaz sur leur architecture.

Conclusion provisoire d’une crise encore ouverte

Glamsterdam n’est pas encore une catastrophe. C’est un signal d’alarme sérieux. Les nouvelles règles de gaz visent à rendre le réseau plus durable et plus juste dans sa tarification. Mais elles menacent de casser des centaines de milliers de contrats déjà en production. Deux propositions concurrentes tentent de résoudre la contradiction. Le calendrier de tests a déjà été modifié. La communauté technique et la communauté DeFi sont pleinement mobilisées.

La suite dépendra de la capacité d’Ethereum à trouver un équilibre entre innovation et stabilité. C’est un exercice qu’il a déjà réussi plusieurs fois, parfois de justesse. Cette fois encore, les enjeux sont élevés. Des protocoles majeurs, des liquidités importantes et la confiance dans le principe d’immuabilité des smart contracts sont en jeu.

Pour l’instant, le réseau a choisi de ralentir plutôt que de forcer le passage. C’est probablement la décision la plus sage à court terme. Reste à transformer ce temps gagné en solution technique robuste. Les prochaines semaines diront si Glamsterdam deviendra un exemple de gouvernance mature ou le point de départ d’une nouvelle crise de confiance.

Dans tous les cas, l’épisode rappelle une vérité simple : sur Ethereum, changer les règles du jeu après que les contrats ont été déployés n’est jamais anodin. Chaque modification de gaz, chaque nouvel opcode, chaque ajustement de coût doit être pesé avec une extrême prudence. La force du réseau repose autant sur sa capacité à évoluer que sur sa capacité à ne pas trahir ceux qui ont déjà construit dessus.

Les développeurs, les chercheurs, les fondateurs de protocoles et les utilisateurs ont tous un rôle à jouer dans les discussions en cours. Plus les retours de terrain seront nombreux et précis, plus la décision finale aura de chances d’être équilibrée. Glamsterdam est devenu, presque malgré lui, un test grandeur nature de la maturité de l’écosystème Ethereum face à un risque systémique identifié à temps.

Il ne reste plus qu’à espérer que le temps supplémentaire sera utilisé pour construire une solution qui protège à la fois l’avenir du protocole et le passé déjà déployé. Car dans l’univers des smart contracts, le passé n’est jamais vraiment derrière soi. Il continue de tourner, bloc après bloc, tant que quelqu’un interagit avec lui.