De Glamsterdam à Hegotá : Après l'extension, quelle est la prochaine étape pour Ethereum ?

Après une pause dans les travaux de construction, Ethereum commence enfin à s'attaquer à ces expériences en chaîne qui rendent la vie des utilisateurs ordinaire si frustrante.

Rédaction : imToken

Si l'on devait relier les mises à jour d'Ethereum des dernières années, le mot clé serait sans aucun doute « extension ».

De l'introduction de Blob dans Dencun, qui réduit considérablement les taxes pour Rollup, à l'ajustement de l'efficacité des validateurs et des mécanismes de staking dans Pectra, en passant par l'implémentation de PeerDAS dans Fusaka pour alléger la charge de distribution des données, la couche protocolaire a concentré presque tous ses efforts sur une seule chose : permettre à Ethereum d'absorber plus de données tout en maintenant les barrières d'entrée pour les nœuds à un niveau raisonnable.

Cette combinaison a effectivement porté ses fruits, le coût des données pour Rollup a diminué, la limite de gaz du réseau principal augmente régulièrement, et Ethereum ne ressemble plus à la dernière bulle où des frais de plusieurs dizaines de dollars faisaient fuir les utilisateurs.

Cependant, même si la route est plus large, la conduite reste encore délicate :

• Nous devons toujours transférer des actifs entre trois ou quatre L2, et un faux pas peut nous faire choisir la mauvaise chaîne ;
• Un transfert qui est emballé en quelques secondes peut nécessiter d'attendre une dizaine de minutes avant d'être confirmé par le pont ou l'échange ;
• Les Builders professionnels monopoliseront presque toujours le packaging des blocs, et si vous souhaitez effectuer une transaction sensible, vous risquez d'être rejeté par des règles non écrites ;
• Sans parler du fait qu'à ce jour, un nouvel utilisateur qui souhaite simplement transférer quelques centaines de dollars en USDC doit d'abord comprendre pourquoi son portefeuille doit contenir des ETH, ce qu'est un Nonce, et ce qu'est le Gas ;

Ces problèmes se manifestent tous comme des frictions dans l'expérience utilisateur, mais ils impliquent en réalité des mécanismes de protocole plus profonds tels que les règles de confirmation, la construction de blocs, la résistance à la censure et le modèle de compte.

C'est précisément ce que Ethereum va commencer à traiter de manière concentrée, de Glamsterdam à Hegotá, entre le quatrième trimestre 2026 et 2027.

I. L'extension continue, mais commence à « coudre » L1 et L2

Bien sûr, l'extension ne va pas freiner.

Glamsterdam reste fortement orienté vers la performance, avec deux éléments particulièrement remarquables : l'un s'appelle ePBS (EIP-7732) et l'autre BAL (Block-level Access Lists, EIP-7928). Pour simplifier :

• ePBS consiste à formaliser la séparation des rôles entre Proposer et Builder, qui existent déjà en grande partie en dehors du protocole, et à découper la fenêtre de temps pour la création et la validation des blocs de manière plus scientifique, laissant ainsi de la place pour des blocs plus grands à l'avenir ;
• BAL permet aux blocs de dresser dès le départ une « liste d'accès », permettant aux nœuds de précharger des données ou de les traiter en parallèle, ce qui s'attaque aux goulets d'étranglement de stockage I/O ;

Cependant, en dehors de l'extension, la douleur réelle de la plupart des gens aujourd'hui n'est pas que le TPS d'Ethereum soit trop bas, mais que « il y a trop de chaînes ».

Par exemple, l'ETH est sur le réseau principal, les mèmes sont sur la chaîne Robinhood, l'USDC utilisé pour les paiements peut être sur Arbitrum, et l'USDC que l'on veut acheter se trouve sur Base...

Pour la fondation Ethereum, les Rollups font partie du paysage d'Ethereum, mais pour les utilisateurs, cela revient à échanger des devises à l'international ou à obtenir un visa.

Ainsi, pour recoller les morceaux éparpillés, en plus des protocoles inter-chaînes, un mécanisme de base récemment promu par la couche protocolaire mérite d'être souligné : le FCR (Fast Confirmation Rule, règle de confirmation rapide).

Beaucoup pensent qu'une transaction est considérée comme validée une fois qu'elle est intégrée dans un bloc, mais sur le plan cryptographique et de consensus, un bloc nouvellement créé peut subir de petites réorganisations, et la véritable « finalité » irréversible nécessite qu'Ethereum passe par deux Epochs, ce qui prend environ 13 minutes.

Cela n'a pas d'importance pour les transferts quotidiens, mais pour les ponts inter-chaînes, les règlements de gros montants et les échanges centralisés, c'est un véritable supplice. Pour éviter le risque de réorganisation, ils doivent vous faire attendre.

L'idée du FCR est de ne pas avoir à attendre la finalité complète de dix minutes, mais d'utiliser les attestations que les validateurs produisent en continu pour évaluer plus tôt si un bloc a déjà reçu un soutien de consensus suffisant, en fonction du poids des votes accumulés.

Selon les objectifs fixés par la fondation Ethereum, dans des conditions de synchronisation normale du réseau, le FCR devrait permettre d'anticiper cette « forte confirmation » à environ 15 à 30 secondes. Bien que cela ne soit pas équivalent à une finalité complète, cela devrait suffire à fournir un signal de confirmation plus précoce et avec un modèle de sécurité clair pour de nombreux ponts, communications inter-chaînes et infrastructures qui doivent actuellement attendre la finalité.

Plus intéressant encore, le FCR n'a pas besoin d'attendre un hard fork pour être activé ; il s'agit plutôt d'un ensemble de règles de confirmation qui peuvent être progressivement adoptées par les clients de consensus et les infrastructures.

Une fois que les différents L2, ponts inter-chaînes et portefeuilles commenceront à utiliser ce signal, les retards inter-couches causés par « l'attente de la finalité L1 » pourraient être réduits de plusieurs minutes à quelques dizaines de secondes.

Cela signifie également que, à l'avenir, lorsque vous déplacerez un actif, il se peut que cela traverse discrètement deux chaînes ou plusieurs chaînes en arrière-plan, mais sur le front, il vous suffira de cliquer sur confirmer, et cela arrivera rapidement.

II. Une question plus fondamentale : qui a le pouvoir de décider si une transaction peut être intégrée à la chaîne ?

Cependant, à mesure que les blocs deviennent de plus en plus grands et que les Builders deviennent de plus en plus professionnels, Ethereum est confronté à un autre dilemme très typique.

Puisque les Builders professionnels, grâce à leur puissance de calcul et à leur flux de commandes, ont atteint une efficacité maximale dans la construction des blocs, la majorité du pouvoir de vie ou de mort sur les blocs repose naturellement entre les mains de quelques grandes institutions.

Cela entraîne un risque extrêmement dangereux : la censure.

Si certains Builders, en raison de pressions réglementaires, de concurrence commerciale ou simplement parce qu'ils n'aiment pas certains protocoles de confidentialité, choisissent délibérément d'ignorer les transactions légitimes dans le pool de mémoire, même si vous avez votre clé privée et que vous payez suffisamment de Gas, votre transaction peut être bloquée à l'extérieur de la chaîne (pour en savoir plus, lisez « Intégrer la résistance à la censure dans le protocole : qui décide si une transaction Ethereum peut être intégrée à la chaîne ? »).

Si la décentralisation ne peut même pas garantir l'accès de base aux « transactions résistantes à la censure », alors peu importe le volume, c'est un château de cartes.

C'est pourquoi dans la planification de Hegotá, le FOCIL (Fork-choice Enforced Inclusion Lists, EIP-7805) a été placé à un endroit si crucial.

Sa logique est extrêmement simple et brutale : il impose des contraintes aux Builders.

Pour chaque Slot, le protocole sélectionne aléatoirement un groupe de validateurs indépendants ordinaires, leur demandant d'insérer les transactions légitimes qu'ils voient dans le pool de mémoire dans une « liste d'inclusion », les Builders peuvent toujours organiser l'ordre des transactions pour maximiser leur MEV, mais le bloc qu'ils soumettent doit obligatoirement inclure les transactions de cette liste.

Si un Builder choisit délibérément d'ignorer cette liste, tous les validateurs du réseau rejetteront ce bloc selon les règles de choix de fork. En d'autres termes, vous pouvez gagner de l'argent grâce à votre talent, mais vous ne pouvez pas décider qui a le droit d'utiliser Ethereum.

Une fois ce mécanisme en place, cela permettra également de résoudre un autre problème que Ethereum a longtemps tenté de résoudre, à savoir la question de la confidentialité, qui est tant attendue.

Comme tout le monde le sait, lorsque l'on parle de confidentialité, on évoque souvent les preuves à divulgation nulle de connaissance, les adresses invisibles, les pools de mélange, mais tant que le Builder reconnaît « c'est un appel vers un contrat de confidentialité », il peut tout simplement le rejeter, et votre magie mathématique sera instantanément contrecarrée.

Actuellement, dans la voie de la confidentialité d'Ethereum, le FOCIL bloque précisément les endroits les plus susceptibles d'être bloqués, car tant que la couche protocolaire peut garantir le droit d'accès à chaque transaction légitime, l'exploration de la confidentialité en amont aura une chance de prospérer.

Actuellement, des propositions de confidentialité plus radicales comme l'EIP-8182 (tentative d'introduire un pool protégé natif au niveau du protocole) sont encore en phase de discussion (Proposé), mais la tendance est déjà très claire, à savoir que la confidentialité ne peut plus être considérée comme une fonctionnalité marginale d'une DApp tierce, elle doit progressivement devenir une nécessité fondamentale d'Ethereum.

III. La dernière étape, l'AA natif et des portefeuilles plus conviviaux

Les ajustements structurels dont nous avons parlé se produisent principalement sous la surface, tandis que la troisième chose sera étroitement liée à l'expérience d'utilisation réelle des utilisateurs ordinaires.

C'est que Ethereum a enfin décidé de procéder à une grande réforme de son modèle de compte EOA, qui existe depuis plus de dix ans.

Pour être honnête, le modèle de signature par clé privée d'Ethereum, qui est toujours utilisé aujourd'hui, est extrêmement contre-intuitif pour les utilisateurs ordinaires d'Internet :

Si vous perdez votre clé privée, c'est la fin ; même si votre portefeuille contient des milliers de stablecoins, si vous manquez 0,001 ETH pour les frais, vos actifs ne peuvent pas être transférés ; pour utiliser DeFi, vous devez d'abord approuver puis échanger, et vous devez cliquer trois fois pour terminer une seule action ; le Nonce des transactions doit être strictement ordonné, si une transaction est bloquée, tout est bloqué.

Lors des deux premières mises à jour, la communauté a essayé diverses solutions intermédiaires. Par exemple, l'EIP-4337 a introduit des portefeuilles de contrats en dehors du protocole pour contourner le problème ; ou l'EIP-7702 a été introduit dans Pectra pour permettre aux adresses ordinaires de monter temporairement une logique de contrat pour plus de flexibilité.

Mais le 7702 n'est qu'un pont, le véritable point central de Hegotá est l'EIP-8141 (Frame Transactions, transactions en cadre), qui représente une véritable abstraction de compte native.

On peut le comprendre simplement comme suit : une transaction Ethereum d'autrefois était un ensemble de trois éléments indissociables, par exemple qui prouve que c'est vous (validation) + qui paie cette somme (paiement de Gas) + ce que vous voulez faire (exécution), tandis que l'EIP-8141 décompose ces trois éléments en différentes « trames » au niveau du protocole.

• Trame de validation : elle n'est plus figée sur une signature elliptique ECDSA, elle peut prendre en charge des méthodes de validation plus flexibles comme Passkey, et combiner davantage avec des capacités telles que l'empreinte digitale ou la reconnaissance faciale, rendant le changement de clé et la récupération de compte plus naturels ;
• Trame de paiement : la prise en charge native des frais de Gas. Les applications peuvent directement payer les frais de Gas pour les nouveaux utilisateurs, ou vous pouvez spécifier que les frais soient directement déduits de l'USDC dans le transfert, sans avoir besoin d'intermédiaires pour acheter et vendre en dehors de la chaîne ;
• Trame d'exécution : elle prend en charge nativement le traitement par lots atomiques, autorisation + échange en une seule étape, si cela réussit, tout prend effet ensemble, sinon tout est simplement annulé ;

Si l'on ajoute l'EIP-8250 (Keyed Nonces) qui est en discussion, les comptes futurs pourraient même avoir plusieurs pistes de Nonce parallèles.

Une fois que ces capacités sont intégrées au protocole, pour des portefeuilles comme imToken, la forme du produit connaîtra une libération qualitative.

Il faut savoir que la plupart des efforts des portefeuilles passés ont été consacrés à rappeler aux utilisateurs de se préparer pour le Gas, à expliquer pourquoi une transaction est bloquée, à éduquer les utilisateurs sur la manière de noter les phrases de récupération, et à aider les utilisateurs à changer de RPC entre différentes chaînes.

À l'avenir, lorsque les algorithmes de signature, le paiement des frais de Gas, le contrôle des autorisations et le routage des transactions pourront tous être programmés, les portefeuilles pourront enfin retrouver leur place, devenant un système d'exploitation silencieux entre les utilisateurs et le monde décentralisé.

Ils resteront, comme auparavant, entièrement sous le contrôle des utilisateurs, mais leur utilisation sera aussi naturelle que le paiement par code QR d'Alipay ou le déverrouillage par empreinte digitale.

Écrit à la fin

En regardant les mises à jour d'Ethereum au cours des dernières années, le chemin est en réalité très clair.

Dencun a résolu le Blob ; Pectra continue d'étendre tout en améliorant les capacités des validateurs et des comptes ; Fusaka pave la voie à un plus grand débit de données avec PeerDAS ; et le prochain Glamsterdam, à travers des changements structurels comme ePBS et BAL, jettera les bases pour une limite de gaz plus élevée et une exécution parallèle.

L'extension n'est toujours pas terminée, mais elle n'est plus le seul problème.

Ethereum a enfin libéré ses mains pour faire face à ces problèmes fondamentaux et ennuyeux, c'est pourquoi la fondation Ethereum a résumé les nouvelles orientations de recherche et développement du protocole en trois objectifs très simples :

Élargir, améliorer l'expérience utilisateur et renforcer L1.

Ethereum a déjà prouvé au monde qu'il peut devenir un ordinateur mondial qui ne s'arrête jamais, et la prochaine étape est de permettre aux utilisateurs ordinaires de l'utiliser de manière fluide.