Guide d'introduction aux preuves à connaissance nulle : Histoire du développement, applications et principes fondamentaux
TechFlow SélectionTechFlow Sélection
Guide d'introduction aux preuves à connaissance nulle : Histoire du développement, applications et principes fondamentaux
Repasser en revue les évolutions théoriques et applicatives des ZKP depuis le début.
Dédié à des analyses Web3 approfondiesRédaction : HashKey Capital
L'industrie blockchain connaît actuellement une croissance fulgurante des projets basés sur les preuves à connaissance nulle (ZKP), en particulier grâce à l'émergence de leurs applications dans la mise à l'échelle et la protection de la vie privée. Cela nous expose à une grande variété de projets ZKP. En raison du caractère profondément mathématique des ZKP, il devient nettement plus difficile pour les passionnés de cryptographie d’en comprendre en profondeur les mécanismes. Nous souhaitons donc retracer ensemble l’évolution théorique et pratique des ZKP, explorer leur impact et leur valeur pour l’industrie crypto — à travers une série de rapports, fruit de la réflexion de l’équipe de recherche de HashKey Capital. Ce texte constitue le premier volet de cette série, consacré à l’histoire, aux applications et aux principes fondamentaux des ZKP.
I. Histoire des preuves à connaissance nulle
Le système moderne de preuve à connaissance nulle trouve son origine dans l'article publié conjointement par Goldwasser, Micali et Rackoff intitulé « The Knowledge Complexity of Interactive Proof Systems » (appelé GMR85), présenté en 1985 et publié en 1989. Cet article étudiait principalement la quantité de connaissances échangées au cours de K tours d’interaction dans un système interactif afin de prouver la validité d’un énoncé (statement). Si cette quantité peut être rendue nulle, on parle alors de preuve à connaissance nulle. Le modèle suppose que le prouveur (prover) dispose de ressources infinies, tandis que le vérificateur (verifier) ne possède que des ressources limitées. Un inconvénient majeur des systèmes interactifs est qu’ils ne sont pas rigoureusement démontrables mathématiquement, mais seulement corrects avec une très faible probabilité d’erreur (1/2^n).
Ainsi, les systèmes interactifs ne sont pas parfaits : ils offrent seulement une quasi-complétude. Les systèmes non interactifs (NP), qui eux garantissent une complétude totale, sont dès lors apparus comme le choix idéal pour les systèmes de preuve à connaissance nulle.
Les premiers systèmes de preuve à connaissance nulle étaient déficients en termes d'efficacité et d'utilisabilité, ce qui les a longtemps cantonnés au domaine théorique. Ce n’est que durant la dernière décennie qu’ils ont connu un essor spectaculaire, notamment grâce au développement de la cryptographie appliquée aux crypto-monnaies, plaçant ainsi les ZKP au cœur des innovations clés. L'un des axes de recherche les plus cruciaux a été le développement d’un protocole de preuve à connaissance nulle, universel, non interactif et à taille de preuve bornée.
En substance, les ZKP impliquent toujours un compromis entre la rapidité de génération de la preuve, la rapidité de vérification et la taille de la preuve. Le protocole idéal serait rapide à prouver, rapide à vérifier et produirait une preuve de petite taille.
La percée la plus importante dans ce domaine a été l'article de Groth en 2010, « Short Pairing-based Non-interactive Zero-Knowledge Arguments », qui a jeté les bases théoriques du zk-SNARK, l'une des familles les plus importantes de ZKP.
Sur le plan applicatif, le tournant décisif date de 2015 avec l’adoption du système ZKP par Zcash, permettant la protection de la confidentialité des transactions et des montants. Cette avancée a ensuite ouvert la voie à l’intégration des zk-SNARK avec les contrats intelligents, élargissant considérablement leur champ d’application.
Parmi les contributions académiques marquantes figurent :
-
Pinocchio (PGHR13) en 2013 : « Pinocchio: Nearly Practical Verifiable Computation », qui a réduit drastiquement les temps de preuve et de vérification, servant de base au protocole utilisé par Zcash.
-
Groth16 en 2016 : « On the Size of Pairing-based Non-interactive Arguments », qui a optimisé la taille des preuves et amélioré l'efficacité de vérification, devenant aujourd’hui l'algorithme ZK le plus largement utilisé.
-
Bulletproofs (BBBPWM17) en 2017 : « Bulletproofs: Short Proofs for Confidential Transactions and More », introduisant un algorithme de preuve non interactive très compact, ne nécessitant aucun paramètre de configuration fiable (trusted setup), intégré six mois plus tard dans Monero — une transition remarquablement rapide de la théorie à la pratique.
-
zk-STARKs (BBHR18) en 2018 : « Scalable, transparent, and post-quantum secure computational integrity », proposant un protocole ZK-STARK ne nécessitant pas de trusted setup. Cette avancée a ouvert une nouvelle voie prometteuse dans l’évolution des ZKP, menant notamment à la création de StarkWare, l’un des projets ZK les plus influents.
D'autres développements importants comme PLONK et Halo2 ont également apporté des améliorations significatives aux zk-SNARK.
II. Aperçu des applications des preuves à connaissance nulle
Les deux applications les plus répandues des preuves à connaissance nulle sont la protection de la vie privée et la mise à l'échelle. Initialement, avec l'apparition de transactions privées et de projets emblématiques comme Zcash et Monero, les transactions confidentielles ont constitué une catégorie majeure. Toutefois, la nécessité perçue de ces fonctionnalités n’a pas atteint les attentes du secteur, faisant progressivement reculer ces projets vers un rang secondaire (sans toutefois disparaître). En revanche, la nécessité de solutions de mise à l’échelle est devenue impérieuse. À partir de 2020, avec le virage d’Ethereum 2.0 (désormais appelé consensus layer) vers une architecture centrée sur les rollups, les technologies ZK ont fait un retour en force, redevenant un sujet central.
Transactions privées : plusieurs projets ont déjà mis en œuvre cette fonctionnalité, notamment Zcash utilisant SNARK, Tornado, Monero utilisant Bulletproof, ainsi que Dash. Techniquement, Dash n’utilise pas de ZKP, mais un système de mixage rudimentaire capable de masquer les adresses sans cacher les montants ; nous ne l’aborderons donc pas ici.
Les étapes d’une transaction zk-SNARK dans Zcash sont les suivantes :
Source : Demystifying the Role of zk-SNARKs in Zcash
-
Phase de configuration (System setup) : génération de la clé de preuve (pour chiffrer le polynôme de preuve) et de la clé de vérification via la fonction KeyGen
-
Phase CPA : utilisation du schéma de chiffrement ECIES (Elliptic Curve Integrated Encryption Scheme) pour générer les clés publique et privée
-
Phase de frappe de pièces (Minting Coins) : définition du nombre de nouvelles pièces, adresse publique et engagement (commitment) de la pièce
-
Phase de versement (Pouring) : génération de la preuve zk-SNARK, ajoutée au registre des transactions de versement
-
Phase de vérification : le vérificateur s'assure que les volumes des transactions Mint et Pour sont corrects
-
Phase de réception : le destinataire reçoit les pièces. Pour les utiliser, il relance le processus de versement, générant une nouvelle preuve zk-SNARK, et répétant les étapes 4 à 6 pour finaliser la transaction.
L'utilisation des ZKP par Zcash présente certaines limitations : son architecture repose sur le modèle UTXO, ce qui signifie que certaines informations transactionnelles sont simplement « blindées » plutôt que véritablement masquées. Conçu comme un réseau indépendant inspiré de Bitcoin, il peine à s'étendre et à s'intégrer à d'autres applications. Moins de 10 % des utilisateurs exploitent effectivement la fonction de protection (shielding), ce qui témoigne d’un faible taux d’adoption des transactions privées (source : 2202).
Tornado utilise un grand pool de mixage unique, plus universel, et s’appuie sur un réseau éprouvé comme Ethereum. Tornado est essentiellement un mixeur utilisant zk-SNARK, avec un trusted setup basé sur l'article de Groth16. Tornado Cash offre notamment les fonctionnalités suivantes :
-
Seules les pièces déposées peuvent être retirées
-
Aucune pièce ne peut être retirée deux fois
-
Le processus de preuve est lié à une notification d’annulation (Nullifier) ; des preuves identiques mais avec des hachages de Nullifier différents ne permettent pas de retirer des pièces
-
Sécurité de 126 bits, préservée même en cas de composition
Vitalik a souligné que, comparée à la mise à l'échelle, la confidentialité est relativement facile à atteindre : si les protocoles de mise à l'échelle fonctionnent, la confidentialité ne devrait plus poser de problème majeur.
Mise à l'échelle : les solutions ZK peuvent être déployées au niveau 1 (ex : Mina) ou au niveau 2, sous forme de zk-rollup. L'idée des zk-rollups remonte probablement à un article de Vitalik en 2018, « On-chain scaling to potentially ~500 tx/sec through mass tx validation ».
Dans un zk-rollup, deux rôles principaux existent : le Séquenceur (Sequencer) et l’Agrégateur (Aggregator). Le Séquenceur regroupe les transactions, tandis que l’Agrégateur fusionne un grand nombre de transactions en un seul rollup, puis génère une preuve SNARK (ou une autre preuve ZK). Cette preuve est comparée à l’état précédent de la couche 1 pour mettre à jour l’arbre de Merkle d’Ethereum et calculer le nouvel état.
Source : Polygon
Avantages et inconvénients des zk-rollups :
-
Avantages : frais réduits, résistance aux attaques économiques (contrairement aux OP), pas de délai de retrait, possibilité de préserver la confidentialité, finalité rapide
-
Inconvénients : coût computationnel élevé pour générer la preuve ZK, problèmes de sécurité (les SNARK nécessitent un trusted setup), vulnérabilité aux ordinateurs quantiques (les SNARK oui, les STARK non), risque de réorganisation des transactions
Source : Recherches Ethereum
Selon la disponibilité des données et la méthode de preuve, Starkware propose une classification classique des solutions L2 (la couche Volition permet de choisir entre données sur chaîne ou hors chaîne) :
Source : Starkware
Les zk-rollups les plus compétitifs actuellement incluent : StarkNet de Starkware, zkSync de Matterlabs, Aztec Connect d’Aztec, Hermez et Miden de Polygon, Loopring et Scroll.
Le choix technologique principal porte sur l’adoption de SNARK (et ses variantes améliorées) ou de STARK, ainsi que sur le niveau de compatibilité avec la machine virtuelle Ethereum (EVM), qu’elle soit partielle ou complète.
-
Aztec a développé un protocole SNARK généraliste, Plonk. Aztec3 pourrait supporter l’EVM, mais privilégie la confidentialité plutôt que la compatibilité EVM
-
StarkNet utilise zk-STARK, une solution ZKP ne nécessitant pas de trusted setup, mais ne supporte pas actuellement l’EVM et dispose de son propre compilateur et langage
-
zkSync utilise également Plonk et supporte l’EVM. zkSync 2.0 est compatible EVM et dispose de son propre zkEVM
-
Scroll est un zk-rollup compatible EVM, dont l’équipe est un contributeur majeur au projet zkEVM de la Fondation Ethereum
Quelques mots sur la compatibilité EVM :
La compatibilité entre les systèmes ZK et l’EVM a longtemps été problématique, obligeant les projets à faire des compromis. Ceux qui privilégient le ZK construisent souvent une machine virtuelle dédiée, accompagnée d’un langage ZK spécifique et d’un compilateur propriétaire, ce qui augmente la courbe d’apprentissage pour les développeurs et crée des boîtes noires peu transparentes. Actuellement, deux approches dominent : soit une compatibilité stricte avec les opcodes de Solidity, soit la conception d’une nouvelle machine virtuelle à la fois ZK-friendly et compatible avec Solidity. Personne n’aurait anticipé une convergence aussi rapide, mais les itérations technologiques récentes ont porté la compatibilité EVM à un nouveau niveau, permettant désormais aux développeurs de migrer presque sans friction (d’Ethereum principal vers zk-rollup). Il s’agit d’une avancée encourageante qui redéfinira l’écosystème de développement et la concurrence autour des ZK. Nous examinerons plus en détail cette question dans nos prochains rapports.
III. Principes fondamentaux de mise en œuvre des zk-SNARK
Goldwasser, Micali et Rackoff ont défini trois propriétés essentielles des preuves à connaissance nulle :
-
Complétude (Completeness) : toute déclaration soutenue par un témoin valide peut être vérifiée avec succès
-
Robustesse (Soundness) : aucune déclaration non valide, même accompagnée d’un faux témoin, ne peut passer la vérification
-
Connaissance nulle (Zero-knowledgeness) : le processus de vérification ne divulgue aucune information supplémentaire
Pour mieux comprendre les ZKP, commençons par les zk-SNARK, car bon nombre d’applications blockchain actuelles en sont issues. Décortiquons d’abord ce qu’est un zk-SNARK.
zk-SNARK signifie : preuve succincte non interactive à connaissance nulle (zero-knowledge Succinct Non-interactive ARguments of Knowledge).
-
Connaissance nulle (Zero Knowledge) : le processus de preuve ne révèle aucune information superflue
-
Succinct : la taille de la preuve est très réduite
-
Non interactif (Non-interactive) : pas d’échange interactif requis entre prouveur et vérificateur
-
Arguments : la fiabilité est garantie contre les prouveurs à puissance de calcul limitée ; seuls des prouveurs disposant d’une puissance infinie pourraient truquer la preuve
-
of Knowledge : le prouveur ne peut pas construire une preuve valide sans connaître l’information requise
-
Pour le prouveur, il est impossible de construire des paramètres et une preuve valides sans connaître le témoin (Witness), par exemple l’entrée d’une fonction de hachage ou le chemin vers un nœud donné dans un arbre de Merkle.
Le principe de preuve zk-SNARK selon Groth16 est illustré ci-dessous :
Source : https://learnblockchain.cn/article/3220
Les étapes sont les suivantes :
-
Transformer le problème en circuit logique
-
Platiner le circuit sous forme R1CS (Rank-1 Constraint System)
-
Convertir le R1CS en QAP (Quadratic Arithmetic Programs)
-
Établir un trusted setup et générer des paramètres aléatoires, incluant la clé de preuve (PK) et la clé de vérification (VK)
-
Génération et vérification de la preuve zk-SNARK
Dans le prochain article, nous approfondirons les principes et applications des zk-SNARK, analyserons plusieurs cas concrets pour mieux comprendre leur évolution, et explorerons leur relation avec les zk-STARK.
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
