La prochaine mise à jour majeure d'Ethereum entre dans sa phase finale.
Selon la feuille de route officielle actuelle d'Ethereum, la mise à niveau Glamsterdam est prévue pour être déployée sur le réseau principal dans la seconde moitié de 2026. Fin juin, elle est entrée dans la phase de test final sur les réseaux de développement, avec des tests continus sur des réseaux de développement multi-clients autour des fonctionnalités clés telles que le PBS intégré, les listes d'accès au niveau des blocs et la reprix du Gas. Cependant, la date d'activation exacte n'est pas encore définitivement fixée.
Dans le même temps, sur les réseaux sociaux, le sujet le plus discuté est sans doute la promesse de performance directe d'un « réseau principal atteignant 10 000 TPS » après la mise à niveau. Mais au-delà de cela, cette mise à niveau reconstruit en profondeur la chaîne de production de blocs et le moteur d'exécution d'Ethereum. L'ampleur et la profondeur des modifications sont telles que la communauté des développeurs la qualifie largement de « plus grande mise à niveau depuis The Merge (la fusion d'Ethereum) ».
Alors, qu'est-ce que cette « Glamsterdam » (combinaison de la mise à niveau de la couche consensus Gloas et de la mise à niveau de la couche exécution Amsterdam), au nom plutôt stylé, modifie exactement ? Comment va-t-elle remédier aux points faibles du passé et quels changements révolutionnaires apportera-t-elle à notre expérience quotidienne sur la chaîne ?
I. Pourquoi est-ce la « plus grande mise à niveau depuis The Merge » ?
Si les précédentes mises à niveau Dencun et Fusaka visaient principalement à préparer le terrain pour la disponibilité des données (Blob) des L2, Glamsterdam recentre les efforts sur la L1, lançant une refonte majeure des performances et de l'architecture de la couche 1.
Cela reflète la réalité sous-jacente de la volonté actuelle d'Ethereum de « rendre la L1 à nouveau grande » : comment permettre à la L1 de traiter plus de transactions, sans que le coût d'exécution des nœuds et les risques de centralisation du réseau n'augmentent en parallèle.
Cependant, pour l'utilisateur lambda, les mises à niveau d'Ethereum sont souvent résumées à une question simple : le Gas sera-t-il moins cher ? Le débit augmentera-t-il ? Mais franchement, la prochaine mise à niveau Glamsterdam ne peut être simplement décrite comme une « baisse des frais » ou une « augmentation de capacité ».
Dans l'ensemble, cette mise à niveau touche plusieurs aspects clés de la base d'Ethereum, y compris qui construit les blocs, comment les transactions sont exécutées, comment les nœuds lisent et synchronisent l'état, et combien de Gas devraient payer les différentes opérations sur la chaîne. Il s'agit essentiellement de redessiner le paradigme fondamental de production et de traitement des blocs d'Ethereum. Selon les détails techniques actuellement dévoilés, les changements principaux les plus notables se concentrent sur trois aspects :
- PBS intégré (ePBS) : restructurer la relation de jeu entre le proposeur de bloc et le constructeur, éliminer la dépendance aux relais externes ;
- Listes d'accès au niveau du bloc (BALs) : fournir une carte d'accès préalable à l'exécution des transactions, ouvrant la voie au traitement parallèle et à une synchronisation plus rapide des nœuds ;
- Reprix du Gas : introduire un modèle de facturation des ressources plus précis pour contrôler l'expansion de l'état dans un environnement à haut débit ;
Premièrement, pour comprendre le PBS intégré, il faut savoir que les blocs sur Ethereum ne sont pas nécessairement soumis directement par le Proposeur. Surtout dans l'architecture MEV-Boost actuelle, la plupart des Proposeurs externalisent le travail de collecte des transactions, d'ordonnancement et de recherche de revenus MEV à des Constructeurs de blocs professionnels, tandis que le Proposeur est principalement responsable de choisir, parmi plusieurs blocs candidats, celui offrant le prix le plus élevé pour le soumettre au réseau.
Cette division du travail, où le « Constructeur assemble et le Proposeur soumet », est le PBS (Proposer-Builder Separation).
Le problème est que ce mécanisme n'est pas entièrement codé dans le protocole de base d'Ethereum – le Proposeur et le Constructeur doivent passer par des logiciels tiers et des services MEV-Boost Relay pour finaliser les offres de bloc, la livraison du contenu et le paiement.
Cela signifie que le Relay doit à la fois s'assurer que le Constructeur finit par publier le bloc complet et empêcher le Proposeur de « tricher » en regardant le contenu du bloc à l'avance et en refusant de payer. Il joue donc un rôle d'« intermédiaire de confiance » fragile et centralisé.
L'ePBS (Enshrined PBS) proposé par l'EIP-7732 vise précisément à résoudre ce point sensible. Il prévoit d'intégrer directement cette relation de jeu dans le protocole de consensus d'Ethereum, supprimant ainsi les relais tiers, faisant du Constructeur un participant natif reconnu par le protocole. Le Constructeur soumet d'abord un engagement de bloc et une offre, le protocèle verrouille automatiquement le paiement correspondant, puis un « Comité de Ponctualité de la Charge Utile (Payload Timeliness Committee) » dédié juge si le Constructeur a publié la charge utile d'exécution à temps.
Cela permet de séparer partiellement le traitement du bloc de consensus et de la charge utile d'exécution, prolongeant la fenêtre de propagation et de traitement de la charge utile d'exécution d'environ 2 secondes à environ 9 secondes. Ces quelques secondes supplémentaires, bien que minimes, sont cruciales pour la scalabilité d'Ethereum – cela signifie que les nœuds auront plus de temps pour recevoir et traiter des blocs plus grands et plus de données Blob, libérant ainsi de l'espace pour augmenter davantage la limite de Gas.
Deuxièmement, une autre percée majeure de Glamsterdam au niveau de la couche d'exécution est l'EIP-7928, qui propose les listes d'accès au niveau du bloc (BALs, Block-Level Access Lists).
Comme on le sait, actuellement, avant de recevoir un bloc, un nœud Ethereum ne peut pas savoir directement depuis le bloc quels comptes chaque transaction va lire, quels contrats et stockages elle va accéder, ni quels états elle va modifier. Il découvre généralement ces dépendances de données au fur et à mesure de l'exécution des transactions.
C'est comme entrer dans un grand entrepôt pour récupérer des marchandises sans avoir de liste complète des emplacements. Le personnel doit chercher tout en traitant, donc pour éviter que deux personnes modifient simultanément le même stock, une grande partie du travail doit être effectuée dans un ordre strictement fixe (séquentiel, en thread unique).
Les listes d'accès au niveau du bloc (BALs) équivalent à fournir une « carte d'accès à l'état » complète pour chaque bloc. Dans l'en-tête du bloc, elles déclarent à l'avance quelles adresses et quels emplacements de stockage (Storage Slots) l'ensemble des transactions du bloc va atteindre, ainsi que le résultat de l'état après exécution des transactions. Grâce à cette carte, les nœuds peuvent, avant l'exécution, déterminer quelles transactions accéderont aux mêmes données et quelles transactions ne sont pas en conflit :
Ainsi, pour les parties non conflictuelles, les nœuds peuvent lire à l'avance les états concernés depuis le disque, et traiter en parallèle une partie de la validation des transactions et du calcul de la racine d'état, sans avoir à tout entasser dans une file d'attente strictement séquentielle. De plus, comme les BALs enregistrent également les changements d'état après l'exécution des transactions, certains nœuds peuvent utiliser ces résultats pour reconstruire l'état lors de la synchronisation et du rattrapage de l'état du réseau, sans avoir à exécuter depuis le début chaque transaction du bloc dans tous les scénarios (l'auteur y voit un concept proche du sharding), permettant à Ethereum de devenir une blockchain à exécution complètement parallèle.
À long terme, c'est donc une clé fondamentale sous-jacente pour que le réseau principal d'Ethereum brise son plafond de performance.
Enfin, le reprix du Gas consiste principalement, via des leviers économiques, à recalibrer en profondeur la tarification du Gas pour plusieurs opérations sur la chaîne.
La raison est que le coût actuel du Gas sur Ethereum ne correspond pas parfaitement à la consommation réelle de ressources des nœuds. Par exemple, un calcul complexe pur, une fois exécuté, ne laisse généralement pas un fardeau durable important aux nœuds. Mais créer un nouveau compte, déployer un contrat intelligent ou écrire un nouvel emplacement de stockage génère des données que tous les nœuds complets du monde doivent conserver de manière permanente.
Dans le passé, les frais pour ces comportements de création d'état ne reflétaient pas entièrement le coût de stockage permanent qu'ils engendraient (explosion de l'état). Si Ethereum maintenait la tarification existante après avoir augmenté la limite de Gas, plus d'espace de bloc pourrait être rapidement transformé en données d'état incontrôlables, finissant par submerger complètement le matériel des nœuds.
L'EIP-8037, déjà confirmé pour faire partie de Glamsterdam, prévoit de restructurer complètement ces règles. Cela inclut la séparation comptable du calcul et de l'état, recalculant les coûts en fonction du volume des nouvelles données d'état ajoutées, séparant le Gas de calcul ordinaire du Gas d'état ; et également le contrôle de l'explosion de l'état, faisant que les applications qui créent beaucoup de nouveaux comptes, déploient de grands contrats redondants ou écrivent fréquemment de nouveaux états verront probablement leurs coûts opérationnels augmenter, tandis que les applications consommant principalement des ressources de calcul instantané, sans augmenter continuellement l'état, auront une structure de coûts plus attractive.
En fin de compte, la réforme du Gas de Glamsterdam ne doit pas être comprise comme une « baisse générale des frais » mais comme une clarification : combien de ressources de calcul instantané une transaction consomme-t-elle vraiment, et quel fardeau de stockage à long terme laisse-t-elle au réseau, puis faire payer différentes opérations d'une manière plus proche de leur coût physique réel.
Dans l'ensemble, ces trois parties, bien que semblant indépendantes, visent en réalité le même objectif ultime : préparer à l'avance l'infrastructure centrale de base pour permettre au réseau principal d'Ethereum d'augmenter encore significativement sa limite de Gas et sa capacité de traitement.
II. Pourquoi ne pas simplement agrandir les blocs ?
Beaucoup pourraient se demander : si c'est trop lent et trop cher, pourquoi ne pas simplement augmenter la limite de Gas, doubler directement la capacité des blocs ?
C'est une question récurrente. Théoriquement, pour augmenter la capacité du réseau principal, la méthode la plus directe est effectivement d'augmenter la quantité de Gas autorisée par bloc. Après tout, plus la limite de Gas est élevée, plus un bloc peut contenir de transactions et de calculs.
Mais la limite de Gas n'est pas un nombre que l'on peut augmenter indéfiniment. Si les blocs deviennent aveuglément plus grands, cela déclenche un effet domino : les nœuds doivent recevoir plus de données, exécuter plus de transactions et calculer de nouveaux états dans le même laps de temps. Si la vitesse de traitement ne suit pas, les nœuds moins performants auront plus de mal à suivre, la propagation et la validation des blocs pourraient être retardées, augmentant finalement les risques de fourche du réseau et de centralisation.
Simultanément, plus de transactions signifient aussi plus de comptes, de contrats et de données de stockage écrits de manière permanente dans la base de données d'Ethereum. Ces données ne disparaissent pas automatiquement à la fin d'une transaction, mais s'accumulent continuellement dans la base de données d'état d'Ethereum, conduisant à une expansion plus rapide de l'état.
Ainsi, la scalabilité d'Ethereum ne fait pas face à un simple problème mathématique, mais doit simultanément résoudre trois problèmes :
- Premièrement, comment laisser plus de temps aux nœuds pour propager et traiter les gros blocs ;
- Deuxièmement, comment réduire les goulots d'étranglement de performance causés par l'exécution séquentielle des transactions ;
- Enfin, comment empêcher qu'un espace de bloc accru ne se transforme rapidement en une expansion incontrôlable de l'état ;
C'est la logique centrale de Glamsterdam : ne pas d'abord augmenter aveuglément la capacité et laisser les nœuds subir la charge, mais d'abord restructurer la façon dont les blocs sont produits, les transactions exécutées et les ressources tarifées, déboucher les tuyaux en profondeur, puis ouvrir naturellement la porte à une augmentation de la capacité du réseau principal.
Parmi ces mesures, l'ePBS, en réorganisant le traitement des blocs à l'intérieur d'un Slot, laisse plus de temps aux nœuds pour propager et valider les gros blocs ; les BALs, en fournissant explicitement les relations d'accès à l'état, améliorent l'efficacité de lecture, d'exécution et de synchronisation des clients ; et le reprix du Gas se charge de limiter la croissance non durable de l'état.
Lors des tests collaboratifs de Glamsterdam en avril 2026, les développeurs principaux ont effectué des tests de charge centrés sur les implémentations multi-clients et ont clairement proposé comme objectif technique post-mise à niveau une limite de capacité crédible d'au moins 200 millions de Gas. Cet objectif s'appuie précisément sur le soutien de base fourni conjointement par l'ePBS, les BALs et le reprix du Gas d'état.
Bien sûr, 200 millions de Gas se rapprochent davantage de la capacité de charge que le système aura après la mise à niveau, et de la direction dans laquelle il pourra évoluer à l'avenir. Cela ne signifie pas que le réseau principal augmentera immédiatement la limite de Gas à ce niveau le jour de l'activation de Glamsterdam.
Ce qui est vraiment important, c'est qu'Ethereum passe d'une « scalabilité prudente et exploratoire » à une « préparation préalable à une scalabilité beaucoup plus importante du réseau principal, via une restructuration de l'architecture de base ».
III. Quels impacts pour les utilisateurs lambda et l'écosystème Ethereum ?
Du point de vue de l'utilisateur lambda, la question la plus importante concernant la mise à niveau Glamsterdam reste celle des frais de transaction : vont-ils baisser ?
Dans l'ensemble, la réponse est plus proche de « ils devraient baisser et devenir plus stables », plutôt que « toutes les transactions deviendront immédiatement moins chères ».
Comme l'ePBS et les listes d'accès au niveau du bloc créent les conditions pour une limite de Gas plus élevée, on peut s'attendre à ce que le nombre de transactions qu'un bloc peut contenir augmente certainement. Donc, si la demande sur la chaîne reste inchangée, l'offre d'espace de bloc augmentant, cela contribuera naturellement à atténuer la congestion et à réduire la probabilité d'une augmentation soudaine des frais de base (Base Fee).
Mais pour une transaction individuelle, les changements peuvent différer selon le type d'opération. Par exemple, les transferts ETH standards pourraient bénéficier de l'optimisation du Gas de base ; et comme les BALs indiquent à l'avance les chemins d'accès à l'état, la précision de l'estimation des frais de Gas par les portefeuilles s'améliorera considérablement. La mauvaise expérience passée où, en raison de la volatilité du marché, l'estimation de Gas par le portefeuille était inexacte, entraînant l'échec de la transaction mais tout de même le prélèvement de frais, appartiendra au passé.
Cependant, les opérations de déploiement de contrats, de création en masse de comptes ou d'écriture de nombreux nouveaux états pourraient voir leurs coûts augmenter en raison du reprix de l'état. Ainsi, le résultat le plus probable de Glamsterdam est une baisse des coûts pour les transactions simples, des frais plus stables en période de congestion, et le fait que les applications intensives en état commencent à payer un prix plus juste pour les ressources réseau qu'elles occupent à long terme.
Pour les utilisateurs principalement sur les L2, cette mise à niveau n'est pas non plus sans rapport. L'ePBS prolonge la fenêtre de propagation des données de la charge utile d'exécution d'environ 2 secondes à environ 9 secondes, ce qui peut non seulement supporter des blocs de réseau principal plus grands, mais laisse aussi plus d'espace pour qu'Ethereum traite plus de données Blob. Une fois la capacité Blob encore élargie, les Rollups auront plus d'espace pour soumettre leurs données de transaction, ce qui, à long terme, aidera à stabiliser les coûts de données des L2.
De plus, pour les portefeuilles, les plateformes d'échange et les ponts inter-chaînes, un changement plus perceptible par les utilisateurs pourrait venir de l'EIP-7708. Actuellement, les transferts de jetons ERC-20 génèrent généralement des journaux (logs) Transfer standardisés, mais certains transferts d'ETH natifs entre contrats intelligents ne laissent pas de traces d'événements aussi claires. Les portefeuilles et les plateformes doivent souvent s'appuyer sur des outils de suivi de transactions internes supplémentaires pour identifier ces flux d'ETH.
L'EIP-7708 exige que les transferts d'ETH non nuls et les opérations de destruction d'ETH génèrent des journaux standard, permettant aux portefeuilles, plateformes d'échange et ponts inter-chaînes d'identifier plus fi ablement les dépôts, retraits et mouvements internes d'ETH dans les contrats. À l'avenir, les relevés d'actifs ETH vus par les utilisateurs pourraient être plus complets, et certains transferts internes qui nécessitaient auparavant un suivi de transaction complexe pour être affichés pourront aussi être plus facilement identifiés directement par les portefeuilles.
Pour les opérateurs de nœuds et les utilisateurs de staking, l'impact est plus direct. Glamsterdam modifie simultanément la façon dont les blocs sont traités au niveau de la couche d'exécution et de la couche de consensus. Par conséquent, les nœuds et les validateurs devront mettre à niveau leurs versions client pour supporter Glamsterdam avant son activation sur le réseau principal. Les utilisateurs détenteurs ordinaires n'auront pas besoin de migrer leurs ETH, ni d'effectuer une quelconque « mise à niveau d'actif » ou « échange de jetons ».
À plus long terme, ce que Glamsterdam influence vraiment, c'est la manière dont Ethereum va retrouver un équilibre entre scalabilité et décentralisation. Après tout, une fois la capacité des blocs augmentée, si le coût matériel nécessaire pour exécuter un nœud augmente de manière significative en parallèle, bien que le débit du réseau principal soit plus élevé, le réseau pourrait devenir de plus en plus dépendant des grandes institutions.
La combinaison ePBS, listes d'accès au niveau du bloc et reprix du Gas d'état tente de former une autre voie de scalabilité : ne pas exiger simplement des nœuds qu'ils traitent plus de travail dans le même laps de temps, mais réorganiser le flux de production des blocs, fournir à l'avance les informations de dépendance des transactions, et faire payer différentes ressources en fonction de leur fardeau réel.
C'est aussi la différence fondamentale entre Glamsterdam et une simple augmentation de la limite de Gas. Elle n'essaie pas de résoudre tous les problèmes d'Ethereum avec un seul EIP, mais transforme simultanément trois mécanismes interconnectés : la production de blocs, l'exécution des transactions et la croissance de l'état.
Pour conclure
À long terme, ce que Glamsterdam influence profondément, c'est la direction narrative d'Ethereum dans sa recherche d'un nouvel équilibre entre « scalabilité haute performance » et « décentralisation absolue ».
C'est aussi l'idée fondamentale ou l'inertie d'Ethereum que nous connaissons de plus en plus – face à la pression croissante des blockchains monolythiques haute performance, ne pas choisir la voie simple et brutale d'augmenter les exigences matérielles, mais choisir un chemin visant à maintenir autant que possible sa couleur décentralisée et sa résilience fondamentale. Comme cette fois, à travers la combinaison de la réécriture de la chaîne de production de blocs (ePBS), de la fourniture explicite et préalable des dépendances des transactions (BALs), et du paiement précis des ressources selon leur fardeau physique (reprix du Gas), il s'agit toujours de dégager, en garantissant que des personnes ordinaires puissent exécuter des nœuds et participer à la validation, une capacité de réseau principal plus vaste.
De ce point de vue, chaque frais de Gas avantageux que nous paierons à l'avenir, chaque relevé interne d'ETH plus précis et clair dans notre portefeuille, chaque espace potentiel de baisse des frais sur les L2, bénéficieront peut-être profondément des fondations que Glamsterdam, dans la seconde moitié de 2026, aura reposées pour Ethereum.
