Comment comprendre la prochaine étape de l'évolutivité d'Ethereum ?

Rédaction : imToken

Objectivement, au cours de la période récente, la perception intuitive de nombreux utilisateurs vis-à-vis d’Ethereum ne provenait pas tant de la feuille de route ou des réunions de développeurs, mais de multiples opérations concrètes sur la chaîne.

Par exemple, ces deux dernières années, la baisse progressive des frais de gas lors des transferts, l’amélioration de l’interopérabilité entre chaînes, etc., c’est aussi pour cela que l’expansion d’Ethereum n’a jamais été une simple « course à la performance » — pour l’utilisateur lambda, des TPS plus élevées, des blocs plus grands, une architecture sous-jacente plus complexe, n’ont de sens que lorsqu’elles se traduisent réellement par des coûts plus faibles, une utilisation plus fluide et une expérience de portefeuille plus sûre.

Et récemment, une série de nouvelles dynamiques d’Ethereum pointent justement vers une tentative de systématiser le transfert de la complexité, autrefois assumée par le portefeuille, les DApps, les relais tiers et l’utilisateur lui-même, vers le niveau du protocole.

Cela inclut notamment les Keyed Nonces, la mise à niveau Glamsterdam autour d’un seuil de 200 millions de gas limit, ainsi que la feuille de route de 2026 qui insiste sur l’abstraction native des comptes, l’interopérabilité entre L2, le renforcement de la sécurité L1, et d’autres lignes directrices encore.

1. Gas Limit porté à 200 millions ?

Commençons par ce qui est le plus perceptible pour l’utilisateur : le Gas Limit.

Comme chacun le sait, dans 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 le Gas Limit d’un bloc est fixe, c’est-à-dire que le nombre de places disponibles est limité : plus il y a de places, plus de passagers peuvent être transportés en même temps ; si les places sont rares, chacun doit faire une enchère pour la même place, ce qui fait monter le prix du gas.

Théoriquement, augmenter la limite de gas d’un bloc permettrait d’améliorer considérablement la performance du réseau principal d’Ethereum. Cependant, dans le contexte du développement massif des solutions L2 et autres voies, Ethereum a toujours été prudent, en déplaçant une grande partie de la pression d’expansion vers ces couches secondaires.

En examinant la courbe d’expansion du Gas Limit d’Ethereum, on constate qu’en septembre 2019, le Gas Limit est passé pour la première fois de 8 millions à 10 millions, et ce n’est qu’aujourd’hui, après 7 ans, qu’il est passé de 8 millions à 60 millions, notamment avec une accélération en 2025 — 30 millions en février, puis 36 millions, puis 45 millions en juillet, et enfin 60 millions après la mise à niveau Fusaka en décembre.

On peut dire que la majorité de cette expansion a été réalisée en 2025. Bien sûr, cette année est cruciale dans l’histoire d’Ethereum : la mise à niveau Pectra en mai, suivie de Fusaka 7 mois plus tard, montre que la Fondation Ethereum, après des changements importants dans sa direction, reste capable de pousser des mises à jour majeures, marquant aussi l’entrée officielle dans un rythme de « deux hard forks par an ».

Selon le résumé de l’interopérabilité de Soldøgn publié par la Fondation Ethereum le 2 mai, plus de 100 contributeurs clés d’Ethereum ont participé à une réunion d’interopérabilité sur l’île de Svalbard, en Norvège, centrée sur la mise en œuvre multi-clients de Glamsterdam, les tests et l’alignement des paramètres. À la fin de la réunion, un consensus stratégique s’est formé autour d’un Gas Limit de 200 millions pour Glamsterdam.

Cela signifie que, si tout se passe bien, la capacité d’exécution de l’Ethereum L1 pourrait passer de ses 60 millions actuels à 200 millions, voire plus. Sur une échelle plus longue, l’attitude publique de l’écosystème Ethereum vis-à-vis du Gas Limit devient beaucoup plus « agressive » : la proposition EIP-9698 suggère même une augmentation par dix tous les deux ans, visant 3,6 milliards en 2029, soit 50 fois le niveau actuel.

Mais il faut souligner que augmenter le Gas Limit ne consiste pas simplement à agrandir le bloc.

Si l’on se contente d’augmenter brutalement la capacité de calcul d’un bloc, à court terme, cela pourrait réduire les coûts, mais à long terme, cela alourdirait la charge des nœuds, entraînerait une croissance excessive de l’état, et rendrait plus difficile pour l’utilisateur lambda de faire fonctionner un nœud, ce qui finirait par affaiblir la décentralisation fondamentale d’Ethereum.

Ainsi, la stratégie d’expansion de Glamsterdam repose sur une série de mesures combinées :

• ePBS (séparation du proposeur et du constructeur de blocs) pour rendre la construction et la validation plus sûres ;
• les Block-Level Access Lists (BAL) pour anticiper l’accès aux comptes et aux données lors de l’exécution, permettant la lecture parallèle, la validation parallèle des transactions et le calcul parallèle des racines d’état ;
• l’EIP-8037, qui augmente le coût des opérations de création d’état pour éviter une croissance trop rapide de l’état après l’augmentation du Gas Limit.

En fin de compte, Ethereum ne cherche pas simplement à « accueillir plus de transactions », mais à réfléchir à comment augmenter la capacité du réseau tout en maintenant la facilité de participation pour les nœuds et la vérifiabilité du système.

C’est la différence fondamentale entre la voie d’expansion d’Ethereum et celle de nombreux autres blockchains haute performance, qui privilégient souvent le sacrifice du coût de validation pour maximiser le débit apparent. Ethereum vise à augmenter la capacité tout en restant accessible et vérifiable par des nœuds ordinaires.

2. Keyed Nonces : transformer « une file d’attente » en « plusieurs canaux »

Si le Gas Limit concerne « combien peut contenir un bloc », alors les Keyed Nonces s’intéressent à une question encore plus fine mais cruciale : comment faire la file d’attente d’une transaction ?

Dans Ethereum, le nonce peut être compris comme le « numéro de série » d’une transaction d’un compte, empêchant la double exécution et assurant que les transactions d’un même compte soient traitées dans l’ordre.

Ce mécanisme est simple à comprendre dans le cas d’un transfert classique : la première transaction, la deuxième, la troisième, etc., s’enchaînent dans l’ordre.

Mais le problème apparaît lorsque le compte devient plus complexe, par exemple avec des transactions privées, des portefeuilles intelligents, des clés de session, des opérations en lot, ou des paiements tiers. Dans ce cas, un seul nonce linéaire peut devenir un goulot d’étranglement. La proposition EIP-8250 introduit donc les Keyed Nonces, dont l’idée centrale est de remplacer la seule file d’attente de nonce par une structure (nonce_key, nonce_seq), où :

• nonce_key à 0 correspond au nonce traditionnel ;
• un nonce_key non nul permet de gérer indépendamment une séquence de nonce via un protocole dédié, chaque clé étant indépendante et résistante à la relecture.

Ce concept, technique en apparence, peut être illustré par une métaphore : un compte comme une banque avec une seule fenêtre, où toutes les opérations doivent faire la queue ; Keyed Nonces, c’est comme répartir ces opérations dans plusieurs fenêtres, pour les transferts, retraits privés, autorisations de session, exécutions en lot, chacun dans son propre canal.

Cela est particulièrement important pour les protocoles de confidentialité, car pour éviter de lier directement l’activité de l’utilisateur à une adresse publique, plusieurs utilisateurs peuvent partager une même adresse d’expéditeur, mais avec un seul nonce. Si ce dernier est unique, cela peut entraîner des conflits ou des invalidations de transactions.

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 les conflits de file d’attente au niveau du protocole.

Vitalik lui-même voit cette innovation comme une étape plus large : il indique que les Keyed Nonces « ne sont pas seulement une meilleure prise en charge des protocoles de confidentialité, mais aussi une étape vers une nouvelle stratégie d’expansion de l’état d’Ethereum — en créant des types de stockage spécialisés pour différents cas d’usage, tout en maintenant la décentralisation du protocole et en maximisant la scalabilité. »

En résumé, on peut voir cela comme une solution à la fois pour le « volume » de blocs (Gas Limit) et pour la « forme » de l’état : Ethereum ne veut pas seulement accueillir plus de transactions, mais aussi plus de types de transactions.

3. Quel impact pour l’utilisateur lambda ?

Pour l’écosystème Ethereum, beaucoup de mises à jour protocolaires semblent éloignées de l’utilisateur moyen. Mais en fin de compte, tout se traduit par l’expérience du portefeuille.

Car l’entrée principale de l’utilisateur dans Ethereum n’est pas la feuille de route, ni la réunion de développeurs, mais chaque transfert, autorisation, signature, interaction cross-chain ou DApp dans le portefeuille. Autrement dit, les changements au niveau du protocole ne prennent tout leur sens que lorsqu’ils se traduisent en opérations plus claires, plus fluides, plus sûres dans le portefeuille.

Par exemple, l’abstraction des comptes, qui est aujourd’hui très connue, ne vise pas à faire comprendre plus de termes techniques à l’utilisateur, mais à lui permettre d’utiliser plus naturellement ses comptes sur la chaîne. Ainsi, ces dernières années, la gestion en lot, le paiement de gas par un tiers, les mécanismes de récupération, les différentes méthodes de signature, l’autorisation de session, et des stratégies de sécurité plus flexibles deviennent progressivement des capacités fondamentales dans les portefeuilles.

De même, pour Keyed Nonces, qui semble une optimisation très technique de la file d’attente des comptes, son impact potentiel sur l’expérience utilisateur n’est pas abstrait. Beaucoup d’utilisateurs ont déjà rencontré des situations où une transaction tarde à confirmer, ou où une opération est bloquée, ou encore où ils veulent annuler ou accélérer une transaction sans comprendre la relation entre nonce, gas et remplacement. Lorsqu’on opère plusieurs transactions en parallèle, une étape échouée peut bloquer tout le processus.

Pour l’utilisateur lambda, ces problèmes donnent l’impression que le portefeuille ou la chaîne sont peu pratiques, mais en réalité, ils sont liés à la conception du modèle de compte avec un nonce linéaire unique. La direction que prennent Keyed Nonces, c’est de permettre à un compte de ne plus suivre une seule file, mais plusieurs canaux parallèles selon le contexte.

Ainsi, à l’avenir, les transferts classiques, les autorisations DApp, les transactions privées, en lot ou avec paiement de gas, pourront théoriquement disposer d’un espace d’exécution plus indépendant, réduisant les blocages et conflits.

Cela ouvrira sans doute de nouvelles possibilités pour la conception de portefeuilles intelligents.

Plus important encore, ces capacités, qui auparavant nécessitaient une coordination entre portefeuille, DApp, relais et utilisateur, seront désormais intégrées dans le protocole, permettant au portefeuille de fournir une interface plus claire, plus intuitive, avec des indications de signature plus compréhensibles, des chemins de transaction plus explicites, une détection des risques en amont, et une expérience d’interaction plus fluide.

C’est pourquoi, Gas Limit, BAL, ePBS, Keyed Nonces, Frame Transactions, l’abstraction native des comptes et l’interopérabilité entre L2, bien qu’appartenant à des modules techniques différents, convergent tous vers un même objectif : faire d’Ethereum un réseau capable de supporter des scénarios d’utilisation plus complexes, sans sacrifier la décentralisation ni la sécurité.

En regroupant ces dynamiques, on constate que la priorité récente d’Ethereum n’est pas dispersée :

• l’augmentation du Gas Limit pour répondre à la capacité et aux coûts ;
• BAL, ePBS, EIP-8037 pour maintenir la vérifiabilité et contrôler la croissance de l’état lors de l’expansion ;
• Keyed Nonces et Frame Transactions pour résoudre les limites du modèle de compte, de la confidentialité et des portefeuilles intelligents ;
• l’abstraction native des comptes et l’interopérabilité L2 pour améliorer concrètement l’expérience utilisateur.

Cela marque une nouvelle étape pour Ethereum.

Après plusieurs années où le marché s’est concentré sur l’expansion L2, la réduction des coûts de Blob, et la modularité, avec une migration progressive des actifs entre différentes L2, Ethereum répond désormais à une question plus globale : « Comment faire que l’expérience sur la chaîne ressemble à un tout cohérent ? »

Dans ce processus, l’importance du portefeuille sera encore renforcée.

Car le portefeuille n’est pas seulement la porte d’entrée dans Ethereum, mais aussi l’interface par laquelle les capacités du protocole sont comprises et exploitées. Plus les évolutions sous-jacentes seront complexes, plus il faudra que le portefeuille se transforme en une interface claire : indications de signature, chemins de transaction compréhensibles, détection proactive des risques, et une expérience d’interaction plus fluide.

Restons mobilisés.