Que sont les ZK-SNARK ? Preuves de confidentialité et exploitation minière expliquées

1Qu'est-ce qu'un ZK-SNARK ?

Un ZK-SNARK est une preuve cryptographique qui permet à un prouveur de convaincre un vérificateur qu'une déclaration est vraie et que le prouveur connaît les informations secrètes requises, sans révéler ce secret. Le nom complet est Argument de connaissance succinct et non interactif sans connaissance. Il s’agit d’une famille de constructions de preuves, et non d’un algorithme universel.

Dans une transaction blockchain, la déclaration publique pourrait être : « Ce transfert suit les règles du protocole. » Le témoin privé peut inclure des clés secrètes, des notes, des soldes ou une trace d'exécution. Une preuve valide peut montrer que les données cachées satisfont aux règles sans placer les données elles-mêmes dans un grand livre public. C'est pourquoi les ZK-SNARK sont utiles pour les paiements privés, les calculs vérifiables, les revendications d'identité et les systèmes de mise à l'échelle.

2Ce que signifie chaque partie de ZK-SNARK

« Succinct » ne garantit pas la même taille d'épreuve ou le même temps de vérification dans chaque système. Groth16, les systèmes de la famille PLONK, les systèmes de la famille Marlin et Halo 2 font des choix différents. Les coûts exacts dépendent du circuit, des courbes, du schéma d'engagement, de la mise en œuvre, du matériel et de l'objectif de sécurité.

3Comment fonctionne un ZK-SNARK ?

Les mathématiques sont avancées, mais le flux de travail peut être compris en cinq étapes.

1. Définissez l'énoncé. Les développeurs expriment les règles sous forme de circuit arithmétique ou de système de contraintes. Pour un paiement, les règles peuvent vérifier la propriété, la conservation de la valeur et qu'un intrant n'a pas déjà été dépensé.
2. Séparer les apports publics et privés. Les entrées publiques sont visibles pour le vérificateur. Le témoin privé contient les valeurs secrètes nécessaires pour satisfaire le circuit.
3. Préparez les paramètres de preuve. Selon le système de preuve, cela peut impliquer des paramètres spécifiques au circuit, une chaîne de référence structurée universelle ou une configuration qui ne repose pas sur un caractère aléatoire secret.
4. Générez la preuve. Le prouveur calcule un objet cryptographique compact montrant qu'un témoin valide satisfait à toutes les contraintes.
5. Vérifiez la preuve. Un nœud ou un contrat intelligent vérifie la preuve à l'aide d'entrées publiques et d'une clé de vérification. Il accepte ou rejette sans connaître le témoin.

Cela ne signifie pas que le vérificateur fait confiance au prouveur. La preuve est utile car un prouveur malhonnête ne devrait pas être en mesure de faire passer une fausse déclaration, en supposant que la cryptographie et l'implémentation sont correctes.

4Complétude, solidité et zéro connaissance

Ces garanties s'appliquent à l'instruction codée par le circuit. Si le circuit omet une règle métier, utilise une plage incorrecte ou accepte une condition dangereuse, la preuve peut être cryptographiquement valide alors que l'application reste erronée. La conception des circuits, l'examen de la mise en œuvre, la génération de paramètres, le comportement du portefeuille et la sécurité opérationnelle font donc partie des limites de sécurité.

5Qu'est-ce qu'une configuration approuvée ?

Certains ZK-SNARK nécessitent une chaîne de référence structurée générée avant le début de la preuve. Les anciens systèmes spécifiques aux circuits utilisaient des cérémonies qui produisaient des paramètres publics tandis que les participants tentaient de détruire le hasard secret, parfois appelé « déchet toxique ». Si tous les contributeurs étaient de connivence ou si le processus était compromis, certains systèmes pourraient perdre leur solidité.

Le calcul multipartite réduit ce risque : une cérémonie peut rester sécurisée si au moins un participant se comporte honnêtement et détruit sa contribution secrète. Les conceptions plus récentes proposent différents modèles de configuration. Une configuration universelle peut prendre en charge de nombreux circuits, tandis que les conceptions transparentes ou sans confiance évitent le caractère aléatoire caché de la configuration. Ces choix affectent la taille de la preuve, la vitesse du prouveur, le coût de la vérification, la récursivité et la complexité de la mise en œuvre.

6Comment Zcash utilise les ZK-SNARK et le minage

Zcash est l'exemple de production le plus connu de ZK-SNARK pour la confidentialité des paiements. Dans une transaction protégée, les engagements représentent des notes privées, les annuleurs empêchent que la même note soit dépensée deux fois et une preuve montre que la transaction obéit aux règles du protocole. En fonction du type de transaction et des informations de visualisation divulguées, les adresses, les valeurs et les données mémo peuvent rester protégées pendant que les nœuds vérifient toujours la validité.

Les ZK-SNARK ne sont pas l'algorithme de minage de Zcash. Le minage de Zcash utilise la preuve de travail Equihash. Les mineurs se font concurrence pour produire des blocs, commander des transactions valides et sécuriser l’historique de la chaîne. Les nœuds vérifient les preuves de connaissance nulle dans les transactions protégées avant de les accepter. La couche de preuve établit l'exactitude de la transaction ; la couche de consensus et d'exploration de données décide quelles transactions valides font partie de la chaîne canonique.

Cette distinction est importante pour le matériel. Un ASIC Equihash accélère le hachage de preuve de travail ; il ne sert pas de générateur général de preuves Halo 2. De même, un appareil qui génère une preuve de portefeuille n’exploite pas automatiquement ZEC. Notre Guide de sécurité minière Zcash explique comment Orchard, le logiciel de portefeuille, les nœuds et l'exploitation minière Equihash s'articulent.

Pour connaître la raison pour l'utilisateur derrière les transactions protégées et la divulgation sélective, voir Valeur de confidentialité de Zcash en 2026.

7Aleo, Rollups, identité et calcul vérifiable

Aleo utilise des preuves sans connaissance pour l'exécution de programmes privés. Un utilisateur peut créer une preuve qu'une transition d'état a suivi un programme publié tout en gardant privées les données d'enregistrement éligibles. Le réseau vérifie la preuve et traite la logique publique finalisée grâce à son système de consensus. La preuve ZK démontre une exécution correcte ; AleoBFT fournit un accord de réseau. Les traiter comme la même opération répéterait la confusion entre extraction et preuve observée dans les anciennes explications de Zcash.

Le plus large Perspectives du réseau Aleo couvre son modèle de confidentialité, sa décentralisation et sa participation au réseau sans réduire le projet à un seul acronyme.

Les ZK-SNARK prennent également en charge d'autres conceptions :

• Cumuls de validité : prouver qu'un lot de transitions d'état hors chaîne a été exécuté correctement avant qu'un contrat de couche de base n'accepte la nouvelle racine d'état.
• Identité privée : prouver l’âge, l’appartenance, la juridiction ou la possession d’un titre sans révéler le titre complet.
• Preuve de réserves ou de passif : démontrer que les données engagées satisfont à une relation tout en limitant la divulgation, à condition que l’engagement et le périmètre comptable soient complets.
• Calcul vérifiable : prouver que le logiciel a produit un résultat à partir d’entrées validées sans obliger chaque vérificateur à répéter le travail coûteux.

Un « rollup ZK » n’est pas automatiquement privé. De nombreux cumuls de validité publient suffisamment de données de transaction pour la reconstruction et utilisent des preuves principalement pour l'exactitude et la mise à l'échelle. La confidentialité dépend de ce qui est public, de ce qui est caché et de ce que prouve le circuit.

8Limites, coûts et risques de sécurité

Les ZK-SNARK compressent la vérification, mais la génération de preuves peut être gourmande en calcul et en mémoire. Les développeurs doivent traduire les programmes en contraintes, gérer les clés de démonstration et de vérification, sélectionner les courbes et les schémas d'engagement et optimiser les circuits. Les applications complexes peuvent nécessiter du matériel spécialisé ou une infrastructure de preuve distribuée.

• Bogues de circuits : une contrainte manquante peut permettre à un témoin invalide de satisfaire la déclaration implémentée.
• Bogues d'implémentation : Les erreurs de sérialisation, de caractère aléatoire, de portefeuille, de vérificateur ou de bibliothèque peuvent nuire aux bonnes mathématiques.
• Hypothèses de configuration : les systèmes utilisant un SRS dépendent du modèle de sécurité et de l’exécution de la génération de paramètres.
• Fuite de métadonnées : la synchronisation du réseau, les données IP, le comportement du portefeuille, les entrées publiques et les enregistrements d'échange peuvent révéler des informations hors de la preuve.
• Risque de mise à niveau : le changement de circuits ou de systèmes de preuve nécessite une compatibilité, un audit et une planification de migration minutieux.

9ZK-SNARK, STARK et preuves ZK générales

Le bon système de preuve dépend de l’application. Un protocole de paiement peut donner la priorité à la confidentialité et à la preuve mobile. Un rollup peut donner la priorité au débit et au coût de vérification en chaîne. Un protocole de longue durée peut valoriser une configuration transparente ou une récursivité. « Utilise ZK » est un point de départ pour l'analyse, pas une description technique complète.