Glamsterdam arrive : ce que pourrait apporter la prochaine grande mise à jour d'Ethereum

Ethereum continue d'évoluer vers un réseau plus scalable, plus efficace et mieux préparé à un usage institutionnel croissant. Après Pectra et Fusaka, le prochain grand axe de la roadmap est Glamsterdam, une mise à jour qui regroupe des changements importants à la fois sur la couche d'exécution et sur la couche de consensus.

Glamsterdam combine deux axes de travail : Amsterdam, lié à l'execution layer, et Gloas, centré sur la consensus layer. Comme pour tout hard fork d'Ethereum, son périmètre peut encore évoluer au fil des discussions, des tests et de la coordination entre clients. Malgré cela, les propositions actuellement sur la table permettent déjà de comprendre la direction que prend le réseau.

L'objectif n'est pas seulement d'ajouter de nouvelles fonctionnalités, mais d'améliorer des parties clés de l'infrastructure d'Ethereum : production de blocs, efficacité d'exécution, soutenabilité de l'état, performance des clients et opérations des validateurs.

Glamsterdam arrive à un moment important pour Ethereum. Le réseau doit continuer à augmenter sa capacité sans compromettre ses propriétés fondamentales : sécurité, décentralisation, résilience et vérifiabilité.

Ces dernières années, Ethereum a progressivement séparé les responsabilités et optimisé différentes couches du protocole. The Merge a changé le mécanisme de consensus ; Dencun a introduit les blobs pour améliorer la scalabilité des L2 ; Pectra a étendu des capacités liées aux comptes, aux validateurs et à l'expérience utilisateur ; et Fusaka poursuit cette trajectoire d'optimisation.

Glamsterdam vise une dimension particulièrement sensible : la manière dont les blocs sont construits, la manière dont l'état est consulté, la façon dont les clients se préparent à des limites de gas plus élevées et l'amélioration des opérations de validateurs dans des scénarios plus exigeants.

Le travail sur Glamsterdam a déjà avancé à travers des devnets et des interops dédiés. Pendant le Soldøgn Interop, les équipes Ethereum ont travaillé sur les tests d'ePBS avec des builders externes, l'optimisation des Block-Level Access Lists et la définition de paramètres de repricing comme base pour un possible gas limit floor de 200M après Glamsterdam. Cet objectif dépend encore des décisions finales des All Core Devs, mais il montre une direction claire : plus de capacité d'exécution sans perdre de vue les limites opérationnelles des clients.

L'une des propositions les plus importantes de Glamsterdam est ePBS, ou enshrined Proposer-Builder Separation, décrite dans EIP-7732.

Aujourd'hui, la séparation entre proposer et builder existe principalement via une infrastructure externe. Avec ePBS, Ethereum cherche à intégrer cette séparation directement dans le protocole, en réduisant les dépendances externes et en rendant plus explicite le rôle de chaque acteur dans la production des blocs.

En termes simples, ePBS sépare plus clairement deux fonctions :

• qui propose le bloc ;
• qui construit le contenu du bloc.

Cela peut contribuer à améliorer la neutralité, la transparence et la robustesse du processus de construction des blocs. Pour les opérateurs de validateurs, cela implique aussi de suivre de près de nouvelles responsabilités, les temps de coordination et de possibles changements dans la gestion des slots.

Pour les institutions qui font du staking, ePBS est important parce qu'il touche une partie critique d'Ethereum : la manière dont le bloc qui entre finalement dans la chaîne est produit. Ce n'est pas une amélioration cosmétique, mais une évolution de l'architecture qui soutient le fonctionnement quotidien du réseau.

Un autre élément important de Glamsterdam concerne les Block-Level Access Lists, définies dans EIP-7928.

Les Block-Level Access Lists permettent de décrire quels comptes et quelles parties de l'état seront consultés pendant l'exécution d'un bloc. Cela peut aider les clients à mieux préparer l'accès aux données, améliorer l'efficacité d'exécution et ouvrir la voie à davantage de parallélisation.

En pratique, cette proposition vise à permettre à Ethereum de traiter les blocs plus efficacement. Si le réseau veut progresser vers des limites de gas plus élevées, les clients ont besoin de meilleurs outils pour gérer l'accès à l'état et réduire les goulots d'étranglement.

C'est pourquoi les Block-Level Access Lists ne doivent pas être vues comme une amélioration isolée. Elles font partie d'un ensemble plus large de changements destinés à aider Ethereum à augmenter sa capacité d'exécution de manière plus soutenable.

L'un des grands défis d'Ethereum est la croissance de l'état. Chaque nouveau compte, contrat ou donnée persistante augmente la charge que les nœuds doivent stocker et traiter.

Glamsterdam inclut des propositions comme EIP-8037, centrée sur l'ajustement des coûts liés à la création d'état, et EIP-8038, orientée vers la mise à jour des coûts d'accès à l'état.

L'idée de fond est simple : si certaines opérations génèrent une charge permanente plus lourde pour le réseau, leur coût doit mieux refléter cet impact.

Ce type de changement est particulièrement important pour la santé à long terme d'Ethereum. Un réseau plus efficace ne dépend pas seulement de sa capacité à traiter plus de transactions, mais aussi de sa capacité à le faire sans dégrader la capacité des nœuds à rester synchronisés, vérifier l'état et participer au réseau avec fiabilité.

Glamsterdam inclut également des propositions qui affectent directement les opérations des validateurs.

L'une d'elles est EIP-8061, qui vise à augmenter l'exit churn et le consolidation churn afin d'améliorer la capacité du protocole à traiter les sorties et les consolidations. Cette ligne de travail est particulièrement importante pour les opérateurs et les institutions, car elle touche directement aux délais de sortie, à la gestion de la liquidité opérationnelle et à la capacité de réponse face à des changements de marché ou à des événements défavorables.

EIP-8045 reste également en discussion. Elle vise à éviter que des validateurs slashed continuent d'être sélectionnés pour proposer des blocs dans des scénarios où ces blocs seraient invalides. La proposition a été resserrée au cours du travail sur Glamsterdam, il convient donc de la comprendre comme une amélioration de résilience en évolution, et non comme une règle finale totalement arrêtée.

Pour les opérateurs de validateurs, ces propositions comptent parce qu'elles touchent des processus très concrets : sorties, consolidations, sélection des proposers, gestion des risques et réponse aux incidents.

Glamsterdam est encore en développement, mais plusieurs domaines doivent déjà être suivis de près par les opérateurs de validateurs.

Le premier est la compatibilité des clients. Chaque hard fork exige une coordination entre les équipes des execution clients et des consensus clients, et tout changement dans la production des blocs ou l'accès à l'état peut avoir des implications opérationnelles.

Le deuxième est la gestion de l'infrastructure. Si Ethereum avance vers des limites de gas plus élevées, les opérateurs devront revoir les exigences matérielles, la performance des nœuds, le monitoring, les latences et la capacité de réponse.

Le troisième est la gestion du risque. Les changements liés à ePBS, au churn ou au slashing peuvent affecter la manière dont les processus internes, les alertes et les playbooks opérationnels sont conçus.

Dans le staking institutionnel, ces détails comptent. Il ne suffit pas d'avoir des validateurs actifs ; il faut opérer avec des procédures claires, un monitoring constant et une capacité d'adaptation aux changements du protocole.

Pour les institutions, fonds, custodians ou entreprises qui délèguent de l'ETH, Glamsterdam est aussi l'occasion d'évaluer la qualité de leur fournisseur de staking.

Certaines questions importantes sont :

• si le fournisseur suit de près les discussions des All Core Devs et le périmètre final de chaque hard fork ;
• comment les mises à jour des clients sont préparées avant mainnet ;
• quels processus de test et de monitoring sont utilisés ;
• comment les risques liés au slashing, aux missed slots et à la performance des validateurs sont gérés ;
• quelle expérience le fournisseur possède dans l'opération d'infrastructure sur des réseaux en évolution.

Ethereum n'est pas un réseau statique. Chaque mise à jour exige des capacités techniques, de la coordination et du jugement opérationnel. Pour une institution, choisir un fournisseur de staking signifie faire confiance à une équipe capable de s'adapter à ce rythme sans improviser.

Chez Stakely, nous opérons de l'infrastructure blockchain sur plusieurs réseaux et nous suivons de près les mises à jour qui affectent les validateurs, les nœuds et le staking institutionnel.

Glamsterdam est important parce qu'il touche plusieurs couches critiques d'Ethereum : production de blocs, accès à l'état, efficacité des clients et opérations des validateurs. Ce n'est pas simplement une mise à jour technique supplémentaire, mais une évolution qui peut influencer la manière dont Ethereum est opéré à grande échelle.

Pour nous, suivre ces améliorations dès les premières phases fait partie du travail nécessaire pour opérer une infrastructure avec rigueur. Comprendre les changements avant leur arrivée sur mainnet permet de préparer les clients, d'ajuster les processus internes et de mieux accompagner ceux qui font confiance à Ethereum comme réseau de staking.

Ethereum continuera d'évoluer. Et chaque mise à jour majeure rappelle une idée essentielle : le staking ne consiste pas seulement à déléguer de l'ETH, mais à s'appuyer sur une infrastructure prête à soutenir le réseau sur le long terme.

Si vous souhaitez faire du staking d'ETH avec un opérateur européen spécialisé dans l'infrastructure blockchain, vous pouvez en savoir plus sur notre solution de staking Ethereum avec Stakely.