Un nouveau modèle architectural publié aujourd'hui sur EthResearch propose de créer un rôle d'exécution intermédiaire entre la L1 d'Ethereum et les rollups persistants, en le présentant comme une couche « L1.5 ». Selon ce design, l'état utilisateur reste dans les wallets, l'état partagé réside sur la L1 d'Ethereum, et le calcul est délégué à une couche éphémère sans état qui produit une preuve de validité puis disparaît, sans laisser d'obligations d'état résiduel sur le réseau. La proposition complète est disponible sur EthResearch, le forum public où les chercheurs d'Ethereum publient et débattent des idées de protocole à un stade précoce avant toute mise en œuvre.

Points clés

• Le label L1.5 est un cadrage architectural, et non une nouvelle couche protocolaire canonique d'Ethereum. Il décrit un environnement de calcul temporaire qui règle ses résultats sur la L1 sans conserver son propre état entre les tâches.
• Le modèle est conçu pour des contextes d'exécution bornés, tels que des sessions spécifiques à une application ou des fenêtres d'événements à forte intensité, où un opérateur de rollup de longue durée constituerait une surcharge inutile.
• La mise en œuvre dépend de deux EIP au statut Draft, EIP-8141 et EIP-8288, ce qui signifie que L1.5 est une proposition de recherche conditionnée à de futurs travaux protocolaires d'Ethereum, et non une fonctionnalité déployée.

Pourquoi les rollups éphémères sont présentés comme la couche L1.5 d'Ethereum

La publication EthResearch du 28 octobre 2026 introduit L1.5 comme un modèle de conception, et non comme un amendement au protocole. L'affirmation centrale est que tous les calculs n'exigent pas un environnement d'exécution de longue durée doté d'un séquenceur, d'un pont et d'engagements d'état persistants. Certaines charges de travail sont bornées par définition, et les forcer à passer par un L2 permanent introduit une surcharge d'infrastructure inutile. Ce cadrage se positionne en regard de la feuille de route centrée sur les rollups qui oriente la stratégie de scalabilité d'Ethereum depuis 2020, en vertu de laquelle l'exécution a été largement déléguée aux réseaux L2 persistants tandis que la L1 sert de couche de règlement et de disponibilité des données.

Ce qui rend un rollup éphémère

Selon la proposition, une tâche L1.5 admissible doit satisfaire quatre propriétés : elle doit être sans état entre les tâches, vérifiée par la L1, payée sans lier l'utilisateur à une identité persistante, et réglée sans exiger un opérateur de longue durée. La couche de calcul éphémère reçoit un instantané d'état, exécute, puis renvoie un nouvel état accompagné d'une preuve de validité — une attestation cryptographique permettant à la L1 de confirmer qu'un calcul a été effectué correctement sans le réexécuter. Elle ne conserve rien de nécessaire à la tâche suivante.

Il s'agit d'une rupture nette avec le fonctionnement des rollups persistants. Un séquenceur Optimism ou Arbitrum maintient un arbre d'état continu, gère les réorganisations et se coordonne avec des systèmes de preuves de fraude ou de validité sur un horizon temporel indéfini. Le modèle L1.5 abandonne délibérément cette continuité, en traitant chaque tâche comme une unité de travail isolée.

Comment la L1, la couche éphémère et les utilisateurs s'articulent

Le modèle de garde d'état proposé répartit précisément les responsabilités. Les wallets détiennent l'état appartenant aux utilisateurs, tandis que la L1 d'Ethereum héberge l'état partagé, y compris les engagements et les nullifiers, et vérifie chaque transition d'état. La couche de calcul éphémère se situe entre les deux : elle reçoit les entrées, exécute et émet une preuve que la L1 peut vérifier. Une fois le règlement terminé, l'environnement éphémère est retiré.

Cette configuration se distingue à la fois de l'exécution purement L1, contrainte par les limites de gaz par bloc et le débit de séquençage, et des L2 classiques, qui nécessitent un opérateur persistant, un pont actif et une racine d'état canonique maintenue sur une chaîne de blocs indéfinie. Le cadrage L1.5 décrit un rôle de calcul convoqué pour une tâche spécifique puis dissous.

Ethereum s'échange à 2 354,52 $, en hausse de 2,04 % sur les dernières 24 heures, pour une capitalisation boursière d'environ 287,7 milliards de dollars, selon CoinGecko, fournissant le contexte économique au regard duquel les propositions visant à améliorer le débit d'exécution d'Ethereum sont évaluées. L'indice global de sentiment crypto s'établit à 51, une lecture Neutre qui ne reflète ni euphorie ni crainte alors que la recherche entre en revue publique.

Aucun commentaire social d'expert vérifié n'a émergé concernant la proposition depuis sa publication, ce qui est cohérent avec l'absence de fenêtre de réaction publique étendue pour une publication de recherche mise en ligne le jour même. Le niveau de sentiment Neutre reflète l'écosystème dans son ensemble plutôt qu'une réception spécifique de cette proposition architecturale.

Les arbitrages d'infrastructure : rapidité, composabilité et règlement

Cas d'usage potentiels : contextes d'exécution délimités

Le design éphémère convient naturellement aux charges de travail à forte intensité et limitées dans le temps : une fenêtre d'exécution de vote de gouvernance, une session de règlement par lot pour une chambre de compensation de dérivés, ou une mise à jour d'état de jeu spécifique à une application. Dans ces contextes, déployer un L2 complet avec un séquenceur et un pont canonique imposerait un coût de coordination supérieur à ce que l'exécution elle-même justifie.

Les protocoles qui traitent déjà une demande on-chain par à-coups, comme les marchés monétaires gérant des cascades de liquidations ou les mises à jour de paramètres de risque pilotées par la gouvernance d'Aave, représentent la catégorie de charges de travail pour lesquelles une exécution isolée à haut débit suivie d'un règlement propre réduirait la congestion de la L1 sans nécessiter de déploiement L2 permanent. La propriété essentielle est que l'application n'a pas besoin que son état persiste sur une durée illimitée ; elle a besoin d'une exécution correcte et vérifiable pour un périmètre de tâche défini.

Latence, séquençage, synchronisation d'état et finalité

Les questions pratiques pour tout développeur évaluant ce modèle portent sur la manière dont l'état est transféré vers et depuis l'environnement éphémère. La répartition d'état de la proposition assigne les engagements partagés et les nullifiers à la L1, mais la latence de pont entre l'état détenu dans le wallet de l'utilisateur et le contexte d'exécution de la couche éphémère constitue un problème de séquençage que chaque implémentation devra résoudre. Le temps de génération des preuves compte également : si la couche éphémère doit produire une preuve de validité avant que la L1 ne finalise le résultat, la latence de bout en bout est limitée à la base par la vitesse de construction des preuves.

C'est là que la dépendance aux EIP au stade draft devient déterminante. EIP-8141, une proposition Draft Core de la piste de normalisation créée le 29 janvier 2026, introduit des transactions de trame avec une logique abstraite de validation et de paiement du gaz, couvrant les modes de trame VERIFY et SENDER. Sans elle, la propriété de paiement sans identité persistante qu'exige le modèle L1.5 ne dispose d'aucun point d'ancrage natif sur la L1.

EIP-8288, créée le 3 juin 2026 et également Draft Core, étend l'EIP-8141 avec une agrégation récursive basée sur les STARK pour les signatures et les preuves STARK, et fait d'un STARK récursif une exigence de validité des blocs. Les STARK — des arguments de connaissance évolutifs et transparents — sont une classe de preuves de validité vérifiables à un coût bien inférieur à celui qu'exigerait la réexécution du calcul attesté. C'est la couche d'agrégation de preuves qui permettrait de vérifier efficacement sur la L1 la sortie du rollup éphémère sans consommer un gaz disproportionné par tâche. Les deux EIP sont au statut Draft, ce qui signifie qu'aucune n'est programmée pour un hard fork spécifique ; dans le processus d'amélioration d'Ethereum, les propositions progressent par les étapes Draft, Review, Last Call et Final, et une norme ne prend effet qu'une fois incluse dans une mise à niveau du réseau.

Risque de composabilité et fragmentation de la liquidité

L'exécution délimitée s'accompagne d'un coût de composabilité que les L2 persistants connaissent aussi, mais selon un profil différent. Un L2 de longue durée accumule TVL et liquidité au fil du temps, construisant une profondeur de composabilité au sein de son propre environnement. Un rollup éphémère, par conception, ne détient aucune liquidité persistante : chaque tâche démarre à partir d'un nouvel instantané d'état et se règle sur la L1. Pour les protocoles où la composabilité entre plusieurs contrats au sein d'une même transaction est une attente centrale des utilisateurs, comme le routage DEX multi-paths ou les liquidations adossées à des prêts flash, la contrainte d'absence d'état entre les tâches du modèle éphémère limite le type d'interactions exécutables dans le périmètre d'une seule tâche.

La proposition ne présente pas cela comme un défaut, mais comme une frontière de conception. Le modèle L1.5 n'est pas destiné à remplacer les environnements d'exécution L2 à usage général. Il cible la catégorie de charges de travail qui peuvent être entièrement spécifiées à l'avance, exécutées de manière atomique et réglées proprement. Il s'agit d'un espace problematique plus étroit que celui traité par Optimism ou Arbitrum, mais aussi d'un domaine où l'infrastructure actuelle est peut-être surdimensionnée.

Le degré de succès de ce cadrage en pratique sera déterminé par la progression de l'EIP-8141 et de l'EIP-8288 dans le processus d'amélioration d'Ethereum, et par l'acceptation par les développeurs d'applications de la contrainte d'absence d'état entre les tâches pour leurs modèles de charge de travail spécifiques. Les développeurs déployant sur des infrastructures L2 émergentes, comme ceux qui migrent actuellement des contrats de staking entre Arbitrum et Avalanche, illustrent la complexité opérationnelle liée à la gestion de l'état dans des environnements de rollups persistants. Le modèle L1.5 offre un cadrage alternatif pour les tâches où cette gestion continue de l'état est précisément le problème que l'on cherche à éviter, et non une fonctionnalité que l'on souhaite exploiter.

Perspectives

La publication de recherche présente L1.5 comme une contribution au vocabulaire architectural plutôt que comme une annonce de déploiement. Sa validité en tant que modèle pratique dépend de la finalisation de deux EIP au statut Draft, de l'adéquation de la latence de génération des preuves aux exigences de débit des cas d'usage cibles, et de l'acceptation par les développeurs d'applications des arbitrages de composabilité qu'impose l'exécution sans état. Le statut des deux propositions est suivi publiquement sur le site des EIP d'Ethereum, si bien que leur progression dans la normalisation est directement observable à mesure que le processus d'amélioration avance. Tant que l'EIP-8141 et l'EIP-8288 n'auront pas quitté le statut Draft, le design L1.5 demeurera une proposition de ce que la pile d'exécution d'Ethereum pourrait prendre en charge, et non une description de ce qu'elle fait actuellement.