Mise à niveau de Glamsterdam : la réponse à l'extension L1 d'Ethereum

Original  Odaily Planet Daily jk

La mise niveau Glamsterdam d'Ethereum, qui arrive prochainement, est considére comme la plus grande refonte du protocole depuis The Merge par les dveloppeurs principaux. Ce nom est une combinaison de deux parties : la mise niveau de la couche d'excution utilise "Amsterdam", tire du lieu de l'ancienne Devconnect Amsterdam ; la mise niveau de la couche de consensus est nomme "Gloas", d'aprs une toile. Suite la mise niveau de Fusaka, Glamsterdam promeut l'extension L1 en rorganisant la manire dont le rseau traite les transactions et gre sa base de donnes en croissance , rvolutionnant fondamentalement la manire dont Ethereum cre et vrifie les blocs.

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

• Acclrer le traitement (paralllisation) : rorganiser la manire dont le rseau enregistre les dpendances des donnes, permettant de traiter simultanment un grand nombre de transactions de manire sre, au lieu de les traiter lentement une par une.
• Extension : dcomposer le travail lourd de cration et de vrification des blocs, permettant au rseau de diffuser des donnes plus volumineuses sans ralentir.
• Durabilit : ajuster les frais du rseau pour reflter prcisment le cot matriel long terme de stockage de nouvelles donnes, facilitant ainsi l'augmentation future des limites de Gas tout en prvenant la dgradation des performances matrielles.

Les deux propositions phares de la mise niveau se situent respectivement au niveau de la couche de consensus et de la couche d'excution :

Il y a deux grandes propositions phares. Source : Ethereum

Proposition phare 1 : ePBS, transformer les "intermdiaires externaliss" en "rgles internes"

Commenons par la proposition phare de la couche de consensus, qui spare les proposeurs et les constructeurs au sein du protocole, abbrge en anglais ePBS (EIP-7732).

Chaque fois qu'Ethereum produit un bloc, cela se fait en deux tapes : une personne est responsable de "choisir quel bloc" (le proposeur), et une autre est responsable de "assembler les transactions dans le bloc" (le constructeur). Actuellement, cette rpartition n'est pas prvue par le protocole Ethereum lui-mme, mais dpend d'un certain nombre de "socits intermdiaires" (appeles relais) pour faciliter le processus. Cette relation hors-chane a cr une voie pendant la vrification des blocs, forant les validateurs terminer rapidement la diffusion et l'excution des transactions dans une fentre de 2 secondes, limitant ainsi la quantit de donnes que le rseau peut traiter. Pour donner un exemple, c'est comme si un restaurant devait coordonner les commandes et la cuisine par l'intermdiaire d'une personne externe ; si cette personne fait dfaut, la cuisine et la salle peuvent ne pas s'accorder.

Ce que fait ePBS, c'est d'inscrire cette rpartition "commande-cuisine" dans le manuel d'exploitation du restaurant, ne dpendant plus d'un intermdiaire externe. Cela signifie que le mcanisme de livraison de blocs et de paiement de confiance sur la chane est directement construit dans le protocole lui-mme, tant qu'il n'est pas ncessaire de dpendre d'un middleware tiers. Cependant, si les deux parties souhaitent utiliser des fonctions complexes non prvues par le protocole, elles peuvent toujours choisir de recourir un intermdiaire externe. De plus, pour ne plus avoir de confusion lors de la "livraison des plats", ePBS a mis en place un "groupe de vrification des plats" pour vrifier "qui a command" et "si les plats sont prts temps" ; la fentre de livraison de 2 secondes a donc t largie environ 9 secondes, permettant au restaurant de traiter plus de commandes la fois, ce qui signifie qu'Ethereum peut supporter plus de donnes destines la couche 2.

Proposition phare 2 : BALs, dressez d'abord votre "liste de courses"

Passons maintenant la proposition phare de la couche d'excution, la liste d'accs au niveau des blocs, abbrge en anglais BALs (EIP-7928).

Actuellement, la manire dont Ethereum traite les transactions ressemble une personne aveugle faisant des courses au supermarch : elle doit d'abord toucher un produit, confirmer ce que c'est, avant de dcider de la prochaine tape, ce qui l'oblige faire la queue un par un. Parce qu'elle ne sait pas d'avance quelles donnes seront ncessaires pour une transaction, par exemple quels comptes seront impliqus, le systme doit traiter les transactions strictement dans l'ordre, sinon deux transactions pourraient accidentellement vouloir modifier les mmes donnes (comme le solde d'une mme adresse), ce qui provoquerait des conflits.

Les BALs permettent cette personne d'obtenir une liste de courses claire indiquant "quels rayons visiter et quels articles prendre" avant de partir. Avec cette liste, le systme peut pralablement identifier les transactions qui ne s'entravent pas mutuellement, permettant ainsi de grouper les transactions non lies et de les traiter simultanment sans avoir faire la queue une par une. Cette liste a un avantage supplmentaire : lorsque de nouveaux nuds rejoignent le rseau, ils peuvent directement copier le rsultat final enregistr dans cette liste, sans avoir recalculer toutes les transactions historiques complexes, ce qui permet aux nouveaux nuds de synchroniser leur progression beaucoup plus rapidement. Pour permettre cette liste de circuler rellement dans le rseau, Glamsterdam a également inclus une mise niveau du protocole de transmission, permettant aux nuds de partager effectivement ces listes d'accs, ce protocole de transmission est dsormais une exigence pour tous les clients de la couche d'excution.

Propositions associes : recalculer les "cots d'espace" des oprations

En plus de ces deux propositions phares, Glamsterdam a également inclus deux propositions de recalibrage, qui peuvent tre comprises comme un ajustement des "frais de stockage" et des "frais de requte" du rseau.

• La premire concerne les oprations telles que la cration de nouveaux comptes et le dploiement de contrats qui "occupent de l'espace" de manire permanente dans le rseau. Les frais antrieurs n'taient pas proportionnels l'espace qu'ils occupaient, et maintenant, ils seront recalculs selon "chaque espace occup, des frais correspondants seront appliqus", l'objectif tant de contrler la vitesse de croissance des donnes du rseau un niveau scuritaire et prvisible de 120 GiB par an, garantissant que le rseau puisse continuer fonctionner avec du matriel ordinaire. De plus, ces frais de stockage seront comptabilisés dans un compte distinct, ne se mlant plus avec les frais de calcul des transactions elles-mmes. Tant que les dveloppeurs sont prts payer un peu plus de frais de stockage, ils peuvent toujours dployer des applications plus grandes et plus complexes, sans tre bloqus par le plafond total de Gas.
• La deuxime concerne les oprations de requte et de lecture de donnes dj existantes dans le rseau, dont le prix avait t trop bas pour suivre les cots de requte rels aprs l'augmentation de la quantit de donnes, cette fois, les frais de ces oprations seront augments pour se rapprocher des charges relles des matriels modernes, tout en prvenant que des personnes exploitent les frais trop bas pour bloquer le rseau avec des requtes massives.

Date de mise en ligne du mainnet : pas encore fixe

Concernant le calendrier, Glamsterdam est actuellement dans une phase assez délicate. Au niveau officiel, la dernire runion excutive des dveloppeurs principaux (ACDE) a eu lieu lors de la 241e session, le 16 juillet, avec pour principaux sujets le rapport sur les dernires avances de la phase Devnet de Glamsterdam et le choix des propositions phares pour le prochain vote de mise niveau Hegota. Un calendrier largement cit dans l'industrie indiquait que la phase Devnet avait subi huit itrations de 0 7, s'étendant du 28 mars 2026 au 8 juillet, suivie d'un fork du testnet Sepolia prvu pour le 3 aot 2026, et d'un fork du testnet Hoodi prvu pour le 17 aot 2026, avec une date cible d'activation du mainnet fixe au 16 septembre 2026.

Le calendrier initial prvoyait le premier semestre 2026, source : Ethereum

Cependant, d'aprs les dernires nouvelles, ce calendrier a probablement t retard. L'quipe EthPandaOps a rcemment lanc un nouveau testnet appel Plataberget, le premier testnet public court terme spcialement conu pour Glamsterdam, et le dploiement officiel de Sepolia et Hoodi devrait tre retard jusqu'en septembre, ce qui dplace l'objectif de mise en ligne du mainnet vers le quatrime trimestre 2026. C'est la deuxime fois que Glamsterdam voit sa date de mise niveau repousse, aprs un premier report du premier semestre 2026. Les dveloppeurs principaux ont dj soulign plusieurs fois que la prcision de la mise niveau prcde tout dlai spcifique, donc avant que la runion officielle de l'ACD ne verrouille une hauteur de bloc prcise, nous pourrions devoir attendre le quatrime trimestre, voire la fin de l'anne, pour voir cette mise niveau.