Rédigé par : KarenZ, Foresight News
La mise à niveau Glamsterdam d'Ethereum est trop souvent réduite à une simple itération technique pour augmenter le débit. En réalité, il s'agit plutôt d'une réorganisation profonde du processus de création des blocs, de validation et de tarification des ressources, visant à préparer le terrain pour une limite de Gas plus élevée, une plus grande capacité de blob et une exécution parallèle future.
Au 23 juin 2026, ethereum.org présente Glamsterdam comme une mise à niveau planifiée pour le second semestre 2026. Ce nom combine la mise à niveau de la couche d'exécution Amsterdam et celle de la couche de consensus Gloas. La feuille de route officielle la situe après Fusaka (décembre 2025) et avant Hegotá, avec deux fonctionnalités principales : la Séparation intégrée au protocole entre Proposant et Constructeur (ePBS), et les Listes d'Accès au niveau du Bloc (BAL).
Qui propose, qui construit : l'ePBS inscrit la division du travail dans le protocole
Aujourd'hui, la création d'un bloc sur Ethereum ressemble à une relève très serrée : une personne propose le bloc, une autre construit son contenu transactionnel, le tout dépendant d'infrastructures externes au protocole comme MEV-Boost et les relais tiers.
Ce système fonctionne depuis des années, mais il place une partie des relations de confiance hors protocole et force les validateurs à gérer simultanément consensus, exécution et disponibilité des données dans une fenêtre temporelle très courte.
L'un des premiers changements majeurs de Glamsterdam, l'EIP-7732 ou ePBS (Séparation intégrée Proposant-Constructeur), consiste justement à formaliser cette division des rôles dans le protocole.
En bref, le proposant sélectionne le bloc de consensus, et le constructeur prépare le contenu transactionnel. Le constructeur ne peut pas se contenter d'une promesse verbale ; il doit d'abord fournir une « garantie » dans le protocole : préciser quel bloc d'exécution il va livrer et combien il paiera au proposant. Ensuite, le Comité de Ponctualité de la Charge Utile (Payload Timeliness Committee, PTC) vérifie s'il a livré à temps.
L'objectif clé de ce changement n'est pas seulement de réduire la dépendance aux relais tiers, mais aussi de gagner du temps pour la propagation et la validation des blocs.
Actuellement, les validateurs doivent traiter à la fois le consensus et l'exécution dans un intervalle critique très court. L'ePBS sépare ces deux tâches, permettant de révéler et de valider la charge d'exécution un peu plus tard. Selon la conception de l'EIP-7732, la fenêtre de propagation de la charge d'exécution, c'est-à-dire le temps disponible pour que les données soient diffusées sur le réseau et reçues par les nœuds, pourrait passer d'environ 2 secondes à environ 9 secondes. Une fenêtre plus longue permettrait à Ethereum d'augmenter la capacité des blocs en limitant les risques accrus de perte de votes ou de réorganisation dus à un téléchargement, une validation ou un vote trop lent des nœuds.
Cela ne sera peut-être pas directement perceptible pour l'utilisateur moyen, mais c'est essentiel pour la scalabilité d'Ethereum. Une fenêtre de propagation et de validation plus longue signifie que le réseau peut traiter des charges plus importantes en toute sécurité. Dans un article du 16 juin 2026, CoinDesk cite Parithosh Jayanthi, ingénieur DevOps de l'Ethereum Foundation, selon qui Glamsterdam pourrait être l'un des plus grands forks depuis le Merge, modifiant de nombreuses hypothèses sur Ethereum et préparant le terrain pour des mises à l'échelle plus importantes.
BAL et retarification : la scalabilité ne consiste pas seulement à accélérer, mais aussi à gérer la base de données
L'autre changement central de Glamsterdam est l'EIP-7928, les Listes d'Accès au niveau du Bloc (Block-Level Access Lists).
On peut l'imaginer comme un « journal d'accès » attaché à chaque bloc : il enregistre quels comptes et quels emplacements de stockage ont été touchés lors de l'exécution du bloc, et quel est l'état résultant. Ainsi, les nœuds ne traitent plus les blocs en aveugle et peuvent savoir à l'avance quelles données doivent être lues et quels calculs peuvent être avancés en parallèle.
L'EIP-2930 avait déjà introduit des listes d'accès au niveau de la transaction, mais elles étaient optionnelles et peu utilisées. L'EIP-7928 les élève au niveau du bloc : l'en-tête du bloc contient une « empreinte » (un hachage) de cette liste, tandis que la charge d'exécution stocke la liste complète. Lors de l'exécution du bloc, les nœuds vérifient la cohérence entre la liste et les accès réels ; en cas d'incohérence, le bloc est invalidé.
Pourquoi est-ce important ? Actuellement, lors de l'exécution d'une transaction, de nombreux accès aux données ne sont connus qu'au moment où l'étape correspondante est atteinte. Les nœuds ne savant pas si un lot de transactions va lire ou écrire simultanément sur le même compte ou emplacement de stockage, ce qui rend difficile un traitement parallèle confiant. La BAL expose explicitement la trace d'accès de l'exécution du bloc, permettant aux clients d'effectuer des lectures disque parallèles, une validation de transactions parallèle, un calcul parallèle de la racine d'état, et de mettre à jour l'état sans rejouer entièrement les transactions dans certains cas. Ce n'est pas un bouton pour réduire directement les frais des utilisateurs, mais cela ouvre la voie à l'ingénierie client pour le parallélisme.
Mais la logique de scalabilité de Glamsterdam ne se limite pas à « élargir la route ». Elle doit aussi contrôler l'expansion à long terme de la base de données d'Ethereum. L'EIP-8037 augmente le coût de création d'état et introduit un Coût Par Octet d'État (CPSB). L'état peut être compris comme le contenu de la base de données qu'Ethereum doit conserver à long terme, comme les nouveaux comptes, contrats et emplacements de stockage. Une transaction se termine après son exécution, mais l'état reste dans le registre que tous les nœuds doivent maintenir. Si l'état croît trop vite, le fonctionnement des nœuds devient de plus en plus coûteux, menaçant progressivement la décentralisation.
L'EIP-8037 présente des chiffres de contexte éloquents : en janvier 2026, une base de données de nœud Geth dédiée à l'état pesait environ 390 GiB. Après l'augmentation de la limite de Gas du réseau principal de 30 à 60 millions, la création quotidienne d'état est passée d'environ 105 MiB à environ 326 MiB, soit une croissance annuelle d'environ 116 GiB. En extrapolant proportionnellement avec une limite de 200 millions de Gas, la croissance annuelle de l'état pourrait atteindre environ 387 GiB, dépassant en moins d'un an le seuil de dégradation des performances fixé à 650 GiB.
Ainsi, l'EIP-8037 vise à distinguer la tarification du « calcul temporaire » de celle de « l'occupation permanente de la base de données ». Créer un nouvel état coûtera plus cher, car cela impose au réseau un coût de stockage à long terme, et non un coût de calcul ponctuel.
Vitalik Buterin a également expliqué, en évoquant la feuille de route de scalabilité de Glamsterdam, que cette mise à niveau séparerait le coût de création d'état des coûts d'exécution et de calldata : l'objectif est de permettre une expansion plus importante de la capacité d'exécution, sans que la taille de l'état n'augmente au même rythme.
Considérés ensemble, la BAL permet aux nœuds de traiter plus facilement les blocs en parallèle, résolvant le problème « d'aller plus vite » ; la retarification de la création d'état fait payer plus cher les opérations qui occupent durablement la base de données, résolvant le problème de « ne pas trop gonfler le registre ». La scalabilité de Glamsterdam ne consiste pas simplement à augmenter la limite de Gas, mais à poser une question plus réaliste : Ethereum peut-il accueillir plus de transactions tout en évitant une pression incontrôlable sur la propagation des blocs, la validation des transactions et le stockage de l'état.
La liste des EIP de Glamsterdam se précise : lesquels sont fixés, lesquels sont en attente ?
Au 23 juin 2026, selon le suivi des mises à niveau d'Ethereum sur Forkcast, les développeurs testent actuellement Glamsterdam dans des environnements devnets. Le déploiement sur Sepolia est prévu pour le 3 août, et sur le réseau principal pour le 16 septembre (ces dates pourront être ajustées).
Actuellement, 10 EIP sont prévus pour Glamsterdam :
- EIP-7708 (Les transferts ETH déclenchent également des journaux d'événements, facilitant l'indexation et le suivi des transferts ETH natifs)
- EIP-7732 (ePBS, formalise la division proposant/constructeur dans le protocole, réduisant la dépendance aux relais externes)
- EIP-7778 (Supprime la comptabilité du Gas liée aux remboursements de Gas, simplifiant le calcul du Gas par bloc)
- EIP-7843 (Ajoute l'opcode SLOTNUM, permettant aux contrats de lire le numéro du slot actuel)
- EIP-7928 (Listes d'Accès au niveau du Bloc BAL, enregistre les comptes et emplacements de stockage accédés pendant l'exécution, prépare le terrain pour la validation parallèle)
- EIP-7954 (Augmente la limite maximale de taille des contrats, autorisant des codes d'opérations plus volumineux)
- EIP-7976 (Augmente le coût plancher du calldata, ajuste le coût minimum du calldata)
- EIP-7981 (Augmente le coût des listes d'accès, recalibre la tarification du Gas pour les listes d'accès)
- EIP-8024 (Opcodes SWAPN, DUPN, EXCHANGE rétrocompatibles, améliore les capacités de manipulation de la pile de l'EVM)
- EIP-8037 (Augmente le coût en Gas de la création d'état, freine l'expansion trop rapide de la base de données d'état)
Ces EIP peuvent être grossièrement classés en plusieurs catégories : premièrement, la restructuration des processus de création de blocs et de validation, avec l'EIP-7732 et l'EIP-7928 comme noyau ; deuxièmement, l'ajustement de la tarification des ressources, incluant les EIP-7778, 7976, 7981 et 8037 ; troisièmement, les modifications de l'EVM et de l'expérience développeur, avec les EIP-7708, 7843, 7954 et 8024.
En d'autres termes, Glamsterdam ne modifie pas qu'un seul point fonctionnel, mais met à niveau simultanément la division du travail de création de blocs, la validation parallèle, la tarification du Gas et la praticité de l'EVM.
Une autre série d'EIP figure sur la liste « En considération pour inclusion » :
- EIP-2780 (Sépare le Gas intrinsèque de la transaction par ressource)
- EIP-7610 (Annulation lors de la création de contrats sur des comptes de stockage non vides)
- EIP-7688 (Structures de données de la couche de consensus compatibles avec le futur)
- EIP-7904 (Analyse des coûts en Gas de calcul, pourrait être retiré de Glamsterdam)
- EIP-7975 (eth/70, listes de reçus partielles de blocs)
- EIP-7997 (Contrats d'usine déterministes)
- EIP-8038 (Mise à jour des coûts en Gas pour l'accès à l'état)
- EIP-8045 (Empêche les validateurs sanctionnés de continuer à proposer des blocs)
- EIP-8061 (Augmente le taux de sortie et de fusion - churn limit)
- EIP-8070 (eth/72, Sparse Blobpool)
- EIP-8080 (Permet aux sorties d'utiliser la file d'attente de consolidation - consolidation queue)
- EIP-8136 (Différences au niveau cellulaire pour la diffusion de colonnes de données)
- EIP-8159 (eth/71, Échange de listes d'accès aux blocs)
- EIP-8246 (Supprime le brûlage lié à SELFDESTRUCT)
- EIP-8282 (Requêtes d'Exécution des Constructeurs, fournit des demandes d'enregistrement et de sortie dédiées aux constructeurs ePBS)
De plus, Forkcast classe actuellement l'EIP-8254 (limite le nombre de demandes de dépôt par bloc de la couche d'exécution à 8192) comme « Proposé pour inclusion ».
Du point de vue des stakers, les EIP-8061 et EIP-8080, en considération, méritent une attention particulière. Pour les stakers, cela pourrait signifier une amélioration de la liquidité de sortie. Dans un article du 5 mai 2026, Figment indique que les stakers institutionnels doivent surtout suivre l'ePBS, l'EIP-8061 et l'EIP-8080, et estime qu'avec environ 38,9 millions d'ETH stakés en avril 2026, l'EIP-8061 pourrait augmenter la limite de churn de sortie de 256 ETH/epoch à environ 1187 ETH/epoch, tandis que l'EIP-8080 permettrait aux sorties normales d'utiliser la capacité excédentaire de la file d'attente de consolidation. Figment rappelle que tous les chiffres avant le déploiement sur le réseau principal doivent être considérés comme des estimations.
Source : Figment
Le protocole évolue, et les membres de la Fondation aussi
Les préparatifs techniques de Glamsterdam coïncident avec des changements de personnel au sein du groupe Protocole (Protocol cluster) de l'Ethereum Foundation. Un billet de blog de l'Ethereum Foundation du 11 mai 2026 indique que Glamsterdam a atteint plusieurs jalons : un objectif crédible de limite de plancher de 200 millions de Gas post-Glamsterdam a été établi, l'ePBS fonctionne de manière stable sur le devnet multi-client Glamsterdam, et l'EIP-8037 a été finalisé.
Le même article annonce une passation de leadership au sein du Protocol cluster : Will Corcoran, Kev Wedderburn et Fredrik deviennent les nouveaux coordinateurs du cluster. Les anciens coordinateurs Barnabé Monnot et Tim Beiko quittent l'Ethereum Foundation, et Alex Stokes est en congé.
La Fondation décrit la répartition des rôles des trois nouveaux coordinateurs ainsi : Will Corcoran possède une expérience de coordination inter-équipes ; Kev Wedderburn dirige l'équipe zkEVM ; Fredrik dirige les projets Protocol Security et Trillion Dollar Security.
Ces changements ne se limitent pas à l'équipe Protocole. Le 18 juin 2026, Hsiao-Wei Wang annonce, après un congé, sa décision de démissionner de ses fonctions de co-directrice exécutive et de membre du conseil d'administration de l'Ethereum Foundation.
L'ancien chercheur de l'Ethereum Foundation, Dankrad Feist, déclare le 19 juin 2026 que les personnes quittant l'EF sont des partisans des valeurs CROPS (Censorship-Resistant & Capture-Resistant, Open Source, Privacy, Security - Résistance à la censure et à la capture, Open Source, Confidentialité, Sécurité), que le problème n'est pas stratégique mais managérial, et estime que cet exode de talents est plutôt négatif pour Ethereum. De son côté, Azeem, co-fondateur de Miden, offre une interprétation inverse, estimant que l'EF a du mal à se transformer, et que la sortie de talents pourrait conduire à la création de nouvelles organisations plus aptes à exécuter la feuille de route d'Ethereum, ce qui serait à long terme un bénéfice net pour l'écosystème.
Le discours interne à l'Ethereum Foundation semble davantage tracer des limites. Le co-directeur exécutif intérimaire de l'Ethereum Foundation, Bastian Aue (Aerugo), répond que les départs de l'EF s'expliquent par des divergences stratégiques, des problèmes d'adéquation au poste, des mouvements institutionnels normaux ou des choix personnels. L'EF ne souhaite pas discuter de questions personnelles de ressources humaines sur les réseaux sociaux, mais affirme que les personnes partantes méritent une sortie digne.
L'Ethereum Foundation utilise ensuite un thread officiel sur Twitter pour fournir une narration organisationnelle plus claire : réaliser le potentiel d'Ethereum nécessite une alliance de multiples organisations. Au cours de la dernière année, plusieurs organisations se sont jointes pour renforcer la résilience et les capacités de l'écosystème. Parmi les exemples cités par l'EF figurent : ethlabs (annoncé le 23 juin, un laboratoire de R&D à but non lucratif axé sur la prochaine phase d'adoption d'Ethereum et de l'ETH), l'Eth Apps Guild (lancé en avril 2026, axé sur l'adoption réelle d'applications natives Ethereum, notamment dans les marchés émergents), l'Ethereum Economic Zone (lancé en 2026, visant à réduire la fragmentation de l'écosystème via la composabilité synchrone et les preuves à connaissance nulle en temps réel), et Argot (fondé en 2025, un collectif autonome d'ingénieurs et chercheurs mainteneurs de Solidity et des outils de compilation open source).
Ce thread officiel permet de mieux comprendre les changements récents à l'Ethereum Foundation : la Fondation ne se contente pas de pousser des personnes et des projets vers l'extérieur, ni d'abandonner la coordination centrale, mais semble plutôt répartir la feuille de route d'Ethereum entre plusieurs organisations pour une responsabilité partagée.
Conclusion
Ainsi, Glamsterdam ne doit pas être perçu uniquement comme un ensemble d'EIP. C'est une réorganisation technique majeure d'Ethereum avant d'atteindre des débits plus élevés : la question de qui construit le bloc, qui le propose, qui le valide, quelles données doivent être conservées à long terme et quelles ressources doivent coûter plus cher est remise sur la table.
Les mots-clés de la feuille de route technique sont l'ePBS, la BAL et le début d'une tarification multidimensionnelle du Gas ; les mots-clés de la feuille de route organisationnelle sont plus pragmatiques : l'Ethereum Foundation peut-elle maintenir sa capacité de coordination, et les nouvelles organisations extérieures à la Fondation peuvent-elles transformer cette coordination en livraison continue.
Références :
https://forkcast.org/upgrade/glamsterdam/
https://ethereum.org/roadmap/glamsterdam/
https://blog.ethereum.org/2026/05/11/protocol-update-may-26
https://x.com/VitalikButerin/status/2027403360484430122
