« Les L2 sont-ils en train de grignoter la valeur du L1 ? » « Ethereum est-il en train de perdre sa composabilité globale ? » Durant les deux années où les L2 ont été au sommet de leur popularité, cette anxiété a pratiquement envahi toute la communauté Ethereum.
À cette époque, dans le cadre de mise à l’échelle d’Ethereum, le L1 était la couche de règlement stable mais coûteuse, et les L2, en tant que couches d'exécution bon marché et efficaces, ont certes donné à Ethereum plus d'espace de bloc, mais ont également progressivement fait perdre l'expérience complète de « une seule chaîne ».
C'est pourquoi, ces deux dernières années, ces questions ont continué à pousser Ethereum à reconsidérer la relation entre L1 et L2.
D'une part, Ethereum L1 continue d'augmenter la limite de Gas, de promouvoir la statelessness et la vérification zkEVM, ne se contentant plus de servir de base de règlement à faible débit ; d'autre part, les discussions au sein de la communauté sont de plus en plus vives. Début d'année, Vitalik a déclaré sans détour qu'avec l'amélioration de la capacité de mise à l'échelle du réseau principal d'Ethereum, certaines prémisses de la feuille de route établie il y a cinq ans, qui considérait les L2 comme le principal moyen de mise à l'échelle, avaient changé (lecture complémentaire « Comprendre la réflexion de Vitalik sur les L2 : dire adieu à la fragmentation, une remise en ordre tournée vers le Native Rollup dans la nouvelle phase »).
Et récemment, Barnabé Monnot, chercheur chez Ethereum, a déclaré qu'il était nécessaire de reconsidérer la relation à long terme entre L1 et L2, y compris comment les L2 devraient créer de la valeur à l'avenir, pourquoi le finalité (finality) doit être considérablement raccourcie, et si, avec les systèmes de preuve entrant progressivement dans le processus de validation du réseau principal, le L1 pourrait également devenir une sorte de « Rollup de lui-même ».
Bien que ces points de vue ne correspondent pas encore à une feuille de route protocolaire déterminée, ils offrent une perspective d'observation précieuse.
En fin de compte, le problème auquel Ethereum est confronté aujourd'hui n'est plus seulement de continuer à augmenter l'espace de bloc, mais de savoir comment réorganiser la division du travail entre L1, L2, couche d'exécution et couche de règlement lorsque les transactions, les actifs et les états des utilisateurs sont dispersés dans des environnements d'exécution de plus en plus nombreux.

I. Ethereum n'« abandonne » pas les L2, mais doit trouver un nouveau positionnement
Pour être réaliste, lors de la formation initiale de la feuille de route de mise à l'échelle d'Ethereum centrée sur les Rollups, la tâche la plus importante des L2 était relativement simple : fournir plus d'espace de transaction et à moindre coût pour Ethereum.
Dans les conditions techniques de l'époque, cette division du travail était tout à fait raisonnable.
Parce que tous les validateurs d'Ethereum devaient réexécuter les transactions du L1, la capacité de débit du réseau principal ne pouvait pas être augmentée de manière radicale à court terme. Les Rollups, quant à eux, pouvaient exécuter des transactions par lots hors chaîne, ne soumettant au réseau principal que les données compressées ou des engagements d'état, réduisant considérablement le coût unitaire des transactions tout en conservant certains attributs de sécurité d'Ethereum.
Ainsi, la mise à l'échelle a progressivement suivi deux voies parallèles : le L1 restait modéré, priorisant la décentralisation et la sécurité, tandis que les L2 prenaient en charge les nouvelles transactions, réduisant continuellement les coûts grâce aux Blobs, à la compression de données et aux technologies de preuve.
Mais aujourd'hui, les prémisses de cette division du travail ont changé.
La Fondation Ethereum a réorganisé les travaux protocolaires en 2026, fusionnant les travaux relativement indépendants « Mise à l'échelle du L1 » et « Mise à l'échelle des Blobs » en une seule feuille de route Scale unifiée. L'augmentation de la limite de Gas, l'élargissement de la disponibilité des données, l'optimisation du client d'exécution, la promotion de la statelessness et du client attester zkEVM ont été placés dans le même cadre de mise à l'échelle.
En d'autres termes, Ethereum ne considère plus la mise à l'échelle du L1 et des L2 comme deux tâches distinctes, mais commence à répartir les capacités d'exécution, de consensus et de données sous l'angle de l'ensemble du système.
Ce changement ne signifie pas qu'Ethereum prévoit d'abandonner les L2 ou de réabsorber toutes les activités sur le réseau principal. Au contraire, cela signifie qu'il sera difficile pour les L2 de continuer à justifier leur valeur à long terme uniquement par des « transactions plus rapides et du Gas moins cher ».
Après tout, si le L1 lui-même peut augmenter sa capacité d'exécution de plusieurs ordres de grandeur tout en préservant la sécurité et la décentralisation, alors l'exécution EVM standard et l'espace de bloc à faible coût ne seront plus des capacités exclusives des L2 ; ce que les L2 devront fournir se tournera davantage vers des besoins différenciés que le L1 a du mal à satisfaire de manière uniforme, tels que l'optimisation pour des applications spécifiques, les fonctionnalités de confidentialité ainsi que des modèles de gouvernance et économiques plus flexibles.
La dernière déclaration de la Fondation Ethereum cette année sur la relation entre L1 et L2 met également clairement l'accent sur ce point. Par le passé, l'objectif principal des L2 était de mettre à l'échelle Ethereum, la différenciation et la personnalisation n'étant que des valeurs secondaires ; aujourd'hui, il s'agit de fournir des fonctionnalités différenciées tout en continuant à contribuer à une capacité d'extension supplémentaire.
En contrepartie, le L1 doit devenir un hub mondial suffisamment puissant, sans autorisation et hautement résilient, portant le règlement, l'état partagé, la liquidité et la DeFi.
Cela fait en réalité passer les L2 d'une catégorie technologique uniforme à un spectre continu plus complexe :
- À une extrémité du spectre se trouvent les Rollups qui héritent autant que possible des attributs de sécurité d'Ethereum ; ils souhaitent réduire les comités de sécurité multi-signatures, ouvrir des mécanismes de preuve sans autorisation et garantir que les utilisateurs puissent toujours se retirer via le L1 même si l'opérateur cesse de fonctionner.
- Au milieu se trouvent des environnements d'exécution qui héritent de certains attributs d'Ethereum selon les besoins commerciaux ; ils peuvent avoir des droits de gestion plus forts, des séquenceurs indépendants ou des designs de conformité spécifiques, en échange de performances, de confidentialité et de flexibilité opérationnelle.
- À l'autre extrémité, il peut s'agir simplement de chaînes utilisant l'EVM, utilisant les actifs d'Ethereum ou accédant à certaines infrastructures inter-chaînes, mais étant relativement indépendantes en matière de sécurité et de règlement.
C'est pourquoi on dit qu'Ethereum ne cherche pas à abandonner les L2, mais à redéfinir clairement la division du travail. En fin de compte, au cours des 3 à 5 dernières années, les L2 représentaient d'abord une technologie de mise à l'échelle, tandis qu'à l'avenir, ils représenteront plus probablement un ensemble d'environnements d'exécution établissant différentes relations de sécurité, de règlement et de liquidité avec Ethereum.

II. L'interopérabilité n'est pas seulement le cross-chain, mais la manière dont les états se font confiance
Cependant, alors qu'Ethereum s'étend en un système composé d'un grand nombre de L2, un autre problème récurrent émerge progressivement : le nombre croissant de L2 fragmentent inévitablement la liquidité, l'état des comptes et l'expérience applicative.
Cela s'est clairement manifesté dans l'utilisation pratique de ces dernières années. Par exemple, un utilisateur peut détenir des actifs sur une chaîne, utiliser une application sur une autre, et avoir besoin d'aller sur une troisième pour effectuer une transaction, au point qu'une même stablecoin a différentes versions sur différents réseaux, et qu'un même compte doit gérer différents Gas Tokens, des ponts inter-chaînes et des points d'entrée d'actifs.
C'est pourquoi l'interopérabilité devient une partie de plus en plus importante de la feuille de route d'Ethereum.
L'équipe protocolaire d'Ethereum a concentré les priorités de la feuille de route Improve UX 2026 sur deux directions : l'abstraction de compte native et l'interopérabilité, et estime que la clé pour résoudre la fragmentation des L2 réside dans le fait de faire à nouveau ressentir Ethereum comme « une seule chaîne ». Cette vision repose sur la maturation de l'architecture d'intentions (intents).
- Parmi celles-ci, l'Open Intents Framework permet aux utilisateurs de simplement déclarer le résultat souhaité, par exemple « convertir tel actif sur la chaîne A en USDC sur la chaîne B », puis laisser les solveurs en arrière-plan effectuer le calcul du chemin, l'avance de fonds, l'exécution et le rééquilibrage des fonds (lecture complémentaire « Quand les « intentions » deviennent la norme : comment l'OIF met fin à la fragmentation inter-chaînes et ramène le Web3 à l'intuition utilisateur ? »).
- Allant plus loin, la couche d'interopérabilité Ethereum (Ethereum Interoperability Layer - EIL) tente de construire une couche de transmission sans confiance (trustless), avec pour objectif de donner aux transactions cross-L2 une expérience indiscernable de celle des transactions sur une seule chaîne (lecture complémentaire « La feuille de route Interop d'Ethereum : comment débloquer le « dernier kilomètre » de l'adoption massive »).
Du côté des comptes, l'EIP-7702 dans la mise à niveau Pectra permet déjà aux EOA traditionnels d'exécuter temporairement du code de contrat intelligent, prenant en charge le traitement par lots de transactions, le paiement de Gas par un tiers et les mécanismes de récupération ; les futures propositions d'abstraction de compte native, représentées par l'EIP-8141, tentent d'intégrer davantage la logique des comptes intelligents dans le protocole, faisant progressivement des portefeuilles à contrat intelligent la forme de compte par défaut, et réduisant la dépendance à des services supplémentaires de Bundlers, Relayers et intermédiaires.
Les règles de confirmation rapide (fast confirmation) du L1 visent à fournir un signal de confirmation plus sécurisé en quelques secondes ou dizaines de secondes, avant la finalité complète, ce qui pourrait raccourcir le temps d'attente des applications dans la plupart des scénarios normaux. Cela bénéficierait directement à toutes les applications cross-chain dépendant de la finalité du L1, ce qui est crucial pour les ponts inter-chaînes, le règlement des stablecoins, les transactions d'actifs RWA.
Car le goulot d'étranglement réel de nombreuses interactions inter-chaînes n'est pas de savoir si le message peut être envoyé, mais quand la chaîne cible peut être suffisamment certaine que l'état sur la chaîne source ne pourra plus être annulé.
Un point souvent négligé est que l'inclusion d'une transaction dans un bloc n'équivaut pas à ce qu'elle ait atteint la finalité. Du point de vue de l'utilisateur, une transaction peut apparaître comme réussie après quelques secondes, mais pour les ponts, les exchanges, les protocoles de prêt et les solveurs inter-chaînes, ils doivent encore évaluer la probabilité que cette transaction soit victime d'une réorganisation de bloc, et s'ils peuvent en conséquence libérer des actifs sur une autre chaîne ou exécuter l'opération suivante.
C'est pourquoi aujourd'hui, de nombreux services cross-chain qui semblent proches d'un « règlement instantané » n'attendent pas réellement que la chaîne source termine le règlement final, mais reposent sur des solveurs ou des fournisseurs de liquidités qui avancent les fonds. Simplement, ce mécanisme optimise l'expérience utilisateur sans faire disparaître le temps d'attente sous-jacent.

Ainsi, l'objectif à long terme d'Ethereum est de raccourcir progressivement la finalité elle-même de l'ordre de la minute à celui de la seconde. Cependant, il ne s'agit pas d'une seule mise à niveau unique déjà planifiée, mais d'un ensemble de tâches de recherche à mener par étapes, incluant le découplage du vote de finalité et du choix de fourche (fork choice), l'optimisation de l'ensemble des validateurs, l'agrégation des votes et la propagation réseau, puis la modification progressive du protocole de consensus.
Dans l'ensemble, une bonne expérience d'interopérabilité ne consiste pas à donner à des dizaines de chaînes un même bouton cross-chain, mais à permettre à différents environnements d'exécution de se faire mutuellement confiance sur leurs états plus rapidement et à moindre coût.
III. Quand le L1 devient aussi un Rollup, la frontière entre les couches existe-t-elle encore ?
Si le changement de positionnement des L2 et le raccourcissement de la finalité consistent toujours à réajuster l'architecture en couches existante, un autre point soulevé par Barnabé touche davantage à la définition même de L1 et L2 : avec l'entrée des systèmes de preuve dans le réseau principal d'Ethereum, le L1 pourrait finalement devenir lui aussi une sorte de « Rollup de lui-même ».
Cette affirmation peut sembler contre-intuitive.
Après tout, un Rollup est généralement compris comme un réseau de mise à l'échelle construit sur le L1 ; il exécute les transactions à l'extérieur, puis le L1 valide les résultats d'état. Ethereum étant lui-même le réseau de consensus et de règlement de base, comment pourrait-il devenir son propre L2 ?
Pour comprendre ce point de vue, il faut d'abord dissocier le « Rollup » de la relation hiérarchique. Dans Ethereum actuel, lorsqu'un nœud reçoit un bloc, il doit réexécuter toutes les transactions qu'il contient, calculer indépendamment les changements d'état et juger si le bloc respecte les règles du protocole.
Ce mode garantit que les nœuds peuvent vérifier par eux-mêmes, mais signifie également que la capacité d'exécution globale du réseau doit être contrainte par les conditions matérielles des nœuds ordinaires. Plus la quantité de calcul dans un bloc est importante, plus le matériel et le temps nécessaires aux validateurs pour terminer l'exécution sont importants.
À l'avenir, avec la maturation des preuves en temps réel et du zkEVM L1, les transactions pourront toujours être calculées par des nœuds d'exécution hautes performances, mais les validateurs ordinaires n'auront pas nécessairement besoin de réexécuter personnellement chaque transaction. Par exemple, le nœud d'exécution, après avoir terminé le calcul, génère une preuve de validité ; les autres validateurs n'ont alors besoin de vérifier que cette preuve, de volume plus petit et de coût plus faible, pour confirmer que la transition d'état est correcte.
Du point de vue de la relation entre exécution et validation, cela présente effectivement des similitudes avec un Rollup : une partie des participants est responsable de l'exécution haute performance, les résultats d'exécution sont compressés en une preuve cryptographique, et les participants au consensus plus larges ne répètent plus tous les calculs, mais vérifient la preuve et confirment l'état final.
Par conséquent, ce que Barnabé appelle « L1 devenant son propre Rollup » est plus adapté comme résumé de ce mode de vérification, et non comme signifiant que le réseau principal d'Ethereum serait placé sur une autre chaîne de base ou serait « rétrogradé » à son propre L2.
Son point central est que lorsque les preuves remplaceront progressivement la réexécution par tous les nœuds, le Rollup pourrait ne plus être seulement un nom de couche situé au-dessus du L1, mais deviendrait une architecture d'exécution et de validation plus générique.

Cela brouillera davantage les frontières traditionnelles entre L1 et L2.
D'une part, le L1 peut augmenter sa propre capacité d'exécution grâce aux preuves zkEVM ; d'autre part, les Native Rollups souhaitent permettre aux L2 d'invoquer plus directement la capacité de validation au sein du protocole Ethereum, laissant le L1 valider les transitions d'état des L2 de manière plus native et unifiée.
Aujourd'hui, différents Rollups doivent généralement construire leurs propres systèmes de preuve, contrats de validation, mécanismes de mise à niveau et comités de sécurité. Une fois qu'une erreur survient dans le système de preuve, qu'une mise à niveau protocolaire urgente est nécessaire ou que l'opérateur fait défaut, les utilisateurs doivent souvent encore dépendre de structures de gouvernance et de confiance supplémentaires. La direction à long terme des Native Rollups est d'intégrer une partie de la logique de validation des Rollups comme une capacité native d'Ethereum, permettant aux L2 de réduire leurs structures de sécurité autonomes, d'hériter plus complètement des règles de transition d'état du L1, et d'avoir la possibilité de se passer de comités de sécurité.
Si l'on va encore plus loin, lorsque plusieurs L2 pourront s'appuyer sur une confirmation L1 plus rapide, des mécanismes de preuve unifiés et une composabilité synchrone pour accéder aux états les uns des autres, leur relation avec le réseau principal pourrait ne plus ressembler à celle connectée par des ponts inter-chaînes comme aujourd'hui.
Ils ressembleraient davantage à plusieurs domaines d'exécution sous le même consensus Ethereum, certains étant responsables d'activités financières générales, d'autres orientés vers le jeu, les réseaux sociaux ou les paiements, d'autres offrant des capacités de confidentialité ou de conformité spéciales. Ils auraient différentes logiques d'exécution et formes de produit, mais dépendraient tous d'un même ensemble d'état vérifiable, de base de sécurité et de système de règlement d'actifs.
Bien sûr, cela reste une direction à long terme.
Mais quelle que soit la forme finale sous laquelle ces technologies se concrétiseront, elles ont déjà fait passer la démarcation entre L1 et L2 d'une frontière architecturale nette à une relation d'héritage de sécurité à différents degrés.
Pour conclure
La grande tendance de l'univers est que ce qui est longtemps uni finit par se diviser, et ce qui est longtemps divisé finit par s'unir.
Ethereum a autrefois obtenu la composabilité globale grâce à l'état partagé ; il a ensuite séparé l'exécution via les Rollups pour gagner plus de capacité. Aujourd'hui, ce qu'il doit accomplir est de reconnecter les actifs, les comptes et les applications qui ont été séparés, sans annuler les résultats de la mise à l'échelle.
Pour l'utilisateur ordinaire, l'Ethereum idéal n'a jamais dû être une carte réseau composée de dizaines de chaînes, de différents Gas Tokens et de ponts inter-chaînes. En réalité, l'endroit où les transactions sont exécutées, la provenance de la liquidité, et qui effectue le règlement final peuvent progressivement être laissés aux portefeuilles, aux applications et au protocole sous-jacent. Cependant, les hypothèses de confiance, les limites de sécurité et les chemins de sortie impliqués ne doivent pas être cachés en même temps que l'expérience opérationnelle.
Par conséquent, l'aboutissement des L2 n'est peut-être ni de remplacer le L1, ni d'être éliminés par un L1 en constante expansion, mais de devenir un ensemble d'environnements d'exécution ayant différentes fonctionnalités et performances, mais capables de partager la sécurité, la liquidité et une relation d'état.
Par le passé, Ethereum a obtenu plus de capacité en séparant l'exécution.
À l'étape suivante, voyons si, une fois séparés, ils peuvent encore reformer un seul Ethereum.







