Preuves à divulgation nulle de connaissance : SNARK, STARK et ce qu'elles prouvent réellement

2026-08-24

Une preuve à divulgation nulle de connaissance est une méthode cryptographique qui permet d'établir la validité d'un énoncé soigneusement défini sans révéler l'information privée qui rend cet énoncé valide. Son nom peut inviter à une interprétation trop large. Il ne signifie pas qu'un système ne révèle absolument rien. Une preuve montre normalement qu'un énoncé défini satisfait à des règles de vérification définies ; une application peut encore exposer des entrées publiques, des horaires, des journaux, des identifiants ou d'autres métadonnées situées hors de la preuve.

La question utile est donc précise : quel énoncé est prouvé, qu'est-ce qui reste privé, qu'est-ce qui est public, et qu'établit une vérification réussie ? Cet article introduit ces termes avant de présenter SNARK et STARK comme de grandes familles de systèmes de preuves à divulgation nulle de connaissance. Il s'agit d'une explication pédagogique, non d'une recommandation d'utiliser, de sélectionner ou de considérer comme fiable un système de preuve particulier.

Schéma conceptuel d'un prouveur qui produit une preuve contrôlée par un vérificateur

Énoncés, témoins et relations définies

Tout système de preuve commence par une relation qu'il peut évaluer. La partie publique est souvent appelée un énoncé. Cet énoncé peut dire qu'une valeur satisfait à des conditions publiées, ou qu'un calcul a produit une sortie conformément à un ensemble de règles déclaré. L'information qui démontre pourquoi l'énoncé est vrai est couramment appelée un témoin. Un témoin peut être une valeur secrète, un ensemble d'entrées ou d'autres informations privées définies par le système de preuve.

La frontière entre l'énoncé et le témoin est essentielle. Un vérificateur ne peut contrôler que la relation qui a été encodée. Si un énoncé affirme qu'une entrée satisfait à une condition précise, l'acceptation établit cette condition selon les règles du système. Elle n'établit pas automatiquement l'origine de l'entrée, l'inclusion de tous les faits réels pertinents, ni l'intention d'une personne après la vérification. Ces questions exigent leurs propres éléments, définitions et règles de gouvernance.

De nombreux systèmes décrivent la relation au moyen d'un circuit semblable à un programme. Un circuit est ici une abstraction d'opérations contraintes que le système de preuve peut contrôler ; ce n'est pas simplement un programme d'application ordinaire. La façon d'écrire la relation, les champs utilisés et les contraintes appliquées varient selon les constructions. Une preuve porte par conséquent sur une relation précise, non sur une affirmation vague à propos de la réalité.

Ce vocabulaire explique aussi pourquoi un énoncé bien formé est indispensable. Si une relation omet une condition importante, une preuve peut rester valide pour cette relation incomplète. La cryptographie protège l'intégrité de la relation définie ; elle ne décide pas quels impératifs du monde réel auraient dû y être inclus.

Ce que la divulgation nulle de connaissance cache et ne cache pas

La propriété de divulgation nulle de connaissance concerne ce qu'un vérificateur apprend en recevant ou en utilisant une preuve. De façon informelle, le vérificateur doit être convaincu qu'un énoncé est valide sans apprendre le témoin au-delà de ce que l'énoncé révèle déjà. Les travaux classiques sur les systèmes de preuve interactifs ont formalisé cette intuition en comparant la vue réelle du vérificateur à une vue simulée qui n'utilise pas le témoin.

Cette propriété appartient à un protocole ; elle ne s'applique pas automatiquement à toutes les couches de l'application environnante. Un système peut publier volontairement un énoncé ou une entrée publique. Il peut conserver des journaux, exposer un identifiant ou communiquer au travers d'un réseau qui transporte des métadonnées. Une preuve peut limiter la divulgation relative à un témoin alors que d'autres parties du système créent des risques de confidentialité différents. Une analyse de la vie privée doit donc examiner l'ensemble des flux d'information, et pas seulement la présence d'une preuve à divulgation nulle de connaissance.

Cette propriété ne rend pas non plus le vérificateur passif. Il reçoit assez de matériel de preuve pour effectuer les contrôles prescrits. Le protocole est conçu pour que ce matériel permette d'accepter l'énoncé sans fournir le témoin secret sous une forme exploitable, sous réserve des hypothèses de la construction et de son champ annoncé. Toute information révélée intentionnellement doit rester claire pour ceux qui interprètent le résultat.

Le prouveur et le vérificateur

Le prouveur est la partie ou le composant qui possède le témoin et génère une preuve. Le vérificateur reçoit l'énoncé public, les paramètres publics applicables et les données de preuve, puis exécute la procédure de vérification du système. Il s'agit de rôles, et non de catégories fixes de personnes. Une application peut les organiser comme services indépendants, composants locaux ou participants d'un environnement distribué.

La génération d'une preuve et sa vérification servent des buts différents. Le prouveur démontre qu'il peut satisfaire la relation à l'aide du témoin. Le vérificateur contrôle que la preuve respecte la relation et ses règles de vérification. Il n'a pas à reproduire le calcul privé parce qu'il a reçu une preuve. La quantité exacte de travail, de matériel de preuve, d'interaction et de préparation publique varie selon la construction.

Le contexte compte également. Une preuve valable pour un énoncé n'est pas automatiquement pertinente pour un autre. Les versions, entrées publiques, définitions de relation et matériels de vérification peuvent modifier son interprétation. Un système de preuve ne peut pas décider si un résultat technique convient à une décision juridique, scientifique, organisationnelle ou sociale. Définir la relation et décider comment lire son résultat restent des responsabilités de l'application.

Exhaustivité, solidité et acceptation

Deux propriétés fondamentales expliquent l'utilité de la vérification. L'exhaustivité signifie, en substance, qu'un prouveur honnête possédant un témoin valide pour un énoncé vrai devrait pouvoir produire une preuve qu'un vérificateur honnête accepte. Sans cette propriété, un participant correct pourrait être rejeté alors même que la relation est satisfaite.

La solidité traite de la direction opposée. En substance, elle indique qu'un prouveur ne devrait pas pouvoir amener un vérificateur à accepter un énoncé faux, sauf avec la probabilité limitée ou selon les hypothèses précisées par le système. La solidité n'est pas une capacité universelle de vérification des faits. Elle s'applique à une relation formelle, à un modèle d'adversaire et à une définition de sécurité. Elle ne prouve pas à elle seule que des entrées ont été collectées correctement ni qu'une affirmation réelle non encodée est vraie.

Certaines constructions évoquent aussi la solidité de connaissance. Au niveau général, ce terme relie une preuve réussie à l'idée que le prouveur possède, ou peut produire, un témoin du type requis. Sa définition exacte est technique et propre à la construction. Il ne faut pas en déduire que le prouveur connaît tous les faits contextuels qu'un lecteur pourrait associer à l'énoncé public.

Ensemble, l'exhaustivité et la solidité donnent un sens limité à l'acceptation : une preuve bien formée d'une relation vraie doit être acceptée, tandis qu'une relation fausse ne doit pas l'être parce qu'elle est simplement affirmée. Elles ne dispensent ni de formuler la bonne relation, ni de l'implémenter correctement, ni d'évaluer le résultat dans son contexte.

Génération et vérification de preuve dans leur contexte

Sur le plan conceptuel, la génération commence avec un énoncé public, un témoin privé et une relation qui les relie. Le prouveur exécute les opérations prescrites par son système et produit des données de preuve. La vérification commence avec l'énoncé public, le matériel de vérification requis et ces données. Le vérificateur renvoie alors une acceptation ou un rejet selon le protocole.

Les systèmes font des choix différents concernant l'interaction, l'aléa, les paramètres publics, les hypothèses cryptographiques et la représentation des calculs. Certains comportent une phase de préparation qui crée des paramètres ; d'autres sont qualifiés de transparents parce qu'ils évitent un participant de préparation secret. Ces choix comptent, mais leurs étiquettes ne démontrent pas à elles seules qu'une implémentation complète possède les propriétés de sécurité attendues.

Quatre questions restent utiles pour le lecteur, quel que soit le système : quel énoncé est exactement public ? Quel est le témoin ? Quel matériel de vérification est supposé ou digne de confiance ? Qu'établit l'acceptation, et que laisse-t-elle sans réponse ? Elles s'appliquent qu'une preuve soit reliée à un registre, une attestation, une base de données ou tout autre logiciel.

SNARK et STARK comme familles de systèmes de preuve

SNARK est couramment développé en Succinct Non-interactive Argument of Knowledge, soit argument succinct et non interactif de connaissance. Dans les grandes lignes, les constructions SNARK cherchent à permettre au prouveur de produire une preuve compacte qu'un vérificateur contrôle sans échange interactif. Le mot argument a un sens technique : la sécurité repose sur des hypothèses computationnelles plutôt que sur une garantie mathématique inconditionnelle. Les constructions individuelles peuvent différer par leur modèle de préparation, leurs hypothèses, la représentation de la preuve et les relations prises en charge.

Les recherches telles que l'article Pinocchio illustrent une structure familière du calcul vérifiable : un matériel public décrit un calcul, un exécutant produit une preuve pour une entrée donnée, et un vérificateur la contrôle. Cet exemple historique ne doit pas être traité comme une définition de chaque système ultérieur qualifié de SNARK. Le terme générique couvre des idées apparentées, et non une implémentation uniforme.

STARK est couramment développé en Scalable Transparent Argument of Knowledge, soit argument de connaissance évolutif et transparent. Le terme est associé à des constructions qui mettent l'accent sur la transparence du modèle de préparation et utilisent des techniques de preuve différentes des approches SNARK courantes fondées sur les appariements. La recherche STARK d'origine traite de l'intégrité transparente des calculs et d'un contexte de sécurité post-quantique. Ces descriptions concernent une construction et ses hypothèses ; elles ne rendent pas toutes les implémentations interchangeables et n'établissent pas un résultat universel.

La comparaison utile est donc précise. Elle considère les hypothèses formelles d'une construction, ses exigences de préparation, sa représentation de relation, son environnement de vérification, la qualité de son implémentation et les données publiques. SNARK et STARK sont des cartes conceptuelles, non des conclusions automatiques sur la sécurité, la confidentialité ou l'adéquation d'un système.

Portée, limites et confiance environnante

Une preuve valide n'établit que l'énoncé représenté par sa relation. Elle ne démontre pas indépendamment que les données de départ ont été recueillies équitablement, qu'une source était autorisée, qu'un événement extérieur s'est produit ou que l'énoncé est toujours actuel. Si une relation reçoit des entrées incomplètes ou trompeuses, la vérification peut rester correcte pour ces entrées. La preuve protège un calcul défini, pas toutes les interprétations possibles de son résultat.

La divulgation nulle de connaissance ne supprime pas non plus toute question de vie privée. Les entrées publiques peuvent être révélatrices. Des présentations répétées peuvent créer des associations. Des métadonnées de réseau, d'appareil, de compte, d'interface ou d'application peuvent exister hors de la preuve. Une conception doit examiner directement ces canaux au lieu de traiter la preuve comme une frontière complète de confidentialité.

La sécurité pratique dépend en outre d'hypothèses mathématiques, de la gestion des paramètres lorsque c'est pertinent, de logiciels corrects et d'un vérificateur qui évalue l'énoncé voulu. Une défaillance à l'un de ces niveaux peut modifier le résultat. C'est pourquoi les étiquettes courtes telles que SNARK ou STARK doivent être un point de départ pour une lecture attentive, et non un jugement final.

Pour interpréter une affirmation de preuve, identifiez l'énoncé, le témoin, les entrées publiques, le prouveur, le vérificateur et le matériel de vérification. Séparez ensuite l'acceptation technique de la confiance plus large : un vérificateur peut établir qu'un résultat respecte des règles de protocole tout en devant encore évaluer les sources, définitions, le contexte et ses propres politiques. Cette distinction méthodique décrit ce que les preuves à divulgation nulle de connaissance prouvent réellement et les limites qui subsistent.

Articles associés

Autres articles Bitbase sur ce sujet :

- Preuve de personnalité et résistance aux attaques Sybil

- Transactions privées, shielded addresses et view keys

- Comment l’éligibilité à un airdrop est décidée : instantanés, points et filtres Sybil

Avertissement : Cet article est un contenu pédagogique de Bitbase Academy, fourni à titre d'information uniquement. Il ne constitue pas un conseil en investissement, en trading, en fiscalité ou en finance. Les cryptoactifs sont volatils ; évaluez votre propre risque. Rédigé en août 2026 ; référez-vous aux informations officielles les plus récentes.