Guide pédagogique crypto

Comprendre « Qu'est-ce que la ZK-EVM (Zero-Knowledge Ethereum Virtual Machine) ? » avec des explications précises, des exemples et des sources vérifiables.

Mis à jour le 13/10/2026

Définition : de quoi parle-t-on ?

La ZK‑EVM, ou Zero‑Knowledge Ethereum Virtual Machine, est une version modifiée de l’EVM qui exécute des contrats intelligents tout en prouvant, via des preuves à divulgation nulle (ZKP), que les calculs ont été réalisés correctement, sans exposer les données d’entrée. Contrairement à l’EVM classique, la ZK‑EVM ne transmet pas les informations sensibles, mais génère plutôt un circuit vérifiable et une attestation cryptographique. Cela permet d’obtenir à la fois la compatibilité Ethereum et l’anonymat computationnel.

À quoi cela sert-il ?

La raison d’être de la ZK‑EVM est de combiner la puissance d’un réseau Ethereum avec la confidentialité offerte par les preuves à divulgation nulle. Elle permet aux développeurs de déployer des dApps qui traitent des données sensibles – comme des identités, des transactions financières ou des contrats privés – sans révéler ces informations au réseau. En outre, la ZK‑EVM offre une scalabilité accrue, car les preuves peuvent être vérifiées plus rapidement que les chaînes de blocs traditionnelles, ce qui réduit les coûts de transaction et la latence.

Comment cela fonctionne, étape par étape

Étape 1 Le contrat Solidity est d’abord compilé par un compilateur spécialisé qui transforme son code source en un circuit arithmétique. Ce circuit représente chaque opération arithmétique et logique que le contrat doit exécuter, mais ne contient pas les données d’entrée. Cette étape est cruciale car elle détermine la structure de la preuve qui sera générée plus tard.
Étape 2 Une fois le circuit créé, il est exécuté dans un environnement de calcul qui fournit les entrées réelles du contrat. Au bout de l’exécution, un algorithme zk‑SNARK produit une preuve cryptographique attestant que l’opération a été réalisée sans divulguer les entrées. Cette preuve est compacte et peut être vérifiée instantanément par n’importe quel nœud de la ZK‑EVM.
Étape 3 Le nœud qui reçoit la preuve l’applique à l’ensemble du circuit compilé. Grâce à la formule de vérification zk‑SNARK, le nœud peut confirmer, en quelques opérations, que la preuve est valide. Si la vérification réussit, la transaction est acceptée et les changements d’état sont appliqués à la blockchain.
Étape 4 Une fois validée, la transaction modifie l’état du contrat sans exposer les données d’entrée. Le nouveau snapshot d’état est alors ajouté au registre public. Comme la preuve prouve le bon déroulement, les nœuds n’ont plus besoin de recomputations lourdes, ce qui réduit considérablement la charge réseau.

Exemple concret (scénario fictif)

Imaginez une plateforme de vote électronique où chaque bulletin doit rester confidentiel mais vérifiable. Le client soumet son vote, encodé en entrée, au compilateur qui génère un circuit représentant le scrutin. Le circuit est exécuté, produisant une preuve zk‑SNARK attestant que le vote a été comptabilisé sans révéler sa valeur. Cette preuve est transmise à la ZK‑EVM, qui la vérifie instantanément. Une fois approuvée, le vote est ajouté au registre, et le cryptomonnaie de récompense est distribué. Le résultat final, visible publiquement, montre le nombre de voix pour chaque candidat sans exposer qui a voté. La plateforme garantit la transparence du processus tout en préservant l’anonymat des électeurs, et les vérifications rapides permettent de traiter des milliers de votes sans surcharge réseau.

Différences et cas d’utilisation

EVM classique vs ZK‑EVMLe premier expose toutes les données d’entrée, tandis que la ZK‑EVM utilise des preuves à divulgation nulle pour masquer les informations sensibles, tout en maintenant la compatibilité avec les contrats existants.Scaling via zk‑Rollup vs ZK‑EVMZk‑Rollup agrège plusieurs transactions hors chaîne puis publie une preuve, tandis que la ZK‑EVM exécute les contrats directement sur la chaîne avec preuve, éliminant le besoin d’états intermédiaires.Optimistic Rollup vs ZK‑EVMOptimistic Rollup repose sur des mécanismes de contestation et un délai de validation, alors que la ZK‑EVM fournit une confirmation instantanée grâce à la preuve cryptographique, réduisant ainsi la latence.

Avantages et intérêts possibles

La ZK‑EVM permet de conserver la compatibilité avec les contrats Ethereum tout en protégeant les données d’entrée grâce à des preuves à divulgation nulle. Cela réduit l’exposition des informations sensibles et renforce la confidentialité des transactions, surtout utile pour les applications où la vie privée est prioritaire.
En utilisant des circuits vérifiables, la ZK‑EVM permet de regrouper plusieurs opérations en une seule preuve, ce qui peut diminuer la charge de travail sur la couche principale de la blockchain. Cette approche est particulièrement bénéfique pour les rollups à faible latence où le coût de validation est un facteur critique.
La ZK‑EVM offre une compatibilité quasi-naturelle avec les outils de développement Ethereum existants, comme Truffle ou Hardhat, ce qui facilite la migration des contrats sans réécriture. Cela réduit les coûts de développement et accélère les cycles de déploiement tout en conservant la sécurité des preuves à divulgation nulle.

Inconvénients et limites

Les preuves à divulgation nulle requièrent un temps de calcul initial élevé, ce qui peut entraîner des frais de transaction plus importants au moment de la génération de la preuve, surtout lors de la création de circuits complexes. Cette contrainte peut limiter l’adoption dans les applications à faible marge de profit.
La ZK‑EVM dépend de la création et de la vérification de circuits qui peuvent devenir très volumineux pour des contrats complexes, augmentant la consommation de ressources sur les nœuds vérificateurs. Cela peut engendrer une centralisation potentielle si seules quelques entités disposent des capacités de traitement nécessaires.
Les preuves générées par la ZK‑EVM sont actuellement plus lourdes en taille de fichier que les transactions classiques, ce qui peut entraîner une surcharge du réseau lors de l’injection massive de preuves. Cette limitation peut bloquer la scalabilité si la demande dépasse la capacité de propagation des données.

Risques réels à connaître

Si un circuit de preuve est mal conçu, il peut accepter des résultats incorrects tout en produisant une preuve valide, permettant ainsi une fraude invisible. Cette faille peut conduire à la perte de fonds ou à la manipulation de l’état de la blockchain sans être détectée immédiatement.
Les ZK‑EVM reposent sur des bibliothèques cryptographiques tierces. Une vulnérabilité dans l’une de ces dépendances peut compromettre la validité de la preuve, rendant les transactions acceptées par erreur et exposant les participants à des attaques de type replay ou double dépense.
Le processus de vérification des preuves nécessite la participation de nœuds vérificateurs. Si ces nœuds sont mal configurés ou sous‑concentrés, la vérification peut être lente ou incorrecte, créant un point de défaillance unique qui peut être ciblé par des acteurs malveillants pour bloquer ou retarder les transactions.
Les preuves à divulgation nulle ne protègent pas la confidentialité des métadonnées de la transaction, telles que l'adresse du destinataire. Si ces informations sont exposées, elles peuvent être exploitées pour tracer les mouvements de fonds, contournant partiellement la protection offerte par la ZK‑EVM.

Comment vérifier concrètement

Effectuer une audit de code statique sur le circuit généré : analyser le fichier .wasm ou .json du circuit pour vérifier qu’il n’existe pas de branche conditionnelle non contrôlée et que toutes les variables d’entrée sont correctement initialisées. Cette vérification ne garantit pas la robustesse contre les attaques ciblées.
Tester la preuve avec un ensemble de cas d’entrée connus : exécuter le circuit avec des valeurs d’entrée prédictibles et comparer le résultat avec le résultat attendu. Un échec indique un problème de logique, mais ne détecte pas les failles d’implémentation cryptographique.
Vérifier la validité de la preuve sur un réseau de test indépendant : soumettre la preuve à un nœud de test et s’assurer que la vérification renvoie le même hash d’état que celui attendu. Cela ne prouve pas que le circuit est optimisé ou qu’il ne contient pas de vulnérabilités.
Exécuter un audit de performance : mesurer le temps de génération de la preuve et la taille du fichier généré. Comparer ces métriques à des benchmarks de circuits similaires pour identifier les goulets d’étranglement. Cette analyse ne couvre pas la qualité de la preuve ni la sécurité.
Faire une vérification de conformité avec les spécifications ZKP : valider que le circuit respecte les exigences de l’interface de preuve (par ex. SNARK, STARK). Cette vérification s’assure que le format est correct mais ne garantit pas l’absence de failles logiques.

Pour aller plus loin

Ces références officielles permettent de recouper les règles et les mises en garde ; elles ne valident pas un projet particulier.

AMF — informations et prévention pour les épargnants
Ethereum.org — documentation du réseau Ethereum
Définition : Confirmation Ethereum
Débuter en crypto
Checklist avant transfert
Assistant anti-arnaque

FAQ

Quelles sont les principales différences entre une ZK‑EVM et une EVM classique ?Une EVM classique exécute chaque instruction du contrat et publie l’état de la blockchain à chaque transaction, exposant les données d’entrée. La ZK‑EVM, quant à elle, exécute le même code mais génère après un circuit vérifiable une preuve cryptographique attestant que le calcul a été correct, sans divulguer les valeurs d’entrée. Cette distinction permet de combiner compatibilité Ethereum avec confidentialité computationnelle.

Comment la ZK‑EVM gère-t-elle les mises à jour de contrats intelligents ?La ZK‑EVM ne modifie pas la logique des contrats, elle se contente de transformer chaque appel en un circuit vérifiable. Lorsqu’un contrat est mis à jour, le nouveau code doit être recompilé en circuit et les preuves générées doivent correspondre à l’état précédent. Si la mise à jour contredit l’historique, la preuve sera rejetée par le vérificateur, préservant l’intégrité de la chaîne.

La ZK‑EVM est-elle compatible avec les rollups existants ?Oui, la ZK‑EVM peut être utilisée comme moteur exécutif derrière un rollup ZK. Les transactions sont d’abord exécutées dans la ZK‑EVM, puis une preuve globale est publiée sur la couche principale. Cela permet d’atteindre une scalabilité élevée tout en conservant la sécurité et la compatibilité des contrats Ethereum, sans modifier les infrastructures de rollup existantes.

Retrouvez la version originale et les mises à jour sur SunLibCrypto .