Preuves à divulgation nulle (ZK) : les bases
Comprendre les preuves à divulgation nulle de connaissance : l’intuition, SNARK vs STARK, trusted setup, ZK rollups, paiements privés et limites.
L’essentiel
L’idée de départ : prouver sans montrer
Imaginez que vous deviez prouver à un videur que vous avez plus de 18 ans. Aujourd’hui, vous montrez votre carte d’identité : il voit votre date de naissance exacte, votre nom, votre adresse parfois. Tout ce qu’il avait besoin de savoir, c’était « majeur : oui ou non ».
Une preuve ZK permet précisément cela : convaincre quelqu’un qu’une affirmation est vraie, sans lui donner rien d’autre que ce seul fait.
Le concept a été formalisé en 1985 dans un article de recherche, The Knowledge Complexity of Interactive Proof Systems. Deux rôles y sont définis :
- le prouveur (prover), qui connaît un secret et veut prouver une affirmation ;
- le vérificateur (verifier), qui veut être convaincu sans apprendre le secret.
L’exemple de la grotte
L’illustration classique est celle de la grotte d’Ali Baba, popularisée par le cryptographe Jean-Jacques Quisquater. Une grotte forme un anneau, avec une porte magique au fond qui ne s’ouvre qu’avec un mot de passe. Peggy (la prouveuse) entre et choisit un côté sans que Victor (le vérificateur) la voie. Victor crie ensuite de quel côté il veut la voir ressortir. Si Peggy connaît le mot de passe, elle réussit à chaque fois. Si elle ne le connaît pas, elle n’a qu’une chance sur deux à chaque essai. Après vingt essais réussis, la probabilité qu’elle ait triché devient infime, et Victor n’a pourtant jamais entendu le mot de passe.
Les trois propriétés d’une preuve ZK
Pour mériter son nom, un protocole ZK doit respecter trois propriétés :
| Propriété | Ce qu’elle garantit |
|---|---|
| Complétude | Si l’affirmation est vraie et que chacun est honnête, la preuve est acceptée |
| Robustesse (soundness) | Un tricheur ne peut pas faire accepter une affirmation fausse, sauf avec une probabilité négligeable |
| Divulgation nulle | Le vérificateur n’apprend rien d’autre que « vrai » ou « faux » |
Interactif ou non interactif
L’exemple de la grotte est interactif : il faut plusieurs allers-retours entre les deux parties. Sur une blockchain, c’est peu pratique, car des milliers de nœuds doivent pouvoir vérifier la preuve sans dialoguer avec le prouveur. On utilise donc des preuves non interactives : le prouveur produit une preuve unique, que n’importe qui peut vérifier seul, autant de fois que nécessaire. Ces travaux remontent notamment à Blum, Feldman et Micali.
SNARK et STARK : les deux grandes familles
Deux acronymes reviennent sans cesse dans l’écosystème.
zk-SNARK signifie Zero-Knowledge Succinct Non-Interactive Argument of Knowledge. « Succinct » veut dire que la preuve est courte et rapide à vérifier, quelle que soit la complexité du calcul prouvé.
zk-STARK signifie Zero-Knowledge Scalable Transparent Argument of Knowledge. « Transparent » veut dire qu’aucune cérémonie de paramètres secrets n’est nécessaire.
| Critère | zk-SNARK | zk-STARK |
|---|---|---|
| Paramètres initiaux | Souvent un trusted setup | Aléa public, pas de trusted setup |
| Taille de la preuve | Petite, vérification peu coûteuse | Plus grande, vérification plus chère |
| Sécurité face à l’ordinateur quantique | Repose sur les courbes elliptiques, vulnérables en théorie | Repose sur des fonctions de hachage, considérées comme résistantes |
Aucun des deux n’est « meilleur » dans l’absolu : c’est un arbitrage entre taille des preuves, coût de vérification, hypothèses de confiance et performances sur de gros calculs. Certains projets combinent d’ailleurs les deux approches.
Le trusted setup, expliqué simplement
Beaucoup de SNARK ont besoin de paramètres publics générés une fois pour toutes, parfois appelés Common Reference String. Pour les fabriquer, on utilise un nombre aléatoire secret. Problème : quiconque connaîtrait ce secret pourrait fabriquer de fausses preuves qui passeraient la vérification. Dans le cas d’une cryptomonnaie privée, cela pourrait permettre de créer de la monnaie à partir de rien sans que personne ne s’en aperçoive.
La parade est la cérémonie multipartite : de nombreux participants ajoutent chacun leur part d’aléa, puis la détruisent. Il suffit qu’un seul participant ait été honnête et ait bien détruit sa contribution pour que le résultat soit sûr. C’est l’hypothèse dite « 1 sur N ».
Deux exemples réels :
- Zcash a organisé deux cérémonies de ce type, pour ses protocoles Sprout puis Sapling.
- Ethereum a mené une cérémonie dite KZG pour préparer son mécanisme de « blobs » (des espaces de données bon marché pour les rollups). Elle a réuni plus de 140 000 contributions, ce qui en fait, selon ethereum.org, la plus grande cérémonie de ce genre. Pour la compromettre, il aurait fallu que 100 % des participants soient malhonnêtes.
La recherche a aussi produit des systèmes sans trusted setup. Zcash a ainsi introduit en mai 2022, avec la mise à jour NU5, le protocole Orchard basé sur Halo 2, qui supprime le besoin de cérémonie.
À quoi servent les preuves ZK dans la crypto
Passer à l’échelle : les ZK rollups
Un rollup est un réseau de couche 2 qui exécute les transactions en dehors de la blockchain principale, puis y publie un résumé. Dans un ZK rollup, ce résumé est accompagné d’une preuve de validité : une preuve cryptographique que toutes les transactions du lot ont été correctement exécutées. Le contrat intelligent sur Ethereum vérifie la preuve et n’accepte le nouvel état que si elle est valide.
Conséquence pratique : pas besoin d’attendre une période de contestation pour retirer ses fonds vers Ethereum, contrairement aux rollups optimistes. Les données des transactions restent publiées sur Ethereum, sous forme compressée, pour que chacun puisse reconstituer l’état. Attention : ici, la preuve sert surtout à garantir l’exactitude du calcul, pas à cacher les transactions. Un ZK rollup n’est pas forcément privé.
Les paiements privés
Zcash utilise les zk-SNARK pour ses transactions dites blindées (shielded) : elles sont chiffrées sur la blockchain, mais le réseau peut quand même vérifier qu’elles sont valides, c’est-à-dire que personne ne dépense plus que ce qu’il possède. Des applications ont aussi appliqué la même logique sur Ethereum pour masquer le lien entre dépôt et retrait, avec les enjeux juridiques que cela a pu soulever.
Les preuves d’identité et d’attributs
Les preuves ZK permettent de prouver une caractéristique sans montrer le document complet : être majeur, résider dans un pays, être une personne unique. Ethereum.org cite par exemple le système d’identité numérique national du Bhoutan, où un citoyen peut prouver sa citoyenneté ou son âge sans exposer ses données.
Le vote et d’autres usages
Des systèmes de vote comme MACI utilisent les preuves ZK pour garder chaque vote secret tout en limitant la corruption. Plus largement, on parle de calcul vérifiable : déléguer un calcul lourd à quelqu’un et vérifier rapidement qu’il l’a fait correctement.
Les limites à connaître
- Le coût de génération. Produire une preuve demande beaucoup de puissance de calcul, parfois du matériel spécialisé. Cela peut pousser à la centralisation des prouveurs.
- Le coût de vérification sur la chaîne. Selon ethereum.org, vérifier une seule preuve zk-SNARK coûte environ 500 000 unités de gas sur Ethereum, et davantage pour un STARK. Ce coût est partagé entre les transactions d’un lot.
- Les hypothèses de confiance. Un trusted setup reste une hypothèse, même si elle est faible avec des milliers de participants.
- La menace quantique pour les systèmes basés sur les courbes elliptiques, qui reste théorique à ce jour.
- La complexité. Les circuits ZK sont difficiles à écrire et à auditer. Un bug dans le circuit peut rendre acceptable une preuve qui ne devrait pas l’être : la garantie mathématique ne vaut que si l’implémentation est correcte.
- La confidentialité n’est pas automatique. Votre adresse, vos montants de dépôt, l’horaire de vos transactions ou vos habitudes peuvent encore vous identifier en dehors de la partie protégée.
Ce guide est une information générale et ne constitue pas un conseil en investissement, juridique ou fiscal.
Exemple concret
Léa veut retirer 0,5 ETH d’un ZK rollup vers Ethereum. Voici ce qui se passe, simplifié :
- Sa demande de retrait est incluse dans un lot de plusieurs milliers de transactions traité par l’opérateur du rollup.
- Un prouveur calcule une preuve de validité qui atteste que toutes ces transactions respectent les règles, y compris que Léa possédait bien 0,5 ETH.
- Le contrat du rollup sur Ethereum vérifie la preuve en une seule opération.
- Une fois la preuve acceptée, le retrait peut être exécuté, sans période de contestation de plusieurs jours.
À aucun moment Ethereum ne rejoue les milliers de transactions : il vérifie seulement la preuve. En revanche, les données du lot sont publiées sur Ethereum, et le retrait de Léa reste visible. La preuve a garanti l’exactitude, pas l’anonymat.
Checklist pour évaluer un projet qui « utilise le ZK »
- À quoi sert la preuve : exactitude du calcul, confidentialité, ou les deux ?
- Quel système de preuve est utilisé (SNARK, STARK, autre) ?
- Y a-t-il eu un trusted setup ? Combien de participants, et la cérémonie est-elle documentée publiquement ?
- Les circuits et contrats ont-ils été audités, et le code est-il public ?
- Qui génère les preuves : un seul opérateur ou plusieurs ?
- Les données restent-elles disponibles pour reconstituer l’état en cas de problème ?
Les erreurs à éviter
- Croire que « ZK » veut dire « anonyme ». Beaucoup de ZK rollups sont entièrement publics ; le ZK y sert à la mise à l’échelle.
- Prendre la preuve mathématique pour une garantie totale. Une implémentation boguée ou un contrat modifiable peuvent toujours poser problème.
- Ignorer la question du trusted setup quand un projet l’a utilisé sans cérémonie publique ou avec très peu de participants.
- Oublier les métadonnées. Même avec une transaction blindée, les montants ronds, les horaires ou la réutilisation d’adresses peuvent trahir votre activité.
- Confondre marketing et technique. Le mot « ZK » est parfois utilisé comme argument commercial pour des projets qui n’utilisent que marginalement ces preuves.
À retenir
- Une preuve ZK prouve qu’une affirmation est vraie sans révéler l’information sous-jacente, grâce à trois propriétés : complétude, robustesse et divulgation nulle.
- Les zk-SNARK produisent des preuves courtes mais nécessitent souvent un trusted setup ; les zk-STARK sont transparents mais produisent des preuves plus lourdes.
- Un trusted setup est sûr tant qu’au moins un participant a été honnête ; des systèmes comme Halo 2 s’en passent.
- Dans les ZK rollups, la preuve garantit l’exactitude des transactions, pas leur confidentialité.
- Les preuves ZK ont un coût (calcul, vérification, complexité) et ne protègent pas des fuites de métadonnées.