Pourquoi les ZkEVM exécutent le code d’Ethereum mais le prouvent en zero-knowledge

La machine virtuelle d’Ethereum (ETH), conçue en 2015, avait pour mission d’exécuter des contrats intelligents — pas de produire des preuves cryptographiques. Les preuves à divulgation nulle de connaissance (zero-knowledge, ZK) ont été, elles, imaginées pour vérifier un calcul de manière économique et privée, sans aucune notion d’opcode.

Pendant des années, ces deux mondes ont semblé fondamentalement incompatibles.

Puis des ingénieurs ont réussi à les fusionner. Résultat : l’une des briques d’infrastructure les plus exigeantes techniquement de tout l’écosystème crypto.

La ZkEVM — pour zero-knowledge Ethereum Virtual Machine — vise à exécuter des contrats intelligents compatibles Ethereum, puis à prouver cryptographiquement qu’ils ont été correctement exécutés, grâce à des preuves ZK, sans demander aux développeurs de réécrire une seule ligne de code.

Sur le papier, l’idée paraît simple. En pratique, cela revient à résoudre des problèmes qui ont bloqué l’industrie pendant plus de cinq ans.

TL;DR

Une ZkEVM exécute des contrats intelligents compatibles Ethereum et génère une preuve zero-knowledge attestant de la correction de l’exécution, ce qui permet un règlement rapide et peu coûteux des transactions sur le mainnet Ethereum.

Plus une ZkEVM est difficile à construire, plus elle est compatible avec l’outillage Ethereum existant : ce compromis est au cœur de tous les choix de conception dans ce domaine.

Les utilisateurs bénéficient de la sécurité d’Ethereum sans payer les frais de gas du mainnet, et les développeurs peuvent déployer leurs contrats Solidity existants avec peu ou pas de modifications.

Ce que font vraiment les preuves zero-knowledge

Avant de parler EVM, il faut bien comprendre ce que sont — et ne sont pas — les preuves zero-knowledge. Une preuve ZK est une méthode cryptographique qui permet à une partie, le prover, de convaincre une autre partie, le verifier, qu’une affirmation est vraie, sans révéler les données qui la rendent vraie.

L’exemple classique consiste à prouver que l’on connaît un mot de passe, sans jamais transmettre ce mot de passe. Dans un contexte blockchain, l’énoncé à prouver est presque toujours computationnel : « J’ai exécuté ce programme sur ces données d’entrée, j’ai obtenu tel résultat, et je l’ai fait correctement. »

Le vérificateur — typiquement un contrat intelligent sur Ethereum en couche 1 — contrôle la preuve en quelques millisecondes, au lieu de ré-exécuter lui-même chaque transaction.

Les preuves zero-knowledge permettent à un réseau de couche 2 de regrouper des milliers de transactions, de générer une preuve compacte validant l’ensemble, puis de ne publier que cette preuve sur Ethereum, ce qui réduit drastiquement le coût par utilisateur.

Deux grandes familles de systèmes de preuve dominent aujourd’hui le paysage ZkEVM. Les SNARKs (Succinct Non-interactive ARguments of Knowledge) produisent des preuves très petites, vérifiables rapidement, mais nécessitent une cérémonie d’initialisation de confiance. Les STARKs (Scalable Transparent ARguments of Knowledge) n’ont pas besoin d’un tel setup et offrent une résistance aux attaques quantiques, mais leurs preuves sont plus volumineuses. La plupart des équipes ZkEVM ont, pour l’instant, convergé vers des systèmes à base de SNARKs, car le coût de vérification sur le mainnet Ethereum est une contrainte dure.

Pourquoi l’EVM est si difficile à « prouver »

La machine virtuelle d’Ethereum est un environnement d’exécution basé sur une pile, avec plus de 140 opcodes, un système de gas, une gestion de la mémoire complexe et quantité de cas limites accumulés en près de dix ans d’usage réel. Chaque opcode, de l’ADD le plus simple jusqu’aux précompilés cryptographiques comme ECRECOVER, doit pouvoir être exprimé sous forme de contraintes arithmétiques compréhensibles par un système de preuve ZK.

Le problème, c’est que les systèmes de preuve ZK s’expriment dans un langage mathématique extrêmement restreint : des corps finis et des équations polynomiales. L’EVM, elle, n’a absolument pas été pensée pour cela. Des opcodes comme KECCAK256 (la fonction de hachage d’Ethereum) sont presque tout ce qu’il y a de plus hostile aux circuits ZK : ils reposent sur des opérations bit à bit qui se traduisent par d’énormes ensembles de contraintes, coûteuses à traiter.

Ce décalage a donné naissance à ce que les chercheurs ont baptisé le « problème d’incompatibilité EVM ». On pouvait construire un rollup ZK rapide et bon marché, mais ne faisant tourner que des programmes sur mesure, écrits pour un environnement ZK-friendly. Ou bien viser le support complet de l’EVM, au prix de temps et de coûts de génération de preuve tels qu’ils en annulaient l’intérêt. Tout l’enjeu d’ingénierie des ZkEVM consiste à résorber ce compromis.

Générer une preuve ZK pour un seul hash KECCAK256 peut nécessiter des millions de contraintes arithmétiques. Un bloc Ethereum typique contient des milliers de hashs, ce qui explique pourquoi la génération de preuves ZkEVM prenait des heures dans les premières implémentations et requiert encore aujourd’hui du matériel spécialisé.

Les quatre types de ZkEVM et ce qu’ils impliquent

Toutes les ZkEVM ne se valent pas. Le chercheur Ethereum Vitalik Buterin a proposé en 2022 une classification, aujourd’hui largement reprise, qui distingue quatre types d’implémentations selon leur degré de compatibilité avec l’écosystème Ethereum existant. Comprendre ces types est le moyen le plus rapide d’évaluer n’importe quel projet ZkEVM.

Type 1 : strictement équivalent à Ethereum. La ZkEVM prouve la transition d’état exacte d’Ethereum, la structure des blocs, les fonctions de hachage, tout, sans aucune modification. Les clients Ethereum existants peuvent donc la synchroniser nativement et tous les outils fonctionnent « out of the box ». Le coût, c’est une génération de preuve extrêmement lente et coûteuse. Aucun ZkEVM de production n’opère aujourd’hui en Type 1, même si certains acteurs y travaillent.

Type 2 : équivalent EVM. Certains éléments internes sont ajustés — par exemple remplacer KECCAK par un hash plus adapté aux preuves ZK dans le state trie — tout en conservant une compatibilité totale au niveau du bytecode EVM. Les contrats intelligents se comportent à l’identique. Les développeurs ne voient aucune différence. La génération de preuves est plus rapide qu’en Type 1, mais reste lourde. Scroll et les premières versions de Polygon zkEVM se situent dans cette catégorie.

Type 3 : davantage de modifications, au point de casser un petit nombre de fonctionnalités très marginales, comme certains précompilés. La quasi-totalité des contrats existants continuent de fonctionner. Mais le coût de génération de preuve baisse de façon significative. La plupart des ZkEVM commerciaux lancés en 2023‑2024 se sont positionnés entre le Type 2 et le Type 3 lors de leurs premières itérations.

Type 4 : compilation du code source Solidity ou Vyper vers une machine virtuelle sur mesure, conçue pour être ZK-friendly, au lieu de prouver directement le bytecode EVM. C’est l’option la plus rapide et la moins chère, mais elle peut introduire des divergences de comportement subtiles et rendre inopérants certains « tricks » bas niveau propres à l’EVM. zkSync Era adopte cette approche avec son compilateur maison basé sur LLVM.

Cette taxonomie est déterminante pour les bâtisseurs. Un projet qui migre un protocole DeFi éprouvé depuis le mainnet visera un Type 2 ou 3 afin de garantir une stricte parité de comportement. Un projet construit from scratch acceptera volontiers un Type 4 en échange de coûts de preuve plus bas et d’une finalité plus rapide.

Comment une ZkEVM traite concrètement une transaction

Suivre une transaction de bout en bout permet de matérialiser l’architecture. Lorsqu’un utilisateur envoie une transaction à un réseau ZkEVM, la séquence est la suivante.

Première étape : la transaction arrive chez un séquenceur, un nœud chargé d’ordonner et d’agréger les transactions en lots. Le séquenceur exécute les transactions, met à jour l’état de la couche 2 et fournit à l’utilisateur une « confirmation souple » quasi instantanée. Le portefeuille de l’utilisateur affiche déjà son nouveau solde, mais la transaction n’est pas encore finalisée cryptographiquement sur Ethereum.

Deuxième étape : le lot de transactions est transmis à un prover, un logiciel (ou matériel) spécialisé qui exécute l’algorithme de preuve ZK. Le prover prend l’état avant exécution, l’ensemble des transactions et l’état après exécution, puis génère une preuve de validité attestant que la transition d’état a été calculée correctement. Cette phase est très gourmande en calcul et peut durer de quelques secondes à plusieurs minutes selon le système.

Troisième étape : la preuve, accompagnée d’une petite quantité de données de transaction compressées, est envoyée à un contrat intelligent Ethereum appelé contrat vérificateur.

Ce contrat vérifie la preuve en un seul appel on-chain, pour un coût en gas fixe, quel que soit le nombre de transactions contenues dans le lot. Une fois la preuve validée, la racine d’état de la couche 2 est finalisée sur Ethereum et bénéficie du même niveau de sécurité qu’une transaction mainnet classique.

ZkEVM modulaire et interopérabilité cross-chain

Le design originel des ZkEVM reposait sur un seul calque de règlement : Ethereum. Toute la preuve et tout le règlement se faisaient sur le mainnet. Une nouvelle génération d’architectures, les ZkEVM modulaires, découplent désormais couche d’exécution, couche de preuve et couche de règlement pour les combiner à la carte.

C’est dans ce paysage que des projets comme Prom se positionnent.

Prom se présente comme une ZkEVM modulaire de couche 2, conçue pour offrir une interopérabilité entre chaînes EVM et non-EVM. Plutôt que de prouver l’exécution et de régler uniquement sur Ethereum, Prom soumet des preuves à plusieurs chaînes en parallèle, créant un pont mathématique entre des écosystèmes qui, jusque-là, n’avaient aucun lien trustless.

L’approche modulaire est importante parce qu’elle remet en question l’idée qu’Ethereum serait la seule surface de règlement légitime.

Une preuve ZkEVM, au fond, n’est qu’un objet mathématique. Si la chaîne A et la chaîne B disposent toutes deux d’un contrat vérificateur capable de contrôler cette preuve, un seul et même artefact peut finaliser une transition d’état sur les deux chaînes simultanément. C’est ainsi que les preuves ZK deviennent un primitive d’interopérabilité universelle, et plus seulement un outil de scalabilité.

Les architectures ZkEVM modulaires dissocient exécution et règlement : une même preuve de validité peut être vérifiée sur Ethereum, sur une chaîne non-EVM, ou sur les deux, établissant une source de vérité cryptographique partagée entre des écosystèmes autrement incompatibles.

ZkEVM contre rollups optimistes : le match, point par point

La comparaison entre ZkEVM et rollups optimistes revient sans cesse, et pour cause : les deux approches visent le même objectif, mais avec des philosophies radicalement opposées.

Les rollups optimistes partent du principe que les transactions sont valides par défaut et ne les vérifient qu’en cas de contestation via une preuve de fraude pendant une période de litige (généralement sept jours). Résultat : des coûts d’exploitation plus faibles, une mise en œuvre plus simple, mais des retraits vers la couche 1 Ethereum qui prennent une semaine, sauf à passer par un pont de liquidité. Arbitrum et Optimism dominent aujourd’hui ce segment des rollups optimistes.

Les rollups ZkEVM, eux, ne présument de rien. Chaque lot de transactions est considéré comme invalide tant qu’une preuve cryptographique n’en établit pas la validité. Cela renchérit le coût de calcul côté preuve, mais permet de finaliser les retraits sur Ethereum en quelques heures plutôt qu’en plusieurs jours, sans dépendre d’observateurs honnêtes chargés de détecter la fraude.

Pour l’utilisateur final, les différences concrètes se résument ainsi :

Vitesse de retrait : avantage net aux ZkEVM, avec une finalité fondée sur la preuve en quelques heures, contre environ sept jours pour un retrait natif sur rollup optimiste.
Coût des transactions : les rollups optimistes restent souvent moins chers aujourd’hui, la génération de preuves ajoutant un surcoût. Cet écart se réduit toutefois au rythme des progrès matériels et algorithmiques côté preuve.
Modèle de sécurité : les ZkEVM offrent des garanties de validité purement cryptographiques. Les rollups optimistes reposent sur un modèle de sécurité économique via preuves de fraude, robuste mais non équivalent à une preuve mathématique.
Compatibilité EVM : les ZkEVM modernes (Type 2/3) ont comblé l’écart et prennent désormais en charge quasi tout l’écosystème d’outils Ethereum, effaçant ce qui fut longtemps un avantage majeur des rollups optimistes.
Risque de liveness : un système ZkEVM peut se figer si le prouveur tombe en panne. Un rollup optimiste continue de traiter les transactions tant que le séquenceur reste opérationnel.

Il n’y a pas de solution universellement supérieure. Les applications à très fort volume, obsédées par le coût et capables d’absorber un délai de retrait de plusieurs jours, privilégient généralement les rollups optimistes. Celles qui exigent une finalité rapide, des règlements inter-chaînes ou une preuve mathématique de la correction de l’exécution s’orientent plutôt vers les ZkEVM.

Qui profite réellement des ZkEVM aujourd’hui ?

Les ZkEVM ne sont plus une promesse lointaine. Plusieurs réseaux sont déjà en production, avec de la valeur verrouillée et de vrais utilisateurs payant de vrais frais. Reste à identifier clairement qui tire le plus parti de chaque couche de cette pile technologique.

Les protocoles DeFi migrés depuis le mainnet Ethereum bénéficient d’une sémantique d’exécution quasi identique (Type 2/3) et de coûts de gas drastiquement réduits. Un protocole qui excluait de fait les particuliers avec 30 $ de gas par swap sur le mainnet peut offrir des transactions à moins d’un centime sur un ZkEVM, sans réécrire ses contrats intelligents.

Les ponts et applications cross-chain tirent profit des architectures ZkEVM modulaires capables de publier des preuves sur plusieurs chaînes. Plutôt que de faire confiance à un pont multisignatures — historiquement la catégorie la plus ciblée et la plus piratée en crypto — les utilisateurs peuvent s’appuyer sur une preuve mathématique vérifiée on-chain.

Les entreprises et institutions développant des applications permissionnées ou semi‑permissionnées obtiennent un environnement d’exécution éprouvé, assorti d’une auditabilité cryptographique. Chaque transition d’état est prouvablement correcte, un élément clé pour la conformité réglementaire et la tenue de comptes.

Les développeurs qui lancent un projet aujourd’hui doivent arbitrer entre Type 4 et Type 2 avant de choisir leur réseau. Si vous écrivez du Solidity neuf et recherchez la vitesse de preuve maximale et les frais les plus bas, un réseau Type 4 peut être le plus adapté. Si vous migrez un protocole existant et ne pouvez pas vous permettre de divergences de comportement, un réseau Type 2 ou Type 3 reste l’option la plus sûre.

Pour l’utilisateur lambda, un ZkEVM se résume à une chaîne compatible Ethereum, rapide et peu coûteuse, où son wallet habituel fonctionne et où ses jetons existants peuvent être bridgés facilement. Toute la complexité cryptographique sous-jacente disparaît en arrière-plan, comme toute bonne infrastructure devrait le faire.

Conclusion

Le ZkEVM est sans doute l’un des problèmes de convergence les plus ardus de la cryptographie appliquée : il s’agit de prendre une machine virtuelle conçue sans structure mathématique explicite et de l’obliger à parler le langage des preuves à divulgation nulle de connaissance.

Les équipes qui y sont parvenues ont passé des années à composer avec l’incompatibilité des fonctions de hachage, l’explosion du nombre de contraintes et la nécessité de prouveurs matériels qui n’existaient tout simplement pas lorsque les papiers fondateurs ont été publiés.

Le secteur reste en évolution rapide. Les temps de génération des preuves continuent de diminuer. Des réseaux de prouveurs décentralisés se déploient. L’équivalence complète de Type 1 avec Ethereum reste un objectif sur lequel plusieurs équipes se rapprochent activement.

Pour tout acteur qui construit sur l’écosystème Ethereum ou y investit, comprendre le fonctionnement réel des ZkEVM — au‑delà des slogans marketing — est désormais un prérequis pour toute décision stratégique.

À suivre : Les 500 Md$ que Nvidia veut injecter dans l’IA mettent les tokens de calcul crypto sous surveillance