ZK Proof : fonctionnement, usages et limites

Une preuve à divulgation nulle de connaissance, souvent appelée ZK Proof ou ZKP, permet de démontrer qu’une affirmation est vraie sans révéler l’information secrète utilisée pour la prouver. Cette famille de protocoles cryptographiques sert à vérifier un calcul, une identité ou une transaction tout en limitant les données exposées. Elle joue aussi un rôle important dans certaines solutions de mise à l’échelle des blockchains.

Qu’est-ce qu’une ZK Proof ?

Dans une blockchain, tous les participants ne doivent pas nécessairement refaire un calcul complexe pour être convaincus de son résultat. Une ZK Proof permet à un prouveur de produire une preuve, puis à un vérificateur de contrôler cette preuve à partir d’éléments publics. Le secret utilisé par le prouveur, parfois nommé « témoin », n’est pas transmis au vérificateur.

Un exemple simplifié consiste à prouver que l’on connaît le mot de passe d’un compte sans envoyer le mot de passe lui-même. Dans un système réel, la preuve repose sur des opérations mathématiques et non sur une simple déclaration de confiance.

Selon la présentation d’Ethereum.org sur les preuves zero-knowledge, le concept moderne remonte à un article de recherche de 1985. Depuis, plusieurs familles de protocoles ont été développées pour rendre les preuves plus compactes, plus rapides à vérifier ou mieux adaptées aux blockchains.

Les trois propriétés fondamentales

Une preuve à divulgation nulle de connaissance est généralement décrite à partir de trois propriétés :

Complétude : si l’affirmation est vraie et que les participants suivent le protocole, le vérificateur doit accepter la preuve.
Solidité : un prouveur malveillant ne doit pas pouvoir convaincre le vérificateur d’une affirmation fausse, sauf avec une probabilité négligeable.
Divulgation nulle : la preuve ne doit révéler aucune information supplémentaire sur le secret, au-delà du fait que l’affirmation est vraie.

Ces propriétés ne signifient pas qu’un système entier est automatiquement privé ou invulnérable. Le protocole peut être correct tandis que l’application révèle encore des métadonnées, utilise un circuit mal conçu ou contient une faille dans son contrat intelligent.

Comment fonctionne une preuve de connaissance zéro ?

Le développeur commence par traduire la règle à vérifier sous la forme d’un circuit ou d’un ensemble de contraintes. Le prouveur fournit des entrées publiques et privées. Il exécute ensuite le calcul pour générer une preuve cryptographique. Le vérificateur contrôle cette preuve avec les entrées publiques, sans recevoir les données privées.

Dans une preuve interactive, le prouveur et le vérificateur échangent plusieurs messages. Les systèmes utilisés sur les blockchains sont souvent non interactifs : une preuve peut être générée, publiée puis vérifiée plus tard par un contrat intelligent.

Le coût n’est pas réparti de manière égale. La génération peut demander beaucoup de calcul et de mémoire, tandis que la vérification est conçue pour rester rapide. Cette asymétrie est précisément ce qui rend les ZKP intéressantes pour vérifier sur une blockchain un calcul effectué ailleurs.

ZK-SNARK et ZK-STARK : quelles différences ?

Les ZK-SNARK produisent généralement des preuves compactes et rapides à vérifier. Certaines constructions exigent toutefois une cérémonie d’initialisation de confiance. Si les paramètres secrets de cette cérémonie n’ont pas été détruits correctement, la sécurité du système peut être compromise. D’autres SNARK utilisent une configuration universelle ou évitent certains de ces compromis.

Les ZK-STARK sont dites « transparentes » car elles n’exigent pas le même type de configuration de confiance. Elles s’appuient sur des hypothèses cryptographiques différentes, mais leurs preuves peuvent être plus volumineuses. Le choix ne se résume donc pas à désigner une famille comme meilleure : il dépend du coût de génération, de la taille de la preuve, du temps de vérification et du modèle de confiance accepté.

Quel rapport avec les ZK-rollups ?

Un ZK-rollup regroupe des transactions exécutées hors de la couche principale, puis publie une preuve de validité permettant de vérifier que la transition d’état respecte les règles. Le contrat de la couche 1 contrôle la preuve avant d’accepter le nouvel état.

La documentation officielle sur les ZK-rollups Ethereum explique que le calcul et le stockage de l’état sont déplacés hors chaîne, tandis qu’un résumé et une preuve cryptographique sont soumis au réseau principal. Cette méthode peut augmenter le débit sans demander à Ethereum de réexécuter chaque transaction du lot.

Attention à une confusion fréquente : le terme « ZK » ne garantit pas que toutes les transactions d’un rollup sont confidentielles. Une preuve de validité peut démontrer la correction d’un lot alors que des données de transaction restent publiques. La confidentialité dépend de ce que le circuit masque et des données publiées.

Applications au-delà de la mise à l’échelle

Les preuves ZK peuvent servir à prouver qu’une personne remplit une condition d’âge sans révéler sa date de naissance, qu’un utilisateur appartient à un groupe autorisé sans dévoiler son identité, ou qu’une institution respecte une contrainte de réserve sans publier toutes ses positions. Elles peuvent aussi intervenir dans l’authentification, le vote électronique, la conformité et le partage sélectif d’informations.

Dans le Web3, ces usages nécessitent néanmoins une conception prudente. Une preuve mathématique confirme seulement la proposition encodée dans le circuit. Elle ne garantit pas que la donnée de départ est vraie, que l’interface ne trompe pas l’utilisateur ou que la clé privée est bien protégée.

Risques et limites à connaître

Erreurs de circuit : une contrainte oubliée peut permettre de générer des preuves valides pour un comportement indésirable.
Coût du prouveur : la génération de preuves peut nécessiter du matériel puissant ou une infrastructure spécialisée.
Configuration de confiance : certaines constructions dépendent d’une cérémonie correctement exécutée.
Centralisation opérationnelle : un séquenceur ou un service de preuve unique peut créer une dépendance, même si la preuve reste vérifiable.
Complexité d’audit : les circuits, bibliothèques et contrats doivent tous être examinés. Les piratages récents de protocoles crypto rappellent qu’une technologie avancée n’élimine pas les erreurs d’implémentation.

Comment évaluer un projet qui utilise des ZK Proofs ?

Il faut d’abord identifier ce que la preuve garantit réellement : confidentialité, validité d’un calcul, solvabilité ou simple appartenance à un ensemble. Vérifiez ensuite quelles données restent publiques, qui génère les preuves, si l’utilisateur peut sortir du système en cas de panne et si le code critique a été audité.

Le whitepaper du projet doit préciser la famille de preuves employée, ses hypothèses de sécurité et le rôle des opérateurs. Des expressions comme « confidentialité totale » ou « sécurité absolue » sans documentation technique constituent un signal d’alerte.

À retenir

Une ZK Proof permet de vérifier une affirmation tout en limitant la divulgation du secret utilisé pour la démontrer. Cette technologie peut renforcer la confidentialité et rendre certains calculs plus faciles à vérifier sur une blockchain. Elle ne remplace toutefois ni les audits, ni la sécurité des clés, ni l’analyse du modèle de confiance. Pour juger un protocole, il faut regarder la garantie exacte du circuit, les données publiques et les dépendances opérationnelles.