Pourquoi Glamsterdam pourrait être l’une des mises à niveau les plus importantes après le Merge d’Ethereum ?
Article : KarenZ, Foresight News
La mise à niveau Glamsterdam d’Ethereum est la plus facilement mal interprétée comme une nouvelle itération technique visant simplement à augmenter le débit. Plus précisément : elle réordonne la manière de produire les blocs, le processus de validation et la tarification des ressources, afin de poser les bases pour une limite de Gas plus élevée, une capacité de blobs plus grande et une exécution parallèle à l’avenir.
Au 23 juin 2026, ethereum.org a indiqué que Glamsterdam est marqué comme une mise à niveau prévue pour la seconde moitié de 2026. Le nom de Glamsterdam vient de la combinaison de la mise à niveau Amsterdam côté couche d’exécution et de la mise à niveau Gloas côté couche de consensus. La feuille de route officielle le place après Fusaka en décembre 2025 et avant Hegotá, et précise deux fonctions principales : la séparation proposer-builder “in-protocol”, c’est-à-dire ePBS, et les listes d’accès au niveau du bloc, à savoir BAL.
Qui propose, qui construit : ePBS inscrit la répartition de production dans le protocole
Aujourd’hui, la production d’un bloc sur Ethereum ressemble à une passation de relais avec un timing très serré : les uns sont responsables de proposer le bloc, les autres de construire le contenu des transactions, et au milieu, on dépend encore d’infrastructures hors protocole comme MEV-Boost et des relais tiers (relay).
Ce mécanisme fonctionne depuis des années. Il place une partie de la relation de confiance hors du protocole, et permet aussi aux validateurs de traiter simultanément, sur une fenêtre de temps très courte, des tâches comme le consensus, l’exécution et la disponibilité des données.
L’une des plus grandes évolutions de Glamsterdam est EIP-7732, à savoir ePBS (Enshrined Proposer-Builder Separation). Il inscrit dans le protocole la séparation des rôles entre proposer et builder.
En bref : le proposer est responsable de choisir le bloc de consensus, et le builder prépare le contenu des transactions qui s’y trouvent. Le builder ne peut pas se contenter de promettre verbalement : il doit d’abord “déposer un engagement” dans le protocole—préciser quel bloc d’exécution il livrera et combien il est prêt à payer au proposer ; ensuite, le Payload Timeliness Committee (PTC, comité de ponctualité des charges utiles) vérifie s’il respecte les délais de livraison.
Le point clé de cette modification n’est pas seulement de réduire la dépendance aux relais tiers : c’est aussi de gagner du temps pour la propagation des blocs et leur validation.
Aujourd’hui, les validateurs doivent traiter simultanément le consensus et l’exécution dans une fenêtre critique très courte. ePBS sépare ces deux tâches, de sorte que la charge d’exécution puisse être révélée et validée plus tard. D’après la conception de EIP-7732, la fenêtre de diffusion de la charge d’exécution—c’est-à-dire le temps pendant lequel les données se diffusent sur le réseau et sont reçues par les nœuds—peut passer d’environ 2 secondes à environ 9 secondes. Avec une fenêtre plus longue, lorsqu’Ethereum augmente la capacité des blocs, il y a moins de risques de “perdre des votes” ou de devoir faire une réorganisation à cause du fait que les nœuds n’auraient pas eu assez de temps pour télécharger, valider et voter.
L’impact direct pour les utilisateurs ordinaires n’est peut-être pas très visible, mais il est crucial pour le redimensionnement d’Ethereum. Une fenêtre plus longue de diffusion et de validation signifie que le réseau peut traiter des charges plus importantes de manière plus sûre. Dans un rapport du 16 juin 2026, CoinDesk cite ce que dit un ingénieur DevOps de la Fondation Ethereum, Parithosh Jayanthi : Glamsterdam pourrait être l’une des plus grandes fourches depuis le Merge, et changer de nombreuses hypothèses sur Ethereum, tout en préparant le terrain pour un redimensionnement à plus grande échelle à l’avenir.
BAL et re-tarification : redimensionner, ce n’est pas seulement appuyer sur l’accélérateur, il faut aussi s’occuper de la base de données
Une autre modification clé de Glamsterdam est EIP-7928 : Block-Level Access Lists, c’est-à-dire les listes d’accès au niveau du bloc.
On peut le comprendre comme le fait d’associer à chaque bloc une “trace d’accès” : quels comptes, quelles positions de stockage ce bloc a rencontrés pendant son exécution, et quel état pertinent en résulte ensuite. Tout doit être consigné. Ainsi, lorsqu’un nœud traite un bloc, il n’a plus l’impression de “tirer au hasard” (boîte aveugle) et peut savoir plus tôt quelles données doivent être lues et quelles opérations peuvent être parallélisées.
Les EIP-2930 précédents avaient déjà introduit des listes d’accès au niveau des transactions, mais elles étaient optionnelles et leur utilisation restait limitée. La différence de l’EIP-7928 est qu’elle élève la liste d’accès au niveau du bloc : le header de bloc conserve cette “empreinte” (enregistrement par hachage), et la charge d’exécution stocke la liste complète. Lorsqu’un nœud exécute un bloc, il vérifie si les traces d’accès consignées dans la liste correspondent réellement au déroulement de l’exécution du bloc ; si ça ne correspond pas, le bloc est invalide.
Pourquoi est-ce important ? Aujourd’hui, lors de l’exécution de transactions sur Ethereum, de nombreux accès aux données ne sont connus qu’une fois qu’on arrive réellement à ce point d’exécution. Les nœuds ne savent pas si un lot de transactions lira et modifiera simultanément le même compte ou le même slot de stockage, ce qui rend la parallélisation difficile à exécuter en toute confiance. BAL revient à rendre explicite les trajectoires d’accès pendant l’exécution d’un bloc, ce qui permet aux clients d’effectuer des lectures disque en parallèle, des validations de transactions en parallèle, et des calculs de racine d’état en parallèle. Dans certains scénarios, cela permet même de rejouer partiellement des transactions et de mettre à jour l’état. Ce n’est pas un bouton qui fait baisser directement les frais pour les utilisateurs ; c’est une ouverture d’espace d’ingénierie pour permettre la parallélisation côté clients.
Mais la logique de redimensionnement de Glamsterdam ne se limite pas à “élargir la route”. Elle vise aussi à maîtriser l’expansion durable de la base de données d’Ethereum. 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 sur le long terme, par exemple les nouveaux comptes, les nouveaux contrats et les nouveaux slots de stockage. L’exécution d’une transaction s’arrête ensuite, mais l’état reste dans le grand livre que tous les nœuds doivent maintenir. Si l’état croît trop vite, exécuter un nœud devient de plus en plus coûteux, et la décentralisation en pâtira progressivement.
Les chiffres de contexte fournis par EIP-8037 sont très parlants : au 1er janvier 2026, une base de données de nœud Geth dédiée à l’état pèse environ 390 GiB ; après l’augmentation de la limite de Gas du mainnet de 30 millions à 60 millions, le nouvel état par jour passe d’environ 105 MiB à environ 326 MiB, soit une croissance annuelle équivalente 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, et dépasser en moins d’un an le seuil de dégradation des performances de 650 GiB.
L’objectif de EIP-8037 est donc de séparer la tarification de la “computation temporaire” et de la “occupation permanente de base de données”. Créer un nouvel état coûtera plus cher, parce que ce n’est pas seulement un coût de calcul ponctuel pour le réseau, mais une charge de stockage durable.
Vitalik Buterin a aussi mentionné, dans son explication de la feuille de route de Glamsterdam pour le redimensionnement, que Glamsterdam séparerait le coût de création d’état entre les coûts d’exécution et de calldata : l’objectif est d’augmenter davantage la capacité d’exécution, sans que la taille de l’état n’explose au même rythme.
En les regardant ensemble, BAL facilite la gestion en parallèle des blocs par les nœuds : c’est la solution au “faire plus vite”. La nouvelle tarification de la création d’état fait payer plus cher les opérations qui occupent durablement la base de données : c’est la solution au “ne pas gonfler de plus en plus le grand livre”. Le redimensionnement de Glamsterdam ne consiste pas simplement à augmenter le Gas limit : il pose une question plus réaliste—Ethereum peut-il accueillir plus de transactions tout en évitant que la diffusion des blocs, la validation des transactions et le stockage de l’état ne deviennent incontrôlables ?
La liste des EIP de Glamsterdam se dessine : qu’est-ce qui est déjà arrêté, et qu’est-ce qui attend encore ?
Au 23 juin 2026, d’après les éléments suivis sur Forkcast concernant les mises à niveau d’Ethereum, les développeurs d’Ethereum testent actuellement Glamsterdam dans des environnements devnets. Le 3 août, la mise à niveau sera lancée sur Sepolia, et le 16 septembre sur le mainnet (les dates exactes peuvent évoluer).
Il y a 10 EIP prévus pour être inclus dans la liste Glamsterdam :
EIP-7708 (le virement ETH déclenchera aussi un journal, ce qui facilite l’indexation et le suivi des transferts natifs d’ETH)
EIP-7732 (ePBS : intégrer dans le protocole la séparation entre proposer et builder afin de réduire la dépendance aux relais (relay) externes)
EIP-7778 (suppression de la comptabilisation du Gas des blocs liée au Gas refund, pour simplifier le calcul du Gas au niveau du bloc)
EIP-7843 (ajout de l’opcode SLOTNUM pour que les contrats puissent lire le numéro de slot courant)
EIP-7928 (liste d’accès au niveau du bloc BAL : consigne les comptes et positions de stockage qui ont été accédés lors de l’exécution du bloc, ouvrant la voie à la vérification en parallèle)
EIP-7954 (augmentation de la limite maximale de taille de contrat, permettant des bytecodes de contrat plus importants)
EIP-7976 (augmentation du coût plancher de la calldata, ajustement du coût minimal de la calldata)
EIP-7981 (augmentation du coût des listes d’accès : recalibrage de la tarification en Gas des access lists)
EIP-8024 (opcodes SWAPN, DUPN, EXCHANGE rétrocompatibles, renforçant les capacités des opérations de pile EVM)
EIP-8037 (augmentation du coût en Gas de création d’état, freinant l’expansion trop rapide de la base de données d’état)
Ces EIP peuvent grossièrement être classés en trois catégories : la première concerne la refonte des processus de production de blocs et de validation, avec EIP-7732 et EIP-7928 au cœur ; la deuxième concerne des ajustements de tarification des ressources, incluant EIP-7778, EIP-7976, EIP-7981 et EIP-8037 ; la troisième concerne des modifications de l’EVM et de l’expérience développeur, incluant EIP-7708, EIP-7843, EIP-7954 et EIP-8024.
Autrement dit, Glamsterdam n’améliore pas seulement un point de fonctionnalité : il met à jour en même temps la répartition de la production de blocs, la validation en parallèle, la tarification du Gas et la disponibilité de l’EVM.
Une autre série d’EIP reste encore dans la liste “à envisager pour inclusion” :
EIP-2780 (Gas intrinsèque (intrinsic Gas) scindé selon les ressources)
EIP-7610 (rollback lors de la création d’un contrat depuis un compte de stockage non vide)
EIP-7688 (structure de données de couche de consensus pensée pour la compatibilité future)
EIP-7904 (analyse du coût du Gas, potentiellement retirée de Glamsterdam)
EIP-7975 (eth/70, une partie des listes de reçus de blocs)
EIP-7997 (contrats de fabrique déterministes)
EIP-8038 (mise à jour des coûts en Gas d’accès à l’état)
EIP-8045 (exclure les validateurs déjà pénalisés qui continuent à proposer des blocs)
EIP-8061 (augmentation du churn lors de la sortie et de la fusion)
EIP-8070 (eth/72, Sparse Blobpool)
EIP-8080 (permettre d’utiliser une consolidation queue pour les sorties)
EIP-8136 (delatas au niveau des cellules pour la diffusion de données)
EIP-8159 (eth/71, échange de listes d’accès de blocs)
EIP-8246 (suppression du burn de SELFDESTRUCT)
EIP-8282 (Builder Execution Requests : fournir aux builders ePBS des demandes d’enregistrement et de sortie dédiées)
Par ailleurs, Forkcast liste actuellement aussi EIP-8254 (limiter le nombre de deposit requests dans chaque bloc de couche d’exécution à 8192) dans la liste “à envisager pour inclusion”.
Du point de vue des stakers, il faut surtout s’intéresser aux EIP-8061 et EIP-8080 figurant sur la liste. Pour les stakers, cela signifie que la liquidité lors des sorties pourrait s’améliorer. Dans un article du 5 mai 2026, Figment affirme que les stakers institutionnels doivent particulièrement surveiller ePBS, EIP-8061 et EIP-8080. En estimant qu’au 4/2026 le volume de staking s’élevait à environ 38,9 millions d’ETH, Figment indique que 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 “ordinaires” d’exploiter la marge de la file de fusion via une consolidation queue. Figment rappelle en même temps que tous les chiffres avant le lancement sur le mainnet doivent être considérés comme spéculatifs.
Source : Figment
Mise à niveau du protocole, et changements aussi au sein de la Fondation
La préparation technique de Glamsterdam et les changements RH dans le “Protocol cluster” de la Fondation Ethereum se sont presque produits en même temps. Dans son billet du 11 mai 2026 sur le blog, la Fondation Ethereum indique que Glamsterdam a atteint plusieurs jalons : une limite plancher de 200 millions de Gas mise en place comme objectif fiable post-Glamsterdam, ePBS fonctionnant de façon stable sur le Glamsterdam devnet multi-clients, et EIP-8037 finalisé.
Le même article annonce aussi la passation à la tête du Protocol cluster : Will Corcoran, Kev Wedderburn et Fredrik deviendront de nouveaux coordinateurs du cluster de protocole. L’ancien coordinateur Barnabé Monnot et Tim Beiko quittent la Fondation Ethereum, et Alex Stokes est en congé.
La description des responsabilités pour trois nouveaux coordinateurs est la suivante : Will Corcoran dispose d’une expérience de coordination entre équipes ; Kev Wedderburn dirige l’équipe zkEVM ; Fredrik dirige Protocol Security et le projet Trillion Dollar Security.
Ces changements ne se sont pas limités à l’équipe protocolaire. Le 18 juin 2026, Hsiao-Wei Wang a publié un billet indiquant qu’après une période de congé, il/elle avait décidé de démissionner de ses fonctions de co-directeur exécutif et de membre du conseil d’administration de la Fondation Ethereum.
L’ancien chercheur de la Fondation Ethereum, Dankrad Feist, a déclaré le 19 juin 2026 que ceux qui quittent l’EF sont des croyants de CROPS (anti-censure et anti-capture, open source, confidentialité, sécurité). Le problème ne serait pas la stratégie, mais la gestion—et il estime que ce flux de talents vers l’extérieur est plutôt négatif pour Ethereum. Azeem, cofondateur de Miden, interprète la situation dans l’autre sens : selon lui, l’EF aurait du mal à se transformer d’elle-même ; après un départ de talents, il pourrait se créer une nouvelle organisation capable d’exécuter davantage la feuille de route d’Ethereum, ce qui serait au final un avantage net à long terme pour l’écosystème.
Le discours des initiés de la Fondation Ethereum ressemble davantage à un ajustement des frontières. La directrice exécutive adjointe intérimaire de la Fondation Ethereum, Bastian Aue (Aerugo), a répondu : les raisons de départ des membres de la Fondation Ethereum incluent des divergences stratégiques, l’adéquation à un poste, des changements organisationnels normaux ou des choix personnels. L’EF ne discutera pas de questions personnelles de ressources humaines sur les réseaux sociaux, mais indique que les personnes qui quittent l’organisation devraient avoir une sortie digne.
La Fondation Ethereum a ensuite fourni une narration organisationnelle plus claire via un thread Twitter officiel : pour réaliser le potentiel d’Ethereum, plusieurs organisations doivent former une alliance. Au cours de la dernière année, plusieurs organisations ont déjà renforcé ensemble la résilience et les capacités de l’écosystème. Les exemples donnés par l’EF incluent ethlabs (un laboratoire de R&D à but non lucratif axé sur l’adoption de la prochaine étape d’Ethereum et d’ETH), annoncé le 23 juin ; Eth Apps Guild (orientée vers l’adoption réelle des applications natives d’Ethereum, en particulier en se concentrant sur les marchés émergents), lancée en avril 2026 ; Ethereum Economic Zone (objectif : réduire la fragmentation de l’écosystème via la combinabilité synchronisée et des preuves ZK temps réel) ; et Argot (un collectif autonome d’ingénieurs et de chercheurs chargé de maintenir des outils autour de Solidity et des compilateurs open source), fondé en 2025.
Ce thread officiel rend plus facile la compréhension des changements récents de la Fondation Ethereum : la Fondation ne pousse pas seulement des personnes et des projets vers l’extérieur, et n’abandonne pas la coordination centrale ; elle pourrait plutôt découper la feuille de route d’Ethereum pour qu’elle soit assumée conjointement par davantage d’organisations.
Résumé
Ainsi, Glamsterdam ne devrait pas être considéré uniquement comme un ensemble d’EIP. C’est un réagencement d’ingénierie d’Ethereum avant d’atteindre un débit plus élevé : qui construit des blocs, qui propose, qui valide, quelles données doivent être conservées à long terme et quelles ressources doivent coûter plus cher—tout est remis sur la table.
Les mots-clés de la trajectoire technique sont ePBS, BAL et le début d’un modèle de Gas multidimensionnel ; côté organisationnel, les mots-clés sont plus concrets : est-ce que la Fondation Ethereum peut conserver sa capacité de coordination, et est-ce que les nouvelles organisations en dehors de la Fondation pourront transformer cette capacité en livraison continue.
Référence :
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