80 à 90% des blocs Ethereum passent aujourd'hui par des builders externes. Des acteurs privés, hors protocole, qui décident de l'ordre de vos transactions. Si ce chiffre vous surprend, vous allez comprendre pourquoi la Fondation Ethereum considère Glamsterdam comme sa mise à jour la plus ambitieuse depuis The Merge.
Prévue pour le premier semestre 2026, Glamsterdam ne se contente pas d'ajuster quelques paramètres. Elle s'attaque à un truc que tout le monde dans l'écosystème connaît mais que peu d'utilisateurs voient : la construction des blocs est centralisée, et ça affecte vos frais et la neutralité du réseau.
Pourquoi Ethereum a un problème de centralisation que personne ne voit ?
Quand vous envoyez une transaction sur Ethereum, vous imaginez probablement que le validateur la prend et l'inclut dans le prochain bloc. En fait, non.
Depuis The Merge, un système de séparation proposeur/builder (PBS) s'est mis en place de manière informelle. Les validateurs (proposeurs) délèguent la construction des blocs à des acteurs spécialisés (builders) via un logiciel externe, MEV-Boost, développé par Flashbots. Le builder assemble les transactions dans l'ordre le plus rentable, puis propose le bloc au validateur.
Le problème : tout ça fonctionne via des relais tiers. Des intermédiaires de confiance dans un système censé ne pas en avoir besoin. Si ces relais décident de censurer certaines transactions, ou s'ils tombent en panne, le réseau perd une partie de sa neutralité.
Et c'est exactement ce qui s'est passé à plusieurs reprises. Des transactions liées à Tornado Cash ont été exclues par certains relais, pas par choix du protocole, mais par choix d'entreprises privées. Pour un réseau qui se veut résistant à la censure, c'est un vrai problème.
Comment l'ePBS va corriger ça concrètement ?
L'EIP-7732, le gros morceau de Glamsterdam, intègre la séparation proposeur/builder directement dans le protocole Ethereum. C'est ce qu'on appelle l'ePBS, pour "enshrined Proposer-Builder Separation".
En pratique, voici ce qui change. Les builders soumettent des offres contenant un hash de leur bloc, sans en révéler le contenu. Le proposeur choisit l'offre la plus élevée, toujours sans voir ce qu'il y a dedans. Un nouveau groupe, le Payload Timeliness Committee, vérifie que le builder livre son bloc à temps. Si le builder ne livre pas, le slot reste vide, mais le proposeur garde quand même son paiement.
Ce mécanisme supprime le besoin de faire confiance à des relais externes. Le protocole lui-même gère la relation entre proposeurs et builders, avec des règles transparentes et vérifiables par tous les nœuds.
Les chercheurs estiment que l'ePBS pourrait réduire l'extraction de MEV d'environ 70%. Pour quiconque trade, emprunte ou fournit de la liquidité sur la couche de base d'Ethereum, ça se traduit par des exécutions plus équitables. Moins de sandwich attacks, moins de front-running.
Qu'est-ce que les Block-Level Access Lists changent pour la vitesse du réseau ?
Le deuxième changement majeur, c'est l'EIP-7928 : les Block-Level Access Lists (BALs). Le nom est technique, mais l'idée est simple.
Aujourd'hui, quand Ethereum exécute un bloc, chaque transaction doit aller chercher les données dont elle a besoin au fur et à mesure. C'est comme lire un livre en devant aller chercher chaque page à la bibliothèque au lieu de les avoir toutes devant soi.
Avec les BALs, chaque bloc déclare à l'avance tous les comptes et slots de stockage qu'il va toucher. L'en-tête du bloc inclut un hash de cette liste. Les nœuds peuvent alors pré-charger toutes les données nécessaires avant même de commencer l'exécution.
Et ça ouvre la porte à l'exécution parallèle. Les nœuds pourront traiter plusieurs transactions en même temps, tant qu'elles ne touchent pas les mêmes données. Aujourd'hui, tout passe en file indienne.
L'objectif affiché : passer d'environ 1 000 TPS effectifs sur la couche de base à quelque chose comme 10 000 TPS. C'est un bond, mais il faut le relativiser. Les BALs ne délivrent pas cette performance à elles seules. Elles posent les fondations techniques pour que les prochaines mises à jour puissent y arriver.
Le gas va-t-il vraiment baisser de 78% ?
Un autre EIP en discussion pour Glamsterdam, l'EIP-7904, propose de recalibrer le coût en gas de nombreuses opérations. L'idée : les prix actuels ne reflètent plus les ressources réellement consommées. Certains opcodes coûtent trop cher par rapport à ce qu'ils demandent aux nœuds, d'autres pas assez.
Si cet EIP est inclus dans la version finale, les projections parlent d'une réduction de 78,6% pour les transferts simples d'ETH et les interactions classiques avec des smart contracts. C'est une baisse considérable, et elle toucherait directement les utilisateurs du layer 1.
Mais attention : cet EIP n'est pas encore confirmé. Il fait partie des propositions en cours d'évaluation, aux côtés de l'EIP-8037 (augmentation du coût de création d'état), l'EIP-8038 (augmentation du coût de lecture à froid) et l'EIP-7954 (relèvement de la taille maximale des contrats).
On se retrouve avec un drôle de paradoxe : certains EIP veulent baisser les coûts, d'autres veulent les augmenter pour protéger le réseau. Les développeurs n'ont pas encore tranché, et ce genre de débat peut durer.
Ce que Glamsterdam ne résout pas (et Vitalik le dit lui-même)
L'ePBS empêche la centralisation des builders de contaminer la couche de staking. OK. Mais Vitalik Buterin a lui-même reconnu que le problème de fond reste entier : les builders, eux, restent centralisés.
Autrement dit : même avec ePBS, un petit nombre d'acteurs continuera probablement à construire la majorité des blocs, parce que c'est un jeu d'économies d'échelle. Plus vous avez d'accès au flux d'ordres, plus vous pouvez optimiser vos blocs, plus vous gagnez.
Ce que l'ePBS fait, c'est s'assurer que cette concentration chez les builders ne donne pas un pouvoir disproportionné aux validateurs qui les utilisent. C'est la différence entre un monopole dans un secteur et un monopole qui contrôle aussi le régulateur.
Par ailleurs, Glamsterdam a explicitement exclu plusieurs propositions qui faisaient débat. Pas de réduction du temps de slot. Pas de gas multidimensionnel. Pas de vérification de signature post-quantique. Pas de listes d'inclusion forcée (FOCIL). Ces sujets sont repoussés à des mises à jour ultérieures.
Comment ça se compare à ce que font Solana et les autres ?
Pendant qu'Ethereum peaufine son architecture, Solana avance avec Firedancer, son nouveau client validateur qui vise 1 million de TPS. Polkadot déploie JAM pour repenser son modèle multichain.
Deux philosophies différentes. Solana mise sur la performance brute d'un seul layer. Ethereum continue de parier sur une architecture en couches : le L1 gère la sécurité et la disponibilité des données, les L2 gèrent le débit.
Glamsterdam renforce cette stratégie. La mise à jour Dencun avait déjà réduit les frais L2 de 90%. Fusaka a doublé la capacité blob et réduit la bande passante des validateurs de 85% grâce au PeerDAS. Glamsterdam ajoute l'ePBS et les BALs comme nouvelles briques.
La question, c'est combien de temps les utilisateurs vont continuer à accepter cette approche incrémentale. Quand Solana traite des millions de transactions par jour à des frais quasi nuls, expliquer que les fondations techniques se mettent en place pour un futur ZK-EVM à 1000x ne convainc pas tout le monde.
Ce que ça change si vous détenez de l'ETH ou si vous stakez
Si vous êtes validateur, Glamsterdam modifie votre rôle. Vous n'aurez plus besoin de MEV-Boost comme intermédiaire. Le protocole gère la relation avec les builders directement. C'est moins de logiciel tiers à maintenir et moins de surface d'attaque.
Si vous stakez via des protocoles comme EigenLayer ou d'autres services de restaking, l'impact est indirect mais réel. Un L1 plus efficace et plus décentralisé, c'est un meilleur socle pour tout l'écosystème qui se construit dessus.
Pour les utilisateurs qui tradent sur des DEX comme Uniswap ou qui fournissent de la liquidité sur Aave, la réduction du MEV est probablement le changement le plus concret. Moins de valeur extraite de vos transactions signifie de meilleurs prix d'exécution.
Quand est-ce que Glamsterdam arrive sur le mainnet ?
La Fondation Ethereum a publié ses priorités protocolaires pour 2026 le 18 février dernier. Trois axes : Scale, Improve UX, Harden the L1. Glamsterdam s'inscrit dans les trois.
Le calendrier vise un déploiement au premier semestre 2026. Les testnets devraient être actifs dans les prochaines semaines si ce n'est pas déjà le cas. Une deuxième mise à jour, baptisée Heze-Bogota, est prévue pour la fin de l'année.
Si Ethereum tient ce rythme de deux hard forks par an, c'est un changement notable. Historiquement, les mises à jour majeures prenaient souvent plus de temps que prévu. Mais depuis Pectra et Fusaka en 2025, le rythme s'est accéléré.
Glamsterdam ne va pas transformer Ethereum du jour au lendemain. Mais pour la première fois, le protocole s'attaque frontalement à la centralisation des builders. C'est un sujet qui traîne depuis des années dans les forums de dev. Si l'ePBS fonctionne et que les BALs ouvrent la voie à l'exécution parallèle, Ethereum tient son prochain palier. Reste à voir si ça arrive assez vite. La concurrence n'attend pas.
Dernière mise à jour : mars 2026
