Auteur|jk
La prochaine mise à niveau Glamsterdam d'Ethereum est considérée par les développeurs principaux comme la refonte la plus importante au niveau du protocole depuis The Merge. Ce nom est une combinaison de deux parties : la partie de mise à niveau de la couche d'exécution reprend "Amsterdam", tiré de la ville d'Amsterdam qui a accueilli des éditions précédentes de Devconnect ; la partie de mise à niveau de la couche de consensus est nommée "Gloas", d'après une étoile. Suite à la précédente mise à niveau Fusaka, Glamsterdam fait progresser la scalabilité de la couche L1 en réorganisant la façon dont le réseau traite les transactions et gère sa base de données en croissance continue, refondant fondamentalement la manière dont Ethereum crée et valide les blocs.
Cette mise à niveau s'articule autour de trois objectifs principaux :
- Accélération du traitement (parallélisation) : Réorganiser la façon dont le réseau enregistre les dépendances de données afin de pouvoir traiter en toute sécurité un grand volume de transactions simultanément, plutôt que lentement et séquentiellement.
- Scalabilité : Séparer le travail intense de création et de validation des blocs, donnant au réseau plus de temps pour diffuser des volumes de données plus importants sans ralentir.
- Durabilité : Ajuster les frais du réseau pour qu'ils reflètent avec précision les coûts matériels à long terme du stockage des nouvelles données, ouvrant la voie à de futures augmentations de la limite de gaz tout en évitant la dégradation des performances matérielles.
Les deux principales propositions phares de la mise à niveau concernent respectivement la couche de consensus et la couche d'exécution :
Deux propositions phares principales (Headliner). Source : Ethereum
Proposition phare n°1 : ePBS, transformer le "médiateur externe" en "règle intégrée"
Commençons par la proposition phare de la couche de consensus : la séparation interne des rôles du proposant et du constructeur (ePBS, EIP-7732).
À chaque création de bloc sur Ethereum, il y a en réalité deux étapes : une personne est responsable de "sélectionner le bloc" (le proposant), une autre est responsable d'"assembler réellement les transactions dans le bloc" (le constructeur). Actuellement, cette division du travail n'est pas dictée par le protocole Ethereum lui-même, mais dépend d'une série d'"intermédiaires" hors chaîne (appelés relais) pour être coordonnée. Cette relation hors chaîne crée également un goulot d'étranglement pendant la période de validation des blocs, forçant les validateurs à diffuser et exécuter les transactions à la hâte dans une fenêtre de temps serrée de 2 secondes, limitant ainsi la quantité de données que le réseau peut traiter. Pour faire une analogie, c'est comme si dans un restaurant, la prise de commande et la préparation des plats dépendaient d'un coordinateur externe indépendant pour transmettre les commandes, et si ce coordinateur fait défaut, la cuisine et le service en salle pourraient perdre le fil.
L'ePBS fait en sorte d'intégrer ce système de division du travail "commande-préparation" directement dans le manuel de fonctionnement du restaurant, ne dépendant plus d'un coordinateur externe. Ainsi, un mécanisme fiable de livraison de blocs et de paiement est directement intégré au protocole lui-même, éliminant ainsi le besoin de s'appuyer sur des intermédiaires tiers. Cependant, si les parties souhaitent utiliser des fonctionnalités complexes non encore définies dans le protocole, elles peuvent choisir de continuer à utiliser des coordinateurs externes. Parallèlement, pour éviter que l'étape de "transmission" ne devienne un désordre, l'ePBS établit un "groupe de vérification" séparé pour inspecter respectivement "qui a passé la commande" et "si le plat a été préparé et servi à temps". La fenêtre de transmission initiale de 2 secondes est ainsi étendue à environ 9 secondes, permettant au restaurant de traiter plus de commandes en une seule fois, c'est-à-dire permettant à Ethereum de supporter plus de données destinées aux solutions de Layer 2.
Proposition phare n°2 : BALs, établir la "liste de courses" avant de partir
Passons maintenant à la proposition phare de la couche d'exécution : les listes d'accès au niveau du bloc, ou BALs (EIP-7928).
Actuellement, la façon dont Ethereum traite les transactions est un peu comme si une personne faisait ses courses les yeux bandés : elle doit d'abord toucher un article, confirmer ce que c'est, puis décider de la prochaine étape, donc elle ne peut les traiter qu'un par un, en file d'attente. Comme on ne sait pas à l'avance quelles données une transaction utilisera (par exemple, quels comptes elle concernera), le système doit traiter les transactions strictement de manière séquentielle. Sinon, deux transactions pourraient accidentellement tenter de modifier simultanément les mêmes données (comme le solde d'une même adresse), provoquant un conflit ou une erreur.
Les BALs, c'est comme donner à cette personne, avant de partir, une "liste de courses" qui indique clairement "quels rayons visiter et quels articles prendre". Avec cette liste, le système peut voir à l'avance quelles transactions sont totalement indépendantes et ne se "marchent pas sur les pieds". Il peut ainsi regrouper les transactions sans relation de dépendance et les traiter en parallèle, simultanément, sans avoir à les traiter une par une en file d'attente. Cette liste a un avantage supplémentaire : lorsqu'un nouveau nœud rejoint le réseau, il peut directement copier le résultat final enregistré dans cette liste, sans avoir à recalculer toutes les transactions historiques complexes, ce qui accélère considérablement la synchronisation pour les nouveaux nœuds. Pour permettre à cette liste de circuler réellement dans le réseau, Glamsterdam inclut également une mise à niveau du protocole de transmission qui l'accompagne, permettant aux nœuds de partager effectivement ces listes d'accès. Ce protocole de transmission est désormais une exigence obligatoire pour tous les clients de la couche d'exécution.
Propositions d'accompagnement : Réviser la tarification des opérations "encombrantes"
Outre ces deux propositions phares, Glamsterdam inclut également deux propositions d'accompagnement de retarification, qui peuvent être comprises comme des ajustements de la "grille tarifaire" pour les frais de "stockage" et de "consultation" du réseau.
- La première concerne les opérations qui "occupent de l'espace de manière permanente" sur le réseau, comme la création d'un nouveau compte ou le déploiement d'un contrat. Leur tarification précédente n'était pas assez proportionnelle à l'espace qu'elles occupent réellement. Désormais, le calcul se fera selon le principe "payer en fonction de l'espace occupé". L'objectif est de contrôler la vitesse de croissance des données de l'ensemble du réseau à un niveau sûr et prévisible, d'environ 120 GiB par an, garantissant que le réseau peut continuer à fonctionner même avec du matériel ordinaire. Parallèlement, ces frais de stockage seront comptabilisés dans un compte séparé et ne seront plus mélangés avec les frais de calcul du traitement des transactions elles-mêmes. Tant que les développeurs sont prêts à payer un peu plus pour le stockage, ils pourront toujours déployer des applications plus grandes et plus complexes, sans être immédiatement bloqués par la limite totale de gaz.
- La seconde concerne les opérations de consultation ou de lecture des données déjà présentes sur le réseau. Leur tarification était auparavant trop faible par rapport aux coûts réels de requête compte tenu de l'augmentation du volume de données. Cette fois-ci, le tarif de ces opcodes (codes d'opération) sera augmenté pour mieux refléter la charge réelle sur le matériel moderne, tout en empêchant quiconque de profiter de la tarification trop avantageuse pour intentionnellement saturer le réseau avec un grand nombre de requêtes.
Date de déploiement sur le mainnet : Pas encore fixée
En ce qui concerne le calendrier, Glamsterdam se trouve actuellement à une étape plutôt délicate. Officiellement, la dernière réunion exécutive de l'ensemble des développeurs principaux (ACDE) consultable était la 241e, le 16 juillet. Les principaux points à l'ordre du jour comprenaient une mise à jour sur les derniers progrès de la phase Devnet de Glamsterdam et le vote pour sélectionner la proposition phare de la prochaine mise à niveau, Hegota. Un planning largement cité précédemment dans l'industrie montrait que la phase Devnet comprenait huit itérations, de 0 à 7, couvrant la période du 28 mars 2026 au 8 juillet 2026. Le hard fork du testnet Sepolia était initialement prévu pour le 3 août 2026, celui du testnet Hoodi pour le 17 août 2026, et la date cible pour l'activation sur le mainnet était le 16 septembre 2026.
Le planning initial était pour le premier semestre 2026. Source : Ethereum
Mais d'après les développements les plus récents, ce calendrier a très probablement été repoussé. L'équipe EthPandaOps a récemment lancé un nouveau testnet appelé Plataberget, qui est le premier testnet public à court terme spécialement conçu pour Glamsterdam. Les déploiements formels sur Sepolia et Hoodi devraient désormais être retardés et ne suivre qu'en septembre, et la date cible de déploiement sur le mainnet a été reportée au quatrième trimestre 2026. Il s'agit du deuxième glissement de date pour Glamsterdam, après avoir déjà été repoussé par rapport à la date initiale du premier semestre 2026. Les développeurs principaux ont déjà souligné à plusieurs reprises que la correction de la mise à niveau est prioritaire par rapport au respect d'une date précise. Par conséquent, avant qu'une hauteur de bloc spécifique ne soit verrouillée lors d'une réunion formelle de l'ACD, il est possible que nous ne voyions cette mise à niveau qu'au quatrième trimestre, voire vers la fin de l'année.
