Stratégie de couche Ethereum : Comment L1 zkEVM transforme les aspects à court et long terme de la blockchain

Depuis 2026, Ethereum fait face à un moment critique dans l’évolution de son architecture en couches. La fréquence des annonces de la part de la communauté des développeurs principaux atteint un sommet, reflétant un changement stratégique fondamental sur la façon dont l’écosystème doit se développer. À court terme, Ethereum équilibre désormais le rôle de Layer 1 et Layer 2 ; mais sa vision à long terme vise une transformation bien plus ambitieuse : transformer le L1 Ethereum lui-même en un système zkEVM intégré, et non simplement une base de sécurité pour le L2.

Cette nouvelle compréhension se manifeste dans une série de propositions techniques récentes. Le 26 février, Justin Drake de la Fondation Ethereum a publié une ébauche de feuille de route appelée Strawmap, décrivant la direction du développement du protocole L1 Ethereum pour les années à venir. Le document cible cinq objectifs principaux : accélérer la finalité à quelques secondes, implémenter un “Gigagas” L1 avec un débit jusqu’à 10 000 TPS via zkEVM, lancer un L2 à haute vitesse basé sur DAS (Data Availability Sampling), un système cryptographique résistant aux ordinateurs quantiques, et des fonctionnalités de confidentialité native — tous planifiés à travers sept hard forks jusqu’en 2029, en moyenne une tous les six mois.

De la focalisation sur le L2 à la réintégration du L1 : trois vagues de changement dans la narration d’Ethereum

Le parcours d’Ethereum au cours des dix dernières années peut être cartographié en trois phases d’évolution narrative, chacune reflétant des priorités différentes pour la couche.

Première phase (2015–2020) : l’ère du Ledger programmé

La narration centrale d’Ethereum est la création d’une plateforme pour contrats intelligents Turing-complets. Pendant cette période, l’avantage principal d’Ethereum par rapport à Bitcoin réside dans sa flexibilité d’exécution : la capacité de déployer DeFi, NFT, DAO, et diverses autres applications décentralisées. Le protocole L1 Ethereum devient la couche principale d’exécution, accueillant la majorité des activités de la cryptoéconomie. Ce rôle positionne Ethereum comme “l’épine dorsale de l’infrastructure Web3”, même si aucune question sérieuse sur la scalabilité ne se pose alors.

Deuxième phase (2021–2023) : l’ère des rollups L2

Lorsque les coûts en gas sur le mainnet Ethereum ont explosé, la narration a changé. Les rollups L2 deviennent la solution dominante, et Ethereum se repositionne : de couche d’exécution principale à couche de règlement. Des upgrades comme The Merge (2022) et EIP-4844 (Proto-Danksharding) sont conçus pour soutenir ce modèle — le L1 étant responsable de la sécurité et de la disponibilité des données, la computation principale migrée vers le L2. Cette stratégie offre une scalabilité significative, mais crée un nouveau dilemme.

Troisième phase (2024–2025) : réflexion et repositionnement

Le succès des L2 engendre un paradoxe inattendu : les utilisateurs migrent massivement vers Arbitrum, Base, Optimism et autres plateformes L2, laissant le L1 Ethereum avec une activité relativement limitée. La valeur captée par le L1 diminue, tandis que le L2 domine. Des questions fondamentales émergent : si tous les utilisateurs et activités sont sur le L2, quelle est la pertinence du L1 ? Comment le L1 peut-il capter une valeur à long terme ?

Ce questionnement pousse à une évolution radicale. La communauté réalise que la stratégie basée uniquement sur le L2 n’est pas durable. Il faut une réintégration et une synergie entre L1 et L2, pas simplement une division du travail séparée.

Strawmap 2026 : huit axes techniques vers un L1 zkEVM intégré

Cette nouvelle vision se concrétise dans huit axes de travail techniques étroitement liés. Chaque axe est un projet pluriannuel, et la réussite globale nécessite des avancées simultanées dans tous les domaines. C’est cette orchestration de huit innovations interdépendantes qui distingue le L1 zkEVM des efforts précédents de scalabilité : leur complexité ne réside pas dans une seule avancée, mais dans la coordination de ces huit innovations.

Axe 1 : Formalisation de la spécification EVM

Le fondement de toute preuve à zéro connaissance est une définition mathématique précise. Aujourd’hui, le comportement de l’EVM est défini par des implémentations clients (Geth, Nethermind, Besu, etc.), et non par une spécification formelle rigoureuse. Les incohérences entre ces implémentations compliquent énormément le développement de circuits ZK. Cet axe vise à convertir chaque instruction et règle de transition de l’EVM en spécification formelle vérifiable par machine. Sans cela, toutes les étapes suivantes reposent sur du sable.

Axe 2 : Migration vers des fonctions de hachage ZK-friendly

Ethereum utilise largement Keccak-256, qui est très peu optimal pour les circuits ZK — avec un surcoût computationnel énorme, augmentant drastiquement le temps et le coût de génération de preuves. Cet axe consiste à substituer progressivement Keccak par des fonctions de hachage adaptées aux ZK comme Poseidon et la famille Blake, notamment dans les Merkle trees et chemins de preuve. Ce changement a un impact étendu, car les fonctions de hachage sont omniprésentes dans le protocole.

Axe 3 : Verkle Tree en remplacement du Merkle Patricia Tree

L’infrastructure de l’état (state tree) d’Ethereum utilise actuellement un Merkle Patricia Tree (MPT). Le Verkle Tree le remplace par des commitments vectoriels, réduisant la taille des witnesses par un facteur pouvant atteindre plusieurs dizaines. Pour un L1 zkEVM, cela signifie réduire drastiquement la quantité de données nécessaires pour prouver chaque bloc, accélérer la génération de preuves, et rendre économiquement viable un L1 zkEVM. Le Verkle Tree est une infrastructure clé pour la viabilité du L1 zkEVM.

Axe 4 : Clients sans état (Stateless Clients)

Un client sans état est un nœud qui vérifie un bloc sans stocker localement toute la base de données d’état d’Ethereum — il utilise simplement des witnesses inclus dans le bloc. Étroitement lié au Verkle Tree (qui ne devient feasible que si les witnesses sont petits), il a deux objectifs : réduire la barrière hardware pour faire tourner un nœud (augmentant la décentralisation) et fournir une limite claire d’entrée pour la preuve ZK (le prouveur n’a besoin que de traiter le witness, pas tout l’état mondial).

Axe 5 : Standardisation du système de preuves ZK

Le L1 zkEVM nécessite un système de preuves ZK mature pour générer des proofs de l’exécution des blocs. Le paysage ZK actuel est très fragmenté, sans solution universellement reconnue. Cet axe définit une interface standardisée pour les preuves au niveau du protocole Ethereum, permettant à différents systèmes de preuve de concourir via une interface cohérente, plutôt que de monopoliser une seule solution. Cela maintient une ouverture technique tout en laissant place à l’évolution. L’équipe PSE (Privacy and Scaling Explorations) de la Fondation Ethereum a déjà accumulé de nombreux expérimentations dans cette direction.

Axe 6 : Découplage de l’exécution et du consensus

Actuellement, couche d’exécution (EL) et couche de consensus (CL) d’Ethereum communiquent via l’Engine API. Dans l’architecture L1 zkEVM, chaque transition d’état dans l’EL nécessite une preuve ZK. La génération de preuve peut prendre bien plus de temps que la production d’un bloc, créant un goulot d’étranglement. Cet axe vise à résoudre ce problème : comment séparer exécution et génération de preuve sans compromettre le mécanisme de consensus — l’exécution peut se terminer rapidement, la preuve étant générée de façon asynchrone et vérifiée par le validateur au moment opportun pour finaliser la finalité. Cela implique des modifications profondes du modèle de finalité des blocs.

Axe 7 : Preuves récursives et agrégation de preuves

Le coût de génération d’une preuve ZK pour un seul bloc est très élevé. Mais si les preuves de plusieurs blocs peuvent être compressées récursivement en une seule preuve, le coût de vérification devient beaucoup plus faible. Les progrès dans cet axe déterminent directement le niveau de réduction des coûts possible pour le L1 zkEVM.

Axe 8 : Outils pour développeurs et compatibilité EVM

Toutes ces réformes techniques doivent rester transparentes pour les développeurs de smart contracts sur Ethereum. Des dizaines de milliers de contrats existants ne doivent pas casser, et la toolchain ne doit pas nécessiter une réécriture complète. Cet axe est souvent sous-estimé, mais il est le plus chronophage : chaque mise à jour EVM précédente a nécessité des tests approfondis de compatibilité et des ajustements d’outils. La transition vers un L1 zkEVM implique un effort exponentiel supplémentaire pour la compatibilité et les outils.

Impacts à court terme sur la couche : ce qui change pour le L2 et l’écosystème

Cette transformation a des implications immédiates et à long terme pour les différents acteurs.

Implications à court terme (2026–2027)

Dans l’horizon à court terme, le L2 reste la principale solution de scalabilité. La Fondation Ethereum a explicitement indiqué que le L1 zkEVM ne remplace pas le L2, mais constitue une évolution complémentaire. Les rollups L2 continueront d’être la couche d’exécution principale pour un volume élevé de transactions, donnant aux builders et utilisateurs la confiance à court terme pour continuer à construire dans un écosystème Layer 2 déjà mature.

Cependant, à mesure que le L1 Ethereum deviendra plus capable dans les années à venir, le positionnement du L2 évoluera de “solution de scalabilité sécurisée” à “environnement d’exécution spécialisé”. Le L2 qui saura trouver une proposition de valeur niche — via une VM spécialisée, une optimisation des coûts ou des fonctionnalités de confidentialité — survivra et prospérera dans ce nouvel ordre.

Implications à long terme (2028–2029)

Lorsque le L1 zkEVM sera entièrement intégré, Ethereum ne sera plus seulement une couche de règlement pour le L2. Elle deviendra la “racine de calcul vérifiable” pour tout l’écosystème Web3. Chaque chaîne, chaque L2 pourra finalement ancrer sa provenance mathématiquement dans la chaîne de preuves ZK d’Ethereum, créant une hiérarchie de confiance unifiée mais décentralisée.

Pourquoi ce momentum est crucial : confiance des builders et positionnement à long terme d’Ethereum

L’annonce de Strawmap arrive à un moment où le marché doute de la performance d’ETH. Dans cette optique, la valeur la plus importante de cette feuille de route est la réaffirmation d’Ethereum comme “infrastructure primitive”, non comme une commodité.

Pour les builders : Strawmap offre une certitude directionnelle. Après une période d’incertitude quant à la pertinence d’Ethereum, il devient clair que l’écosystème central continuera à évoluer avec de grands ambitions techniques. Cela inspire la confiance pour un engagement à long terme.

Pour les utilisateurs : Ces avancées techniques se traduisent enfin par une expérience tangible — finalité en quelques secondes, flux d’actifs fluides entre L1 et L2, confidentialité native comme feature plutôt que plugin.

Pour les investisseurs : C’est le moment de réévaluer le positionnement d’Ethereum. Si le L1 zkEVM est implémenté avec succès, Ethereum ne sera plus seulement une couche de règlement pour le L2, mais la racine de confiance vérifiable pour le Web3. Il s’agit d’un changement qualitatif dans la narration, pas seulement d’une amélioration quantitative.

En réalité, le L1 zkEVM ne sera pas un produit lancé immédiatement. La mise en œuvre complète pourrait n’être atteinte qu’en 2028–2029 ou plus tard. Mais elle redéfinit fondamentalement la proposition de valeur d’Ethereum.

Ces huit axes techniques ne sont pas seulement une feuille de route — ils incarnent la culture unique des développeurs d’Ethereum : capables de piloter simultanément huit flux de travail techniques interdépendants, chacun étant un projet d’ingénierie sur plusieurs années, tout en maintenant une coordination décentralisée. C’est un avantage concurrentiel difficile à imiter.

Globalement, de la narration “centrée sur le Rollup” en 2020 à Strawmap 2026, l’évolution de la narration d’Ethereum montre une leçon essentielle : la scalabilité ne peut pas reposer uniquement sur le L2. Le L1 et le L2 doivent évoluer en synergie. Les huit axes du L1 zkEVM sont la cartographie technique de ce changement de paradigme, tous pointant vers une destination unique : faire évoluer le mainnet Ethereum de façon spectaculaire sans sacrifier la décentralisation, en intégrant et en améliorant le rôle du L2, pas en le rejetant.

Dans les trois prochaines années, ce “navire de Theseus” connaîtra sept forks et remplacera de nombreux “panneaux” et “voiles”. Lorsqu’il atteindra sa prochaine étape en 2029, nous pourrions assister à une “couche de règlement globale” véritablement révolutionnaire — rapide, sûre, privée, et toujours ouverte comme au début. Restons attentifs à cette évolution.