Mise à niveau de Glamsterdam, la solution de mise à l'échelle L1 d'Ethereum

Original | Odaily Planet Daily jk

La prochaine mise à jour Glamsterdam pour Ethereum est considérée par les développeurs principaux comme la plus importante restructuration du protocole depuis The Merge. Son nom est la contraction de deux éléments : la mise à jour de la couche d'exécution conserve « Amsterdam », en référence au lieu des précédents événements Devconnect ; la mise à jour de la couche de consensus est nommée « Gloas », d'après une étoile. Dans la lignée de la précédente mise à jour Fusaka, Glamsterdam améliore la scalabilité de la couche 1 en réorganisant le traitement des transactions et la gestion de la base de données croissante du réseau, et en modernisant fondamentalement la façon dont Ethereum crée et vérifie les blocs.

Cette mise à niveau s'articule autour de trois objectifs principaux :

• Traitement accéléré (parallélisation) : réorganisation de la façon dont le réseau enregistre les dépendances des données, lui permettant de traiter simultanément et en toute sécurité un grand nombre de transactions, plutôt que de les traiter lentement une par une.
• Évolutivité : Répartition de la charge de travail importante liée à la création et à la vérification des blocs, ce qui permet au réseau de disposer de plus de temps pour propager de plus grandes quantités de données sans ralentissement.
• Durabilité : Ajuster les frais de réseau pour refléter fidèlement les coûts matériels à long terme liés au stockage des nouvelles données, en éliminant les obstacles aux futures augmentations des limites de gaz tout en évitant la dégradation des performances matérielles.

Les deux principales propositions de mise à niveau portent sur la couche de consensus et la couche d'exécution :

Il existe deux propositions majeures pour Headliner. Source : Ethereum

Proposition phare n° 1 : ePBS, transformer les « intermédiaires externes » en « règles intégrées »

Tout d’abord, discutons de la proposition phare pour la couche de consensus, qui sépare les proposants et les constructeurs au sein du protocole, abrégé en anglais en ePBS (EIP-7732).

Chaque fois qu'Ethereum produit un bloc, deux étapes sont nécessaires : une personne choisit le bloc (le proposant) et une autre assemble les transactions qui le composent (le constructeur). Actuellement, cette répartition des tâches n'est pas définie par le protocole Ethereum, mais repose sur des intermédiaires externes (communément appelés relais) pour faciliter le processus. Cette relation externe crée également un délai lors de la vérification des blocs, obligeant les validateurs à diffuser et exécuter les transactions en seulement deux secondes, ce qui limite la quantité de données que le réseau peut traiter. On peut comparer cela à un restaurant où la prise de commande et la préparation des plats dépendent d'un intermédiaire externe pour coordonner le service ; si cet intermédiaire fait défaut, la cuisine et la salle risquent de ne pas être synchronisées.

ePBS intègre la répartition des tâches « commande-préparation » dans le manuel d'exploitation du restaurant, éliminant ainsi le besoin d'intermédiaires externes. De ce fait, un mécanisme de livraison et de paiement fiable, basé sur la blockchain, est directement intégré au protocole, supprimant ainsi les logiciels intermédiaires tiers. Toutefois, si les deux parties souhaitent utiliser des fonctionnalités complexes non encore prévues par le protocole, elles peuvent toujours recourir à des intermédiaires externes. Par ailleurs, afin de prévenir tout dysfonctionnement lors de la livraison, ePBS a mis en place une « équipe de vérification des plats » chargée de contrôler l'identité du client et la ponctualité de la préparation, étendant ainsi le délai de livraison initial de 2 secondes à environ 9 secondes. Le restaurant peut ainsi traiter davantage de commandes simultanément, ce qui permet à Ethereum de gérer un volume de données plus important destiné à la couche 2.

Deuxième proposition de tête d'affiche : BALs, préparation d'une « liste de courses » avant le départ

Passons maintenant à la proposition phare pour la couche d'exécution, à savoir une liste d'accès au niveau des blocs, abrégée en BAL (EIP-7928).

Actuellement, le traitement des transactions par Ethereum s'apparente à une personne faisant ses courses les yeux fermés dans un supermarché : elle doit d'abord tâtonner pour trouver un article, vérifier de quoi il s'agit, puis décider de la marche à suivre, ce qui l'oblige à faire la queue article par article. Comme le système ne connaît pas à l'avance les données qu'une transaction utilisera, notamment les comptes impliqués, il doit impérativement traiter les transactions dans l'ordre ; sinon, deux transactions pourraient tenter par inadvertance de modifier les mêmes données (comme le solde d'une même adresse), provoquant ainsi des conflits.

Les BAL permettent à une personne d'obtenir une liste de courses indiquant clairement les rayons à consulter et les articles à prendre avant de partir. Grâce à cette liste, le système peut anticiper les transactions qui ne se chevaucheront pas, ce qui permet de regrouper et de traiter en parallèle des transactions indépendantes au lieu de les mettre en file d'attente une par une. Cette liste présente également un autre avantage : lorsque de nouveaux nœuds rejoignent le réseau, ils peuvent copier directement les résultats finaux enregistrés dans cette liste sans avoir à recalculer l'historique complexe des transactions, ce qui accélère considérablement la synchronisation. Pour faciliter la diffusion de cette liste au sein du réseau, Glamsterdam a également intégré une mise à jour du protocole de transmission permettant aux nœuds de partager ces listes d'accès, une fonctionnalité désormais obligatoire pour tous les clients de la couche d'exécution.

Propositions de soutien : Réévaluation des opérations « occupant l’espace »

En plus de ces deux propositions principales, Glamsterdam a également présenté deux propositions complémentaires de réévaluation des prix, qui peuvent être comprises comme un ajustement de la grille tarifaire des « frais de stockage » et des « frais de requête » du réseau.

• La première proposition concerne les opérations telles que la création de nouveaux comptes et le déploiement de contrats qui occupent de l'espace de manière permanente sur le réseau. Auparavant, les frais facturés n'étaient pas proportionnels à l'espace réellement occupé ; désormais, ils seront recalculés en fonction de la quantité d'espace occupée, afin de maîtriser la croissance globale des données du réseau et de la maintenir à un niveau sûr et prévisible de 120 Gio par an. Ceci permettra au réseau de continuer à fonctionner sur du matériel standard. De plus, ces frais de stockage seront facturés séparément et ne seront plus inclus dans les frais de traitement des transactions. Si les développeurs acceptent de payer un peu plus cher pour le stockage, ils pourront continuer à déployer des applications plus volumineuses et plus complexes sans être immédiatement limités par la limite de gaz.
• La seconde proposition concerne les opérations telles que l'interrogation et la lecture de données existantes sur le réseau, dont le prix était auparavant insuffisant et n'avait pas suivi l'augmentation réelle des coûts de requêtes avec le volume de données. Désormais, les normes de tarification de ces codes d'opération seront revues à la hausse afin de mieux refléter la charge réelle du matériel moderne, tout en empêchant les abus liés à ces faibles tarifs visant à saturer intentionnellement le réseau avec un nombre excessif de requêtes.

Date de lancement du réseau principal : non déterminée

Concernant le calendrier, Glamsterdam se trouve actuellement dans une phase délicate. Officiellement, la dernière réunion vérifiable de tous les développeurs principaux de la couche d'exécution (ACDE) était la 241e, qui s'est tenue le 16 juillet. L'ordre du jour comprenait principalement des mises à jour sur la phase Devnet de Glamsterdam et la sélection des propositions phares pour la prochaine mise à niveau, Hegota. Un calendrier largement diffusé dans le secteur indiquait que la phase Devnet avait connu huit itérations, de 0 à 7, s'étalant du 28 mars 2026 au 8 juillet. Ces itérations ont été suivies par le fork du testnet Sepolia, initialement prévu pour le 3 août 2026, et celui du testnet Hoodi, initialement prévu pour le 17 août 2026. La date cible pour l'activation du réseau principal est fixée au 16 septembre 2026.

Le calendrier initial prévoyait le premier semestre 2026. Source : Ethereum

Cependant, compte tenu des derniers développements, ce calendrier a probablement été reporté. L'équipe EthPandaOps a récemment lancé un nouveau réseau de test appelé Plataberget, le premier réseau de test public à court terme spécifiquement conçu pour Glamsterdam. Les déploiements officiels de Sepolia et Hoodi devraient être reportés à septembre, et le lancement du réseau principal est par conséquent repoussé au quatrième trimestre 2026. C'est le deuxième report du calendrier de Glamsterdam, après celui initialement prévu pour le premier semestre 2026. Les développeurs principaux ont insisté à plusieurs reprises sur le fait que la qualité de la mise à niveau prime sur le respect d'une date précise. Par conséquent, tant que la hauteur de bloc exacte n'aura pas été définie lors de la réunion officielle de l'ACD, cette mise à niveau pourrait ne pas être disponible avant le quatrième trimestre, voire la fin de l'année.