Objectivement parlant, ces derniers temps, la perception intuitive de nombreux utilisateurs concernant Ethereum ne provenait souvent pas des feuilles de route ou des réunions de développeurs, mais plutôt d'opérations spécifiques et répétées sur la chaîne.
Par exemple, ces deux dernières années, tout le monde a pu ressentir concrètement la baisse constante des frais de Gas lors des transferts, l'amélioration de l'expérience d'interopérabilité inter-chaînes, etc. C'est pourquoi la mise à l'échelle d'Ethereum n'a jamais été une simple question de « course aux performances » — pour l'utilisateur ordinaire, un TPS plus élevé, des blocs plus grands, une architecture sous-jacente plus complexe, n'ont de sens que lorsqu'ils se traduisent réellement par des coûts plus bas, des opérations plus fluides et une expérience de portefeuille plus sûre.
Et récemment, une série de nouvelles dynamiques au sein d'Ethereum indiquent précisément qu'Ethereum tente de déplacer systématiquement, vers la couche protocolaire, la complexité qui était auparavant supportée par les portefeuilles, les DApps, les relais tiers et les utilisateurs eux-mêmes.
Parmi celles-ci, on trouve les « Keyed Nonces » auxquels Vitalik a participé, le consensus directionnel formé autour d'un plancher de limite de Gas de 200 millions lors de la mise à niveau Glamsterdam, ainsi que toute une série d'éléments annonciateurs dans la feuille de route 2026, soulignant continuellement l'abstraction de compte native, l'interopérabilité inter-L2 et le renforcement de la sécurité de L1.
I. La limite de Gas augmentée à 200 millions ?
Commençons par l'aspect le plus facilement perceptible par l'utilisateur : la limite de Gas.
Comme on le sait, sur le réseau Ethereum, chaque transaction (qu'il s'agisse d'un transfert ou d'une interaction avec un contrat) consomme une certaine quantité de Gas, et la capacité de limite de Gas de chaque bloc Ethereum est fixe, c'est-à-dire que le nombre de places est limité : plus il y a de places, plus on peut transporter de passagers en même temps ; plus les places sont rares, plus il faut enchérir pour la même place, ce qui fait grimper les frais de Gas.
En théorie, l'augmentation de la limite de Gas par bloc augmenterait effectivement et directement les performances du réseau principal d'Ethereum. Cependant, dans le contexte du fort développement des L2 et d'autres voies, Ethereum est resté jusqu'à présent assez prudent et retenu sur ce point, la plus grande partie de la pression de mise à l'échelle ayant été volontairement orientée vers la piste des L2.
En regardant la courbe d'augmentation de la limite de Gas d'Ethereum, on constate qu'après que la limite de Gas du réseau ait dépassé pour la première fois les 10 millions en septembre 2019 (passant de 8 millions), jusqu'à cette année, en 7 ans, la limite de Gas est seulement passée de 8 millions à 60 millions, et ce n'est surtout qu'en 2025 qu'elle est vraiment entrée dans une phase d'accélération — de 30 millions à 36 millions en février, puis à 45 millions en juillet, et enfin à 60 millions après la mise à niveau Fusaka en décembre.
On peut dire que la majeure partie de l'augmentation s'est faite au cours de cette seule année 2025. Bien sûr, nous l'avons déjà mentionné, 2025 est aussi une année cruciale dans l'histoire du développement d'Ethereum. La mise à niveau Fusaka, seulement 7 mois après la mise à niveau Pectra de mai, a prouvé que l'EF, malgré d'importants changements de leadership, restait capable de pousser des mises à jour majeures, marquant aussi l'entrée officielle d'Ethereum dans un rythme de développement accéléré de « deux hard forks par an » (lecture complémentaire « Ethereum 2026 : Décryptage de la dernière feuille de route protocolaire de l'EF, entrée officielle dans l'ère des « mises à niveau ingénierisées » ? »).
Source : Etherscan
Et selon le « Soldøgn Interop Recap » publié par l'Ethereum Foundation le 2 mai, plus de 100 contributeurs principaux d'Ethereum ont participé à Svalbard, en Norvège, à une réunion d'interopérabilité centrée sur la mise à niveau Glamsterdam, l'objectif principal étant de faire avancer l'implémentation multi-client, les tests et l'alignement des paramètres pour Glamsterdam. À la fin de la réunion, les développeurs avaient formé un consensus directionnel autour d'une limite de Gas de 200 millions après Glamsterdam.
Cela signifie que, si les processus ultérieurs se déroulent bien, la capacité d'exécution de L1 d'Ethereum pourrait passer d'environ 60 millions de limite de Gas actuellement, à un niveau d'environ 200 millions. Sur une échelle de temps plus longue, l'attitude du marché envers la limite de Gas est clairement devenue beaucoup plus « audacieuse ». La proposition EIP-9698 suggère même « une multiplication par dix tous les deux ans », pour atteindre 3,6 milliards de limite de Gas en 2029, soit 50 fois le niveau actuel.
Mais il est important de souligner ici qu'augmenter la limite de Gas ne consiste pas simplement à agrandir les blocs.
Si l'on augmente brutalement la capacité de calcul que chaque bloc peut contenir, à court terme, cela pourrait réduire les frais, mais à long terme, cela alourdirait la charge des nœuds, ferait gonfler les données d'état, et signifierait aussi qu'il serait plus difficile pour les utilisateurs ordinaires de faire tourner un nœud, affaiblissant finalement la base de décentralisation, cœur même d'Ethereum.
L'approche de mise à l'échelle de Glamsterdam est donc une combinaison de mesures :
- L'ePBS (enshrined Proposer-Builder Separation) intègre plus clairement les processus de construction et de validation des blocs dans les règles du protocole, permettant aux validateurs de traiter des blocs plus grands de manière plus sûre ;
- Les Block-Level Access Lists (BAL) enregistrent à l'avance les comptes et les emplacements de stockage qui seront consultés lors de l'exécution du bloc, permettant ainsi des lectures disque parallèles, des validations de transactions parallèles et des calculs de racine d'état parallèles ;
- L'EIP-8037, quant à lui, augmente le coût des opérations liées à la création d'état, évitant une croissance trop rapide de l'état après l'augmentation de la limite de Gas.
En fin de compte, Ethereum ne cherche pas seulement à « contenir plus de transactions », mais réfléchit aussi à comment, tout en contenant plus de transactions, ne pas rendre le seuil d'exécution d'un nœud de plus en plus élevé.
C'est aussi la différence fondamentale entre la feuille de route de mise à l'échelle d'Ethereum et les récits de nombreuses chaînes à hautes performances. Ce qui est recherché n'a jamais été d'échanger le coût de validation contre un débit apparent, mais plutôt d'augmenter la capacité de portage du réseau principal lui-même, tout en essayant de maintenir la possibilité pour les nœuds ordinaires de participer et le système de pouvoir être vérifié.
II. Keyed Nonces : transformer « une seule file » en « multiples canaux »
Si la limite de Gas résout la question de « combien un bloc peut contenir », alors les Keyed Nonces s'intéressent à un autre problème plus subtil mais crucial : comment les transactions doivent-elles faire la queue ?
Comme on le sait, dans Ethereum, le nonce peut être simplement compris comme le « numéro de séquence » des transactions d'un compte. Son rôle est d'empêcher qu'une même transaction soit exécutée plusieurs fois, et de garantir que les transactions émises par un même compte sont traitées dans l'ordre.
Ce mécanisme est facile à comprendre dans le scénario d'un simple transfert : première transaction, deuxième, troisième, etc., dans l'ordre.
Mais le problème est que lorsque les capacités d'un compte deviennent plus complexes, comme avec les transactions privées, les portefeuilles intelligents, les clés de session, les opérations par lots, le paiement par un tiers, etc., un nonce linéaire unique peut devenir un goulot d'étranglement. Ainsi, l'idée centrale des Keyed Nonces, proposés par l'EIP-8250, est de passer d'un compte n'ayant qu'une seule file de nonce, à un compte pouvant posséder plusieurs domaines de nonce.
Plus précisément, il remplace le nonce d'expéditeur unique des Frame Transactions de l'EIP-8141 par une structure (nonce_key, nonce_seq), où nonce_key == 0 correspond au nonce de compte traditionnel, tandis qu'une clé non nulle peut choisir une séquence de nonce gérée indépendamment par le protocole. Les transactions sous différentes clés sont indépendantes les unes des autres, la protection contre le rejeu ne les affectant pas mutuellement.
Cela peut sembler technique, mais on peut le comprendre avec une métaphore de la vie quotidienne : auparavant, un compte était comme une banque avec un seul guichet, toutes les opérations devaient faire la queue dans la même file ; les Keyed Nonces, c'est comme répartir les différentes opérations sur différents guichets, le transfert, le retrait privé, l'autorisation de session, l'exécution par lots pouvant chacun emprunter leur propre canal.
Ceci est particulièrement important pour les protocoles de confidentialité. En effet, pour éviter de lier directement l'activité sur la chaîne d'un utilisateur à une adresse publique unique, un protocole de confidentialité pourrait faire en sorte que plusieurs utilisateurs initient des transactions via une même adresse d'expéditeur partagée. Mais avec un mécanisme de nonce unique, une fois la transaction d'un utilisateur incluse dans un bloc, les transactions d'autres utilisateurs encore en attente pourraient devenir invalides ou être bloquées.
Les Keyed Nonces permettent à chaque dépense de choisir son propre domaine de nonce, par exemple dérivé d'un nullifier de confidentialité, réduisant ainsi ce type de conflit de file d'attente au niveau protocolaire.
La vision de Vitalik lui-même à ce sujet est encore plus large. En présentant l'EIP-8250, il a clairement indiqué que les Keyed Nonces « ne sont pas seulement un soutien plus fort aux solutions de confidentialité au niveau du protocole, mais pourraient aussi être la première étape d'une nouvelle stratégie de mise à l'échelle de l'état pour Ethereum — en créant des types de stockage spécifiquement optimisés pour différents cas d'usage, permettant d'atteindre une évolutivité extrême tout en maintenant la décentralisation du protocole. »
En d'autres termes, on peut simplement comprendre que la limite de Gas résout la « taille du bloc », tandis que les Keyed Nonces explorent la « forme de l'état » — ce qu'Ethereum devra supporter à l'avenir, ce ne sont pas seulement plus de transactions, mais plus de types de transactions.
III. Comment cela affectera-t-il l'utilisateur ordinaire ?
Pour l'écosystème Ethereum, de nombreuses mises à niveau protocolaires semblent éloignées de l'utilisateur ordinaire, mais elles finissent toutes par se traduire dans l'expérience du portefeuille.
Parce que le point d'entrée réel de l'utilisateur vers Ethereum n'est pas les EIP, les clients ou les réunions de développeurs, mais chaque transfert, autorisation, signature, interaction inter-chaînes et avec les DApps dans le portefeuille. C'est-à-dire que les changements au niveau protocolaire ne complètent véritablement la transformation d'une mise à niveau technique à une mise à niveau de l'expérience utilisateur que lorsqu'ils sont traduits, au niveau du portefeuille, en une expérience opérationnelle plus claire, plus fluide et plus sûre.
Par exemple, l'abstraction de compte, dont tout le monde a maintenant entendu parler, n'existe pas pour que les utilisateurs comprennent plus de termes techniques, mais pour qu'ils puissent à l'avenir utiliser plus naturellement leurs comptes sur la chaîne. C'est pourquoi ces dernières années, les transactions par lots, le paiement du Gas par un tiers, les mécanismes de récupération, les différentes méthodes de signature, l'autorisation de session ainsi que des stratégies de sécurité plus flexibles deviennent progressivement des capacités de base dans les portefeuilles.
Prenons également l'exemple des Keyed Nonces. Cela ressemble à une optimisation très bas niveau du mécanisme de file d'attente des comptes, mais du côté utilisateur, son impact potentiel n'est pas abstrait. Parce qu'aujourd'hui, de nombreux utilisateurs ont probablement rencontré des scénarios similaires lors d'opérations sur la chaîne : une transaction qui met du temps à être confirmée, bloquant les transactions suivantes ; vouloir annuler ou accélérer une transaction sans comprendre la relation entre nonce, Gas et remplacement de transaction ; surtout lors d'opérations multiples parallèles, une étape qui échoue peut affecter l'ensemble du processus ultérieur.
Pour l'utilisateur ordinaire, ces problèmes semblent relever du « portefeuille pas pratique » ou de la « chaîne pas pratique », mais ils sont en fait liés à la conception du modèle de compte d'Ethereum avec son nonce linéaire unique. La direction représentée par les Keyed Nonces, c'est de permettre aux comptes de ne plus avoir à exécuter toutes les opérations dans une seule file d'attente séquentielle, mais de pouvoir diviser cette file en plusieurs canaux parallèles selon différents scénarios d'utilisation.
Ainsi, à l'avenir, les opérations comme les transferts ordinaires, les autorisations DApp, les transactions privées, les transactions par lots, le paiement du Gas par un tiers pourraient théoriquement avoir des espaces d'exécution plus indépendants, réduisant la probabilité de blocages et de conflits mutuels.
Cela ouvrirait sans aucun doute davantage l'espace de conception des portefeuilles intelligents.
Plus important encore, par le passé, ces capacités nécessitaient souvent que la complexité soit partagée entre le portefeuille, la DApp, les services de relais et l'utilisateur. L'utilisateur devait comprendre la portée des autorisations, juger si le Gas était raisonnable, savoir exactement ce qu'il signait, et confirmer à plusieurs reprises lors d'opérations en plusieurs étapes comme le bridging, l'échange, le staking, la réclamation de récompenses, etc. Toute méprise à une étape pouvait entraîner un échec de l'opération et un risque de perte d'actifs.
Ce qu'Ethereum tente de faire maintenant, c'est précisément de déplacer une partie de cette complexité vers la couche protocolaire, permettant aux portefeuilles de fournir une meilleure abstraction interactive aux utilisateurs, basée sur des capacités sous-jacentes plus standardisées et plus natives.
C'est aussi pourquoi la limite de Gas, les BAL, l'ePBS, les Keyed Nonces, les Frame Transactions, l'abstraction de compte native et l'interopérabilité inter-L2, qui semblent appartenir à différents modules techniques, servent en réalité tous la même chose : permettre à Ethereum de supporter des scénarios d'utilisation sur la chaîne plus complexes, sans sacrifier la décentralisation et la sécurité.
Concrètement, en plaçant ces dynamiques ensemble, on constate que les priorités récentes d'Ethereum ne sont pas dispersées :
- L'augmentation de la limite de Gas résout la capacité d'exécution du réseau principal et la pression sur les frais ;
- Les BAL, l'ePBS, l'EIP-8037 résolvent la question de comment maintenir la vérifiabilité des nœuds et une croissance contrôlée de l'état pendant le processus de mise à l'échelle ;
- Les Keyed Nonces et les Frame Transactions résolvent les goulots d'étranglement au niveau protocolaire pour le modèle de compte, les protocoles de confidentialité et les portefeuilles intelligents ;
- L'abstraction de compte native et l'interopérabilité inter-L2 pointent davantage vers les améliorations d'expérience que l'utilisateur ordinaire pourra réellement ressentir.
Cela signifie aussi qu'Ethereum entre dans une nouvelle phase.
Après tout, ces dernières années, le marché s'est plus concentré sur la mise à l'échelle des L2, la réduction des frais avec les Blobs et les récits de modularité. Les utilisateurs se sont aussi habitués à transférer des actifs entre différentes L2, à chercher des environnements d'interaction à moindre coût. Mais avec la poursuite de l'augmentation de la limite de Gas du réseau principal, l'avancement des mises à niveau comme Glamsterdam, et l'évolution continue des solutions d'abstraction de compte et d'interopérabilité, la question à laquelle Ethereum répond n'est plus seulement « comment rendre les transactions moins chères », mais « comment rendre l'expérience sur la chaîne plus semblable à un tout cohérent ».
Dans ce processus, l'importance des portefeuilles sera sans aucun doute encore amplifiée.
Parce que le portefeuille n'est pas seulement l'entrée de l'utilisateur dans Ethereum, c'est aussi l'interface par laquelle les capacités du protocole sont vraiment comprises et utilisées par l'utilisateur. À l'avenir, plus les mises à niveau sous-jacentes seront complexes, plus elles devront être transformées par le portefeuille en des invites de signature plus claires, des chemins de transaction plus compréhensibles, une identification des risques plus en amont, et une expérience d'interaction sur la chaîne plus fluide.
À méditer ensemble.
