Glamsterdam Ethereum Menace Les Contrats Intelligents Existants

Imaginez un instant que le réseau qui héberge des milliards de dollars en applications financières se mette soudainement à faire échouer des transactions qu’il exécutait sans problème depuis des années. C’est exactement le scénario qui inquiète une partie de la communauté Ethereum en ce moment. L’upgrade baptisé Glamsterdam, censé améliorer la façon dont le réseau facture le gaz, pourrait rendre inutilisables des centaines de milliers de smart contracts déjà déployés. Et la tension monte vite.

Pourquoi Glamsterdam fait trembler les développeurs

Glamsterdam n’est pas une mise à jour anodine. Elle touche directement à la manière dont Ethereum calcule et facture le coût des opérations sur la blockchain, en particulier la création de contrats et l’accès à l’état du réseau. Deux EIP, les propositions 8037 et 8038, sont au cœur du problème. Elles augmentent considérablement le coût de base pour déployer un nouveau contrat intelligent, le faisant passer de 32 000 à 183 600 unités de gaz, sans même compter les frais d’exécution et de stockage du code.

Sur le papier, ces changements ont du sens. Ils cherchent à mieux refléter les ressources réellement consommées par l’activité sur la chaîne. Dans la pratique, beaucoup de contrats existants ont été écrits en supposant que certaines opérations coûteraient toujours le même nombre de gaz. Changer ces valeurs, c’est comme modifier les règles du jeu après que les joueurs ont déjà engagé leurs mises.

Des contrats conçus pour un monde qui change

Les smart contracts ne sont pas des programmes ordinaires. Une fois déployés, la plupart d’entre eux ne peuvent plus être modifiés. Leur code est gravé dans la pierre numérique. Si une application a été écrite en réservant une quantité fixe de gaz pour un appel externe, ou si elle s’appuie sur un comportement précis en cas d’échec de transaction, une hausse inattendue des coûts peut tout faire basculer. Des opérations qui réussissaient auparavant commencent à échouer. Des mécanismes de sécurité se déclenchent au mauvais moment. Des fonds utilisateurs se retrouvent bloqués.

Les chercheurs en sécurité de ChainSecurity ont identifié huit hypothèses fondamentales utilisées par les contrats existants qui risquent de devenir invalides avec les nouvelles règles. Ce n’est pas une question de bugs isolés. C’est une question de paradigme. Des protocoles DeFi établis, des applications qui gèrent des fonds importants, pourraient se retrouver dans une situation délicate sans que leurs équipes puissent intervenir facilement.

Le développeur pseudonyme banteg a récemment souligné sur X qu’une analyse existante avait déjà repéré environ 200 000 contrats susceptibles d’être affectés. Et selon lui, les problèmes méthodologiques de cette analyse laissent penser que le chiffre réel pourrait être encore plus élevé. Les inquiétudes ne se limitent pas à quelques applications mal codées. Elles touchent le déploiement et le fonctionnement de protocoles reconnus.

Deux propositions concurrentes pour limiter les dégâts

Face à la montée des alertes, deux développeurs ont décidé de proposer des solutions distinctes. Dimanche 8 novembre, Leo Glisic et Giulio Rebuffo ont chacun soumis une approche différente pour introduire les nouveaux frais de gaz sans faire plonger les applications déjà en production.

La proposition de Leo Glisic, l’EIP-8488, mise sur une séparation claire. Les nouveaux contrats déployés après l’activation utiliseraient des instructions V2 qui suivent les tarifs révisés. Les anciens contrats, eux, continueraient de fonctionner avec les règles de gaz historiques. C’est une approche de coexistence : on ne force personne à s’adapter, on laisse simplement les nouveaux venus jouer avec les nouvelles règles.

Giulio Rebuffo a choisi une voie plus technique. Sa proposition introduit deux systèmes de comptabilité du gaz à l’intérieur de chaque transaction. Le premier calcule la consommation selon les anciennes règles, afin que le contrat trouve exactement les conditions qu’il attend. Le second calcule le coût réel de la transaction avec la nouvelle grille tarifaire. L’idée est élégante sur le papier, mais Rebuffo reconnaît lui-même qu’aucune implémentation dans un client d’exécution ni aucun test de consensus n’a encore été réalisée pour valider ce design.

Aucune des deux propositions n’a pour l’instant été retenue pour inclusion dans Glamsterdam. Elles restent des pistes de travail, des tentatives de sortir de l’impasse avant que le calendrier ne force une décision.

La communauté se divise

Le débat a rapidement dépassé le cercle des développeurs core. Michael Egorov, fondateur de Curve Finance, a tiré la sonnette d’alarme de façon très directe. Selon lui, avancer avec Glamsterdam dans sa forme actuelle pourrait obliger le réseau à revenir en arrière par un hard fork d’urgence, avec tout le drame et la division que cela implique.

Ryan Berckmans, investisseur et membre actif de la communauté, avait d’abord défendu l’idée d’avancer rapidement. Il estimait qu’Ethereum ne pouvait pas garantir un gaz immuable pour chaque application existante. Après avoir étudié plus en détail les risques de compatibilité, il a fait marche arrière de façon publique et claire : il avait eu tort de pousser pour une activation aussi rapide.

Le chercheur en sécurité pcaversaccio a quant à lui adopté une position encore plus ferme. Selon lui, Glamsterdam ne devrait tout simplement pas être déployé sous sa forme actuelle. Les changements de gaz avaient pourtant été signalés aux développeurs core plusieurs semaines plus tôt. Le sentiment d’urgence se mêle désormais à une forme de frustration.

Un calendrier de tests déjà chamboulé

Les alertes de sécurité n’ont pas tardé à produire des effets concrets. Les développeurs ont reporté l’activation prévue le 26 octobre sur le réseau de test Hoodi. Ce report concerne les changements de la couche d’exécution Amsterdam, les modifications de consensus Gloas, ainsi que l’augmentation prévue de la limite de gaz de Hoodi à 200 millions.

Marius van der Wijden, développeur de l’Ethereum Foundation, a indiqué le 6 novembre que l’organisation travaillait avec ChainSecurity et Dedaub pour examiner les applications touchées et recueillir les retours des équipes de développement. Une discussion a également eu lieu autour d’un nouveau test privé, envisagé entre le 16 et le 20 novembre au plus tôt. Ce calendrier a été élaboré avant même que les deux propositions concurrentes de Glisic et Rebuffo n’apparaissent.

Le retard n’est pas anodin. Chaque semaine de report ajoute de la pression. Les équipes qui préparent leurs propres mises à jour doivent ajuster leurs roadmaps. Les protocoles qui dépendent d’hypothèses précises sur le coût du gaz doivent revoir leurs analyses de risque. Et pendant ce temps, le marché observe.

Ce que changent réellement les nouvelles règles de gaz

Pour comprendre l’ampleur du problème, il faut revenir aux détails techniques. EIP-8037 et EIP-8038 modifient la façon dont Ethereum facture la création et l’accès à l’état de la blockchain. Ces opérations, qui semblaient relativement bon marché, deviennent nettement plus coûteuses. L’objectif est de mieux coller à la réalité des ressources consommées : stockage, calcul, bande passante.

Le souci, c’est que de nombreux contrats ont été conçus autour d’un modèle de coûts stable. Certains réservent une quantité fixe de gaz pour les appels externes. D’autres s’appuient sur le comportement exact du réseau lorsqu’une transaction manque de gaz. Un changement soudain de ces paramètres peut transformer une opération réussie en échec, ou déclencher des mécanismes de protection de façon inattendue.

Dans l’écosystème DeFi, ces subtilités ne sont pas théoriques. Un contrat qui gère des liquidités, des prêts ou des positions dérivées peut se retrouver dans un état incohérent si une transaction intermédiaire échoue pour des raisons de gaz. Les conséquences peuvent aller d’une simple gêne temporaire à des situations bien plus graves, selon la conception du protocole.

Les risques pour les protocoles établis

Les protocoles les plus matures ne sont pas à l’abri. Au contraire. Plus un contrat est ancien et plus il a été optimisé pour les conditions de l’époque, plus il risque d’être sensible aux changements de gaz. Les équipes qui ont déployé leurs contrats il y a plusieurs années n’avaient aucune raison d’anticiper une hausse aussi significative des coûts de création ou d’accès à l’état.

Certaines applications disposent de mécanismes d’upgrade. D’autres non. Celles qui ne peuvent pas être mises à jour se retrouvent dans une position particulièrement fragile. Même celles qui peuvent évoluer doivent passer par des processus de gouvernance, des audits et des déploiements soigneusement orchestrés. Tout cela prend du temps, précisément ce qui risque de manquer si Glamsterdam avance trop vite.

La question n’est donc pas seulement technique. Elle est aussi organisationnelle et économique. Combien d’équipes ont réellement la capacité de réagir rapidement ? Combien de protocoles fonctionnent encore avec des contrats non upgradeables qui représentent une part importante de leur activité ? Ces questions restent pour l’instant sans réponse précise, ce qui ajoute à l’inquiétude.

Deux philosophies s’affrontent

Les propositions de Glisic et de Rebuffo illustrent deux façons différentes de concevoir la compatibilité. L’approche de Glisic est pragmatique et relativement simple à comprendre : on crée un nouveau monde pour les nouveaux contrats et on laisse les anciens dans leur univers. Cela limite les risques de rupture, mais introduit une dualité durable dans le réseau.

L’approche de Rebuffo cherche à préserver l’illusion d’un environnement unique. Chaque transaction voit deux comptabilités tourner en parallèle. Le contrat croit toujours vivre sous les anciennes règles, tandis que le réseau facture selon les nouvelles. C’est plus élégant conceptuellement, mais techniquement plus complexe et encore non testé.

Aucune des deux solutions n’est parfaite. La première crée une dette technique permanente. La seconde ajoute de la complexité d’exécution et reste à prouver. Entre les deux, la communauté doit choisir, ou trouver une troisième voie. Le temps presse, mais précipiter une décision pourrait coûter encore plus cher.

Un précédent qui n’est pas anodin

Ethereum a déjà connu des situations où des changements de protocole ont eu des effets inattendus. Les hard forks d’urgence laissent toujours des traces. Ils divisent la communauté, créent de l’incertitude et peuvent affecter la confiance des utilisateurs et des développeurs. Personne ne souhaite revivre un scénario de ce type.

C’est précisément ce que redoute Michael Egorov lorsqu’il parle d’un possible retour en arrière dramatique. Une fois qu’une mise à jour est activée sur le mainnet, revenir en arrière n’est jamais simple. Même un hard fork correctif prend du temps à coordonner et à déployer. Pendant ce temps, les applications touchées peuvent subir des dysfonctionnements.

La prudence affichée par une partie croissante de la communauté n’est donc pas une opposition au progrès. C’est une demande de maturité. Ethereum a grandi. Les montants en jeu ont explosé. Les protocoles sont devenus des infrastructures critiques pour des milliers d’utilisateurs. Les changements doivent désormais être évalués avec une rigueur proportionnelle à ces enjeux.

Ce qui se joue réellement

Au-delà des détails techniques, Glamsterdam pose une question plus large : jusqu’où Ethereum peut-il aller dans l’optimisation de ses règles sans remettre en cause les hypothèses sur lesquelles reposent des années de développement ? Le réseau a toujours cherché à évoluer. C’est même l’une de ses forces. Mais l’évolution a un coût, et ce coût se mesure aussi en risques pour les applications existantes.

Les développeurs core se trouvent dans une position délicate. Ils doivent moderniser le réseau pour le rendre plus durable et plus efficace, tout en évitant de casser ce qui fonctionne déjà. Les alertes de sécurité, les propositions concurrentes et le report des tests montrent que cette tension est prise au sérieux. Reste à voir si les solutions trouvées seront à la hauteur des enjeux.

Les prochaines semaines seront décisives. Les discussions autour des propositions de Glisic et Rebuffo, les analyses menées avec ChainSecurity et Dedaub, ainsi que les éventuels nouveaux tests sur Hoodi, vont déterminer si Glamsterdam peut avancer ou s’il doit être repensé en profondeur. Dans tous les cas, l’épisode rappelle une vérité simple : sur Ethereum, même les changements qui paraissent techniques peuvent avoir des conséquences très concrètes pour des millions d’utilisateurs.

Les leçons pour l’écosystème

Cet épisode offre plusieurs enseignements. Le premier est que la compatibilité ascendante n’est jamais garantie. Les développeurs de protocoles doivent intégrer cette réalité dans leur conception. Les contrats non upgradeables offrent une immutabilité rassurante, mais ils réduisent aussi la marge de manœuvre face aux évolutions du protocole de base.

Le deuxième enseignement concerne la communication. Les changements de gaz avaient été signalés plusieurs semaines avant que les alertes ne deviennent publiques. Pourtant, une partie de la communauté a eu le sentiment d’être prise de court. Améliorer la transparence et l’anticipation des impacts reste un chantier permanent.

Enfin, la capacité de la communauté à produire rapidement des propositions alternatives montre une maturité croissante. Au lieu de simplement s’opposer, des développeurs ont proposé des chemins de sortie. C’est un signe de santé, même si le chemin vers une solution consensuelle reste encore long.

Où en est-on vraiment aujourd’hui

À l’heure actuelle, Glamsterdam n’est pas annulé. Il est en pause. Les tests sur Hoodi ont été reportés. Les analyses de sécurité se poursuivent. Deux propositions concurrentes sont sur la table. La communauté est divisée entre ceux qui veulent avancer malgré les risques et ceux qui estiment qu’il faut d’abord résoudre les problèmes de compatibilité.

Le scénario le plus probable à court terme reste celui d’une poursuite des discussions techniques et d’un allongement du calendrier de test. Une activation rapide semble désormais peu crédible. Une refonte plus profonde des changements de gaz n’est pas non plus exclue, selon l’évolution des analyses en cours.

Pour les utilisateurs finaux, le message est pour l’instant rassurant. Aucun changement n’a encore été activé sur le mainnet. Les protocoles fonctionnent toujours selon les règles actuelles. Mais pour les équipes de développement et les chercheurs en sécurité, la vigilance reste de mise. Les prochaines réunions de développeurs core seront suivies de près.

La tension entre innovation et stabilité

Ethereum a toujours navigué entre deux impératifs. D’un côté, la nécessité d’innover pour rester compétitif face à d’autres blockchains plus récentes. De l’autre, le devoir de préserver la stabilité d’un écosystème qui gère des montants considérables. Glamsterdam incarne parfaitement cette tension.

Les changements proposés visent à rendre le réseau plus juste et plus durable dans sa gestion des ressources. C’est un objectif légitime. Mais la façon dont ils sont introduits détermine s’ils seront perçus comme une amélioration ou comme une rupture. Les propositions de Glisic et Rebuffo tentent chacune à leur manière de concilier les deux exigences.

Il n’existe pas de solution parfaite. Toute évolution importante crée des gagnants et des perdants, des adaptations nécessaires et des coûts de transition. La question n’est donc pas de savoir s’il y aura des impacts, mais s’ils seront gérables et si les outils pour les anticiper seront suffisamment robustes.

Ce que les développeurs de protocoles peuvent faire dès maintenant

Même si l’activation de Glamsterdam n’est pas imminente, les équipes qui maintiennent des smart contracts ont intérêt à anticiper. Vérifier si leurs contrats reposent sur des hypothèses fixes concernant le coût du gaz. Identifier les parties du code qui pourraient être sensibles à une hausse des frais de création ou d’accès à l’état. Préparer des scénarios de mise à jour si les contrats le permettent.

Les outils d’analyse statique et les audits ciblés sur la consommation de gaz deviennent particulièrement pertinents dans ce contexte. Les chercheurs de ChainSecurity et Dedaub travaillent déjà dans cette direction. Les retours d’expérience de ces analyses pourraient alimenter des bonnes pratiques plus larges pour l’ensemble de l’écosystème.

Enfin, participer aux discussions publiques reste utile. Les propositions d’EIP évoluent souvent grâce aux retours de ceux qui construisent réellement sur le réseau. Plus les voix des protocoles concernés se feront entendre, plus les solutions finales auront de chances d’être adaptées aux réalités du terrain.

Un moment de vérité pour Ethereum

Glamsterdam n’est pas seulement une mise à jour technique. C’est un test de maturité. Ethereum doit démontrer qu’il peut faire évoluer ses règles fondamentales sans mettre en danger les applications qui lui ont fait confiance. Les propositions concurrentes, les alertes de sécurité et le report des tests montrent que le réseau prend cette responsabilité au sérieux.

La suite dépendra de la capacité des développeurs core, des chercheurs en sécurité et des équipes de protocoles à trouver un terrain d’entente. Les prochaines semaines diront si une solution technique élégante émerge, ou si le calendrier doit être encore davantage assoupli. Dans tous les cas, l’épisode restera comme un rappel utile : sur une blockchain aussi critique, chaque changement de gaz peut avoir des conséquences bien au-delà du simple coût d’une transaction.

Pour l’instant, le réseau tient. Les contrats fonctionnent. Mais le signal d’alarme a été tiré, et il ne peut plus être ignoré. L’histoire de Glamsterdam n’est pas encore écrite. Elle se joue en ce moment même, dans les discussions techniques, les analyses de sécurité et les propositions qui tentent de concilier innovation et stabilité. Et c’est précisément ce qui rend ce moment aussi fascinant à suivre pour toute personne intéressée par l’avenir d’Ethereum.