La prochaine phase d'Ethereum : relier L1 et L2, renforcer la confidentialité et améliorer l'expérience utilisateur

Si l'on relie les mises à niveau d'Ethereum des dernières années, le mot-clé est sans aucun doute « mise à l'échelle ».

De l'introduction des blobs par Dencun pour réduire considérablement les coûts des Rollups, à la modification de l'efficacité des validateurs et du mécanisme de staking par Pectra, jusqu'à l'implémentation de Fusaka avec PeerDAS pour alléger la charge de distribution des données, la couche protocole consacre presque toutes ses ressources à un seul objectif : permettre à Ethereum d'absorber davantage de données sans élever excessivement le seuil d'entrée pour les nœuds.

Ce combo fonctionne vraiment : les coûts de données des Rollups ont été réduits, et la limite de Gas du réseau principal progresse de manière stable ; les frais sur Ethereum ne sont plus aussi élevés qu'au dernier cycle haussier, où ils pouvaient atteindre plusieurs dizaines de dollars, décourageant les utilisateurs.

Mais la route est plus large, comment conduire reste encore gênant :

• Nous devons toujours transférer des actifs entre deux ou trois L2, et il suffit d’une petite erreur pour retirer sur la mauvaise chaîne ;
• Une transaction a été incluse en quelques secondes, mais le pont et l'échange exigent que vous attendiez une dizaine de minutes avant de la confirmer ;
• Les professionnels du mining contrôlent presque entièrement le regroupement des blocs ; si vous souhaitez effectuer une transaction sensible, vous risquez constamment d'être exclu par des règles implicites externes au protocole ;
• Sans parler du fait qu’aujourd’hui encore, un utilisateur débutant qui souhaite simplement transférer quelques centaines de dollars en USDC doit d’abord comprendre pourquoi il faut avoir de l’ETH dans son portefeuille, ce qu’est un Nonce et ce qu’est le Gas ;

Ces problèmes apparaissent au premier abord comme des frictions liées à l’expérience utilisateur, mais ils impliquent en réalité des mécanismes de protocole plus fondamentaux tels que les règles de confirmation, la construction des blocs, la résistance à la censure et le modèle de compte.

Et c'est précisément ce nouveau défi que l'ethereum commence à traiter de manière centralisée, de Glamsterdam à Hegotá, du Q4 2026 à 2027.

Of course, scaling won't hit the brakes.

Glamsterdam conserve une forte orientation performance, avec deux éléments particulièrement notables : ePBS (EIP-7732) et BAL (Block-level Access Lists, EIP-7928). En termes simples :

• ePBS consiste à intégrer formellement dans le protocole la séparation entre Proposers et Builders qui existe déjà largement en dehors du protocole aujourd'hui, tout en divisant de manière plus scientifique les fenêtres temporelles pour la production et la validation des blocs, afin de laisser suffisamment de marge pour des blocs plus volumineux à l'avenir ;
• BAL équivaut à faire en sorte que le bloc liste dès le départ une « liste d'accès », permettant aux nœuds de précharger les données à l'avance, voire de les traiter en parallèle, pour résoudre les goulots d'étranglement I/O stockage ;

Au-delà du scaling, la souffrance réelle de la plupart des gens aujourd'hui n'est pas que la TPS d'Ethereum soit insuffisante, mais que « il y a trop de chaînes ».

Par exemple, l’ETH est sur la chaîne principale, les memes sont sur Robinhood Chain, les paiements et règlements sont effectués en USDC sur Arbitrum, et les USDC que vous souhaitez acheter à bas prix sont sur Base.....

Pour la Fondation Ethereum, les Rollups font partie intégrante de l'écosystème Ethereum, mais pour les utilisateurs, cela revient au même que de changer de devise à l'étranger ou d'obtenir un visa.

Ainsi, pour reconstituer le puzzle épars en un réseau cohérent, outre les diverses solutions des protocoles cross-chain, un mécanisme fondamental récemment promu au niveau protocole mérite une attention particulière : le FCR (Fast Confirmation Rule, règle de confirmation rapide).

Beaucoup pensent qu'une transaction est considérée comme effectuée dès qu'elle est incluse dans un bloc, mais sur le plan cryptographique et de la consensus, un bloc récemment généré peut encore faire l'objet d'une petite réorganisation. La « finalité » véritablement irréversible nécessite qu'Ethereum traverse deux Epochs, soit environ 13 minutes.

Cela n'a pas d'importance pour les virements habituels, mais c'est une véritable souffrance pour les ponts cross-chain, les règlements de grande envergure et les échanges centralisés ; pour éviter le risque de réorganisation, ils ne vous laissent qu'à attendre patiemment.

L'ingéniosité de FCR réside dans le fait qu'il n'est pas nécessaire d'attendre passivement les dix minutes complètes de Finalité, mais qu'il utilise les Attestation que les validateurs produisent naturellement en continu, afin de déterminer plus tôt si un bloc a reçu un soutien de consensus suffisamment fort en se basant sur le poids des votes déjà accumulés.

Selon les objectifs définis par la Fondation Ethereum, dans le cas où le réseau reste normalement synchronisé, le FCR permettra de faire avancer cette « confirmation forte » à environ 15 à 30 secondes. Bien que cela ne soit pas équivalent à une finalité complète, il fournira déjà un signal de confirmation plus précoce et doté d’un modèle de sécurité clair pour de nombreuses ponts, communications interchaînes et infrastructures qui doivent actuellement attendre la finalité.

Plus spécifiquement, FCR n'exige pas d'attendre une hard fork spécifique pour être activé ; il s'agit plutôt d'un ensemble de règles de confirmation pouvant être adoptées progressivement par les clients de consensus et l'infrastructure.

Une fois que divers L2, ponts interchaînes et portefeuilles commenceront à utiliser ce signal, les retards inter-couches actuellement 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, lors de votre déplacement d'un actif, l'arrière-plan peut automatiquement traverser deux chaînes ou plus, mais à l'avant-plan, il vous suffit de cliquer sur Confirmer, puis les fonds seront rapidement crédités.

Cependant, à mesure que les blocs deviennent de plus en plus volumineux et que les Builder deviennent de plus en plus professionnels, Ethereum fait face à un autre problème classique.

Puisque les constructeurs professionnels ont poussé l'efficacité de la construction de blocs à son maximum grâce à une puissance de calcul de pointe et un flux d'ordres optimisé, le sort de la majorité des blocs revient naturellement à quelques grandes institutions.

Cela crée un risque extrêmement dangereux : la censure.

Si certains buildeurs, sous pression de conformité, de concurrence commerciale, ou simplement parce qu'ils n'aiment pas certains accords de confidentialité, choisissent délibérément d'ignorer et de refuser d'inclure votre transaction légale dans le mempool, même si vous détenez votre clé privée et payez suffisamment de gas, votre transaction risque d'être bloquée en dehors de la chaîne (lecture complémentaire : Écrire la résistance à la censure dans le protocole : qui décide si une transaction Ethereum peut être incluse sur la chaîne ?).

Si la décentralisation ne peut même pas garantir l'accès aux transactions résistantes à la censure, un débit élevé n'est qu'un château en l'air.

C'est aussi pourquoi FOCIL (Fork-choice Enforced Inclusion Lists, EIP-7805) occupe une place aussi cruciale dans la planification de Hegotá.

Son logique est extrêmement simple et directe : elle consiste à mettre un cerceau de fer sur Builder.

Pour chaque slot, le protocole sélectionne aléatoirement un groupe de validateurs indépendants ordinaires pour inclure les transactions valides en attente qu'ils voient dans leur mémoire tampon dans une « liste d'inclusion », mais vous, le builder, pouvez toujours organiser librement l'ordre des transactions pour tirer profit de votre MEV ; toutefois, le bloc que vous soumettez doit impérativement inclure les transactions de la liste.

Si le Builder ose ignorer sciemment cette liste, tous les validateurs du réseau excluront directement ce bloc selon les règles de sélection de la chaîne. En d'autres termes, vous pouvez gagner de l'argent grâce à vos compétences, mais vous ne pouvez pas décider pour l'ensemble du réseau qui a le droit d'utiliser Ethereum.

Dès que ce mécanisme a été mis en place, il a enfin fourni un point d'ancrage à un autre point faible d'Ethereum longtemps revendiqué mais jamais avancé : la confidentialité tant attendue.

Il est bien connu que par le passé, lorsqu’on parlait de confidentialité, on ne parlait que de preuves à connaissance nulle, d’adresses implicites et de pools de mélange, mais dès que le Builder reconnaît « cette transaction appelle un contrat de confidentialité », il vous refuse immédiatement, et vos mathématiques magiques s’effondrent instantanément.

Actuellement, dans la feuille de route de confidentialité d’Ethereum, FOCIL ferme précisément le point le plus vulnérable à l’étouffement, car tant que le protocole garantit inconditionnellement l’accès à chaque transaction légale, les recherches en matière de confidentialité en haut niveau ont une chance de prospérer.

Actuellement, des propositions plus ambitieuses en matière de confidentialité, comme l’EIP-8182 (qui tente d’introduire un Pool Shielded natif au niveau du protocole), sont encore en phase de proposition, mais la tendance est claire : la confidentialité ne peut plus être traitée comme une fonction périphérique d’un dapp tiers ; elle doit progressivement devenir un élément fondamental de l’infrastructure d’Ethereum.

Les ajustements d'architecture mentionnés précédemment ont principalement eu lieu en coulisses, tandis que le troisième point sera étroitement lié à l'expérience d'utilisation des utilisateurs ordinaires.

C’est donc que l’Ethereum a enfin pris la décision de procéder à une réforme majeure du modèle de compte EOA qui dure depuis plus de dix ans.

Pour être honnête, le modèle de signature de clé privée encore utilisé par Ethereum est extrêmement anti-humain pour les utilisateurs d'Internet un peu plus ordinaires :

Si vous perdez votre clé privée, c'est la perte définitive ; même avec des milliers de stablecoins dans votre portefeuille, un manque de 0,001 ETH pour les frais de transaction bloque temporairement le transfert de vos actifs ; jouer sur DeFi exige d'abord une approbation, puis un échange, et trois signatures pour accomplir une seule action ; les nonces de transaction doivent être traités strictement en ordre : si une transaction est bloquée, toute la chaîne est immobilisée.

Au cours des deux précédentes mises à jour, la communauté a effectué divers compromis. Par exemple, elle a développé l'ERC-4337, utilisant des portefeuilles intelligents en dehors du protocole pour trouver une solution de contournement ; puis, avec Pectra, elle a introduit l'EIP-7702, permettant aux adresses ordinaires de temporiser un code contractuel pour gagner en flexibilité.

Mais 7702 n'est au fond qu'un pont temporaire ; le véritable enjeu de Hegotá réside dans l'abstraction de compte native originale, l'EIP-8141 (Frame Transactions).

On peut le comprendre simplement comme suit : auparavant, une transaction Ethereum liait étroitement trois éléments ensemble — par exemple, qui prouve que c’est vous (vérification) + qui paie cette transaction (paiement du Gas) + ce qui doit être fait exactement (exécution) — tandis que l’EIP-8141 décompose ces trois éléments en différentes « trames » au niveau du protocole (pour en savoir plus, consultez Account Abstraction native + résistance aux menaces quantiques : pourquoi l’EIP-8141 n’est pas encore la star du Hegotá d’Ethereum ?) :

• Vérification par cadre : ne s'appuie plus uniquement sur la signature ECDSA sur courbe elliptique, permettant de prendre en charge des méthodes de vérification plus flexibles telles que les Passkey, et d'intégrer davantage les fonctionnalités des téléphones comme l'empreinte digitale et Face ID, rendant le changement de clés et la récupération de compte plus naturels ;
• Frame de paiement : Gaz sponsorisé de manière native. Les applications peuvent directement payer les frais de gaz pour les nouveaux utilisateurs, ou vous pouvez spécifier dans le frame de paiement de déduire directement les USDC du transfert, éliminant ainsi totalement le besoin de relais pour acheter et vendre hors chaîne ;
• Frame d'exécution : prise en charge native du traitement par lots atomiques, autorisation et échange en une seule étape ; en cas de succès, tout prend effet ensemble ; en cas d'échec, tout est annulé de manière nette et définitive ;

En ajoutant également l'EIP-8250 (Keyed Nonces) actuellement en discussion, les comptes futurs pourraient même avoir plusieurs pistes de Nonce parallèles.

Une fois ces fonctionnalités intégrées nativement dans le protocole, les portefeuilles comme imToken connaîtront une libération qualitative de leur forme produit.

Par le passé, une grande partie de l'effort du portefeuille était consacrée à rappeler aux utilisateurs de préparer du Gas, à expliquer pourquoi une transaction était bloquée, à éduquer les utilisateurs sur la façon de recopier leur phrase de rétablissement et à aider les utilisateurs à basculer entre différentes chaînes RPC.

À l'avenir, lorsque les algorithmes de signature, le paiement de Gas, le contrôle des autorisations et le routage des transactions pourront être programmés, les portefeuilles pourront enfin retrouver leur place naturelle en tant que couche silencieuse d'exploitation entre les utilisateurs et le monde décentralisé.

Il reste entièrement sous le contrôle de l'utilisateur, tout comme le paiement par code QR d'Alipay ou le déverrouillage par empreinte digitale, il devient naturel et intuitif.

En regardant en arrière les mises à jour d'Ethereum au cours de ces dernières années, le chemin est en réalité extrêmement clair.

Dencun résout les blobs ; Pectra continue d'augmenter la capacité tout en améliorant les fonctionnalités des validateurs et des comptes ; Fusaka prépare la voie pour un débit de données encore plus élevé avec PeerDAS ; le prochain Glamsterdam posera les bases de limites de Gas plus élevées et d'exécution parallèle grâce à des changements structurels tels que ePBS et BAL.

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

Ethereum prend enfin le temps de faire face aux problèmes les plus fondamentaux et les plus préoccupants, ce qui explique pourquoi l'EF a réorganisé les orientations de développement du protocole en 2026 en trois objectifs très simples :

Échelle, amélioration de l'UX et renforcement du L1.

Ethereum a déjà prouvé au monde qu'il pouvait devenir un ordinateur mondial fonctionnant sans interruption ; il s'agit maintenant de permettre à chacun de l'utiliser avec une fluidité absolue.