Aller au contenu
Financial Context Wiki

Preuve à divulgation nulle de connaissance

Guide précis des preuves à divulgation nulle de connaissance : complétude, solidité, simulation, témoins, hypothèses de paramétrage, usages blockchain et risques de vérification.

Mis à jour

À titre éducatif uniquement ; ceci ne constitue pas un conseil en investissement ou en sécurité. Une preuve valide ne garantit que l’énoncé encodé, selon les hypothèses du système de preuve.

Réponse directe

Une preuve à divulgation nulle de connaissance (ZKP) permet à un prouveur de convaincre un vérificateur qu’un énoncé est vrai sans révéler le témoin secret qui l’établit. La garantie formelle ne dit pas que la transcription ne contient littéralement aucune information. Elle dit que tout ce qu’apprend un vérificateur admis peut être simulé sans le témoin, hormis ce qui découle de l’énoncé public.

Trois propriétés distinctes évaluent un système : la complétude, qui fait accepter un prouveur honnête muni d’un témoin valide ; la solidité, qui rend négligeable la probabilité d’accepter un énoncé faux ; et la divulgation nulle, qui garde le témoin secret dans le modèle de menace défini. Beaucoup de systèmes pratiques sont des arguments calculatoires : leur solidité vaut face à des adversaires aux ressources bornées et dépend d’hypothèses cryptographiques explicites.

La divulgation nulle diffère aussi de la concision et de la validité. Une preuve peut être ZK mais coûteuse à vérifier, concise tout en exposant des données publiques, ou prouver correctement une relation encodée qui ne correspond pas à la règle voulue par l’application.

1
Exécuter

Le prouveur exécute un lot ou un calcul et enregistre la transition d'état résultante.

Fonctionnement

On part d’un énoncé public x, d’un témoin privé w et d’une relation précise R. Le prouveur produit une preuve, évaluée par le vérificateur avec des paramètres publics ou une clé de vérification. La solidité visée se résume ainsi :

Verify(vk, x, proof) = 1 => exists w: R(x, w) = 1

Cette formule affirme seulement qu’un témoin adapté existe pour la relation encodée. Elle ne le révèle pas, n’authentifie aucune entrée hors chaîne et ne montre pas que R couvre toutes les règles métier prévues.

  • Interactif ou non interactif. Les premiers protocoles ZK échangent défis et réponses. Les systèmes non interactifs regroupent les éléments dans une preuve et reposent généralement sur un paramétrage, un modèle d’oracle aléatoire, ou les deux.
  • Modèle de paramétrage. Groth16 fournit de très petites preuves mais exige un paramétrage structuré propre au circuit. Les systèmes de type PLONK peuvent employer une chaîne de référence structurée universelle et actualisable. STARK évite le paramétrage structuré de confiance, mais produit généralement des preuves plus grandes et dépend des hachages et tests de bas degré.
  • Arithmétisation et engagements. L’implémentation traduit le programme en contraintes algébriques, engage des valeurs issues du témoin et utilise des contrôles aléatoires pour vérifier le calcul sans le refaire ni voir le témoin.
  • Preuve de connaissance. Certains systèmes affirment aussi qu’un prouveur accepté connaît un témoin, ce qu’un extracteur formalise. C’est une propriété distincte, non impliquée par l’étiquette « divulgation nulle ».

Exemple

Supposons que x contienne un engagement et un seuil de 100 units, et que w contienne le solde engagé et le facteur d’aveuglement. La relation vérifie l’ouverture correcte de l’engagement et un solde d’au moins 100 units. Une ZKP valide établit cette relation sans révéler le solde exact.

Elle ne prouve pas à elle seule que le prouveur possède le compte, que les fonds sont libres ou que l’engagement n’a pas été réutilisé. Ces affirmations exigent d’autres contraintes et entrées publiques.

Dans une cryptomonnaie protégée, un circuit peut imposer autorisation, conservation de la valeur et non-duplication tout en cachant certains détails. Dans un validity rollup, une preuve peut certifier une transition d’état par lot ; les données peuvent néanmoins être publiées, donc « ZK Rollup » ne signifie pas automatiquement transactions privées.

Risques

  • Un circuit incomplet ou erroné peut parfaitement prouver la mauvaise règle.
  • L’absence de séparation de domaines, d’identifiant de chaîne, de racine ou d’engagement peut lier la preuve au mauvais contexte.
  • Un paramétrage compromis ou des déchets toxiques conservés peuvent rompre la solidité des systèmes qui exigent une configuration de confiance.
  • Des bogues du prouveur, vérificateur, transcript, de la courbe, du hachage, compilateur ou contrat peuvent annuler la garantie théorique.
  • Entrées publiques, chronologie, graphes de transactions, frais et métadonnées réseau peuvent divulguer des informations hors de l’énoncé ZK.
  • Des canaux auxiliaires dans la génération du témoin, le navigateur, le matériel ou un service distant peuvent exposer les secrets avant la preuve.
  • La vérification n’assure ni disponibilité des données, ni activité du séquenceur, finalité, résistance à la censure ou mises à niveau sûres.
  • Hypothèses et marges concrètes diffèrent entre systèmes ; taille ou vitesse de vérification ne suffisent pas à classer leur sécurité.

Idées reçues

  • « Zéro connaissance signifie qu’aucune donnée n’est révélée. » L’énoncé public et les sorties volontairement exposées restent visibles, et les métadonnées peuvent fuir hors du modèle.
  • « Une preuve valide signifie que l’application est correcte. » Seule la relation encodée a été acceptée ; des erreurs de circuit, d’intégration ou de politique restent possibles.
  • « Tous les systèmes ZK ont les mêmes hypothèses de confiance. » Cérémonies, courbes, hachages, modèles de transcript et contrôles de mise à niveau diffèrent sensiblement.
  • « ZK est du chiffrement. » Le chiffrement masque les données pour qu’une partie autorisée les déchiffre ; une ZKP établit une affirmation sans envoyer le témoin à déchiffrer.

Sujets connexes

Sources

Navigation

Rechercher dans le wiki...