Article par:imToken
La prochaine grande mise à niveau d'Ethereum entre dans sa phase finale.
Selon la feuille de route actuelle de la fondation 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 en phase de test final sur les réseaux de développement, avec des tests continus sur le réseau 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 revalorisation du Gas. Cependant, la date d'activation exacte n'est pas encore définitivement arrêtée.
Dans le même temps, sur les réseaux sociaux, le sujet de discussion le plus brûlant est sans aucun doute la promesse de performance intuitive de « plus de 10000 TPS sur le réseau principal » après la mise à niveau. Mais au-delà de cela, cette mise à niveau opère une refonte en profondeur de la chaîne de production de blocs et du moteur d'exécution d'Ethereum. L'ampleur des modifications et leur portée sont telles que la communauté des développeurs la qualifie généralement de « plus grande mise à niveau depuis The Merge (la fusion d'Ethereum) ».
Alors, que change exactement cette mise à niveau au nom plutôt stylé, « Glamsterdam » (combinaison des mises à niveau de la couche consensus Głas et de la couche exécution Amsterdam) ? Comment va-t-elle remédier aux points faibles du passé, et quels changements radicaux va-t-elle apporter à notre expérience quotidienne sur la chaîne ?
I. Pourquoi s'agit-il de « la plus grande mise à niveau depuis la fusion » ?
Si les mises à niveau précédentes comme Dencun et Fusaka visaient principalement à préparer le terrain pour la disponibilité des données (Blob) des L2, Glamsterdam recentre l'attention sur la L1, déclenchant une grande révision des performances et de l'architecture de la couche 1.
Ceci 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 généralement résumées à une question très simple : le Gas va-t-il devenir moins cher ? Le débit va-t-il augmenter ? Pour être honnête, la mise à niveau Glamsterdam à venir est difficile à résumer par une simple « baisse des frais » ou « augmentation de la capacité ».
Dans l'ensemble, cette mise à niveau touche plusieurs liens clés de la base d'Ethereum, incluant 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 en somme de redessiner le paradigme fondamental de production et de traitement des blocs d'Ethereum. Selon les détails techniques actuellement divulgués, les changements centraux les plus notables se concentrent sur trois aspects :
- PBS intégré (ePBS) : Refonte des relations de jeu entre le proposeur et le constructeur de blocs, éliminant la dépendance aux relais externes ;
- Listes d'accès au niveau des blocs (BALs) : Fournir une carte d'avance pour l'exécution des transactions, ouvrant la voie au traitement parallèle et à une synchronisation plus rapide des nœuds ;
- Revalorisation du Gas : Introduction d'un modèle de tarification des ressources plus précis pour contrôler l'expansion de l'état dans des environnements à haut débit ;
Tout d'abord, pour comprendre le PBS intégré, il faut savoir que les blocs sur Ethereum ne sont pas nécessairement soumis personnellement par le Proposeur. Surtout dans l'architecture MEV-Boost actuelle, la grande majorité des Proposeurs externalisent le travail de collecte des transactions, d'ordonnancement et de recherche de bénéfices MEV à des Constructeurs de blocs professionnels. Le Proposeur est principalement responsable de choisir, parmi plusieurs blocs candidats, celui avec l'offre la plus élevée pour le soumettre au réseau.
Cette division du travail – « le Constructeur assemble, le Proposeur soumet » – est le PBS (Séparation Proposeur-Constructeur).
Le problème est que ce mécanisme n'est pas actuellement intégralement inscrit dans le protocole de base d'Ethereum – le Proposeur et le Constructeur doivent passer par des logiciels tiers extérieurs au protocole et des services de Relais MEV-Boost pour finaliser les offres de blocs, la livraison du contenu et le paiement.
Cela signifie que le Relais doit à la fois s'assurer que le Constructeur publie finalement le bloc complet, et empêcher le Proposeur de « tricher » en regardant le contenu du bloc à l'avance puis en refusant de payer. Il joue donc le rôle fragile et centralisé d'« intermédiaire de confiance ».
Et l'ePBS (Enshrined PBS) proposé par l'EIP-7732 vise précisément à résoudre ce point faible. Il prévoit d'intégrer directement ce jeu de relations dans le protocole de consensus d'Ethereum lui-même, supprimant directement les relais tiers, faisant du Constructeur un participant reconnu nativement par le protocole. Le Constructeur soumet d'abord un engagement de bloc et une offre, le protocole verrouille automatiquement le paiement correspondant, puis un « Comité de ponctualité de la charge utile (Payload Timeliness Committee) » spécifique juge si le Constructeur a publié la charge utile d'exécution à temps.
Cela permettrait 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 peuvent sembler minimes, mais elles sont cruciales pour la scalabilité d'Ethereum – cela signifie que les nœuds disposent de 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.
Ensuite, une autre avancée majeure de Glamsterdam au niveau de la couche d'exécution est l'introduction des listes d'accès au niveau des blocs (BALs, Block-Level Access Lists) proposée par l'EIP-7928.
Comme on le sait, actuellement, avant de recevoir un bloc, un nœud Ethereum ne peut pas directement déduire du bloc quels comptes chaque transaction va lire, quels stockages de contrats elle va accéder, ou 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, et pour éviter que deux personnes ne modifient simultanément le même stock, une grande partie du travail doit être effectuée dans un ordre fixe strict (séquentiel à un seul fil).
Les listes d'accès au niveau des blocs (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) seront touchés par l'ensemble des transactions du bloc, ainsi que les résultats de l'état après l'exécution des transactions. Grâce à cette carte, un nœud peut voir d'un coup d'œil avant l'exécution quelles transactions accéderont aux mêmes données et lesquelles ne se chevauchent pas :
Ainsi, pour les parties non conflictuelles, le nœud peut lire à l'avance l'état concerné depuis le disque, traiter en parallèle une partie de la validation des transactions et du calcul de la racine de l'état, sans avoir à tout entasser dans une file 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 de la remontée de l'état du réseau, sans avoir à exécuter de zéro chaque transaction du bloc dans tous les scénarios (l'auteur comprend personnellement que cela s'apparente à une logique de fragmentation), faisant d'Ethereum une blockchain à exécution entièrement 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, la revalorisation du Gas consiste principalement, via un levier économique, à 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 totalement à la consommation réelle de ressources supportée par les nœuds. Par exemple, un calcul complexe purement exécutif ne laisse généralement pas de fardeau à long terme important pour les nœuds une fois terminé. En revanche, 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 entraînaient (explosion de l'état). Si Ethereum maintient les prix d'origine après avoir augmenté la limite de Gas, davantage d'espace bloc pourrait être rapidement transformé en données d'état incontrôlables, finissant par écraser complètement le matériel des nœuds.
Et l'EIP-8037, déjà confirmé dans le périmètre de Glamsterdam, prévoit de restructurer complètement ces règles. Cela inclut la séparation de la facturation entre calcul et é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 ; ainsi que le contrôle de l'explosion de l'état, de sorte que les applications qui créent un grand nombre de nouveaux comptes, déploient des contrats redondants volumineux ou écrivent fréquemment de nouveaux états verront probablement leurs coûts d'opération augmenter. En revanche, les applications qui consomment principalement des ressources de calcul immédiates et n'augmentent pas continuellement l'état auront une structure de coût plus attractive.
En fin de compte, la réforme du Gas de Glamsterdam ne doit pas être comprise de manière simpliste comme une « baisse générale des frais ». Il s'agit de clarifier combien de ressources de calcul immédiates une transaction consomme réellement, et quel fardeau de stockage à long terme elle laisse au réseau, puis de faire payer différentes opérations selon des modalités plus proches du coût physique réel.
Dans l'ensemble, ces trois parties semblent indépendantes, mais elles visent en réalité le même objectif ultime : transformer à l'avance les infrastructures de base sous-jacentes pour permettre au réseau principal d'Ethereum d'augmenter encore considérablement la limite de Gas et sa capacité de traitement.
II. Pourquoi ne pas simplement agrandir les blocs ?
Beaucoup se demandent peut-être : 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. En théorie, pour augmenter la capacité du réseau principal, la méthode la plus directe est effectivement d'augmenter la limite 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 le nouvel état dans le même laps de temps. Si la vitesse de traitement ne suit pas, les nœuds avec des configurations plus faibles 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.
Parallèlement, plus de transactions signifient aussi plus de données de comptes, de contrats et de stockage écrites de manière permanente dans la base de données d'Ethereum. Ces données ne disparaissent pas automatiquement à la fin de la transaction, mais s'accumulent continuellement dans la base de données d'état d'Ethereum, entraînant une expansion plus rapide de l'état.
Donc, la scalabilité d'Ethereum ne relève pas d'un simple problème mathématique, mais nécessite de résoudre simultanément 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 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é puis laisser les nœuds subir, 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 canaux à la base, pour ensuite naturellement ouvrir la porte à une augmentation de la capacité du réseau principal.
Parmi ces mesures, l'ePBS, en réorganisant le flux de traitement des blocs à l'intérieur d'un créneau horaire (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 la revalorisation du Gas se charge de limiter la croissance non durable de l'état.
Lors des tests de collaboration Glamsterdam d'avril 2026, les développeurs principaux ont effectué des tests de stress concentrés autour des implémentations multi-clients et ont explicitement proposé un objectif technique post-mise à niveau : une capacité crédible d'au moins 200 millions de Gas. La réalisation de cet objectif repose précisément sur le soutien de base fourni conjointement par l'ePBS, les BALs et la revalorisation du Gas d'état.
Bien sûr, 200 millions de Gas se rapprochent plus de la capacité portante que le système possédera 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é plus importante du réseau principal via une restructuration de l'architecture sous-jacente ».
III. Quels seront les impacts pour les utilisateurs lambda et l'écosystème Ethereum ?
Du point de vue de l'utilisateur lambda, la question la plus préoccupante concernant la mise à niveau Glamsterdam reste de savoir si les frais de transaction vont baisser.
Dans l'ensemble, la réponse est plus proche de « ont des chances de baisser et de devenir plus stables » que de « toutes les transactions deviendront immédiatement moins chères ».
Étant donné que l'ePBS et les listes d'accès au niveau des blocs créent les conditions pour une limite de Gas plus élevée, on peut prévoir que le nombre de transactions qu'un bloc peut contenir va certainement augmenter. Donc, si la demande sur la chaîne reste inchangée, l'offre d'espace bloc augmentant, cela contribuera naturellement à atténuer la congestion et à réduire la probabilité de pics soudains des frais de base (Base Fee).
Mais pour une transaction individuelle, les changements peuvent varier selon l'opération. Par exemple, un simple transfert d'ETH pourrait 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 augmentera considérablement. La mauvaise expérience passée, où une estimation incorrecte du Gas due à la volatilité du marché entraînait l'échec d'une transaction mais la facturation des frais, appartiendra au passé.
En revanche, 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 de la revalorisation 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 en même temps, le fait que les applications à forte intensité d'état commencent à payer un prix plus juste pour les ressources réseau qu'elles occupent à long terme.
Pour les utilisateurs utilisant principalement 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 à Ethereum pour traiter plus de données Blob. Une capacité Blob élargie offrira plus d'espace aux Rollups pour soumettre les données de transaction, ce qui, à long terme, contribuera à stabiliser les coûts des données sur les L2.
De plus, pour les portefeuilles, les plateformes d'échange et les ponts inter-chaînes, un changement plus facilement perceptible par les utilisateurs pourrait venir de l'EIP-7708. Actuellement, les transferts de tokens ERC-20 génèrent généralement des journaux d'événements (logs) Transfer standardisés. Cependant, certains transferts natifs d'ETH 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 standardisés. Cela permettra 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 au sein des 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 seront plus facilement identifiés directement par les portefeuilles.
Pour les opérateurs de nœuds et les utilisateurs qui stakent, 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 validateurs devront mettre à niveau leurs versions client pour prendre en charge Glamsterdam avant l'activation sur le réseau principal. Les utilisateurs détenteurs ordinaires, eux, n'auront pas besoin de migrer leurs ETH, ni d'effectuer de prétendue « mise à niveau d'actifs » ou « échange de tokens ».
À plus long terme, ce que Glamsterdam influencera 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 requis pour exécuter un nœud augmente considérablement en parallèle, le débit du réseau principal pourrait certes augmenter, mais le réseau pourrait devenir de plus en plus dépendant des grandes institutions.
Et la combinaison de l'ePBS, des listes d'accès au niveau des blocs et de la revalorisation du Gas d'état tente de former un autre chemin 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 selon le fardeau réel supporté.
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 une seule EIP, mais transforme simultanément trois mécanismes interdépendants : la production de blocs, l'exécution des transactions et la croissance de l'état.
Pour conclure
À long terme, ce que Glamsterdam influencera profondément, c'est la direction narrative d'Ethereum dans la recherche d'un nouvel équilibre entre « scalabilité haute performance » et « décentralisation absolue ».
C'est aussi l'ambition originelle ou l'inertie familière d'Ethereum – face à la pression croissante des blockchains monolithiques haute performance, il ne choisit pas la voie simple et brutale d'augmenter les exigences matérielles, mais opte pour un chemin visant à préserver autant que possible sa couleur décentralisée et sa résilience fondamentale. Comme cette fois-ci, à travers la combinaison de réécriture de la chaîne de production de blocs (ePBS), de fourniture explicite à l'avance des dépendances des transactions (BALs), et de tarification précise des ressources selon leur fardeau physique (revalorisation du Gas), le but reste d'extraire, tout en garantissant que les gens ordinaires puissent exécuter des nœuds et participer à la validation, une capacité de réseau principal encore plus vaste.
De ce point de vue, chaque frais de Gas avantageux que nous paierons à l'avenir, chaque relevé d'ETH interne 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 aura reposées pour Ethereum dans la seconde moitié de 2026.
