Comment L1 zkEVM réécrit la spécification Ethereum : évolution de Rollup aux calculs vérifiables

Depuis 2025, la communauté des développeurs Ethereum montre une intensité d’actualisations et de remises en question de son rôle dans l’écosystème crypto sans précédent. Face aux discussions sur la dynamique des prix d’ETH, la Fondation Ethereum a présenté un ambitieux plan stratégique (Strawmap), décrivant l’évolution technique du protocole pour les années à venir. La spécification n’est pas simplement une amélioration technique — c’est une transformation qualitative d’Ethereum lui-même : du couche de calcul pour L2 à la base vérifiable de confiance pour toute l’économie décentralisée.

Cette transformation signifie que chaque étape de l’exécution de l’état L1 pourra être compressée et vérifiée via des preuves à zéro connaissance. Il ne s’agit pas de copier les projets zkEVM de L2 (zkSync, Starknet, Scroll), mais d’un objectif fondamentalement différent : transformer la couche d’exécution d’Ethereum en un système compatible ZK. Si L2 zkEVM consiste à construire un univers ZK au-dessus d’Ethereum, alors L1 zkEVM vise à transformer Ethereum lui-même pour atteindre ce niveau.

Trois axes de transformation : du registre programmable à l’infrastructure vérifiable

Le développement d’Ethereum au cours de la dernière décennie a été marqué par une évolution progressive de ses fondements conceptuels et de ses priorités techniques. La première période (2015–2020) s’est concentrée sur Ethereum comme registre programmable capable de faire plus que Bitcoin. Smart contracts, DeFi, NFT, DAO — tout cela a émergé de cette histoire d’une plateforme universelle d’exécution sur blockchain.

La deuxième période (2021–2023) a mis l’accent sur la scalabilité via des solutions Layer 2. Avec la hausse du coût du gaz, les utilisateurs ordinaires ne pouvaient plus se permettre des transactions sur L1, et les solutions de Rollup ont commencé à dominer. Ethereum a peu à peu repensé son rôle comme couche de données et de finalité, fournissant une base sécurisée pour L2. The Merge et EIP-4844 ont servi cet objectif.

La troisième période (2024–2025) marque une réflexion plus profonde. Le paradoxe est que l’essor de L2 a démantelé la valeur de L1 : les utilisateurs migrent vers Arbitrum, Base, Optimism, et interagissent rarement directement avec L1. Cela soulève une question critique dans la communauté : où trouver la valeur de L1 si L2 en détourne tous les utilisateurs ?

L’analyse des axes technologiques clés de Strawmap apporte une réponse. Verkle Tree, Stateless Client, vérification formelle de l’EVM, support natif de ZK — tous ces vecteurs convergent dans une direction : doter Ethereum L1 de sa propre vérifiabilité. C’est une transformation qualitative qui culminera avec L1 zkEVM.

La spécification comme fondement : pourquoi 8 axes de travail transforment l’architecture d’Ethereum

L’interconnexion des changements techniques dans Strawmap se comprend mieux en considérant ces 8 axes comme un système architectural unifié, où chaque composant soutient les autres.

Axe 1 : Spécification formelle de l’EVM comme base

La spécification n’est pas une simple abstraction — c’est une définition mathématique de chaque instruction et règle de transformation d’état. Aujourd’hui, le comportement de l’EVM est défini par des implémentations clients (Geth, Nethermind), sans spécification formelle. Cela signifie que le comportement peut différer dans des cas limites. Pour écrire des circuits ZK, il faut une certitude mathématique. La première et principale ligne de travail est donc de formaliser chaque aspect de l’EVM pour pouvoir le vérifier mathématiquement.

Axe 2 : Remplacer les fonctions de hachage par des équivalents ZK compatibles

Ethereum utilise activement Keccak-256, coûteux pour ZK. La tâche principale est de remplacer progressivement Keccak par des fonctions ZK-friendly (Poseidon, Blake) dans les composants internes, notamment dans les arbres de Merkle et preuves de Merkle. C’est une modification systémique, car les fonctions de hachage imprègnent tout le protocole.

Axe 3 : Verkle Tree au lieu de Merkle Patricia Tree

Verkle Tree remplace les chaînes de hachage par des compromis vectoriels, réduisant la taille des preuves de dizaines de fois. Pour L1 zkEVM, cela signifie : moins de données pour prouver un bloc, génération plus rapide de preuves, et que Verkle Tree est une condition préalable essentielle à la faisabilité de L1 zkEVM.

Axe 4 : Clients sans état (Stateless Clients)

Les clients sans état peuvent vérifier des blocs sans stocker localement la base de données complète — ils ont seulement besoin de données witness. Cela est étroitement lié à Verkle Tree, car la faisabilité pratique dépend de la taille des preuves. Pour L1 zkEVM, cela a un double effet : réduction des exigences matérielles pour les nœuds et définition claire des données d’entrée pour les preuves.

Axe 5 : Standardisation des preuves ZK

L1 zkEVM nécessite un système mature de génération de preuves, mais le domaine ZK est très fragmenté. L’objectif est de définir une interface standardisée au niveau du protocole, permettant à différentes implémentations de concurrencer. L’équipe PSE (Privacy and Scaling Explorations) possède une grande expérience dans ce domaine.

Axe 6 : Séparation des couches d’exécution et de consensus

Actuellement, couche d’exécution (EL) et couche de consensus (CL) interagissent via l’API Engine. Dans L1 zkEVM, chaque changement d’état nécessite une preuve ZK, ce qui peut dépasser l’intervalle entre deux blocs. Il faut dissocier exécution et génération de preuves sans compromettre le consensus — exécution rapide, preuves générées de façon asynchrone.

Axe 7 : Preuves récursives et agrégées

Générer une preuve pour un seul bloc est coûteux, mais l’agrégation récursive de plusieurs blocs en une seule preuve réduit considérablement les coûts de vérification. Les progrès dans ce domaine détermineront directement le coût de fonctionnement de L1 zkEVM.

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

Toutes les améliorations de bas niveau doivent rester transparentes pour les développeurs de smart contracts : des dizaines de milliers de contrats ne doivent pas devenir inutilisables. Cette ligne est sous-estimée mais souvent la plus coûteuse en temps. Chaque mise à jour d’EVM a nécessité des tests massifs de compatibilité. Les changements pour L1 zkEVM dépassent tout ce qui a été fait auparavant, et le volume de travail avec les outils va croître de façon exponentielle.

Pourquoi maintenant : réévaluation d’Ethereum comme infrastructure vérifiable

La publication de Strawmap intervient à une période de doutes sur la dynamique des prix d’ETH, mais la véritable valeur réside dans la reconsidération d’Ethereum comme infrastructure à long terme.

Pour les développeurs, Strawmap offre une direction claire et une confiance dans l’investissement en temps. Pour les utilisateurs, ces améliorations se traduisent par une expérience tangible : transactions confirmées en secondes, actifs transférés sans interruption entre L1 et L2, confidentialité intégrée plutôt qu’accessoire.

Objectivement, L1 zkEVM ne verra pas le jour rapidement — sa mise en œuvre complète est attendue vers 2028–2029 ou plus tard. Mais cela remodèle fondamentalement la proposition de valeur d’Ethereum. Si L1 zkEVM réussit, Ethereum cessera d’être simplement une couche de calcul pour L2 et deviendra une base vérifiable de confiance pour tout le Web3, permettant à tout état de chaîne d’être mathématiquement traçable jusqu’à la chaîne de preuves ZK d’Ethereum.

Cela influence aussi la position à long terme de l’écosystème L2. Quand L1 disposera de ses propres capacités ZK, le rôle de L2 évoluera — passant de « solution de scalabilité sécurisée » à « environnement d’exécution spécialisé ». La place que trouveront ces L2 dans cette nouvelle architecture sera l’un des processus d’évolution les plus passionnants des années à venir.

L’essentiel est que L1 zkEVM démontre la capacité unique d’Ethereum : faire avancer simultanément huit axes techniques interdépendants, chacun étant un projet de plusieurs années, tout en conservant une méthode décentralisée de coordination. C’est cela, la véritable ambition ingénierie.

Évolution par la spécification : d’un focus sur Rollup à des calculs vérifiables

L’évolution du récit d’Ethereum — du modèle « axé sur les Rollup » en 2021 à Strawmap 2026 — reflète une trajectoire claire : la scalabilité ne peut dépendre uniquement de L2, L1 et L2 doivent évoluer conjointement et de manière synergique.

Les huit axes de travail de L1 zkEVM traduisent cette mutation de la mentalité. Chacun vise un objectif : assurer une croissance exponentielle de la performance du réseau principal sans sacrifier la décentralisation. Ce n’est pas une opposition à L2, mais une amélioration et une extension organique.

Dans les trois prochaines années, l’écosystème connaîtra sept bifurcations protocolaires, remplaçant de nombreux composants de son architecture. Lorsqu’en 2029 la prochaine étape sera atteinte, nous pourrions voir apparaître un « vrai niveau global vérifiable de calcul » — rapide, sécurisé, privé et, comme toujours, ouvert à tous. La spécification n’est pas simplement un mécanisme — c’est une promesse que Ethereum restera une infrastructure pour un avenir décentralisé.