La mise à niveau Glamsterdam d'Ethereum est-elle annulée ? Non. Les développeurs d'Ethereum ont reporté l'activation prévue le 26 octobre 2026 sur le testnet Hoodi afin d'étudier l'impact éventuel des modifications proposées de la comptabilité du gas sur les contrats intelligents existants. Aucune date de remplacement n'a été fixée pour Hoodi, et Glamsterdam ne disposait d'aucune date d'activation confirmée sur le réseau principal qui puisse être annulée.
Cette distinction est au cœur de la feuille de route Ethereum pour 2026. Glamsterdam a déjà été activé sur le testnet Sepolia le 6 octobre. L'étape mise en pause est un nouveau test sur un réseau public, et non un retour en arrière du réseau principal d'Ethereum ni l'abandon des objectifs de montée en charge de la mise à niveau. La Fondation Ethereum indique que cette pause concerne les interactions entre l'EIP-8037 et les contrats déployés ; l'ordre du jour des développeurs principaux du 22 octobre évoque également des préoccupations de sécurité liées à l'EIP-8038.
Découvrez le trading ETH sur Phemex
Qu'a changé le 22 octobre ?
L'annonce précédente de la Fondation Ethereum prévoyait l'activation sur Hoodi pour le 26 octobre à 17 h 42 min 48 s UTC. Le 22 octobre, ce calendrier a été révoqué : l'activation de la couche d'exécution Amsterdam, l'activation de la couche de consensus Gloas et une augmentation prévue de la limite de gas de Hoodi à 200 millions ont été retirées de la configuration programmée. Aucun epoch ni aucune date de remplacement n'a été annoncé.
Il s'agit d'un changement de calendrier, et non d'une réécriture de l'historique de la chaîne Hoodi. Cela crée aussi une tâche opérationnelle : les opérateurs de nœuds et de validateurs sur Hoodi doivent suivre les instructions révisées de leurs équipes de clients logiciels. Tout logiciel contenant encore l'ancienne configuration d'activation du 26 octobre doit recevoir une mise à jour appropriée afin que les opérateurs ne suivent pas de calendriers contradictoires. La Fondation précise que les utilisateurs du réseau principal et les détenteurs d'ETH n'ont aucune action à entreprendre suite à cette annonce concernant Hoodi.
| Réseau | Statut au 23 octobre 2026 | Signification du statut |
|---|---|---|
| Sepolia | Glamsterdam activé le 6 octobre | Une activation sur un testnet public a eu lieu |
| Hoodi | Activation du 26 octobre reportée ; nouvelle date non fixée | Des tests supplémentaires et des versions révisées des clients sont nécessaires |
| Réseau principal Ethereum | Date d'activation non fixée | Aucun fork programmé du réseau principal n'a été annulé |
Les dates et statuts ci-dessus proviennent des annonces de la Fondation Ethereum relatives aux testnets et de l'avis de report du 22 octobre.
Pourquoi une modification du gas peut-elle devenir un enjeu de sécurité ?
Le « repricing du gas » évoque une simple évolution des coûts de transaction. Pour certains contrats, le gas fait toutefois partie intégrante du comportement du programme. Un contrat peut appeler un autre contrat, observer si cet appel a réussi, puis décider de réessayer, de revenir en arrière (revert) ou d'enregistrer définitivement un échec. Cette décision peut reposer sur des hypothèses concernant la quantité de gas consommée par l'appel et celle qui reste disponible ensuite.
L'EIP-8037 propose une comptabilité distincte pour certains coûts de création d'état ; l'EIP-8038 modifie le coût d'accès à l'état. L'analyse de ChainSecurity explique la préoccupation de compatibilité : selon les règles proposées, un sous-appel échoué pourrait laisser — ou restituer — suffisamment de gas utilisable pour que le gestionnaire d'échec d'un contrat externe aboutisse là où ce même chemin aurait auparavant provoqué un revert. Un contrat dont la sûreté dépend du comportement antérieur pourrait alors enregistrer un résultat non voulu par ses développeurs.
Cela ne signifie pas que tous les contrats intelligents Ethereum présentent une vulnérabilité, que l'ETH a été compromis, ni qu'une exploitation du réseau principal a eu lieu. Les propositions sont examinées avant l'activation de Glamsterdam sur le réseau principal. Les premières recommandations aux développeurs de la Fondation Ethereum indiquaient que la grande majorité des contrats n'étaient pas affectés par les cas de repricing identifiés, tout en invitant les équipes concernées à tester leurs hypothèses et à effectuer les mises à jour nécessaires. Le réexamen de sécurité ultérieur confirme précisément que ces hypothèses méritent un examen plus approfondi.
Les chemins de risque publiquement décrits
Ce qui suit correspond aux modèles de risque décrits dans l'analyse de ChainSecurity, et non à une liste inventoriée de 13 constats distincts :
- Un ancien budget de gas peut ne plus suffire. Un contrat peut transmettre avec succès la quantité de gas demandée par son développeur, mais l'opération appelée pourrait exiger davantage de gas selon les nouvelles règles de tarification. Un contrôle autrefois jugé sûr peut alors entraîner un échec inattendu de type out-of-gas.
- Une faible lecture du gas restant ne raconte plus toute l'histoire. Le réservoir de gas d'état proposé par l'EIP-8037 change ce qui peut être payé après un appel. Un code interprétant
gasleft()seul comme la preuve qu'un gestionnaire d'échec ne peut aboutir peut tirer une conclusion erronée. - La purge de l'état nouvellement créé peut recharger le gas sur un chemin d'échec. Dans les circonstances décrites par ChainSecurity, cette recharge peut permettre au code d'aller au bout après un appel échoué au lieu de revenir en arrière. L'impact sur une application donnée dépend de son chemin d'appels et de ses hypothèses de comptabilité.
- Un intermédiaire effectuant un revert peut restituer plus de gas que prévu. Avec plusieurs contrats dans une chaîne d'appels, le revert d'un contrat intermédiaire peut modifier le gas disponible pour l'appelant initial. Un seuil post-appel qui semblait détecter un échec out-of-gas peut ne plus le faire de manière fiable.
- La gestion des échecs peut devenir un problème au niveau applicatif. La conséquence ne se limite pas à une estimation de frais différente. Dans une conception sensible, traiter une tentative sous-financée comme un échec permanent de l'application pourrait supprimer une nouvelle tentative ou enregistrer un résultat erroné. C'est ce scénario que les développeurs doivent tester, plutôt que de supposer que toute valeur de gas modifiée constitue en soi une faille exploitable.
Que compte réellement le chiffre « 13 » rapporté ?
Certains articles décrivent 13 grands projets DeFi dotés de contrats potentiellement concernés. C'est très différent d'affirmer que les chercheurs ont divulgué 13 vulnérabilités de sécurité indépendantes. L'article technique public de ChainSecurity explique plusieurs mécanismes, mais ne publie pas 13 constats individuellement nommés ni une liste vérifiée de 13 projets affectés. La divulgation responsable et l'investigation font toujours partie de l'histoire.
Pour un article publiable sur les risques de sécurité liés à l'ETH, la formulation la plus prudente est donc : « Selon les informations rapportées, les chercheurs ont identifié des projets potentiellement concernés ; la documentation technique publique décrit des modèles de risque liés à la comptabilité du gas et à la gestion des échecs, et non un registre complet de 13 vulnérabilités. » Il ne faut pas laisser entendre que 13 protocoles Ethereum actifs ont été exploités.
Positions longues ou courtes sur ETH
Quelles améliorations de Glamsterdam restent prévues ?
La pause n'efface pas les bénéfices attendus de la mise à niveau. Les deux fonctionnalités phares de Glamsterdam sont la séparation enshrined proposer-builder et les listes d'accès au niveau bloc. La première intègre certains aspects de la coordination entre proposeurs et constructeurs de blocs dans le protocole de consensus d'Ethereum. Les secondes enregistrent les comptes et emplacements de stockage accédés par un bloc, offrant aux clients la possibilité de traiter plus efficacement une partie des travaux de validation. Il s'agit de capacités proposées, et non d'une promesse de réduction précise des frais ou d'un débit donné de transactions par seconde pour les utilisateurs.
Les modifications de la tarification du gas constituent un autre volet de l'ensemble. Leur objectif est de mieux refléter les ressources consommées par Ethereum à mesure qu'il monte en charge. La pause sur Hoodi illustre l'arbitrage à opérer : améliorer la manière dont le réseau comptabilise les coûts des ressources doit se concilier avec le comportement des contrats déjà déployés sur d'anciennes hypothèses. La question pour les développeurs n'est pas seulement « Les clients peuvent-ils exécuter les nouvelles règles ? » Elle est aussi « Que feront les applications existantes sous ces règles ? »
Que doivent surveiller ensuite les développeurs et les détenteurs d'ETH ?
Les développeurs d'applications devraient examiner les appels qui capturent les échecs et poursuivent l'exécution, en particulier lorsque le code utilise des budgets de gas fixes, des seuils de gas restant ou l'hypothèse qu'un gestionnaire d'échec sera lui-même à court de gas. ChainSecurity recommande de tester le résultat de ces chemins sous l'ancien comme sous le nouveau barème de gas — et non de simplement augmenter une limite numérique en supposant l'application sécurisée.
Les opérateurs sur Hoodi doivent rechercher les versions de clients dont les notes retirent explicitement l'activation précédemment programmée du 26 octobre. La Fondation Ethereum met en garde contre l'hypothèse qu'une version mentionnée dans une annonce plus ancienne inclurait déjà le report.
Les détenteurs d'ETH n'ont pas besoin de convertir leurs ETH, d'installer un logiciel ni d'entreprendre une quelconque action sur le réseau principal en réponse à ce report de testnet. Pour ceux qui s'intéressent aux implications d'investissement, les jalons significatifs sont une publication d'atténuation ou une décision de spécification, un nouveau calendrier Hoodi, des tests réussis et, seulement alors, une date confirmée sur le réseau principal. Le report seul ne permet pas d'établir un effet mesurable sur le futur cours de l'ETH.
Questions fréquentes
La mise à niveau Glamsterdam d'Ethereum est-elle annulée ?
Non. La Fondation Ethereum a reporté l'activation du 26 octobre sur le testnet Hoodi et n'a fixé aucune date de remplacement. Elle n'a pas annoncé l'annulation de Glamsterdam dans son ensemble.
Glamsterdam a-t-il été retardé sur le réseau principal Ethereum ?
Aucune date d'activation confirmée sur le réseau principal ne figurait au calendrier de la Fondation. La perte de la date de test prévue sur Hoodi peut influer sur la trajectoire vers le réseau principal, mais il serait inexact d'affirmer qu'une date précise officiellement programmée sur le réseau principal a été manquée.
Les chercheurs ont-ils trouvé 13 vulnérabilités distinctes liées à Glamsterdam ?
L'analyse technique publique n'énumère pas 13 vulnérabilités séparées. Le chiffre « 13 » cité dans certains articles renvoie à des projets dotés de contrats potentiellement concernés. La préoccupation technique vérifiée porte sur la manière dont les modifications proposées du gas pourraient altérer le comportement de gestion des échecs des contrats existants.
Les fonds des utilisateurs d'Ethereum sont-ils en risque parce que Hoodi a été reporté ?
L'avis de report ne signale aucune compromission du réseau principal et indique que les utilisateurs du réseau principal et les détenteurs d'ETH n'ont aucune action à entreprendre. Les développeurs étudient les implications de compatibilité et de sécurité avant de programmer la mise à niveau sur le réseau principal ; cela ne garantit pas que chaque application ait déjà été évaluée.
À retenir : La répétition générale de Glamsterdam sur Hoodi s'est arrêtée pour une raison précise : les développeurs doivent comprendre comment les nouvelles règles de gas interagissent avec la logique existante des contrats intelligents. La prochaine information utile ne sera pas une date de lancement spéculative, mais la preuve que les chemins d'échec identifiés ont été évalués et qu'un calendrier de test révisé est prêt.
