Yellow.com

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

Pendant des années, ces deux mondes ont semblé foncièrement incompatibles.

Puis des ingénieurs ont trouvé comment les fusionner. Le résultat : l’une des pièces 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 qu’ils ont été exécutés correctement 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, il a fallu résoudre des problèmes qui ont bloqué l’industrie pendant près d’un demi‑décennie.

En résumé

Une ZkEVM exécute des contrats intelligents compatibles Ethereum et génère une preuve à divulgation nulle de connaissance attestant que l’exécution est correcte, ce qui permet de régler les transactions rapidement et à moindre coût 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 toutes les décisions de design dans ce domaine.

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

Ce que font réellement les preuves à divulgation nulle de connaissance

Avant de parler EVM, il faut comprendre ce qu’est — et ce que n’est pas — une preuve à divulgation nulle de connaissance. Une preuve ZK est une méthode cryptographique qui permet à une partie, le prouveur, de convaincre une autre partie, le vérificateur, qu’une affirmation est vraie, sans dévoiler les données qui prouvent cette vérité.

L’exemple classique consiste à prouver que vous connaissez un mot de passe sans jamais révéler ce mot de passe. Dans le contexte blockchain, l’assertion est presque toujours computationnelle : « J’ai exécuté ce programme sur telle entrée, obtenu telle sortie, et je l’ai fait correctement. »

Le vérificateur — dans notre cas un contrat intelligent sur Ethereum en couche 1 — vérifie ensuite la preuve en quelques millisecondes, au lieu de ré‑exécuter lui‑même toutes les transactions.

Les preuves ZK permettent à un réseau de couche 2 d’agréger des milliers de transactions, de générer une seule preuve compacte attestant qu’elles sont toutes valides, puis de ne publier que cette preuve sur Ethereum, ce qui réduit drastiquement le coût par utilisateur.

Deux grandes familles de preuves dominent aujourd’hui le paysage ZkEVM. Les SNARKs (Succinct Non-interactive ARguments of Knowledge) produisent des preuves minuscules et très rapides à vérifier, mais nécessitent une « cérémonie » d’initialisation de confiance. Les STARKs (Scalable Transparent ARguments of Knowledge) n’ont pas besoin de ce setup de confiance et sont résistants aux attaques quantiques, au prix de preuves 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 constitue une contrainte dure.

Pourquoi il est si difficile de « prouver » l’EVM

La machine virtuelle d’Ethereum est un environnement d’exécution basé sur une pile, avec plus de 140 opcodes, un système de comptabilité du gas, une mémoire complexe et une multitude de cas limites accumulés au fil de dix ans d’usage réel. Chaque opcode, du simple ADD jusqu’aux précompilés cryptographiques comme ECRECOVER, doit être exprimable sous forme de contraintes arithmétiques pour qu’un système de preuves ZK puisse raisonner dessus.

Le problème est que les systèmes de preuves ZK ne parlent qu’un langage mathématique très restreint : des corps finis et des équations polynomiales. L’EVM a été conçue sans la moindre prise en compte de ces contraintes. Des opcodes comme KECCAK256 (la fonction de hachage d’Ethereum) sont presque « anti‑ZK » par nature, car ils reposent sur des opérations au niveau du bit qui se traduisent par des ensembles de contraintes énormes et coûteux.

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 il ne pouvait exécuter que des programmes écrits sur mesure pour un environnement ZK‑friendly. Ou bien on pouvait tenter de supporter l’EVM dans son intégralité, mais la génération de preuves devenait si lente et chère qu’elle perdait tout intérêt. Le défi d’ingénierie de la ZkEVM consiste à faire disparaître ce choix cornélien.

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 hashes, d’où des temps de génération de preuves de plusieurs heures dans les premières implémentations ZkEVM — et la nécessité de matériel spécialisé encore aujourd’hui.

Les quatre grands 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 taxonomie désormais largement reprise, qui classe les implémentations en quatre types selon leur degré de compatibilité avec la pile Ethereum existante. Comprendre ces types est le moyen le plus rapide d’évaluer n’importe quel projet ZkEVM.

Type 1 : équivalence totale à 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 alors la synchroniser nativement et l’outillage fonctionne tel quel. En contrepartie, la génération de preuves est extrêmement lente et coûteuse. Aucune ZkEVM en production n’opère aujourd’hui en Type 1, même si certains acteurs s’en approchent.

Type 2 : équivalence EVM. Certaines structures de données internes sont adaptées — par exemple remplacer KECCAK par un hash plus ZK‑friendly dans l’arbre d’état — mais la compatibilité bytecode EVM reste totale. Les contrats se comportent à l’identique : les développeurs ne voient pas la différence. Les preuves sont plus rapides à générer qu’en Type 1, mais restent lourdes. Scroll et les premières versions de Polygon zkEVM visent ce spectre.

Type 3 : davantage de modifications qui cassent un petit nombre de fonctionnalités de niche, comme certains précompilés. La quasi‑totalité des contrats existants continuent de fonctionner, mais la génération de preuves devient nettement moins coûteuse. La plupart des ZkEVM commerciales lancées en 2023‑2024 ont démarré quelque part entre le Type 2 et le Type 3.

Type 4 : compilation du code source Solidity ou Vyper vers une machine virtuelle sur mesure, optimisée pour les preuves ZK, plutôt que de prouver directement le bytecode EVM. C’est l’option la plus rapide et la moins chère, mais elle peut introduire de subtiles différences de comportement et certains hacks bas niveau de l’EVM ne fonctionnent plus. zkSync Era adopte cette approche, avec un compilateur maison basé sur LLVM.

Cette classification est décisive pour les bâtisseurs. Un projet qui migre un protocole DeFi éprouvé du mainnet Ethereum recherchera un Type 2 ou 3 afin de garantir une parité de comportement. Un projet lancé from scratch pourra accepter un Type 4 en échange de coûts de preuve plus faibles 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 sur un réseau ZkEVM, la séquence est la suivante.

D’abord, la transaction arrive sur un séquenceur, un nœud chargé d’ordonner et de regrouper 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 » immédiate. À ce stade, le portefeuille de l’utilisateur reflète son nouveau solde, mais la transaction n’est pas encore finalisée cryptographiquement sur Ethereum.

Ensuite, le lot de transactions est transmis à un prouveur, un logiciel (ou du matériel dédié) qui exécute l’algorithme de preuve ZK. Le prouveur 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 étape est extrêmement gourmande en calcul et peut prendre de quelques secondes à plusieurs minutes selon le système.

Troisièmement, la preuve et une petite quantité de données de transaction compressées sont publiées vers un contrat Ethereum appelé contrat vérificateur.

Ce contrat vérifie la preuve via un seul appel on‑chain, pour un coût en gas fixe, quel que soit le nombre de transactions incluses 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 de la même sécurité qu’une transaction mainnet classique.

ZkEVM modulaire et interopérabilité inter‑chaînes

La conception originelle des ZkEVM supposait un unique layer de règlement : Ethereum. Toute preuve, tout règlement se faisait sur le mainnet. Mais une nouvelle architecture, la ZkEVM modulaire, sépare couche d’exécution, couche de preuve et couche de règlement, afin de les composer indépendamment.

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

Prom se définit comme une ZkEVM modulaire de couche 2 visant l’interopérabilité entre chaînes EVM et non‑EVM. Plutôt que de ne prouver l’exécution et de se régler que sur Ethereum, elle soumet des preuves simultanément à plusieurs chaînes, créant un pont mathématique entre des écosystèmes auparavant dépourvus de connexions « trustless ».

L’approche modulaire est clé car elle rompt avec l’idée qu’Ethereum serait la seule surface de règlement légitime.

Une preuve ZkEVM n’est in fine que des mathématiques. Si la chaîne A et la chaîne B disposent toutes deux d’un contrat vérificateur capable de valider cette preuve, un seul et même artefact cryptographique peut finaliser une transition d’état sur les deux réseaux en parallèle. C’est ainsi que les preuves ZK deviennent un primitif universel d’interopérabilité, au‑delà de leur rôle de simple solution de scalabilité.

Les architectures ZkEVM modulaires découplent l’exécution du règlement, ce qui permet de vérifier une même preuve de validité sur Ethereum, sur une chaîne non‑EVM, ou sur les deux, créant une source de vérité cryptographique partagée entre des écosystèmes autrement incompatibles.

ZkEVM contre rollups optimistes : le face-à-face

La comparaison entre ZkEVM et rollups optimistes revient sans cesse, et pour cause : ces deux approches s’attaquent au même problème avec des philosophies diamétralement opposées.

Les rollups optimistes partent du principe que les transactions sont valides par défaut et ne les vérifient réellement que si un acteur soumet une preuve de fraude pendant une fenêtre de contestation (généralement sept jours). À l’usage, cela les rend moins coûteux à faire tourner et plus simples à développer, mais implique qu’un retrait vers l’Ethereum mainnet prend une semaine, sauf à passer par un bridge 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 ne démontre pas le contraire. Résultat : une charge de calcul nettement plus lourde côté « prover », mais des retraits finalisés sur Ethereum en quelques heures au lieu de plusieurs jours, sans dépendre d’observateurs honnêtes chargés de détecter les fraudes.

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

Vitesse de retrait : net avantage aux ZkEVM, dont la finalité à base de preuves se compte en heures, contre sept jours pour un retrait natif sur rollup optimiste.
Coût des transactions : les rollups optimistes restent aujourd’hui, dans de nombreux cas, moins chers, car la génération de preuves ajoute un surcoût. L’écart se réduit toutefois à mesure que le matériel et les algorithmes de « proving » s’améliorent.
Modèle de sécurité : ZkEVM offre des garanties de validité purement cryptographiques. Les rollups optimistes reposent sur une sécurité économique via les preuves de fraude : robuste, mais pas équivalente à une preuve mathématique.
Compatibilité EVM : les ZkEVM modernes (Type 2/3) ont largement comblé leur retard et supportent désormais l’essentiel de l’outillage Ethereum existant, gommant ce qui fut longtemps un avantage décisif des rollups optimistes.
Risque de « liveness » : un système ZkEVM peut se figer si le prover tombe en panne. Un rollup optimiste continue de traiter les transactions tant que le séquenceur reste opérationnel.

Aucune approche n’est objectivement supérieure en toutes circonstances. Les applications à très fort volume, obsédées par la compression des coûts et capables de tolérer un délai de retrait prolongé, privilégient les rollups optimistes. Celles qui exigent une finalité rapide, des règlements inter-chaînes ou une preuve mathématique de correction s’orientent vers les ZkEVM.

Qui profite réellement des ZkEVM aujourd’hui ?

Les ZkEVM ne sont plus une technologie hypothétique. Plusieurs réseaux sont déjà en production, avec de la valeur verrouillée et de vrais utilisateurs payant de vrais frais. Reste à comprendre qui bénéficie le plus de chaque couche de cette pile technologique.

Les protocoles DeFi migrés depuis l’Ethereum mainnet profitent d’une sémantique d’exécution quasi identique (Type 2/3) et de coûts de gas radicalement inférieurs. Un protocole qui écartait de facto les petits portefeuilles avec des frais de 30 dollars par swap sur le mainnet peut proposer des transactions à la fraction de centime sur un ZkEVM, sans réécrire ses smart contracts.

Les bridges et applications cross-chain tirent avantage des architectures ZkEVM modulaires capables de publier leurs preuves sur plusieurs chaînes. Plutôt que de faire confiance à un bridge multisignature – historiquement la catégorie la plus ciblée par les hacks dans la crypto – les utilisateurs peuvent s’appuyer sur une preuve mathématique vérifiée on-chain.

Les entreprises et institutions qui développent des applications permissionnées ou semi-permissionnées disposent d’un environnement d’exécution éprouvé, avec auditabilité cryptographique. Chaque transition d’état est prouvablement correcte, un point clé pour la conformité réglementaire et la tenue de comptes.

Les développeurs qui lancent aujourd’hui de nouveaux projets doivent arbitrer soigneusement entre Type 4 et Type 2 avant de choisir leur réseau. Si vous écrivez du Solidity « from scratch » et recherchez une vitesse de preuve maximale et des frais minimisés, un réseau de Type 4 peut être approprié. Si vous migrez un protocole existant et ne pouvez pas vous permettre de divergences de comportement, un réseau de Type 2 ou Type 3 sera plus prudent.

Pour l’utilisateur lambda, un ZkEVM se présente avant tout comme une chaîne Ethereum-compatible rapide et peu coûteuse, où son wallet habituel fonctionne et où ses tokens existants peuvent être bridgés. Toute la sophistication cryptographique sous-jacente reste invisible, ce qui est précisément la promesse d’une bonne infrastructure.

Conclusion

ZkEVM constitue sans doute le problème de convergence le plus ardu de la cryptographie appliquée : prendre une machine virtuelle conçue sans structure mathématique particulière et l’obliger à « parler » le langage des preuves à divulgation nulle de connaissance.

Les équipes qui ont relevé ce défi ont passé des années à composer avec des incompatibilités de fonctions de hachage, l’explosion du nombre de contraintes, et un matériel de preuve qui n’existait tout simplement pas lorsque les papiers fondateurs ont été publiés.

L’écosystème continue d’évoluer à grande vitesse. Les temps de génération de preuves se contractent. Des réseaux décentralisés de provers se mettent en place. L’équivalence complète de Type 1 avec Ethereum reste un objectif, et plusieurs équipes s’en rapprochent activement.

Pour tout acteur qui construit sur l’écosystème Ethereum ou y investit, comprendre le fonctionnement réel des ZkEVM – au-delà du discours marketing – est désormais le socle de toute décision stratégique.

Comment la ZkEVM exécute le code d’Ethereum tout en le prouvant par zéro connaissance