Prouver une affirmation sans livrer le secret
Ce concept devient plus accessible lorsqu’on sait déjà lire un smart contract sans être développeur. Le prouveur possède une information, appelée témoin, et produit un objet cryptographique. À partir des données publiques, le vérificateur contrôle cet objet sans apprendre le témoin.
La présentation des zero-knowledge proofs par Ethereum.org rappelle trois propriétés. D’abord, la complétude signifie qu’une affirmation valide peut convaincre un vérificateur honnête. Ensuite, la solidité empêche, sauf probabilité négligeable, une fausse affirmation de passer. Le zero-knowledge limite ce que le vérificateur apprend au-delà de la validité.
Un exemple pédagogique consiste à prouver la connaissance d’un mot de passe sans transmettre celui-ci. Dans une application réelle, le circuit encode une relation mathématique : le hash de l’entrée secrète doit correspondre à une valeur publique.
La preuve ne garantit pas que le programme répond à la bonne question. Si le circuit contient une erreur, il peut prouver fidèlement un calcul incorrect. L’audit de la logique reste donc essentiel.
Preuve interactive et preuve non interactive
Les premières constructions demandaient plusieurs échanges entre prouveur et vérificateur. Chaque défi réduisait la probabilité qu’un tricheur réussisse. Cette interaction convient mal à une blockchain où de nombreux acteurs doivent vérifier le même résultat.
Une preuve non interactive se crée en une fois, puis plusieurs participants peuvent la vérifier. Les systèmes modernes utilisent des paramètres publics, des fonctions de hachage ou d’autres hypothèses afin de remplacer les échanges.
Le mot « argument » indique généralement une sécurité calculatoire : un adversaire disposant de ressources réalistes ne peut pas forger la preuve. Une preuve au sens mathématique peut viser une sécurité plus forte, mais le vocabulaire varie selon les protocoles.
L’utilisateur n’a pas besoin de maîtriser toutes les équations. Il doit toutefois connaître les hypothèses, la taille de la preuve, le temps de génération, le coût de vérification et l’existence éventuelle d’un trusted setup.
ZK-SNARKs : preuves compactes et vérification rapide
SNARK signifie succinct non-interactive argument of knowledge. La preuve reste généralement petite et sa vérification rapide. Ces caractéristiques conviennent aux blockchains, où chaque octet et chaque opération ont un coût.
Certaines familles de SNARK demandent un trusted setup. Une cérémonie produit des paramètres publics à partir d’un secret qui doit ensuite être détruit. Si au moins un participant agit honnêtement dans une cérémonie multipartite bien conçue, le secret complet ne devrait pas être reconstitué.
D’autres SNARK utilisent un setup universel ou transparent selon leur construction. Il faut donc éviter l’affirmation « tous les SNARK ont un trusted setup ». Lisez la documentation du système précis.
La petite taille ne signifie pas une génération gratuite. Créer une preuve pour un gros calcul exige du temps, de la mémoire et parfois du matériel spécialisé. Le coût se déplace du vérificateur vers le prouveur.
ZK-STARKs : transparence et preuves plus grandes
STARK signifie scalable transparent argument of knowledge. Le terme transparent indique l’absence de trusted setup secret dans les constructions habituelles. La sécurité repose notamment sur des fonctions de hachage et des paramètres publics vérifiables.
Les STARK peuvent mieux évoluer sur de grands calculs, mais leurs preuves occupent souvent plus de données. Ethereum.org souligne que cette taille augmente la charge de vérification on-chain par rapport à certains SNARK.
Le choix dépend donc du contexte. Une application peut privilégier une preuve compacte, une cérémonie maîtrisée ou une transparence maximale. Aucune famille ne domine tous les critères.
Les développeurs évaluent également la maturité des bibliothèques, les langages de circuits, les audits et la disponibilité des prouveurs. Une bonne primitive mal intégrée peut créer une faille pratique.
Les ZK-rollups et la mise à l’échelle
Un ZK-rollup regroupe des transactions hors de la couche principale et publie les données ou engagements nécessaires avec une preuve de validité. Le contrat sur Ethereum vérifie la preuve au lieu de réexécuter chaque opération.
Cette architecture réduit le coût par transaction et augmente le débit. La couche principale fournit le règlement et la vérification. Le guide Ethereum consacré aux ZK-rollups explique que le vérificateur confirme le calcul hors chaîne grâce à une preuve.
Le préfixe ZK ne signifie pas toujours que les transactions du rollup sont privées. Beaucoup de rollups utilisent une preuve de validité tout en publiant des données accessibles. La confidentialité exige des circuits et une gestion des données conçus dans ce but.
Les retraits dépendent du mécanisme de preuve, du contrat et de la disponibilité des données. Un bridge vers le rollup ajoute encore des risques. Consultez le guide sur les bridges crypto entre blockchains avant de transférer des fonds.
Confidentialité, validité et disponibilité des données
La validité prouve qu’un changement d’état suit les règles. Une propriété de confidentialité cache certaines entrées. Enfin, la disponibilité garantit que les données nécessaires pour reconstruire ou contester l’état restent accessibles. Ces propriétés ne viennent pas automatiquement ensemble.
Un système peut prouver un calcul valide tout en dépendant d’un opérateur pour publier les données. Si cet opérateur disparaît, les utilisateurs peuvent rencontrer des difficultés pour reconstituer leur solde ou produire une sortie.
Des solutions publient les données sur Ethereum ; d’autres utilisent un comité ou une couche dédiée. Le coût diminue parfois au prix d’une hypothèse de confiance supplémentaire.
Avant d’utiliser un réseau, demandez où les données vivent, qui peut les retenir et quelle procédure permet une sortie forcée. Le mot « proof » ne répond pas à ces questions opérationnelles.
Les usages hors des rollups
Une preuve peut confirmer qu’une personne dépasse un âge minimal sans publier sa date de naissance. Elle peut démontrer l’appartenance à une liste sans révéler quelle entrée correspond à l’utilisateur.
Dans la finance, un acteur peut prouver qu’un calcul respecte une règle ou qu’un ensemble d’actifs dépasse un seuil. La preuve ne garantit toutefois pas que les actifs hors chaîne existent réellement ; un oracle ou un auditeur doit relier la donnée au monde extérieur.
Des systèmes de vote cherchent à vérifier l’éligibilité et l’unicité sans exposer le bulletin. La conception doit empêcher les doubles votes, protéger la confidentialité et permettre un audit.
Les jeux, identités et programmes de conformité explorent aussi ces outils. Chaque usage demande un circuit, une source de données et une politique de révocation adaptés.
Les limites que le marketing oublie
Une zero-knowledge proof ne corrige pas une donnée d’entrée fausse. Si une autorité attribue une mauvaise identité, le système peut prouver correctement la possession de ce mauvais attribut.
Le code du circuit peut contenir un bug. Les contraintes omises représentent une catégorie classique : le prouveur trouve une entrée qui satisfait le circuit sans respecter l’intention du développeur.
Les performances posent une autre limite. Générer une preuve sur un téléphone peut demander trop de ressources. Une application externalise alors la génération, ce qui peut exposer des données si elles ne sont pas protégées.
Les paramètres, bibliothèques et cérémonies exigent une gouvernance. Une vulnérabilité cryptographique ou une mise à jour peut imposer une migration. La longévité du système compte pour des fonds conservés plusieurs années.
Vérifier les promesses d’un projet ZK
Demandez d’abord quelle propriété fait l’objet de la preuve. Une phrase comme « sécurisé par ZK » ne précise ni le circuit ni les données publiques. Cherchez le contrat de vérification, les documents techniques et les audits.
Identifiez la famille de preuve et le setup. Si une cérémonie existe, qui a participé et comment les contributions se vérifient-elles ? Consultez les versions exactes des bibliothèques.
Examinez la disponibilité des données, les séquenceurs et la sortie d’urgence. Un rollup peut avoir une preuve robuste tout en dépendant d’un opérateur central pour l’ordre des transactions.
Vérifiez aussi les permissions et rappelez-vous que les audits ne suffisent pas face aux nouvelles attaques. La cryptographie du rollup ne protège pas contre une autorisation illimitée donnée à une application malveillante.
SNARK ou STARK : comment comparer
Comparez la taille de preuve, le temps de génération, le coût de vérification, le setup et les hypothèses. Ajoutez la maturité des outils et la capacité de l’équipe à auditer le circuit.
Pour une blockchain, le coût de publication peut favoriser une preuve courte. Un calcul massif hors chaîne peut donner la priorité à la scalabilité du prouveur. Dans un système d’identité, la protection des données pendant la génération devient centrale.
La résistance à de futurs ordinateurs quantiques apparaît parfois dans la comparaison. Les STARK reposent généralement sur des hashes considérés plus favorables à ce scénario, mais aucune migration cryptographique ne se réduit à un slogan.
Un projet peut aussi combiner plusieurs preuves, agréger des SNARK ou utiliser une preuve récursive. Le nom commercial ne suffit pas pour déduire l’architecture.
Checklist avant d’utiliser une application ZK
Confirmez le réseau, le contrat et le bridge officiel. Testez un petit dépôt puis un retrait. Relevez les délais, les frais et la procédure de sortie en cas de panne.
Lisez ce que l’application cache réellement. Une transaction peut masquer le montant tout en révélant les participants, ou l’inverse. Les métadonnées de réseau et l’adresse de financement peuvent aussi réduire la confidentialité.
Consultez les audits du circuit, du vérificateur et des contrats périphériques. Vérifiez les clés d’administration et les possibilités de mise à niveau. Un timelock donne du temps, mais seulement si l’utilisateur surveille les annonces.
Les zero-knowledge proofs offrent une avancée majeure : vérifier davantage en révélant moins ou en réexécutant moins. Elles ne suppriment ni les bugs, ni la gouvernance, ni la disponibilité des données. Une évaluation professionnelle distingue toujours la propriété cryptographique de l’ensemble opérationnel qui l’entoure.
Mosengo Léon
Mosengo Léon est un analyste crypto et rédacteur pour BrefCrypto.com, reconnu pour ses analyses approfondies des marchés Bitcoin et cryptomonnaies, l’impact des événements structurants comme les crises et levées de fonds, et sa capacité à rendre accessibles les enjeux techniques et économiques de la blockchain pour investisseurs et passionnés
