Imaginez un instant que les développeurs d’Ethereum, après des mois de préparation minutieuse, décident soudain de freiner une mise à jour majeure quelques jours seulement avant son activation sur un testnet clé. C’est précisément ce qui vient de se produire avec Glamsterdam. Alors que la communauté attendait l’activation prévue le 26 octobre sur Hoodi, une alerte de sécurité liée à EIP-8037 a conduit à un report inattendu. Cette décision, loin d’être anodine, révèle à quel point la prudence reste une priorité absolue lorsque l’on touche aux mécanismes fondamentaux du réseau le plus utilisé au monde pour les applications décentralisées.
Pourquoi Ethereum a décidé de reporter Glamsterdam sur Hoodi
L’annonce officielle de la Fondation Ethereum, publiée le 22 octobre, a confirmé que l’activation de Glamsterdam sur le testnet Hoodi, initialement fixée au 26 octobre à 17 h 42 min 48 s UTC (époque 132 352), était annulée. Cette décision fait suite aux discussions tenues lors de la réunion All Core Developers Execution. Les équipes ont choisi d’approfondir l’analyse de la manière dont EIP-8037 interagit avec les contrats déjà déployés sur le mainnet.
Glamsterdam regroupe plusieurs évolutions importantes, notamment la séparation enshrined proposer-builder et les block-level access lists. Ces changements visent à améliorer l’efficacité du traitement des transactions et à préparer le terrain pour une capacité de traitement plus élevée. Parmi les éléments testés figurait également une augmentation de la limite de gaz à 200 millions sur Hoodi. Ce plafond relevé devait permettre d’observer le comportement des clients d’exécution et de consensus dans des conditions plus exigeantes.
« La sécurité ne se négocie pas. Mieux vaut retarder une activation que de risquer des comportements imprévus sur des contrats existants. »
Christine D. Kim, chercheuse Ethereum, a rapidement alerté les opérateurs de nœuds Hoodi. Elle a recommandé de revenir à une version antérieure des clients ou d’installer les mises à jour qui retirent l’activation prévue. Cette communication claire a permis d’éviter qu’une partie du réseau test ne tente d’activer un hard fork désormais annulé.
Les risques identifiés par ChainSecurity autour d’EIP-8037
EIP-8037 introduit une comptabilité séparée du gaz consommé lors de la création d’état. En parallèle, EIP-8038 modifie les coûts d’accès à l’état existant. Ensemble, ces propositions modifient subtilement les règles de facturation du gaz. ChainSecurity a publié le 13 octobre une analyse technique soulignant que ces changements pouvaient affecter le comportement de certains contrats face aux appels externes qui échouent.
De nombreuses applications décentralisées s’appuient sur le solde de gaz restant pour décider si une opération a échoué de manière définitive ou si elle peut être retentée. Avec les nouvelles règles, une opération qui aurait auparavant provoqué un revert complet pourrait laisser suffisamment de gaz pour que le contrat appelant continue son exécution. Ce décalage de comportement peut conduire un contrat à enregistrer un échec tout en empêchant l’utilisateur de retenter l’opération.
ChainSecurity a indiqué avoir déjà identifié treize exemples concrets de contrats potentiellement concernés sur le mainnet. Les projets concernés ont été contactés dans le cadre d’un processus de divulgation responsable. Les mécanismes impactés concernent notamment les transactions groupées, les retraits et d’autres logiques de gestion d’échec. Aucune modification du code des contrats déployés n’est nécessaire pour que le problème se manifeste : il suffit que les règles de facturation du gaz changent.
Ce que change concrètement le report pour les opérateurs et les développeurs
Le report annule non seulement l’activation du 26 octobre, mais aussi l’augmentation programmée de la limite de gaz à 200 millions sur Hoodi. Il est important de préciser que cette décision ne modifie en rien l’historique des transactions déjà enregistrées sur le testnet. Seule la configuration future est affectée.
La Fondation Ethereum a publié un tableau de versions clients révisées. Du côté consensus, Lodestar v1.50.1 est listé. Côté exécution, Besu 26.10.1 et Nethermind 2.2.1 figurent parmi les versions recommandées. Ethrex propose une pré-version. Les opérateurs doivent vérifier à la fois leurs nœuds beacon et leurs clients validateurs, y compris toute infrastructure de construction de blocs externe. Les versions précédemment annoncées pour Hoodi ne doivent plus être considérées comme compatibles avec le report.
| Client | Couche | Version recommandée |
|---|---|---|
| Lodestar | Consensus | v1.50.1 |
| Besu | Exécution | 26.10.1 |
| Nethermind | Exécution | 2.2.1 |
| Ethrex | Exécution | v30.0.1-rc.2 |
Les développeurs d’applications ont été invités à ne plus planifier de tests sur Hoodi autour de la date du 26 octobre. En revanche, l’activation de Glamsterdam sur Sepolia, qui a eu lieu le 6 octobre, reste en place. Elle continue de fournir des données précieuses sur le comportement de l’upgrade avec une limite de gaz plus élevée.
Le calendrier mainnet reste ouvert et prudent
Avant ce report, les développeurs discutaient de plusieurs dates possibles pour le mainnet : 1er, 8 ou 9 décembre. L’ordre du jour de la réunion du 22 octobre prévoyait même de sélectionner une date la semaine suivante si les tests Hoodi s’étaient déroulés correctement. Aucune de ces dates n’avait été confirmée, et l’annonce de report ne fixe pas de nouveau calendrier.
Cette absence de date fixe n’est pas un signe de retard structurel, mais plutôt le reflet d’une méthodologie éprouvée. Ethereum a déjà démontré, lors de précédentes mises à jour, qu’il préfère prendre le temps nécessaire plutôt que d’exposer le réseau à des risques mal maîtrisés. Les utilisateurs du mainnet et les détenteurs d’ETH n’ont aucune action à entreprendre. Seuls les opérateurs de nœuds Hoodi et les équipes qui prévoyaient des tests spécifiques sont concernés.
Comprendre le rôle du gaz et des règles d’échec dans les contrats
Le gaz est l’unité de mesure qui détermine le coût computationnel d’une opération sur Ethereum. Chaque instruction de la machine virtuelle consomme une quantité définie de gaz. Lorsque le gaz disponible devient insuffisant, la transaction est généralement annulée (revert). De nombreux contrats utilisent cette propriété pour implémenter des logiques de sécurité ou de retry.
EIP-8037 et EIP-8038 modifient la manière dont certaines opérations liées à l’état sont facturées. La création d’état et l’accès à l’état existant voient leurs coûts ajustés de façon différenciée. Dans un contexte où un contrat effectue un appel externe qui échoue par manque de gaz, le solde restant après l’appel peut désormais permettre la poursuite de l’exécution alors qu’il aurait auparavant déclenché un revert global. Ce changement de sémantique est subtil mais potentiellement critique pour des protocoles qui s’appuient sur l’atomicité des opérations.
Les applications DeFi, les systèmes de retraits automatisés et les mécanismes de batching sont particulièrement exposés. Un protocole qui vérifie le succès d’une opération en observant le gaz restant pourrait désormais interpréter un échec comme un succès partiel, ou inversement. C’est pourquoi l’analyse approfondie demandée par les développeurs Ethereum est essentielle avant toute activation sur un environnement qui reflète plus fidèlement le mainnet.
Les bénéfices attendus de Glamsterdam une fois les risques maîtrisés
Malgré le report, Glamsterdam conserve un fort potentiel d’amélioration pour le réseau. La séparation enshrined proposer-builder vise à réduire la dépendance vis-à-vis des constructeurs de blocs externes et à renforcer la résistance à la censure. Les block-level access lists permettent quant à elles d’optimiser l’accès aux données en pré-déclarant les comptes et slots qui seront lus ou écrits pendant l’exécution d’un bloc.
Ces évolutions s’inscrivent dans une stratégie plus large d’augmentation de la capacité de traitement tout en maintenant un niveau de sécurité élevé. Une limite de gaz plus élevée, une fois validée, ouvrirait la voie à des transactions plus complexes et à une meilleure expérience utilisateur sur les applications décentralisées. Curve Finance avait notamment souligné les bénéfices potentiels pour la DeFi, tout en alertant sur les effets secondaires possibles des nouvelles règles de facturation.
- Réduction de la dépendance aux builders externes grâce à la proposer-builder separation enshrined.
- Optimisation de l’accès aux données via les block-level access lists.
- Préparation à une capacité accrue une fois les questions de comptabilité de gaz résolues.
- Meilleure résistance à la censure et à certaines formes de manipulation de l’ordre des transactions.
Leçons des précédents reports et retards d’Ethereum
Ethereum n’en est pas à son premier report. La transition vers la preuve d’enjeu, initialement prévue plus tôt, a été décalée pour garantir la stabilité. Shanghai/Capella a également connu des ajustements de calendrier afin de finaliser correctement le retrait des stakers. Dans chaque cas, la communauté a finalement salué la prudence qui a permis d’éviter des incidents majeurs.
Le processus de développement d’Ethereum repose sur une coordination étroite entre de multiples équipes clients (Geth, Nethermind, Besu, Erigon, Reth, etc.). Chaque modification doit être testée sur plusieurs testnets successifs avant d’atteindre le mainnet. Hoodi, en tant que testnet relativement récent et fidèle au mainnet, joue un rôle important dans cette chaîne de validation. Le fait que Sepolia ait déjà activé Glamsterdam montre que le code de base fonctionne, mais que les interactions avec les contrats existants nécessitent encore un examen approfondi.
Cette méthodologie, parfois perçue comme lente par une partie de la communauté, a contribué à la réputation de fiabilité d’Ethereum. Les fonds bloqués dans les contrats intelligents représentent des milliards de dollars. Une erreur de sémantique sur le gaz pourrait entraîner des pertes ou des comportements inattendus difficiles à corriger une fois déployés.
Impact sur l’écosystème DeFi et les développeurs d’applications
Les protocoles DeFi sont les premiers concernés par les modifications des règles de gaz. Un système de prêt qui effectue des liquidations automatiques, un protocole de yield farming qui récolte des récompenses en batch, ou un bridge qui vérifie le succès d’un transfert peuvent tous dépendre de la sémantique actuelle des échecs par manque de gaz.
Les équipes de développement sont encouragées à revoir leurs contrats à la lumière des analyses de ChainSecurity. Même si les treize exemples identifiés n’ont pas été rendus publics, la divulgation responsable permet aux projets concernés de préparer des correctifs ou des adaptations avant toute activation mainnet. Pour les autres équipes, c’est l’occasion de renforcer les tests autour des chemins d’échec et des appels externes.
À plus long terme, une meilleure compréhension des interactions entre les règles de facturation du gaz et les contrats existants pourrait conduire à des recommandations de bonnes pratiques. Certains développeurs pourraient choisir d’utiliser des patterns plus explicites pour gérer les échecs, plutôt que de s’appuyer uniquement sur le solde de gaz restant.
Perspectives pour la suite du développement d’Ethereum
Le report de Glamsterdam sur Hoodi ne remet pas en cause la feuille de route globale. Les équipes continueront d’analyser les cas limites identifiés et de travailler avec les clients pour garantir une compatibilité maximale. Une fois les préoccupations résolues, une nouvelle date d’activation sur Hoodi sera communiquée, suivie potentiellement d’une activation mainnet.
Cette séquence illustre également l’importance croissante des audits de sécurité externes et des analyses indépendantes. ChainSecurity a joué un rôle clé en signalant les risques avant l’activation. Ce type de collaboration entre chercheurs, équipes clientes et firmes de sécurité renforce la robustesse du processus de mise à jour.
Pour les utilisateurs finaux, l’expérience reste inchangée. Les transactions continuent de s’exécuter normalement, et aucune action n’est requise de leur part. Pour les observateurs attentifs de l’écosystème, cet épisode rappelle que la scalabilité et la sécurité avancent ensemble, parfois au prix de quelques semaines supplémentaires de préparation.
« Retarder une activation pour approfondir l’analyse est une marque de maturité, pas de faiblesse. Ethereum a construit sa crédibilité sur cette approche. »
En attendant la prochaine communication de la Fondation Ethereum, la communauté continue de suivre les discussions des All Core Developers. Les prochaines réunions devraient apporter plus de clarté sur le calendrier révisé et sur les éventuelles adaptations techniques retenues pour atténuer les risques liés à EIP-8037 et EIP-8038. D’ici là, le réseau mainnet poursuit son fonctionnement normal, tandis que les équipes de développement affinent les derniers détails d’une mise à jour qui, une fois déployée, devrait renforcer durablement les capacités d’Ethereum.
Le report de Glamsterdam illustre une fois de plus que le développement d’une blockchain publique de cette envergure exige un équilibre constant entre ambition technique et responsabilité vis-à-vis des fonds et des applications qui reposent sur elle. Les semaines à venir permettront de mesurer comment les équipes transforment cette alerte en améliorations concrètes, tout en préservant la confiance que des millions d’utilisateurs placent dans le réseau.
Les développeurs qui souhaitent anticiper les évolutions futures peuvent d’ores et déjà examiner les spécifications de Glamsterdam et tester leurs contrats sur Sepolia, où l’upgrade est déjà active. Cette approche proactive leur permettra d’être prêts lorsque Hoodi et, plus tard, le mainnet activeront enfin les changements. La prudence actuelle ne ralentit pas l’innovation : elle la rend simplement plus durable.
Enfin, cet épisode met en lumière l’importance de la communication transparente. En alertant rapidement les opérateurs de nœuds et en expliquant clairement les motifs du report, les équipes Ethereum ont limité les risques de fragmentation sur le testnet. Cette clarté contribue à maintenir la cohésion de l’écosystème, même lorsque des ajustements de calendrier deviennent nécessaires. Les observateurs peuvent donc aborder les prochaines étapes avec la certitude que les décisions prises reposent sur une analyse technique approfondie plutôt que sur des contraintes de calendrier.
La suite du développement de Glamsterdam sera suivie de près par l’ensemble de la communauté. Qu’il s’agisse des opérateurs de nœuds, des développeurs d’applications ou des utilisateurs finaux, chacun a un rôle à jouer dans la validation progressive des changements. En attendant les prochaines annonces, le réseau continue de fonctionner de manière stable, offrant le temps nécessaire pour que les questions de sécurité soient pleinement résolues avant toute activation plus large.
Les analyses en cours autour d’EIP-8037 pourraient également inspirer des améliorations plus générales des outils de test et des frameworks de simulation. En identifiant précisément les cas où la sémantique du gaz évolue, les chercheurs contribuent à affiner les environnements de développement et les suites de tests utilisées par l’écosystème. Cette capitalisation des connaissances bénéficiera non seulement à Glamsterdam, mais aussi aux futures propositions qui toucheront aux mécanismes de facturation ou d’exécution.
En définitive, le report de l’activation sur Hoodi constitue un rappel salutaire : dans un système où des milliards de dollars reposent sur des règles d’exécution précises, chaque modification doit être validée avec une rigueur maximale. Ethereum a choisi cette voie, et la communauté peut s’en réjouir. Les prochaines semaines apporteront sans doute des précisions supplémentaires sur le calendrier et les éventuels ajustements techniques retenus. D’ici là, la priorité reste claire : garantir que Glamsterdam, une fois activé, renforce le réseau sans introduire de comportements inattendus pour les contrats existants.
