« Les L2 sont-ils en train de grignoter la valeur des L1 ? » « Ethereum est-il en train de perdre sa composabilité globale ? », pendant les deux années où les L2 étaient au sommet de leur popularité, une telle anxiété a presque rempli toute la communauté Ethereum.
À cette époque, dans le cadre d'extension d'Ethereum, la L1 était la couche de règlement stable mais coûteuse, et la L2 était la couche d'exécution bon marché et efficace. Bien que cela ait donné à Ethereum plus d'espace de blocs, l'expérience complète de « une seule chaîne » a été progressivement perdue.
Par conséquent, au cours des deux dernières années, ces questions ont continuellement poussé Ethereum à reconsidérer la relation entre L1 et L2.
D'une part, Ethereum L1 continue d'augmenter la limite de gaz, de promouvoir la statelessness et la vérification zkEVM, ne se contentant plus d'être seulement une base de règlement à faible débit ; d'autre part, les discussions communautaires deviennent de plus en plus intenses. Début de l'année, Vitalik a déclaré directement qu'avec l'amélioration de la capacité d'extension du réseau principal d'Ethereum, certaines prémisses de la feuille de route établie il y a cinq ans, considérant les L2 comme le principal moyen d'extension, avaient changé (lecture supplémentaire « Comprendre la réflexion de Vitalik sur les L2 : Dire adieu à la fragmentation, redressement et rectification pour les Rollups natifs dans la nouvelle phase »).
Récemment, le chercheur d'Ethereum Barnabé Monnot a également 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 la finalité doit être considérablement raccourcie, et si L1 pourrait également devenir dans un certain sens « son propre Rollup » alors que les systèmes de preuve entrent progressivement dans le processus de vérification du réseau principal.
Ces points de vue, bien qu'ils ne représentent pas encore une feuille de route de protocole établie, offrent néanmoins une perspective d'observation très précieuse.
Au fond, le problème auquel Ethereum est confronté aujourd'hui n'est pas seulement comment continuer à augmenter l'espace des blocs, mais comment réorganiser la division du travail entre L1, L2, la couche d'exécution et la couche de règlement lorsque les transactions, les actifs et les états des utilisateurs sont dispersés dans de plus en plus d'environnements d'exécution.
1. Ethereum n'a pas « abandonné » les L2, mais il doit trouver son nouveau positionnement
Pour être réaliste, lors de la formation initiale de la feuille de route d'extension d'Ethereum centrée sur les Rollups, la tâche la plus importante des L2 était relativement simple : fournir à Ethereum plus d'espace de transactions et à moindre coût.
Dans les conditions techniques de l'époque, cette division du travail était tout à fait raisonnable.
Parce que tous les validateurs d'Ethereum doivent réexécuter les transactions L1, le débit du réseau principal ne peut pas être augmenté de manière radicale à court terme. Les Rollups, quant à eux, peuvent exécuter des transactions par lots hors chaîne, soumettant uniquement les données compressées ou les engagements d'état au réseau principal, préservant ainsi certains attributs de sécurité d'Ethereum tout en réduisant considérablement le coût par transaction.
Ainsi, l'extension s'est développée selon deux voies parallèles : L1 reste modérée, privilégiant la décentralisation et la sécurité, tandis que L2 prend en charge les nouvelles transactions, réduisant continuellement les coûts via les Blobs, la compression de données et les technologies de preuve.
Mais aujourd'hui, les prémisses de cette division du travail ont changé.
La Fondation Ethereum a réorganisé les travaux sur le protocole en 2026, fusionnant les travaux relativement indépendants « d'extension de L1 » et « d'extension des Blobs » en une seule feuille de route Scale unifiée. L'augmentation de la limite de gaz, l'élargissement de la disponibilité des données, l'optimisation du client d'exécution, la promotion de la statelessness et du client attesteur zkEVM sont désormais intégrés dans un même cadre d'extension.
En d'autres termes, Ethereum ne considère plus l'extension de L1 et de L2 comme deux tâches séparées, mais commence à répartir l'exécution, le consensus et la capacité de données du point de vue de l'ensemble du système.
Ce changement ne signifie pas qu'Ethereum prévoit d'abandonner les L2 ou de rapatrier toutes les activités sur le réseau principal. Au contraire, cela signifie que les L2 auront du mal à prouver leur valeur à long terme uniquement par des « transactions plus rapides et du gaz moins cher ».
Après tout, si L1 elle-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, l'exécution EVM générale et l'espace de blocs à faible coût ne seront plus une capacité exclusive des L2 ; ce que les L2 devront fournir se tournera davantage vers des besoins différenciés que L1 a du mal à satisfaire de manière unifiée, tels que l'optimisation pour des applications spécifiques, des fonctionnalités de confidentialité, ainsi que des modèles de gouvernance et économiques plus flexibles.
Dans son dernier exposé cette année sur la relation entre L1 et L2, la Fondation Ethereum a également clairement souligné ce point. Par le passé, l'objectif principal des L2 était d'étendre Ethereum, la différenciation et la personnalisation n'étant que des valeurs secondaires. Maintenant, il s'agit de fournir des fonctionnalités différenciées tout en continuant à contribuer à une capacité d'extension supplémentaire.
En contrepartie, L1 doit devenir un hub global suffisamment puissant, sans autorisation et hautement résilient, portant le règlement, l'état partagé, la liquidité et la DeFi.
Cela pousse en réalité les L2 d'une catégorie technique unifiée vers 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é multisignatures, ouvrir des mécanismes de preuve sans autorisation et garantir que les utilisateurs puissent toujours se retirer en s'appuyant sur L1 même si l'opérateur cesse de fonctionner.
- Au milieu du spectre se trouvent des environnements d'exécution qui héritent de certains attributs d'Ethereum en fonction des besoins métier. Ils peuvent disposer de permissions de gestion plus fortes, de séquenceurs indépendants ou de conceptions de conformité spécifiques, en échange de performances, de confidentialité et de flexibilité opérationnelle.
- À l'autre extrémité se trouvent peut-être des chaînes qui utilisent l'EVM, les actifs Ethereum ou accèdent à certaines infrastructures inter-chaînes, mais qui sont relativement indépendantes en termes de sécurité et de règlement.
C'est pourquoi on dit qu'Ethereum ne veut pas abandonner les L2, mais plutôt redéfinir la division du travail. En fin de compte, au cours des 3-5 dernières années, L2 représentait d'abord une technologie d'extension, tandis qu'à l'avenir, elle représentera plus probablement un ensemble d'environnements d'exécution établissant des relations de sécurité, de règlement et de liquidité différentes avec Ethereum.
2. L'interopérabilité n'est pas seulement le cross-chain, mais comment les états se font mutuellement confiance
Cependant, alors qu'Ethereum s'étend en un système composé de nombreuses L2, un autre problème récurrent émerge progressivement : le nombre croissant de L2 fragmente inévitablement la liquidité, l'état des comptes et l'expérience applicative.
Cela s'est clairement manifesté dans l'utilisation pratique des dernières années. Par exemple, un utilisateur peut détenir des actifs sur une chaîne, utiliser une application sur une autre chaîne, et devoir se rendre sur une troisième chaîne pour effectuer une transaction, de sorte que la même stablecoin a différentes versions sur différents réseaux, et un même compte doit également gérer différents tokens de gaz, ponts inter-chaînes et points d'entrée d'actifs.
Par conséquent, l'interopérabilité est devenue une partie de plus en plus importante de la feuille de route d'Ethereum.
L'équipe du protocole Ethereum a déjà 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 est de faire en sorte qu'Ethereum « se sente à nouveau comme une chaîne ». Cette vision dépend de la maturité de l'architecture d'intention (intent).
- Parmi elles, le cadre d'intentions ouvert Open Intents Framework permet aux utilisateurs de simplement déclarer le résultat qu'ils souhaitent, 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 supplémentaire « Quand l'« intention » devient la norme : comment OIF met fin à la fragmentation cross-chain et ramène le Web3 à l'intuition de l'utilisateur ? »).
- La couche d'interopérabilité Ethereum (EIL) va encore plus loin en tentant de construire une couche de transport sans confiance, avec pour objectif de donner aux transactions cross-L2 une expérience indistinguable de celle des transactions sur une seule chaîne (lecture supplémentaire « 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 gaz délégué et les mécanismes de récupération ; les projets d'abstraction de compte native ultérieurs, représentés par l'EIP-8141, tentent d'intégrer davantage la logique de compte intelligent dans le protocole, faisant progressivement des portefeuilles de contrats intelligents la forme de compte par défaut et réduisant la dépendance à des services intermédiaires supplémentaires tels que les Bundlers et les Relayers.
La règle de confirmation rapide L1 vise à fournir un signal de confirmation plus sécurisé en quelques secondes à dizaines de secondes avant la finalité complète, réduisant ainsi le temps d'attente de l'application dans la plupart des scénarios normaux. Cela bénéficiera directement à toutes les applications cross-chain dépendant de la finalité L1, ce qui est d'une grande importance pour les ponts inter-chaînes, le règlement des stablecoins, les transactions d'actifs RWA, etc.
Parce que le véritable goulot d'étranglement de nombreuses interactions cross-chain n'est pas de savoir si le message peut être envoyé, mais quand la chaîne cible peut être suffisamment sûre que l'état sur la chaîne source ne sera plus annulé.
Un point souvent négligé est qu'une transaction incluse dans un bloc n'équivaut pas à sa finalité. Du point de vue de l'utilisateur, une transaction peut apparaître réussie après quelques secondes, mais pour un pont, un échange, un protocole de prêt ou un solveur cross-chain, ils doivent encore évaluer la possibilité que cette transaction subisse une réorganisation de bloc et s'ils peuvent libérer des actifs sur une autre chaîne ou exécuter l'opération suivante en conséquence.
C'est pourquoi de nombreux services cross-chain aujourd'hui qui semblent offrir une « livraison instantanée » n'attendent pas réellement que la chaîne source achève son règlement final, mais plutôt que des solveurs ou des fournisseurs de liquidité avancent les fonds. Ce mécanisme optimise l'expérience utilisateur mais ne fait pas disparaître le temps d'attente sous-jacent.
L'objectif à long terme d'Ethereum est donc de raccourcir la finalité elle-même de l'ordre de la minute à l'ordre de la seconde. Cependant, il ne s'agit pas d'une mise à niveau unique déjà planifiée, mais d'un ensemble de tâches de recherche nécessitant une mise en œuvre par étapes, incluant le découplage des votes de finalité et du choix de fork, l'optimisation de l'ensemble des validateurs, l'agrégation des votes et la propagation du réseau, puis la modification progressive du protocole de consensus.
Globalement, une bonne expérience d'interopérabilité ne consiste pas à donner à des dizaines de chaînes le 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.
3. Quand L1 devient aussi un Rollup, la frontière hiérarchique existe-t-elle encore ?
Si le changement de positionnement des L2 et le raccourcissement de la finalité consistent toujours à réajuster l'architecture hiérarchique existante, un autre jugement mentionné par Barnabé touche encore plus 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, L1 pourrait finalement aussi devenir dans un certain sens « son propre Rollup ».
Cette affirmation semble contre-intuitive.
Après tout, un Rollup est généralement compris comme un réseau d'extension construit sur L1. Il exécute des transactions en dehors, puis L1 vérifie les résultats d'état. Alors, comment Ethereum lui-même, étant le réseau de consensus et de règlement sous-jacent, pourrait-il devenir son propre L2 ?
Pour comprendre ce point de vue, il faut d'abord décomposer le concept de « Rollup » par rapport aux relations hiérarchiques. Dans l'Ethereum d'aujourd'hui, 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 déterminer si le bloc respecte les règles du protocole.
Ce modèle 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 les validateurs ont besoin de matériel et de temps pour terminer l'exécution.
À l'avenir, avec la maturité des preuves en temps réel et du zkEVM L1, les transactions pourront toujours être calculées par des nœuds d'exécution haute performance, mais les validateurs ordinaires n'auront pas nécessairement besoin de réexécuter personnellement chaque transaction. Par exemple, un nœud d'exécution génère une preuve de validité après avoir effectué les calculs, et les autres validateurs n'ont qu'à vérifier cette preuve, de volume plus petit et de coût plus faible, pour confirmer la correction de la transition d'état.
Du point de vue de la relation entre exécution et vérification, cela présente en effet 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é entend par « L1 devient son propre Rollup » est plus adapté comme résumé de ce mode de vérification, et non comme une affirmation que le réseau principal d'Ethereum serait placé sur une autre chaîne sous-jacente ou « rétrogradé » en son propre L2.
Son point central est que lorsque les preuves remplacent progressivement la réexécution par tous les nœuds, le Rollup pourrait ne plus être seulement un nom de couche situé au-dessus de L1, mais devenir une architecture d'exécution et de vérification plus universelle.
Cela brouillera encore davantage les frontières traditionnelles entre L1 et L2.
D'une part, L1 peut étendre 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 vérification au sein du protocole Ethereum, laissant L1 vérifier la transition d'état des L2 de manière plus native et unifiée.
Aujourd'hui, différents Rollups doivent généralement construire leur propre système de preuve, contrat de vérification, mécanisme de mise à niveau et comité de sécurité. Dès qu'une erreur survient dans le système de preuve, que le protocole nécessite une mise à niveau urgente ou que l'opérateur devient défaillant, les utilisateurs doivent souvent s'appuyer sur des 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 vérification des Rollups comme 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 de L1 et d'avoir la possibilité de se passer de comités de sécurité.
Si nous allons encore plus loin, lorsque plusieurs L2 pourront s'appuyer sur une confirmation L1 plus rapide, un mécanisme de preuve unifié et une composabilité synchrone pour accéder mutuellement à leurs états, leur relation avec le réseau principal pourrait ne plus ressembler à celle d'aujourd'hui connectée par des ponts inter-chaînes.
Elles ressembleraient davantage à plusieurs domaines d'exécution sous le même consensus Ethereum, certains 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 fournissant des capacités de confidentialité ou de conformité spéciale. Elles possèdent différentes logiques d'exécution et formes de produits, mais dépendent toutes d'un ensemble vérifiable d'états, de bases de sécurité et de systèmes de règlement d'actifs.
Bien sûr, il s'agit toujours d'une direction à long terme.
Mais quelle que soit la forme finale de ces technologies, elles ont déjà transformé la frontière entre L1 et L2 d'une limite d'architecture claire en une relation d'héritage de sécurité à différents degrés.
En conclusion
La grande tendance sous le ciel est la réunion après séparation, la séparation après réunion.
Ethereum a autrefois obtenu une composabilité globale grâce à un état partagé ; puis, via les Rollups, il a séparé l'exécution pour obtenir une plus grande capacité. Aujourd'hui, ce qu'il doit accomplir est de reconnecter les actifs, comptes et applications qui ont été séparés, sans annuler les résultats de l'extension.
Pour l'utilisateur ordinaire, l'Ethereum idéal ne devrait jamais être une carte de réseau composée de dizaines de chaînes, de différents tokens de gaz et de ponts inter-chaînes. En fait, l'endroit où la transaction est exécutée, la provenance de la liquidité, la chaîne finale et qui effectue le règlement peuvent progressivement être confiés au portefeuille, à l'application 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 avec l'expérience opérationnelle.
Par conséquent, la fin de jeu des L2 n'est peut-être ni de remplacer L1, ni d'être éliminées par une L1 en constante extension, mais de devenir un ensemble d'environnements d'exécution possédant des fonctionnalités et des performances différentes, mais capables de partager la sécurité, la liquidité et les relations d'état.
Dans le passé, Ethereum a obtenu une plus grande capacité en séparant l'exécution.
Dans la phase suivante, voyons si, après avoir été séparées, elles peuvent toujours se recomposer en un seul Ethereum.
