Ethereum (ETH) a répété sa prochaine grande mise à niveau le 6 octobre. Hors des canaux développeurs, presque personne n’y a prêté attention. Pourtant, le testnet Sepolia applique désormais de nouvelles règles qui modifient qui construit les blocs, comment le gas est tarifé et quelle charge de travail chaque bloc peut embarquer.
Cet article décrypte les 18 changements majeurs de Glamsterdam, menés par la séparation enchâssée du proposeur et du constructeur (ePBS), les listes d’accès au niveau du bloc et la re-tarification du gas, ainsi que leurs effets attendus sur les frais, le MEV, les rollups et la montée planifiée à une limite de 200 millions de gas.
- Glamsterdam est entré en vigueur sur le testnet Sepolia d’Ethereum le 6 octobre 2026, et les développeurs ont fixé au 26 octobre la date pour le testnet Hoodi. Aucune date pour le mainnet n’a encore été actée, même si un projet de calendrier liste des fenêtres début décembre.
- La mise à niveau intègre dans le protocole la passation entre proposeur et constructeur, ajoute des listes d’accès au niveau des blocs pour faciliter le traitement parallèle et re-tarife la façon dont Ethereum facture la création et la lecture de l’état.
- Après Glamsterdam, les développeurs se sont mis d’accord sur un plancher de 200 millions de gas pour la limite de bloc, plus de trois fois le réglage par défaut actuel de 60 millions, même si l’impact sur les frais dépendra de la demande et de l’adoption par les validateurs.
En quoi consiste la mise à niveau Glamsterdam d’Ethereum, et pourquoi est‑elle importante ?
Glamsterdam est la mise à jour réseau qui succède à Fusaka, et son nom combine deux volets. Le côté « execution layer » est baptisé Amsterdam, en référence à la ville hôte de Devconnect 2022, tandis que le côté « consensus » se nomme Gloas, d’après une étoile.
La Fondation Ethereum a publié son annonce de testnet le 28 septembre. L’activation sur Sepolia était programmée à l’epoch 353 024, slot 11 296 768, à 13:53:36 UTC le 6 octobre.
Le fork a été déployé dans les temps.
La chercheuse indépendante Christine D. Kim a rapporté le 9 octobre, dans sa newsletter, que la mise à niveau de Sepolia « s’est déroulée sans heurts » (rapport). Les développeurs ont ensuite planifié Glamsterdam sur Hoodi, le deuxième et dernier testnet public, pour le lundi 26 octobre, avec des versions clients attendues d’ici le 16 octobre.
Le périmètre fonctionnel est recensé dans la proposition de suivi EIP‑7773. Elle regroupe 18 changements de base, appuyés par cinq propositions réseau et deux propositions informationnelles.
Pour le mainnet, en revanche, le calendrier reste ouvert. La Fondation indique que les dates pour Hoodi et la production ne sont « pas encore décidées », et ethereum.org ne mentionne toujours qu’un objectif au quatrième trimestre 2026.
Un projet de proposition de calendrier sur GitHub évoque les 1er, 8 et 9 décembre comme créneaux potentiels pour le mainnet, mais les développeurs n’ont arrêté aucune de ces dates.
L’enjeu est de taille. Pendant des années, Ethereum a choisi de concentrer l’essentiel de l’effort de scalabilité sur les rollups, en gardant une couche de base très prudente. Glamsterdam marque un changement de cap plus affirmé.
La Fondation présente la mise à jour comme l’étape suivante de son plan pour faire passer à l’échelle la couche 1. Les fonctionnalités phares visent surtout à permettre à la chaîne de base de traiter bien plus d’activité de manière sûre, tout en rapprochant le prix du gas du coût réel d’exécution et de croissance de l’état.
À lire aussi : L’UI intelligente de ChatGPT intègre graphiques et calculateurs pour 1,2 Md d’utilisateurs
En quoi Glamsterdam diffère‑t‑il de Pectra et Fusaka ?
Les deux dernières mises à jour d’Ethereum portaient principalement sur le staking et les données. Glamsterdam s’attaque à l’exécution, la partie du système qui fait réellement tourner les transactions.
Pectra a été activée le 7 mai 2025, à l’epoch 364 032. Elle a permis aux portefeuilles classiques de déléguer à du code de smart contract via l’EIP‑7702, relevé le solde maximum par validateur de 32 à 2 048 Ether, et augmenté l’objectif de blobs à six, avec un plafond de neuf.
Fusaka a été activée le 3 décembre 2025 à 21:49:11 UTC. Sa fonctionnalité vedette, PeerDAS (EIP‑7594), permet aux nœuds de vérifier les données de blobs par échantillonnage de petits morceaux, au lieu de tout télécharger.
Fusaka a aussi introduit les forks « blob‑parameter‑only », de petites mises à jour de configuration qui modifient la capacité en blobs sans embarquer d’autres changements. Deux de ces ajustements ont suivi, les 9 décembre 2025 et 7 janvier 2026.
La mise à jour « January Checkpoint » de la Fondation a souligné qu’Ethereum vise désormais 14 blobs par bloc, avec un maximum de 21. Elle y voit une multiplication par 2,3 de l’espace de données pour les couches 2 par rapport à la période pré‑Fusaka.
Côté exécution, Fusaka a plafonné la taille d’une transaction autour de 16,8 millions de gas et fixé dans les clients une limite de bloc par défaut à 60 millions de gas.
Glamsterdam change d’optique. Plutôt que d’ajouter encore de la place pour les données des rollups, la mise à niveau revoit la façon dont les blocs sont produits, validés et tarifés, afin que le seuil de 60 millions puisse monter beaucoup plus haut.
Pectra et Fusaka ont élargi les « tuyaux » pour les L2 ; Glamsterdam reconfigure la salle des machines de la L1.
À lire aussi : TRON peut‑il protéger 95 Md$ de stablecoins des attaques quantiques ? Sun affirme être prêt
Qu’est‑ce que la séparation enchâssée proposeur‑constructeur, ou ePBS ?
Aujourd’hui, la plupart des blocs Ethereum ne sont pas assemblés par les validateurs qui les proposent. Des constructeurs spécialisés rivalisent pour composer le bloc le plus rentable, et un validateur qui exécute le logiciel MEV‑Boost de Flashbots choisit l’enchère la plus élevée.
Cette passation repose sur des « relays », des intermédiaires de confiance. Un relay garde le bloc du constructeur, n’en montre au proposeur que l’en‑tête et l’offre, puis publie le contenu complet une fois la proposition signée.
Ce dispositif fonctionne, mais il est totalement hors protocole. Si un relay tombe, se comporte mal ou censure, les règles de consensus d’Ethereum ne prévoient aucun recours.
L’EIP‑7732 rapatrie cet échange dans Ethereum lui‑même. Il traite les constructeurs comme des participants du protocole et confie aux validateurs un nouveau rôle, les attestations de ponctualité des payloads.
Dans le nouveau flux, un proposeur inclut, dans le bloc beacon, l’engagement signé d’un constructeur sur un payload d’exécution, et le constructeur révèle ensuite ce payload. Le protocole gère automatiquement le paiement au proposeur, ce qui réduit la dépendance à des intergiciels de confiance.
Un sous‑ensemble de validateurs forme le « payload timeliness committee ». Ses membres attestent que le constructeur a bien révélé son payload dans les temps, et que les données de blobs correspondantes étaient disponibles.
Le changement sépare aussi la validation de consensus de la validation d’exécution, et c’est là que la dimension « scalabilité » apparaît.
La feuille de route sur ethereum.org indique que cette séparation élargit la fenêtre de propagation des données sur le réseau d’environ 2 secondes à près de 9 secondes. Avec plus de temps, les validateurs peuvent traiter des payloads nettement plus volumineux sans risque excessif.
Les relays ne vont pas disparaître du jour au lendemain. La même page précise que constructeurs et proposeurs pourront continuer d’utiliser des relays ou intergiciels hors protocole pour des fonctionnalités avancées que le cœur du protocole ne gère pas encore.
À lire aussi : Claude Mythos 5 a atteint des sites gouvernementaux, Anthropic a coupé court aux tests
Comment Glamsterdam pourrait‑il transformer le MEV et l’économie des validateurs Ethereum ?
La « maximum extractable value » (MEV) désigne le profit tiré de l’ordre, de l’inclusion ou de l’exclusion des transactions. Via MEV‑Boost, une grande partie de cette valeur remonte aujourd’hui vers les validateurs sous forme d’enchères des constructeurs, mais le marché qui sous‑tend ces offres est très concentré.
Le tableau de bord Relayscan de Flashbots montrait Titan à l’origine de 52,6 % des blocs MEV‑Boost sur les 24 heures clôturées au 12 octobre au matin. Quasar en construisait 18,5 % et BuilderNet 13,3 %, laissant trois constructeurs capter environ 84 % des blocs.
L’ePBS n’abolit pas le MEV, et il ne disperse pas automatiquement la concentration des constructeurs. Ce qu’il change, c’est le modèle de confiance : le paiement du proposeur ne dépend plus d’un relay tenu d’honorer sa promesse.
Pour les stakers, le gain se joue à la marge. Un validateur solo dispose d’un mécanisme, garanti par le protocole, pour vendre de l’espace de bloc, tandis que les constructeurs doivent eux‑mêmes déposer une mise en jeu (stake) pour participer.
Les stakers bénéficient aussi de sorties plus rapides. Avec l’EIP‑8061, la capacité de sortie évolue avec le montant total d’Ether délégué, ce qui, selon ethereum.org, la quadruple environ aux niveaux actuels et double la marge pour les consolidations de validateurs.
La contrepartie, c’est une fenêtre de sécurité plus courte pour les nœuds qui se déconnectent. Toujours selon ethereum.org, la période de « weak subjectivity » — au‑delà de laquelle un nœud qui revient en ligne doit se resynchroniser à partir d’un point de contrôle de confiance récent — passerait d’environ 15,7 jours à environ 7 jours.
Lors du rassemblement « Soldøgn interop » à Svalbard, qui réunissait un peu plus de 100 contributeurs cœur, les développeurs ont souligné deux points sensibles autour d’ePBS. L’un d’eux porte sur la protection du design contre les attaques Sybil sur le réseau pair‑à‑pair, alors que le dispositif ne demande qu’1 ETH de stake aux constructeurs.
Cette inquiétude a resurgi avant Sepolia. Lors d’un appel de consensus du 17 septembre, le développeur Prysm Potuz a mis en garde contre le fait que de l’Ether de test gratuit permettrait à un attaquant de remporter les enchères avec des constructeurs jetables, puis de retenir les payloads : « Je peux simplement lancer un millier de constructeurs. »
Les premières données sur Sepolia montrent un marché encore très mince. Un compte‑rendu communautaire de l’appel execution‑layer du 8 octobre cite EthPandaOps : seuls quatre ou cinq constructeurs y auraient été actifs, les principaux acteurs étant absents et de nombreux blocs restant construits localement.
L’ePBS ne démontrera vraiment sa valeur que lorsque de « vrais » constructeurs se livreront concurrence pour les blocs, ce qui fait de Hoodi le test le plus révélateur.
À lire aussi : L’iPhone Duo pourrait saluer personnellement l’acheteur au premier démarrage du pliable à 1 999 $
Que sont les listes d’accès au niveau des blocs, et comment améliorent‑elles le traitement des transactions ?
Aujourd’hui, les clients Ethereum traitent largement les transactions d’un bloc les unes après les autres. Ils ne peuvent pas savoir à l’avance quels comptes ou emplacements de stockage une transaction va toucher ; exécuter deux transactions en parallèle expose donc à des collisions potentielles.
L’EIP‑7928 introduit les listes d’accès au niveau des blocs, ou BAL (« block‑level access lists »), qui consignent tous les comptes et emplacements de stockage touchés par un bloc, ainsi que les changements d’état induits par chaque transaction. Les constructeurs produisent cette liste, et l’en‑tête du bloc enregistre les informations nécessaires pour que les clients puissent raisonner sur l’accès à l’état. Munis d’une telle « carte », les clients peuvent paralléliser plusieurs tâches :
- Lire en une seule fois, depuis le disque, tout l’état nécessaire au lieu de le découvrir au fil de l’eau.
- Valider en parallèle, sur des cœurs CPU distincts, les transactions qui ne se recoupent pas.
- Calculer plus efficacement la racine d’état post-bloc.
- Mettre à jour l’état à partir des résultats enregistrés sans rejouer chaque transaction, ce qui accélère la synchronisation.
Une modification réseau complémentaire, l’EIP‑8159, permet aux nœuds d’échanger ces listes entre eux. Une autre, l’EIP‑8189, exploite les données BAL pour réparer l’état pendant le snap sync.
Lors de Soldøgn, les équipes clients ont benchmarqué chaque optimisation BAL derrière son propre « feature flag ». L’objectif : accélérer d’abord les goulots d’étranglement de chaque client, car relever la plus faible implémentation augmente la limite de gas sûre pour tout l’écosystème.
Les BAL et l’ePBS forment un couple indissociable. L’ePBS offre plus de temps d’exécution dans chaque slot, et les BAL permettent aux clients d’exploiter ce temps beaucoup plus efficacement.
À lire aussi : Bezos Pense Que L’IA Pourrait Mener À Des Semaines De Trois Jours Après 30 000 Licenciements Chez Amazon
Comment Glamsterdam Va-T-Il Modifier La Comptabilité Du Gas Et Le Coût D’Exécution Sur Ethereum ?
Les coûts en gas des opérations sur l’état n’avaient pas été revus en profondeur depuis la mise à jour Berlin en 2021. Depuis, l’état d’Ethereum a fortement gonflé, et les récentes hausses de la limite de gas ont encore accéléré cette croissance.
Un billet de la Fondation à destination des développeurs de smart contracts expliquait, le 24 août, que le nouveau barème permet « environ un triplement du débit de base ». Le reprofilage de ces opérations est présenté comme un prérequis à toute nouvelle hausse de la limite de gas.
Deux EIP assurent l’essentiel du travail. L’EIP‑8037 renchérit et mesure séparément le coût de création d’état, tandis que l’EIP‑8038 augmente le coût de lecture et d’écriture de cet état via des opérations comme SLOAD, SSTORE ou les accès « cold » aux comptes.
L’EIP‑8037 fixe un prix de 1 530 gas par nouvel octet d’état, calculé pour viser une croissance annuelle de 120 GiB d’état avec une limite de gas de référence de 150 millions.
À ce tarif, un nouveau slot de stockage coûte 97 920 unités de « state gas », contre 20 000 aujourd’hui, et la création d’un nouveau compte passe à 183 600 unités, contre 25 000. Le déploiement d’un contrat de taille maximale (24 KiB) devient environ huit fois plus cher.
Le gas d’état bénéficie aussi de son propre « compteur ». Le plafond par transaction introduit avec Fusaka ne s’applique plus qu’au gas d’exécution ; à l’échelle d’un bloc, c’est désormais la dimension – exécution ou état – la plus proche de sa limite qui fait foi.
Le reste du « package gas » est plus ciblé, mais s’additionne :
- L’EIP‑7778 exclut les remboursements de gas du calcul de la limite de gas par bloc, même si les utilisateurs continuent de percevoir leurs remboursements sur le gas effectivement payé.
- L’EIP‑7976 relève le plancher du coût de calldata à 64 gas par octet pour les transactions très consommatrices de données.
- L’EIP‑7981 facture les données de listes d’accès au même tarif de 64 gas par octet.
- L’EIP‑2780 reconstruit le gas intrinsèque des transactions en fonction de la consommation réelle de ressources, avec un coût de base de 12 000 gas.
- L’EIP‑7954 augmente la taille maximale des contrats de 24 KiB à 64 KiB.
Dans sa version actuelle, l’EIP‑2780 maintient un simple transfert d’Ether vers un compte existant à 21 000 gas, tandis qu’un transfert créant un nouveau compte ajoute 183 600 unités de state gas. La page Glamsterdam d’Ethereum.org, mise à jour pour la dernière fois le 6 août, continue néanmoins à présenter les transferts comme pouvant devenir jusqu’à 71 % moins chers.
Les chiffres restent susceptibles d’évoluer. Plusieurs de ces propositions, dont l’EIP‑2780 et l’EIP‑8037, sont encore en « Last Call » jusqu’au 1er novembre, et ethereum.org précise que le périmètre peut encore changer avant le déploiement sur mainnet.
À lire aussi : Zcash Vise Un Objectif Quantique En Janvier Pour 70 % Du ZEC, Mais Sans Date Précise
L’Upgrade Peut-Elle Accroître Le Débit De La Layer 1 Et Faire Baisser Les Frais De Transaction ?
Le gain attendu, c’est le débit. À Soldøgn, les développeurs se sont alignés sur un « plancher crédible de limite de gas post‑Glamsterdam à 200 millions », soit environ 3,3 fois le paramètre par défaut actuel de 60 millions.
Ce chiffre repose sur trois piliers. L’ePBS accorde plus de temps à l’exécution, les optimisations BAL libèrent de la marge côté clients, et l’EIP‑8037 empêche une limite de gas plus élevée de se traduire par une explosion incontrôlée de la taille de l’état.
Sepolia fonctionne déjà avec une limite de 200 millions, programmée à l’époque de fork via l’EIP‑8261, qui transforme la limite de gas en paramètre piloté par fork.
Le code client pour Hoodi prévoit la même limite de 200 millions. Les résumés d’appels indiquent que le mainnet adoptera le même type de planification par epoch de fork, mais aucun chiffre ni calendrier n’a été formellement arrêté pour le réseau principal.
Les frais vont‑ils baisser ? Ethereum.org estime que Glamsterdam « devrait très probablement réduire les frais pour les utilisateurs au quotidien ». Plus d’espace par bloc pour une demande inchangée devrait faire pression à la baisse sur les prix, mais le résultat dépendra du volume de nouvelle activité qui viendra occuper cette capacité.
Les opérations très consommatrices d’état, comme la création de nouveaux comptes ou de nouveaux slots de stockage, coûteront davantage de gas : l’upgrade redistribue les coûts au moins autant qu’elle les réduit.
À lire aussi : Kalshi Affronte La NFL À La Cour Suprême Avec 1,8 Mrd $ En Jeu Sur Un Dimanche De Football
Quelles Sont Les Préparations Nécessaires Pour Les Wallets, Smart Contracts, Fournisseurs D’Infrastructure Et Validateurs ?
Pour les détenteurs de base, aucune action n’est requise. La Fondation rappelle que les utilisateurs du mainnet n’ont rien à faire, et ethereum.org prévient que quiconque leur demande de « mettre à jour » leurs ETH est en train d’orchestrer une arnaque.
Pour tous les autres, en revanche, la to‑do list est fournie, et le reprofilage du gas en est le cœur. La relecture de transactions mainnet historiques a mis en évidence un petit ensemble de contrats susceptibles de casser ou de se dégrader, en général parce qu’ils reposent sur des hypothèses de gas codées en dur.
La Fondation souligne qu’une simple hausse des limites de gas suffit à résoudre la majorité des problèmes identifiés, et que l’immense majorité des smart contracts ne sera pas affectée.
Le plan d’action, compilé à partir des consignes de la Fondation et des équipes clients, tient en quelques points :
- Les développeurs de smart contracts doivent vérifier leurs adresses via l’outil de la Fondation recensant les contrats à risque, puis tester les correctifs sur le testnet Platåberget, en prêtant attention à l’allocation fixe de 2 300 gas de Solidity, aux valeurs de gas codées en dur et aux logiques conditionnelles basées sur le gas restant.
- Les wallets, fournisseurs RPC et outils de nœuds doivent mettre à jour leurs modules d’estimation de gas : les constantes de gas mises en cache sous‑évalueront les coûts et provoqueront des transactions échouées.
- Les plateformes d’échange, ponts et indexeurs peuvent exploiter les nouveaux logs définis par l’EIP‑7708, qui imposent l’émission d’un événement standard pour tout transfert ou burn d’Ether non nul.
- Les opérateurs de nœuds doivent mettre à jour à la fois leurs clients d’exécution et de consensus avant chaque activation, et les validateurs doivent mettre à jour le beacon node ainsi que le client validateur.
- Les opérateurs de staking et les teams builders doivent se familiariser avec les nouvelles responsabilités et interfaces ePBS, notamment le « payload timeliness committee », avant chaque fork.
Côté exécution, les clients compatibles Sepolia incluaient Geth 1.17.7, Nethermind 2.1.0, Besu 26.9.0, Erigon 3.7.1, Reth 2.7.0 et Ethrex 29.0.1. Pour le consensus, la liste comprenait Lighthouse 8.3.0‑rc.0, Prysm 7.2.1, Teku 26.9.1, Lodestar 1.49.0, Nimbus 26.10.0 et Grandine 3.0.0‑rc.0.
La configuration par défaut de la limite de gas illustre le poids des détails. La version 7.2.0 de Prysm et la release Sepolia de Teku laissaient les validateurs à 60 millions après le fork, sauf intervention explicite des opérateurs pour la relever à 200 millions.
Prysm a intégré un correctif le 2 octobre afin que les validateurs sans paramétrage explicite suivent automatiquement le calendrier Sepolia à 200 millions, et la Fondation référence désormais Prysm 7.2.1. Les validateurs Teku qui souhaitent adopter le plafond de 200 millions doivent toujours l’indiquer via un flag de configuration.
À lire aussi : Catastrophe De L’IA D’Ici 12 Mois ? OpenAI Et Anthropic Préparent Déjà La Gestion Des Dégâts
Quel Impact Glamsterdam Aura-T-Il Sur Les Rapports Entre La Layer 1 D’Ethereum Et Les Réseaux De Layer 2 ?
Glamsterdam ne tourne pas le dos aux rollups. La feuille de route officielle présente l’upgrade comme un progrès simultané sur les axes « Scale L1 » et « Scale Blobs ».
Le lien est mécanique. En élargissant la fenêtre de propagation, l’ePBS permet, selon ethereum.org, de transporter bien plus de données sur Ethereum – y compris davantage de blobs pour les rollups – sans surcharger le réseau.
Glamsterdam, en tant que tel, ne touche pas aux paramètres de blobs. Depuis Fusaka, la capacité en blobs évolue via des forks dédiés qui ne modifient que ces paramètres ; la capacité de données pour les rollups peut donc continuer à croître selon un calendrier distinct.
Les développeurs ne se précipitent pas sur ce front. Le « January Checkpoint » indiquait qu’un troisième fork de ce type ne serait pas prioritaire tant que l’usage des blobs n’aurait pas rattrapé les deux premières hausses.
Deux fonctionnalités plus modestes visent directement les Layer 2. L’EIP‑7997 installe un contrat « factory » déterministe à la même adresse sur toutes les chaînes EVM participantes, ce qui permet de déployer wallets et applications aux mêmes adresses sur plusieurs réseaux.
La seconde, l’EIP‑8070, introduit un « sparse blobpool », une évolution du réseau sur la manière dont les nœuds traitent les transactions à blobs.
La tension stratégique reste palpable : une Layer 1 moins chère et plus rapide rend le déploiement direct sur le mainnet plus attractif, au risque de concurrencer les rollups qui s’y adossent pour le règlement.
La réponse d’Ethereum, à ce stade, consiste à faire croître les deux couches en parallèle. La feuille de route traite la capacité d’exécution et la capacité en blobs comme deux objectifs autonomes, et Glamsterdam incarne cette double ambition plutôt qu’un arbitrage en faveur de l’une ou l’autre couche.
Pour les utilisateurs de rollups, l’effet concret est un socle de règlement plus robuste et plus minimisé en termes de confiance.
À lire aussi : Les ETFs XRP Attirent 8 M$ En Pleine Vague De Sorties Sur Les Fonds Crypto Menée Par Le Bitcoin
Quelle Est La Prochaine Étape De La Feuille De Route De Scalabilité D’Ethereum Après Glamsterdam ?
Le prochain fork s’appelle Hegotá. Comme Glamsterdam, son nom marie une ville de la couche d’exécution, Bogotá, et une étoile de la couche de consensus, Heze.
Ses têtes d’affiche sont déjà connues. Le cluster Protocol de la Fondation a désigné l’EIP‑7805, les listes d’inclusion imposées par la règle de choix de fork (FOCIL), pour la couche de consensus, et l’EIP‑8141, les « Frame Transactions », pour la couche d’exécution.
FOCIL figurait un temps parmi les candidats pour Glamsterdam. Les développeurs l’ont repoussé à Hegotá pour limiter l’ampleur de ce fork, selon la…Point d’étape de janvier de la fondation
FOCIL permet à plusieurs validateurs d’imposer aux builders l’inclusion de transactions valides, répondant ainsi directement au risque de censure lié à la concentration du marché des builders. Les transactions Frame rendent la validation et le paiement du gas programmables, offrant aux comptes une voie de sortie native par rapport aux clés secp256k1 utilisées aujourd’hui.
La « tier list » associée au cluster a classé 62 EIP proposés, à partir de 397 évaluations fournies par un groupe d’environ 60 personnes. Deux EIP ont été jugés « indispensables », 15 « susceptibles d’être intégrés » et 28 « écartés ».
Le calendrier est ambitieux. Le cluster estime que les équipes clients pourraient, de façon réaliste, commencer à implémenter Hegotá fin T4 2026, en partant de l’hypothèse de travail – et non d’une date officielle – que Glamsterdam serait activé en décembre.
Au-delà de Hegotá, le cluster structure ses travaux autour de cinq grands axes de recherche pluri-forks :
- Fast finality : réduire le temps de finalisation de quelques minutes à quelques secondes, avec le consensus découplé en tête de liste pour le fork suivant Hegotá.
- Sécurité post-quantique : objectif auto-fixé d’un Layer 1 résistant au quantique sur l’exécution, le consensus et les données d’ici décembre 2029.
- Confidentialité : dès Hegotá, prise en charge au niveau du protocole de transactions privées sur le Layer 1, sans confiance et résistantes à la censure.
- État : nouveau trie, croissance soutenable de l’état et accès décentralisé à l’état courant comme historique.
- zkEVM : passage des preuves d’exécution de l’optionnel à l’obligatoire, afin que les validateurs vérifient à terme des preuves plutôt que de ré-exécuter chaque bloc.
À lire aussi : Vente de bitcoins de MARA non prouvée après l’arrivée de 81 M$ sur un wallet Galaxy Digital
Conclusion : ce que Glamsterdam change pour Ethereum
Glamsterdam n’est pas tant une fonctionnalité isolée qu’une réorganisation de la couche de base d’Ethereum. La mise à niveau internalise le marché des builders dans le protocole, offre aux clients un plan de travail pour le parallélisme et fait payer plus justement le coût d’un stockage d’état permanent.
Le déploiement sur Sepolia s’est déroulé sans accroc, mais les tests les plus exigeants restent à venir. Potuz a rappelé que Hoodi héberge des pools de staking et des validateurs individuels, ce qui en fait un fork bien plus délicat que Sepolia.
Une proposition de calendrier émise par les développeurs cœur fixe le fork Hoodi à l’époque 132 352, soit 17:42:48 UTC le 26 octobre. Aucune date n’a été retenue pour le mainnet, et la fondation a indiqué qu’une annonce séparée y sera consacrée.
Les inconnues sont autant économiques que techniques. L’arrivée effective de véritables builders, l’adoption par les validateurs de la nouvelle limite de gas et le niveau de demande qui viendra remplir cet espace supplémentaire détermineront ce que Glamsterdam livrera réellement.
Si le pari est gagnant, la couche de base d’Ethereum pourra monter en puissance selon ses propres paramètres, avec des rollups qui construisent par-dessus, plutôt que de supporter l’intégralité de la charge.
À découvrir ensuite : Introduction d’Evernorth au Nasdaq repoussée au 12 octobre : ce que change le retard de la fusion
