Rédigé par : imToken
Objectivement, ces derniers temps, les impressions directes de nombreux utilisateurs sur Ethereum ne viennent souvent pas de la feuille de route ou des réunions de développeurs, mais plutôt d'opérations spécifiques sur la chaîne.
Par exemple, ces deux dernières années, tout le monde a pu constater que les frais Gas pour les transferts sont de plus en plus bas, que l'expérience d'interopérabilité cross-chain s'est améliorée, etc. C'est pourquoi l'augmentation de capacité d'Ethereum n'a jamais été un simple problème 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 évolutions d'Ethereum pointent précisément vers sa tentative de systématiquement repousser vers la couche protocolaire la complexité qui était autrefois supportée par les portefeuilles, les DApps, les relais tiers et les utilisateurs eux-mêmes.
Cela inclut notamment les Keyed Nonces, auxquels Vitalik a participé, le consensus directionnel autour du « plancher de 200 millions de Gas Limit » lors de la mise à niveau Glamsterdam, ainsi qu'une série de pistes filigranes dans la feuille de route 2026, soulignant continuellement l'abstraction de compte native, l'interopérabilité cross-L2 et le renforcement de la sécurité de la L1.
I. Augmenter la limite de Gas à 200 millions ?
Commençons par l'aspect le plus directement perceptible pour l'utilisateur : la limite de Gas.
Comme chacun 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 Gas Limit de chaque bloc Ethereum est fixe, c'est-à-dire que les places sont limitées : plus il y a de places, plus on peut transporter de passagers simultanément ; plus les places sont rares, plus il faut enchérir pour la même place, et les frais de Gas montent en flèche.
Théoriquement, l'augmentation de la limite de Gas par bloc augmenterait directement et massivement les performances du mainnet Ethereum. Cependant, par le passé, dans le contexte du fort développement de la feuille de route L2, Ethereum a été plutôt prudent et retenu sur ce point, poussant intentionnellement la plupart des pressions de scalabilité vers la piste L2.
En regardant la courbe d'augmentation du Gas Limit d'Ethereum, on constate qu'après que le Gas Limit du réseau soit passé de 8 millions à 10 millions pour la première fois en septembre 2019, il a fallu attendre cette année, soit 7 ans, pour qu'il passe de 8 millions à 60 millions. Notamment, ce n'est qu'en 2025 qu'il est vraiment entré 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 plupart de l'augmentation de capacité s'est concentrée sur 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, après un changement majeur de leadership, conservait la capacité de pousser des mises à jour importantes, marquant également l'entrée officielle d'Ethereum dans le rythme de développement accéléré de « deux hard forks par an » (lecture complémentaire : « Ethereum 2026 : Décrypter la dernière feuille de route protocolaire de l'EF, entrée dans l'ère des « mises à niveau d'ingénierie » ? »).
Source : Etherscan
Et selon le Soldøgn Interop Recap publié par l'Ethereum Foundation le 2 mai, plus de 100 contributeurs clés d'Ethereum ont participé à une réunion d'interopérabilité sur la mise à niveau Glamsterdam dans l'archipel du Svalbard en Norvège. L'objectif principal était d'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 déjà formé un consensus directionnel autour d'un Gas Limit de 200 millions après Glamsterdam.
Cela signifie que, si les prochaines étapes se déroulent bien, la capacité d'exécution de la L1 d'Ethereum pourrait passer du Gas Limit actuel d'environ 60 millions à un niveau de l'ordre de 200 millions. Sur une échelle de temps plus longue, l'attitude de l'écosystème Ethereum envers la discussion publique sur le Gas Limit est clairement devenue beaucoup plus « agressive ». La proposition EIP-9698 suggère même une « multiplication par dix tous les deux ans », visant à porter le Gas Limit à 3,6 milliards d'ici 2029, soit 50 fois le niveau actuel.
Mais il est important de souligner ici qu'augmenter le Gas Limit ne se résume pas à simplement agrandir les blocs.
Si l'on augmentait brutalement la quantité de calcul que chaque bloc peut contenir, à court terme, cela pourrait réduire les frais, mais à long terme, cela entraînerait une charge plus lourde pour les nœuds, une inflation des données d'état, et signifierait que les utilisateurs ordinaires auraient plus de difficultés à exécuter un nœud, affaiblissant finalement le fondement le plus central d'Ethereum : la décentralisation.
L'approche de scalabilité 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 plus sûrement des blocs plus grands ;
- Les Block-Level Access Lists (BAL) enregistrent à l'avance les comptes et emplacements de stockage qui seront consultés lors de l'exécution d'un bloc, permettant ainsi des lectures disque parallèles, des validations de transactions parallèles et des calculs de racine d'état parallèles ;
- Et l'EIP-8037, en augmentant le coût des opérations liées à la création d'état, évite une croissance trop rapide de l'état après l'augmentation du Gas Limit.
En fin de compte, Ethereum ne cherche pas seulement à « contenir plus de transactions », il 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 la différence fondamentale entre la feuille de route de scalabilité d'Ethereum et le récit de nombreuses chaînes hautes performances. Elle n'a jamais cherché à sacrifier le coût de la validation pour obtenir un débit de surface, mais plutôt, dans la mesure du possible, à maintenir la participation des nœuds ordinaires et la vérifiabilité du système, tout en augmentant la capacité de charge du mainnet lui-même.
II. Keyed Nonces : Transformer « une file d'attente » en « plusieurs canaux »
Si le Gas Limit résout la question de « combien un bloc peut contenir », les Keyed Nonces s'intéressent à un autre problème plus détaillé mais crucial : comment les transactions doivent-elles être mises en file d'attente ?
Comme chacun sait, dans Ethereum, le nonce peut être simplement compris comme le « numéro de série » des transactions d'un compte. Son rôle est d'empêcher l'exécution répétée d'une même transaction et de garantir que les transactions envoyées 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 transaction, troisième transaction, etc., dans l'ordre.
Mais le problème est que lorsque les capacités d'un compte deviennent plus complexes, impliquant par exemple des transactions privées, des portefeuilles intelligents, des clés de session, des opérations par lots, des paiements par des tiers, le nonce linéaire unique peut devenir un goulot d'étranglement. Ainsi, les Keyed Nonces proposés par l'EIP-8250 ont pour idée centrale de transformer le fait qu'un compte n'avait qu'une seule file d'attente de nonce, en la possibilité d'avoir plusieurs domaines de nonce.
Plus précisément, ils remplacent le sender nonce 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 que les clés non nulles peuvent choisir des séquences de nonce gérées indépendamment par le protocole. Les transactions sous des clés différentes sont indépendantes les unes des autres et ne s'affectent pas mutuellement en termes de protection contre la relecture.
Cela peut sembler technique, mais on peut le comprendre par une analogie de la vie quotidienne : auparavant, un compte était comme une banque avec un seul guichet, toutes les opérations devaient faire la même queue ; les Keyed Nonces, c'est comme attribuer différentes opérations à différents guichets : transfert, retrait privé, autorisation de session, exécution par lots peuvent chacun emprunter leur propre canal.
Ceci est particulièrement important pour les protocoles de confidentialité. En effet, pour éviter de lier directement les activités on-chain d'un utilisateur à une adresse publique, 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 intégrée dans un bloc, cela peut invalider ou bloquer les transactions d'autres utilisateurs encore en attente.
Et 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 du protocole.
La vision de Vitalik lui-même à ce sujet est encore plus large. En présentant l'EIP-8250, il a clairement déclaré 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 scalabilité de l'état pour Ethereum — en créant des types de stockage spécialement optimisés pour différents cas d'usage, afin d'atteindre une scalabilité extrême tout en préservant la décentralisation du protocole. »
En d'autres termes, on peut simplement comprendre que le Gas Limit résout la « taille des blocs », tandis que les Keyed Nonces explorent la « forme de l'état » — ce qu'Ethereum devra supporter à l'avenir, ce n'est 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 finissent toutes par se traduire dans l'expérience du portefeuille.
Parce que le véritable point d'entrée des utilisateurs vers Ethereum n'est pas les EIP, les clients ou les réunions de développeurs, mais chaque transfert, autorisation, signature, interaction cross-chain et avec les DApps dans le portefeuille. Autrement dit, les changements au niveau du protocole ne réalisent véritablement la transformation d'une mise à niveau technique en une mise à niveau de l'expérience utilisateur que lorsqu'ils sont traduits, au niveau du portefeuille, en une expérience d'utilisation plus claire, plus fluide et plus sûre.
Par exemple, l'abstraction de compte, dont tout le monde parle aujourd'hui, n'existe pas pour que l'utilisateur comprenne plus de termes techniques, mais pour qu'à l'avenir, il puisse utiliser son compte on-chain de manière plus naturelle. C'est pourquoi ces dernières années, les transactions par lots, le paiement du Gas par des jetons, les mécanismes de récupération, les différentes méthodes de signature, les autorisations 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. Car aujourd'hui, de nombreux utilisateurs ont probablement rencontré des situations similaires lors d'opérations on-chain : une transaction qui met du temps à être confirmée, bloquant les transactions suivantes ; vouloir annuler ou accélérer une transaction sans comprendre les relations entre nonce, Gas et remplacement de transaction ; surtout lors d'opérations multiples parallèles, une étape en échec peut affecter tous les processus suivants.
Pour l'utilisateur ordinaire, ces problèmes semblent être du « portefeuille peu pratique » ou de la « chaîne peu pratique », mais ils sont en réalité liés à la conception du nonce linéaire unique dans le modèle de compte d'Ethereum. La direction représentée par les Keyed Nonces consiste à permettre aux comptes de ne plus devoir 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 courantes de transfert, d'autorisation DApp, de transaction privée, de transaction par lots, de paiement de Gas par des tiers pourraient théoriquement avoir des espaces d'exécution plus indépendants, réduisant la probabilité de blocages et de conflits mutuels.
Cela ouvrira sans aucun doute davantage l'espace de conception des portefeuilles intelligents.
Plus important encore, par le passé, ces capacités nécessitaient souvent que le portefeuille, la DApp, les services de relais et l'utilisateur partagent la complexité. L'utilisateur devait comprendre la portée des autorisations, juger si le Gas était raisonnable, savoir exactement ce qu'il signait, et reconfirmiter à chaque étape dans les opérations multi-étapes comme le cross-chain, l'échange, le staking, la récupération de récompenses, etc. Toute mécompréhension à une étape pouvait entraîner un échec de l'opération et un risque de perte d'actifs.
Ce qu'Ethereum essaie de faire maintenant, c'est précisément de repousser une partie de cette complexité vers la couche protocolaire, permettant aux portefeuilles de fournir une meilleure abstraction d'interaction à l'utilisateur, basée sur des capacités sous-jacentes plus standardisées et plus natives.
C'est aussi pourquoi le Gas Limit, les BAL, l'ePBS, les Keyed Nonces, les Frame Transactions, l'abstraction de compte native et l'interopérabilité cross-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 on-chain plus complexes sans sacrifier la décentralisation et la sécurité.
Concrètement, en considérant ces dynamiques ensemble, on constate que les priorités récentes d'Ethereum ne sont pas dispersées :
- L'augmentation du Gas Limit résout la capacité d'exécution du mainnet et la pression sur les frais ;
- Les BAL, l'ePBS, l'EIP-8037 résolvent comment maintenir la vérifiabilité des nœuds et une croissance contrôlée de l'état pendant le processus de scalabilité ;
- Les Keyed Nonces et les Frame Transactions résolvent les goulots d'étranglement au niveau du protocole pour le modèle de compte, les protocoles de confidentialité et les portefeuilles intelligents ;
- L'abstraction de compte native et l'interopérabilité cross-L2 visent davantage l'amélioration de l'expérience que l'utilisateur ordinaire peut 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 davantage concentré sur la scalabilité L2, la réduction des frais par les Blobs et le récit de la modularité. Les utilisateurs se sont aussi habitués à transférer des actifs entre différentes L2 et à rechercher des environnements d'interaction à moindre coût. Mais avec la poursuite de l'augmentation du Gas Limit du mainnet, 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 faire en sorte que l'expérience on-chain ressemble davantage à un tout cohérent ».
Dans ce processus, l'importance du portefeuille sera sans aucun doute encore amplifiée.
Car le portefeuille n'est pas seulement le point d'entrée de l'utilisateur dans Ethereum, c'est aussi l'interface par laquelle les capacités du protocole sont réellement comprises et utilisées par l'utilisateur. À l'avenir, plus les mises à niveau sous-jacentes seront complexes, plus elles devront être traduites par le portefeuille en invitations de signature plus claires, des chemins de transaction plus compréhensibles, une identification des risques plus en amont, et une expérience d'interaction on-chain plus fluide.
À méditer ensemble.
