Rien qu'en termes de perception, depuis 2025, la fréquence des mises à jour de la communauté des développeurs core d'Ethereum est anormalement dense.
De la mise à niveau Fusaka, à Glamsterdam, en passant par la planification à long terme pour les trois prochaines années autour de sujets comme le kEVM, le système cryptographique anti-quantique, la limite de Gas, Ethereum a publié de manière intensive, en quelques mois seulement, de nombreux documents de feuille de route couvrant trois à cinq ans.
Ce rythme en lui-même est un signal.
Si vous lisez attentivement la dernière feuille de route, vous découvrirez une direction plus claire et plus radicale qui émerge : Ethereum est en train de se transformer en un ordinateur vérifiable, et le point final de cette voie est le zkEVM de L1.
I. Les trois dérives du centre de gravité du récit d'Ethereum
Le 26 février, Justin Drake, chercheur à la Fondation Ethereum, a publié sur une plateforme sociale un message indiquant que la Fondation Ethereum avait proposé un projet de feuille de route nommé Strawmap, décrivant les orientations de mise à niveau du protocole L1 d'Ethereum pour les prochaines années.
Cette feuille de route propose cinq objectifs principaux : un L1 plus rapide (finalité en quelques secondes), un L1 « Gigagas » à 10 000 TPS via zkEVM, un L2 à haut débit basé sur l'échantillonnage de la disponibilité des données (DAS), un système cryptographique anti-quantique, une fonction de transfert natif privé ; la feuille de route prévoit également sept forks de protocole d'ici 2029, soit environ un tous les six mois en moyenne.
On peut dire que au cours des dix dernières années, le développement d'Ethereum a toujours été accompagné d'une évolution constante du récit et de l'orientation technologique.
La première phase (2015–2020) était celle du registre programmable.
C'était le noyau narratif initial d'Ethereum, à savoir les « smart contracts Turing-complets ». À l'époque, le plus grand avantage d'Ethereum était qu'il pouvait faire plus de choses que Bitcoin, comme la DeFi, les NFT, les DAO, tous des produits de ce récit. Un grand nombre de protocoles financiers décentralisés ont commencé à fonctionner on-chain, du prêt et des DEX aux stablecoins, Ethereum est progressivement devenu le principal réseau de règlement de l'économie crypto.
La deuxième phase (2021–2023) a été la reprise du récit par les L2.
Avec la flambée des frais de Gas sur le mainnet d'Ethereum, les utilisateurs ordinaires ne pouvaient plus assumer le coût des transactions, et les Rollups sont devenus les acteurs principaux de la scalabilité. Ethereum s'est progressivement repositionné comme une couche de règlement, visant à fournir une base de sécurité pour les L2.
En bref, il s'agissait de migrer la majeure partie du calcul de la couche d'exécution vers les L2, en faisant scale via les Rollups, tandis que le L1 ne serait responsable que de la disponibilité des données et du règlement final. Durant cette période, The Merge, l'EIP-4844 ont servi ce récit, visant à permettre aux L2 d'utiliser la confiance d'Ethereum de manière moins chère et plus sûre.
La troisième phase (2024–2025) s'est concentrée sur l'implosion et la réflexion du récit.
Comme on le sait, la prospérité des L2 a apporté un problème inattendu : le L1 d'Ethereum lui-même est devenu moins important. Les utilisateurs ont commencé à opérer davantage sur Arbitrum, Base, Optimism, et rarement directement sur le L1. La performance du prix de l'ETH d'Ethereum a également reflété cette anxiété.
Cela a conduit la communauté à débattre : si les L2 accaparent tous les utilisateurs et l'activité, où se situe la capture de valeur pour le L1 ? Jusqu'aux secousses internes d'Ethereum en 2025, et à la série de feuilles de route déployées en 2026, cette logique est en train d'évoluer profondément.
En réalité, en examinant les principales orientations techniques depuis 2025, Verkle Tree, les clients sans état (Stateless Client), la vérification formelle de l'EVM, le support natif ZK reviennent constamment. Ces orientations techniques pointent toutes vers la même chose : permettre au L1 d'Ethereum lui-même d'être vérifiable. Il est important de noter qu'il ne s'agit pas seulement de permettre la vérification des preuves des L2 sur le L1, mais de faire en sorte que chaque étape de transition d'état du L1 puisse être compressée et vérifiée par une preuve à connaissance nulle (ZK Proof).
C'est là que réside l'ambition du zkEVM de L1. Contrairement au zkEVM de L2, le zkEVM de L1 (zkEVM en coque, in-shell zkEVM) signifie l'intégration directe de la technologie de preuve à connaissance nulle dans la couche de consensus d'Ethereum.
Ce n'est pas une copie des zkEVM de L2 (comme zkSync, Starknet, Scroll), mais la transformation de la couche d'exécution d'Ethereum elle-même en un système adapté au ZK. Donc, si le zkEVM de L2 consiste à construire un monde ZK sur Ethereum, alors le zkEVM de L1 consiste à faire d'Ethereum lui-même ce monde ZK.
Une fois cet objectif atteint, le récit d'Ethereum évoluera de la couche de règlement des L2 vers la « racine de confiance pour le calcul vérifiable ».
Ce sera un changement qualitatif, et non pas le changement quantitatif des dernières années.
II. Qu'est-ce qu'un véritable zkEVM de L1 ?
Répétons un point bien connu : dans le mode traditionnel, les validateurs doivent « réexécuter » chaque transaction pour vérifier un bloc, tandis qu'en mode zkEVM, les validateurs n'ont besoin de vérifier qu'une seule Preuve ZK. Cela permet à Ethereum d'augmenter la limite de Gas à 100 millions ou plus sans augmenter la charge des nœuds (lecture complémentaire : « Le moment de l'aube » de la route ZK : La feuille de route de la finalité d'Ethereum accélère-t-elle globalement ?).
Cependant, transformer le L1 d'Ethereum en zkEVM n'est absolument pas une question de percée ponctuelle, mais nécessite d'avancer simultanément dans huit directions, chacune étant un projet de plusieurs années.
Ligne de travail 1 : Spécification formelle de l'EVM (EVM Formalization)
Le prérequis de toute preuve ZK est que l'objet à prouver ait une définition mathématique précise. Or, l'EVM d'aujourd'hui voit son comportement défini par les implémentations client (Geth, Nethermind, etc.), et non par une spécification formelle stricte. Le comportement des différents clients peut varier dans des cas limites, ce qui rend extrêmement difficile l'écriture de circuits ZK pour l'EVM, car on ne peut pas écrire de preuve pour un système mal défini.
L'objectif de cette ligne de travail est donc d'écrire chaque instruction de l'EVM, chaque règle de transition d'état, sous forme de spécification formelle vérifiable par machine. C'est la fondation de tout le projet L1 zkEVM. Sans elle, tout ce qui suit serait bâti sur du sable.
Ligne de travail 2 : Remplacement par une fonction de hachage adaptée au ZK
Ethereum utilise actuellement massivement Keccak-256 comme fonction de hachage. Keccak est extrêmement peu adapté aux circuits ZK, avec des coûts de calcul très élevés, ce qui augmenterait significativement le temps et le coût de génération des preuves.
Le cœur de cette ligne de travail est de remplacer progressivement l'utilisation de Keccak à l'intérieur d'Ethereum par des fonctions de hachage adaptées au ZK (comme Poseidon, la famille Blake), en particulier dans l'arbre d'état et les chemins de preuve Merkle. C'est une modification qui touche à tout, car la fonction de hachage imprègne chaque recoin du protocole Ethereum.
Ligne de travail 3 : Remplacement du Merkle Patricia Tree par Verkle Tree
C'est l'un des changements les plus attendus de la feuille de route 2025–2027. Ethereum utilise actuellement le Merkle Patricia Tree (MPT) pour stocker l'état global. Verkle Tree, en remplaçant les liens de hachage par des engagements vectoriels (Vector Commitment), peut compresser le volume des témoins (witness) de plusieurs dizaines de fois.
Pour le L1 zkEVM, cela signifie une réduction drastique de la quantité de données nécessaires pour prouver chaque bloc, une augmentation significative de la vitesse de génération des preuves, et signifie également que l'introduction de Verkle Tree est une infrastructure clé prérequise pour la faisabilité du L1 zkEVM.
Ligne de travail 4 : Clients sans état (Stateless Clients)
Un client sans état signifie qu'un nœud, pour vérifier un bloc, n'a pas besoin de stocker localement la base de données complète de l'état d'Ethereum. Il lui suffit des données de témoin (witness) fournies avec le bloc lui-même pour terminer la vérification.
Cette ligne de travail est profondément liée à Verkle Tree, car seul un witness suffisamment petit rend les clients sans état réellement viables. Ainsi, la signification des clients sans état pour le L1 zkEVM est double : d'une part, ils réduisent considérablement le seuil matériel pour exécuter un nœud, ce qui contribue à la décentralisation ; d'autre part, ils fournissent une limite d'entrée claire pour les preuves ZK, permettant au prouveur de ne traiter que les données contenues dans le witness, et non l'état global entier.
Ligne de travail 5 : Standardisation et intégration du système de preuve ZK
Le L1 zkEVM a besoin d'un système de preuve ZK mature pour générer des preuves pour l'exécution des blocs. Mais actuellement, le paysage technologique du domaine ZK est très fragmenté, sans solution optimale unanimement reconnue. L'objectif de cette ligne de travail est de définir au niveau de la couche protocolaire d'Ethereum une interface de preuve standardisée (proof interface), permettant à différents systèmes de preuve de se connecter via la concurrence, plutôt que d'en désigner un spécifique.
Cela maintient à la fois l'ouverture technologique et laisse de l'espace pour l'évolution continue des systèmes de preuve. L'équipe PSE (Privacy and Scaling Explorations) de l'Ethereum Foundation a déjà accumulé beaucoup de travail préliminaire dans cette direction.
Ligne de travail 6 : Découplage de la couche d'exécution et de la couche de consensus (Évolution de l'Engine API)
Actuellement, la couche d'exécution (EL) et la couche de consensus (CL) d'Ethereum communiquent via l'Engine API. Dans l'architecture du L1 zkEVM, chaque transition d'état de la couche d'exécution nécessite la génération d'une preuve ZK, et le temps de génération de cette preuve pourrait largement dépasser l'intervalle de création d'un bloc.
Le problème central que cette ligne de travail doit résoudre est de savoir comment découpler l'exécution et la génération de preuve sans briser le mécanisme de consensus – l'exécution peut d'abord se terminer rapidement, la preuve peut être générée de manière asynchrone et différée, puis les validateurs peuvent effectuer la confirmation finale au moment opportun. Cela implique une modification profonde du modèle de finalité des blocs (Finality).
Ligne de travail 7 : Preuve récursive et agrégation de preuves
Le coût de génération d'une preuve ZK pour un seul bloc est élevé, mais si les preuves de plusieurs blocs peuvent être agrégées récursivement en une seule preuve, le coût de vérification sera considérablement réduit. Les progrès de cette ligne de travail détermineront directement à quel faible coût le L1 zkEVM pourra fonctionner.
Ligne de travail 8 : Chaîne d'outils pour développeurs et garantie de compatibilité EVM
Toutes les transformations techniques sous-jacentes doivent finalement être transparentes pour les développeurs de smart contracts sur Ethereum. Les centaines de milliers de contrats existants ne doivent pas devenir invalides à cause de l'introduction du zkEVM. La chaîne d'outils des développeurs ne doit pas être obligée de tout réécrire.
Cette ligne de travail est la plus facilement sous-estimée, mais souvent la plus chronophage. Historiquement, chaque mise à niveau de l'EVM a nécessité d'importants tests de compatibilité ascendante et d'adaptation de la chaîne d'outils. L'ampleur des modifications du L1 zkEVM est bien plus grande que celle des mises à niveau précédentes, et la charge de travail pour la chaîne d'outils et la compatibilité sera d'un ordre de grandeur supérieur.
III. Pourquoi est-ce le bon moment pour comprendre cela ?
La publication de Strawmap coïncide avec un moment où le marché nourrit des doutes quant à la performance du prix de l'ETH. Sous cet angle, la valeur la plus importante de cette feuille de route réside précisément dans la redéfinition d'Ethereum comme « infrastructure ».
Pour les builders, représentés par les développeurs, Strawmap apporte une certitude directionnelle ; pour les utilisateurs, ces mises à niveau techniques se traduiront finalement par une expérience perceptible : les transactions finalisées en quelques secondes, les actifs circulant de manière transparente entre le L1 et les L2, la protection de la vie privée devenant une fonction intégrée et non un plugin.
Bien sûr, objectivement, le L1 zkEVM ne sera pas un produit qui sera déployé prochainement. Sa mise en œuvre complète pourrait nécessiter jusqu'en 2028-2029, voire plus tard.
Mais au moins, il redéfinit la proposition de valeur d'Ethereum. Si le L1 zkEVM réussit, Ethereum ne sera plus seulement la couche de règlement des L2, mais la racine de confiance vérifiable de tout le monde Web3, permettant à tout état on-chain de pouvoir finalement être retracé mathématiquement jusqu'à la chaîne de preuves ZK d'Ethereum. Ceci est déterminant pour la capture de valeur à long terme d'Ethereum.
Ensuite, cela influence également le positionnement à long terme des L2. Après tout, lorsque le L1 lui-même aura des capacités ZK, le rôle des L2 changera – évoluant de « solution de scaling sécurisée » vers « environnement d'exécution spécialisé ». Quels L2 pourront trouver leur place dans ce nouveau paysage sera l'évolution écologique la plus digne d'être observée dans les prochaines années.
Le plus important, c'est que je pense que c'est aussi une fenêtre d'observation idéale sur la culture des développeurs d'Ethereum – pouvoir avancer simultanément sur huit lignes de travail technologiques interdépendantes, chacune étant un projet de plusieurs années, et maintenir un mode de coordination décentralisé, c'est en soi la capacité unique d'Ethereum en tant que protocole.
Comprendre cela aide à évaluer plus précisément la position réelle d'Ethereum dans les divers récits concurrents.
Dans l'ensemble, du « centré sur les Rollups » en 2020 à Strawmap en 2026, l'évolution du récit d'Ethereum reflète une trajectoire claire : le scaling ne peut pas reposer uniquement sur les L2, le L1 et les L2 doivent évoluer de concert.
Ainsi, les huit lignes de travail du L1 zkEVM sont la cartographie technique de ce changement de perception. Elles pointent ensemble vers un objectif, à savoir permettre au mainnet d'Ethereum d'obtenir une amélioration de performance d'un ordre de grandeur sans sacrifier la décentralisation. Ce n'est pas un rejet de la voie des L2, mais son perfectionnement et son complément.
Dans les trois prochaines années, ce « Bateau de Thésée » subira sept forks, remplacera d'innombrables « planches ». Lorsqu'il atteindra le prochain arrêt en 2029, nous verrons peut-être une « couche de règlement globale » au vrai sens du terme – rapide, sûre, privée, et comme toujours ouverte.
Restons à l'affût.
