Comment fonctionnent les preuves à divulgation nulle de connaissance et pourquoi elles sont essentielles pour la confidentialité

Vous pouvez prouver que vous avez plus de 18 ans sans révéler votre date de naissance. Vous pouvez prouver que vous avez assez d'argent pour une transaction sans révéler votre solde. Vous pouvez prouver qu'un calcul a été effectué correctement sans révéler les entrées. Les preuves à connaissance nulle rendent tout cela possible, et elles deviennent silencieusement la primitive cryptographique la plus importante dans la blockchain depuis la fonction de hachage.

La plupart des introductions aux preuves à connaissance nulle commencent par l'analogie de la grotte d'Ali Baba, où quelqu'un prouve qu'il connaît le mot secret pour ouvrir une porte en sortant systématiquement du côté demandé par un vérificateur, sans jamais révéler le mot. L'analogie est charmante et complètement inutile pour comprendre pourquoi les preuves ZK comptent en pratique. Elle vous dit qu'une telle preuve est possible. Elle ne vous dit pas pourquoi quelqu'un en aurait besoin sur une blockchain.

Le point de départ pratique est plus simple. Chaque blockchain fait face à la même tension : la transparence permet la confiance, mais la transparence détruit aussi la vie privée. Le registre de Bitcoin est public. Chaque transaction, chaque solde, chaque adresse est visible par n'importe qui. Ethereum est pareil. Cette transparence est ce qui rend le système auditable et digne de confiance, mais cela signifie aussi que quiconque apprend quelle adresse vous appartient peut voir chaque transaction que vous avez jamais faite, chaque jeton que vous détenez, et chaque protocole avec lequel vous avez interagi.

Les preuves à connaissance nulle résolvent cette tension. Elles vous permettent de prouver des faits sur vos données sans révéler les données elles-mêmes. Vous pouvez prouver que votre solde dépasse un seuil sans révéler le solde exact. Vous pouvez prouver qu'une transaction est valide sans révéler l'expéditeur, le destinataire ou le montant. Vous pouvez prouver que vous n'êtes pas sur une liste de sanctions sans révéler votre identité.

Les mathématiques derrière cela sont profondes. Les applications sont immédiates.

Les trois propriétés que toute preuve ZK doit avoir

Chaque système de preuve à connaissance nulle doit satisfaire trois propriétés, et les comprendre est essentiel pour évaluer tout protocole basé sur ZK.

Complétude. Si l'énoncé est vrai et que le prouveur et le vérificateur suivent tous deux le protocole, le vérificateur sera toujours convaincu. Une preuve valide ne manque jamais de vérifier. Si vous connaissez vraiment le secret, la preuve fonctionnera toujours.

Solidité. Si l'énoncé est faux, aucun prouveur malhonnête ne peut convaincre le vérificateur qu'il est vrai, sauf avec une probabilité négligeable. Un prouveur malhonnête ne peut pas fabriquer une preuve valide. La probabilité qu'une fausse preuve passe la vérification est si petite (typiquement moins d'une sur 2^128) qu'elle est effectivement impossible.

Connaissance nulle. Le vérificateur n'apprend rien au-delà du fait que l'énoncé est vrai. La preuve ne fuit aucune information sur le secret lui-même, aucun calcul intermédiaire, ni aucune donnée utilisée pour générer la preuve. La connaissance du vérificateur après avoir vu la preuve est identique à ce qu'elle serait si quelqu'un lui avait simplement dit que l'énoncé était vrai.

La troisième propriété est ce qui rend les preuves ZK utiles plutôt que simplement correctes. Les signatures numériques standard prouvent qu'un message a été signé par une clé spécifique, mais elles révèlent le contenu du message. Les engagements de hachage standard prouvent qu'une valeur a été engagée, mais ils révèlent la valeur lorsqu'elle est ouverte. Les preuves ZK prouvent qu'une relation existe entre des valeurs secrètes sans révéler ces valeurs à aucun moment.

Comment zk-SNARKs et zk-STARKs diffèrent

Les deux systèmes de preuve ZK dominants dans la blockchain sont les zk-SNARKs et les zk-STARKs. Ils résolvent le même problème avec des compromis différents.

zk-SNARKs (Arguments de connaissance succincts non interactifs à connaissance nulle) produisent de petites preuves qui sont rapides à vérifier. Une preuve zk-SNARK typique fait environ 200 à 300 octets et peut être vérifiée sur la chaîne pour environ 200 000 à 300 000 gas sur Ethereum. Le temps de vérification est constant quelle que soit la complexité du calcul prouvé. Une preuve qui vérifie une seule transaction prend le même temps à vérifier qu'une preuve qui vérifie dix mille transactions.

Le coût de cette concision est une configuration de confiance. La plupart des systèmes zk-SNARK nécessitent une cérémonie unique où des paramètres aléatoires sont générés et le caractère aléatoire est détruit par la suite. Si le caractère aléatoire de cette cérémonie n'est pas correctement détruit, un attaquant pourrait forger des preuves. Zcash a mené l'une des cérémonies de configuration de confiance les plus élaborées de l'histoire cryptographique (la cérémonie "Powers of Tau") impliquant des centaines de participants dans le monde entier, où l'hypothèse de sécurité est qu'au moins un participant a honnêtement détruit son caractère aléatoire.

Les systèmes SNARK plus récents comme PLONK et Halo 2 ont réduit ou éliminé l'exigence de configuration de confiance, mais la perception persiste. Certains projets évitent les SNARK précisément à cause de la préoccupation de configuration de confiance, même lorsque les implémentations qu'ils utiliseraient n'en nécessitent pas.

zk-STARKs (Arguments de connaissance transparents et évolutifs à divulgation nulle) éliminent entièrement la configuration de confiance. Ils tirent leur sécurité de fonctions de hachage plutôt que d'hypothèses sur les courbes elliptiques, ce qui les rend transparents (aucun paramètre secret) et théoriquement résistants aux ordinateurs quantiques (la cryptographie basée sur les fonctions de hachage est considérée comme sûre contre les ordinateurs quantiques, contrairement à la cryptographie sur courbes elliptiques).

Le compromis est la taille. Les preuves STARK sont nettement plus grandes que les preuves SNARK, généralement de quelques dizaines à quelques centaines de kilo-octets contre quelques centaines d'octets. Sur une blockchain où le stockage de données coûte du gaz, des preuves plus grandes signifient des coûts de vérification plus élevés. StarkWare, le principal développeur de la technologie STARK, résout ce problème en utilisant la composition récursive de preuves : prouver qu'une preuve est valide, puis prouver que la preuve de la preuve est valide, compressant ainsi l'empreinte finale sur la chaîne.

En pratique, la distinction importe moins qu'il y a cinq ans. Les systèmes de preuve modernes combinent de plus en plus des techniques des deux familles, et l'accent de l'ingénierie est passé de quel système de preuve utiliser à la rapidité avec laquelle le prouveur peut générer des preuves et au coût de vérification pour le vérificateur.

Preuves ZK pour le passage à l'échelle de la blockchain

L'application de passage à l'échelle des preuves ZK est conceptuellement simple. Un rollup exécute un lot de transactions hors chaîne, génère une preuve que le lot a été exécuté correctement, et publie la preuve sur Ethereum. Le contrat de vérification Ethereum vérifie la preuve en une seule opération et accepte le nouvel état.

Ce qui rend cela puissant, c'est l'asymétrie entre la preuve et la vérification. Générer la preuve pour un lot de 10 000 transactions peut prendre plusieurs minutes à une machine puissante. Vérifier la preuve prend une fraction de seconde et coûte un montant fixe de gaz, quel que soit le nombre de transactions dans le lot. Cette asymétrie est ce qui permet aux ZK rollups de compresser des milliers de transactions en une seule vérification Ethereum.

Les principaux ZK rollups adoptent chacun une approche différente de cette architecture.

zkSync Era utilise une machine virtuelle personnalisée (zkEVM) compatible avec Solidity au niveau du langage mais compile vers un jeu d'instructions différent optimisé pour la génération de preuves ZK. Les contrats Ethereum existants peuvent être recompilés pour zkSync avec des modifications minimes.

StarkNet utilise le langage de programmation Cairo et les preuves STARK. Cairo est un langage spécialement conçu pour le calcul prouvable, ce qui lui donne des avantages en termes de performances mais oblige les développeurs à apprendre un nouveau langage et un nouveau paradigme.

Polygon zkEVM vise l'équivalence EVM, ce qui signifie qu'il peut exécuter le même bytecode qu'Ethereum sans recompilation. Cela maximise la compatibilité mais introduit une complexité d'ingénierie pour rendre chaque opcode EVM prouvable.

Scroll vise également une équivalence EVM complète et utilise une approche communautaire pour son implémentation zkEVM, avec pour objectif d'être le ZK rollup le plus compatible avec Ethereum.

La concurrence entre ces approches est finalement une concurrence entre compatibilité et performance. Plus un ZK rollup est compatible avec les outils Ethereum existants, plus il est facile pour les développeurs de migrer. Plus le rollup optimise son jeu d'instructions pour la prouvabilité, plus ses preuves deviennent rapides et moins chères.

Preuves ZK pour la confidentialité

L'application de confidentialité est là où les preuves ZK deviennent les plus conséquentes et les plus controversées.

Une transaction Ethereum standard révèle l'adresse de l'expéditeur, l'adresse du destinataire, le montant transféré et le contrat intelligent appelé. Cette information est définitivement publique. Les entreprises d'analyse de chaîne comme Chainalysis et Elliptic ont bâti des entreprises entières sur le traçage des flux de transactions à travers le registre transparent, reliant les adresses à des identités du monde réel via les données KYC des échanges, les étiquettes d'entités connues et les modèles comportementaux.

Les protocoles de confidentialité ZK brisent cette chaîne de visibilité. Dans une transaction privée basée sur ZK, l'utilisateur génère une preuve que sa transaction est valide (l'expéditeur a des fonds suffisants, pas de double dépense, les montants s'équilibrent) sans révéler qui l'a envoyée, qui l'a reçue, ni combien a été transféré. La preuve est publiée sur la chaîne et vérifiée par le réseau, mais les détails sous-jacents de la transaction restent chiffrés.

Zcash a été la première implémentation majeure de ce concept, lancée en 2016 avec des transactions protégées utilisant des zk-SNARKs. Un utilisateur de Zcash peut choisir entre des transactions transparentes (identiques au registre public de Bitcoin) et des transactions protégées (où l'expéditeur, le destinataire et le montant sont cachés derrière une preuve ZK). En pratique, l'adoption des transactions protégées sur Zcash a été plus faible que ce que les partisans espéraient, la majorité des transactions Zcash utilisant encore le pool transparent.

Les protocoles plus récents construisent une confidentialité programmable, où non seulement les transferts de jetons mais aussi la logique de contrats intelligents arbitraires peuvent s'exécuter de manière privée. Aztec Network construit une couche 2 axée sur la confidentialité sur Ethereum où toutes les transactions sont privées par défaut. Aleo construit une blockchain de couche 1 avec un support ZK natif pour les contrats intelligents privés. Les deux utilisent des preuves ZK pour vérifier les transitions d'état sans révéler le calcul ou les données impliqués.

Le potentiel de la confidentialité s'étend au-delà des transactions individuelles. Les preuves ZK peuvent permettre un vote privé (prouver que vous avez voté sans révéler votre choix), une vérification d'identité privée (prouver que vous êtes citoyen d'un pays spécifique sans révéler votre numéro de passeport), et une DeFi privée (fournir des liquidités à un pool sans révéler votre adresse ou la taille de votre position).

La collision réglementaire

La confidentialité dans la crypto occupe un espace juridique contesté qui est encore en cours de définition.

En août 2022, le Bureau de contrôle des avoirs étrangers (OFAC) du Trésor américain a sanctionné Tornado Cash, un mélangeur basé sur Ethereum qui utilisait des preuves ZK pour rompre le lien entre les adresses de dépôt et de retrait. La sanction du code de contrat intelligent open source, plutôt que d'une personne ou d'une entreprise, était sans précédent et a envoyé des ondes de choc dans la communauté de la confidentialité crypto.

En mai 2024, Alexey Pertsev, l'un des développeurs de Tornado Cash, a été reconnu coupable par un tribunal néerlandais de facilitation de blanchiment d'argent. La condamnation a établi un précédent juridique selon lequel écrire du code préservant la confidentialité peut entraîner une responsabilité pénale si l'outil est utilisé à des fins illicites, que le développeur ait personnellement facilité l'activité illégale ou non.

Ces actions ont façonné la direction du développement de la confidentialité ZK. La génération actuelle de protocoles de confidentialité se construit autour des contraintes réglementaires plutôt que de les ignorer.

Divulgation sélective permet à un utilisateur de prouver des faits spécifiques sur son identité ou son historique de transactions sans tout révéler. Un utilisateur pourrait prouver qu'il a réussi le KYC avec un échange agréé, prouver qu'il n'est pas sur la liste des sanctions de l'OFAC, ou prouver que ses fonds ne proviennent pas d'une adresse sanctionnée, le tout en utilisant des preuves ZK qui ne révèlent rien au-delà de la revendication spécifique vérifiée.

Pools de confidentialité, un concept formalisé par Vitalik Buterin et d'autres, permettent aux utilisateurs de prouver que leur retrait d'un ensemble de confidentialité appartient à un sous-ensemble propre de dépôts. Au lieu de mélanger tous les dépôts sans distinction, le protocole maintient des ensembles d'association qui excluent les adresses illicites connues. Les utilisateurs prouvent leur appartenance à l'ensemble propre sans révéler quel dépôt spécifique ils retirent.

Il reste à voir si ces compromis satisfont les régulateurs. La tension fondamentale, selon laquelle la confidentialité et la surveillance sont architecturalement incompatibles, ne sera pas résolue par la technologie seule. Les preuves ZK donnent aux décideurs politiques un outil qu'ils n'ont jamais eu auparavant : la capacité de vérifier la conformité sans exiger de divulgation. Qu'ils choisissent de l'utiliser est une question politique, pas cryptographique.

Le coût de la preuve a des implications concrètes pour savoir quelles applications adoptent la technologie ZK en premier. Les transactions financières de grande valeur, où le coût de génération d'une preuve est négligeable par rapport à la taille de la transaction, ont été les premiers adoptants. Les transferts inter-chaînes institutionnels, les grandes positions DeFi et les systèmes de règlement d'entreprise peuvent absorber un coût de preuve de plusieurs dollars par transaction sans affecter leur économie. Les applications grand public, où les transactions individuelles peuvent ne valoir que quelques dollars, ont besoin que les coûts de preuve diminuent d'un ordre de grandeur supplémentaire avant que la confidentialité ZK ne devienne pratique pour un usage quotidien. Les efforts d'accélération matérielle des entreprises construisant des ASIC spécifiques à ZK ciblent directement cette barrière de coût.

La convergence des applications de mise à l'échelle et de confidentialité est peut-être l'aspect le plus sous-estimé de la technologie ZK. Un rollup ZK qui traite les transactions de manière privée combinerait les avantages de débit de l'exécution hors chaîne avec les avantages de confidentialité des transitions d'état chiffrées. Les utilisateurs obtiendraient des transactions rapides et peu coûteuses qui sont également invisibles pour l'analyse de chaîne. Plusieurs projets, dont Aztec et Polygon Miden, construisent exactement cette combinaison, bien que la complexité technique de fusionner les deux capacités dans un système de production reste substantielle.

Ce que cela ne couvre pas

Cet article ne couvre pas les mathématiques des engagements polynomiaux, les appariements de courbes elliptiques ou les transformations de Fiat-Shamir qui sous-tendent les systèmes de preuve ZK. Comprendre ces concepts nécessite une algèbre abstraite de niveau supérieur et n'est pas nécessaire pour évaluer les protocoles basés sur ZK en tant qu'utilisateur ou investisseur.

Cet article ne couvre pas l'apprentissage automatique ZK (zkML), un domaine émergent qui utilise des preuves ZK pour vérifier qu'un modèle d'apprentissage automatique a produit une sortie spécifique sans révéler les poids du modèle ou les données d'entraînement. Cette application est expérimentale et ses implications pratiques sont encore à l'étude.

Cet article ne traite pas de la course à l'accélération matérielle pour la génération de preuves ZK. Des entreprises comme Cysic, Ingonyama et Fabric Cryptography construisent des ASIC et des FPGA personnalisés spécifiquement pour la preuve ZK, ce qui pourrait réduire les coûts de preuve de plusieurs ordres de grandeur. Le paysage matériel évolue trop rapidement pour une analyse statique.

Vérifications pratiques avant d'utiliser un protocole basé sur ZK

Vérifiez le statut d'audit du système de preuve. Les systèmes de preuve ZK sont mathématiquement complexes et les erreurs d'implémentation peuvent être catastrophiques. Un bug dans le circuit (la représentation mathématique du calcul prouvé) pourrait permettre à un attaquant de forger des preuves et de frapper des jetons ou de voler des fonds. Vérifiez si le système de preuve et ses circuits ont été audités par des entreprises spécialisées en cryptographie ZK, et non seulement par des auditeurs de contrats intelligents généraux.

Comprenez ce qui est réellement privé. Tous les protocoles basés sur ZK n'offrent pas le même niveau de confidentialité. Certains masquent les montants des transactions mais révèlent les adresses. D'autres masquent les adresses mais révèlent les montants. Certains masquent tout. Lisez la documentation du protocole pour comprendre exactement quelles informations sont dissimulées et ce qui reste visible. Les métadonnées telles que le moment des transactions, les schémas de gaz et la fréquence des interactions peuvent souvent désanonymiser les utilisateurs même lorsque les données de transaction de base sont cachées.

Vérifiez le statut de la configuration de confiance. Si le protocole utilise des zk-SNARKs, déterminez s'il a nécessité une configuration de confiance et comment cette configuration a été réalisée. Les cérémonies de calcul multipartite avec des centaines de participants sont plus dignes de confiance que les petites cérémonies avec une poignée d'entités connues. Les protocoles utilisant STARKs, PLONK avec configuration universelle, ou Halo 2 ne nécessitent pas de configuration de confiance du tout.

Évaluez le risque réglementaire. Les protocoles de confidentialité opèrent dans un environnement juridiquement incertain. Considérez si le protocole dispose d'un mécanisme de conformité (divulgation sélective, pools de confidentialité, preuves de conformité opt-in) et si ce mécanisme a été testé face à un examen réglementaire réel. Utiliser un protocole de confidentialité qui est ensuite sanctionné pourrait compliquer votre capacité à déplacer ou vendre des actifs.

Testez le temps de preuve. Générer une preuve ZK est intensif en calcul. Sur un appareil mobile, prouver une transaction simple peut prendre de 30 secondes à deux minutes. Sur un ordinateur de bureau, cela peut prendre quelques secondes. Si le temps de preuve est trop long pour votre cas d'utilisation, le protocole peut ne pas être pratique pour des transactions fréquentes. Certains protocoles déchargent la preuve sur des serveurs dédiés, ce qui est plus rapide mais introduit une hypothèse de confiance selon laquelle le serveur n'apprend pas vos données privées.