Preuves Zéro-Connaissance : Comment Zcash & Altcoins Assurent Confidentialité Totale

Les preuves à divulgation nulle de connaissance (ZKP) sont devenues l'une des primitives cryptographiques les plus transformatrices dans les systèmes blockchain modernes. Contrairement aux articles de haut niveau qui diluent l'essence technique, ce texte décompose les véritables mécanismes, mathématiques et contraintes derrière les systèmes de confidentialité basés sur ZK utilisés dans des altcoins tels que Zcash, Aleo et Firo—sans abstractions ni contenu marketing.

1. Qu’est-ce qu’une preuve à divulgation nulle de connaissance (mathématiquement)

Une ZKP est un protocole interactif ou non-interactif permettant à un prouveur P de convaincre un vérificateur V qu’une affirmation est vraie sans révéler d’informations autres que la véracité de l’affirmation.

Formellement, une ZKP doit satisfaire :

1. Complétude : si l’affirmation est vraie, un vérificateur honnête accepte.
2. Fiabilité (Soundness) : un prouveur malveillant ne peut pas convaincre le vérificateur d’une affirmation fausse.
3. Zero-knowledge : le vérificateur n’apprend rien sauf la validité.
   Le zéro-connaissance est défini en utilisant un simulateur S :
   si S peut générer une transcription indiscernable sans connaître le témoin, le protocole est zero-knowledge.

Pour l’usage blockchain, l’affirmation ressemble généralement à :

« Je connais un secret (témoin) qui hache cette valeur publique. »
ou
« Je possède des pièces correspondant à des engagements sans révéler lesquelles. »

2. Schémas d'engagement — La base des coins de confidentialité ZK

La plupart des coins de confidentialité utilisent des engagements pour cacher les valeurs de transaction et la propriété.

Un engagement est défini comme :
C = Commit(valeur, aléatoire)

Propriétés :

• Caché : la valeur ne peut pas être extraite de C.
• Liant : le prouveur ne peut pas changer la valeur ultérieurement.

Schémas courants :

• Engagements Pedersen :
  C = v·G + r·H dans les groupes de courbes elliptiques (utilisés dans Firo Lelantus / MimbleWimble).
• Engagements basés sur SHA-256 : utilisés dans certains circuits zk-SNARK pour l'efficacité.

Les engagements Pedersen permettent :

• Homomorphisme additif : C1 + C2 = Commit(v1 + v2, r1 + r2).
  → C’est ainsi que les transactions confidentielles préservent la quantité totale.

3. zk-SNARK et zk-STARK — Pourquoi les coins de confidentialité utilisent l’un ou l’autre

3.1 zk-SNARK (Succinct Non-Interactive Argument of Knowledge)

Utilisé dans :

• Zcash (Sapling)
• Horizen
• Firo Lelantus Spark

Propriétés :

• Preuves très petites (~192 octets dans Sapling).
• Vérification très rapide (~10 ms).
• Nécessitent une configuration de confiance (problème de déchets toxiques).
• Utilisent des appariements de courbes elliptiques (principalement BLS12-381).

Détail technique souvent omis :
Zcash utilisait initialement BN254 (Jubjub), mais est passé à BLS12-381 en raison de faiblesses de sécurité dans les sous-groupes et des préoccupations sur la marge de sécurité 128 bits.

3.2 zk-STARK (Scalable Transparent ARguments of Knowledge)

Utilisé dans :

• Aleo
• StarkNet (pas un coin mais pertinent)

Propriétés :

• Pas de configuration de confiance.
• Sécurisé post-quantique (basé sur des fonctions de hachage, pas d'appariements).
• Preuves volumineuses (~100–500 Ko).
• Vérification rapide et scalable.

Fait peu connu :
Les premières preuves sur le testnet Aleo étaient si volumineuses que la bande passante réseau est devenue un goulot d’étranglement ; les optimisations ont réduit la taille de la preuve d’environ 80 % avant le mainnet.

4. Où le zéro-connaissance apparaît dans une transaction de confidentialité

Un altcoin axé sur la confidentialité utilise généralement les ZKP pour un ou plusieurs des éléments suivants :

4.1 Masquer l’expéditeur

Mécanismes :

• Signatures en anneau (Monero — pas ZK, mais lié).
• Preuves de participation à divulgation nulle de connaissance (Zcash, Lelantus).

Exemple (simplifié) :
Le prouveur montre qu’il connaît une clé secrète pour un élément d’un ensemble d’engagements sans révéler lequel.

4.2 Masquer le destinataire

Utilisation d’adresses furtives ou d’adresses diversifiées.
Zcash utilise des adresses de paiement et des clés de visualisation entrantes pour permettre une transparence sélective.

4.3 Masquer le montant

Engagements Pedersen + une ZKP qui :

• somme correctement les engagements,
• les montants sont non-négatifs (preuves de plage),
• aucune inflation n’est introduite.

Anciennes preuves de plage (Confidential Transactions, propositions Bitcoin) :
~2–3 Ko par sortie.

Bulletproofs :
~700 octets par sortie (Monero les utilise).

zk-SNARKs :
Zcash cache les montants avec des preuves aussi petites que 192 octets au total.

5. Exemple concret de transaction : Zcash Sapling

Une transaction protégée Zcash Sapling prouve :

1. Le dépensier possède un note (pièce cachée).
2. La note n’a pas été dépensée auparavant (ZKP de nullifier).
3. La valeur totale de sortie égale la valeur totale d’entrée (ZKP de balance).
4. Les notes de sortie sont des engagements correctement formés.

Que prouve-t-on réellement ?

Le prouveur construit un circuit couvrant :

• Hachages (BLAKE2s) des engagements de notes
• Hachages Pedersen
• Authentification du chemin de l’arbre de Merkle
• Calcul du nullifier
• Équations de conservation de valeur

La complexité totale du circuit est d’environ 2 millions de contraintes.
La génération de preuve utilise Groth16, nécessitant :

• Calculs FFT
• Multiplications multi-scalaires
• Appariements EC

Sur un ordinateur portable, générer une preuve prend ~1–2 secondes (optimisé avec les courbes Pallas/Vesta dans Orchard).

Fait rarement mentionné :
Le circuit Sapling utilise des décompositions binaires pour les contraintes de plage, augmentant considérablement le nombre de contraintes ; Orchard a remplacé cela par l’arithmétisation PLONKish de Halo 2, réduisant dramatiquement la complexité.

6. Lelantus Spark (Firo) — Un système ZK sous-estimé

Le système “Spark” de Firo est l’un des plus avancés techniquement mais moins connu du public.

Innovations clés :

• Purement ZK (aucune signature en anneau).
• Utilise les One-of-Many Proofs :
  le prouveur démontre qu’il possède une note parmi N, avec une taille de preuve logarithmique en N.
• Pas de configuration de confiance.
• Les montants sont cachés via des engagements Pedersen.
• Les adresses Spark sont non-liables même pour les nœuds effectuant une analyse de la chaîne.

Spark inclut également :

• Réémission d’adresses :
  les propriétaires peuvent actualiser leurs adresses tout en conservant le contrôle, réduisant les fuites de métadonnées.
• Binding universel :
  Empêche l’inflation malveillante en utilisant plusieurs liaisons cryptographiques pour le même engagement.

Fait peu connu :
La conception de Spark réduit la surface d’attaque causée par les “preuves de dépense partielle”, qui rendaient certains protocoles de confidentialité traçables sous certaines heuristiques.

7. Aleo — Exécution ZK, pas seulement transactions ZK

Aleo n’est pas seulement une coin privée — c’est une blockchain L1 avec des smart contracts entièrement privés.

Comment cela fonctionne :

• Les programmes sont écrits en Leo, un DSL semblable à Rust compilant en R1CS.
• L’exécution se fait hors chaîne.
• Une preuve zk-STARK est générée représentant l’intégralité de la trace d’exécution.
• Les mineurs/validateurs vérifient la preuve et mettent à jour l’état.

C’est en pratique :

Une machine virtuelle globale, vérifiable et chiffrée.

Fait peu connu :
Aleo utilise un système hybride de preuves :

• STARKs pour la transparence
• Récursion SNARK (style Kimchi/Halo) pour réduire la taille des preuves

Cette approche hybride est rare et techniquement complexe.

8. Pourquoi les ZKP sont difficiles à implémenter à l’échelle des altcoins

8.1 Coût de preuve

Générer une preuve zk-SNARK nécessite :

• Des millions de contraintes arithmétiques
• FFT sur de grands champs finis
• Multiplications EC multi-scalaires

Même avec des optimisations :

• La génération de preuve peut être limitée par le CPU.
• La consommation mémoire est élevée (plusieurs centaines de Mo sur des systèmes anciens).

8.2 Problèmes de configuration de confiance

Les coins utilisant Groth16 nécessitent une configuration de confiance.
Si les déchets toxiques ne sont pas détruits, un attaquant peut :
→ créer un nombre illimité de coins falsifiés
sans détection.

Zcash a en réalité utilisé une cérémonie multipartite ; les déchets toxiques finaux ont été (selon les rapports) détruits via extraction d’entropie physique et OPSEC rigoureux…
Mais un seul participant malhonnête aurait suffi à compromettre le système.

8.3 Les bugs de circuit peuvent ruiner un coin

Si le circuit d’un système de confidentialité contient un bug non détecté permettant l’inflation, les nœuds ne peuvent pas détecter les coins contrefaits.
Cela s’est produit dans les premières versions de Zcash (corrigé avant exploitation).

Une erreur subtile de contrainte arithmétique peut mettre en faillite tout un écosystème.

9. L’avenir des coins ZK

Tendances techniquement probables :

• Preuves récursives permettant la vérification groupée de transactions.
• Systèmes hybrides STARK–SNARK, comme dans Aleo, pour réduire la taille des preuves.
• Accélération matérielle via GPU et ASIC pour la génération de preuves.
• Confidentialité programmable, permettant la divulgation sélective.
• Circuits ZK adaptés au mobile (les circuits actuels sont beaucoup trop lourds).

Quelques expériences de recherche :

• Mempools chiffrés ZK
• Moteurs de correspondance P2P basés sur ZK
• DEXs basés sur ZK sans révéler les carnets d’ordres

Ceux-ci sont déjà en cours de prototypage dans des projets comme Penumbra et Mina.

10. Attaques réelles et faiblesses dans les coins de confidentialité basés sur ZK

Même si les systèmes ZK visent à garantir la confidentialité et la validité, l’histoire montre que la complexité cryptographique crée souvent de nouvelles surfaces d’attaque.

Voici les problèmes les plus importants, réels, documentés et souvent peu discutés.

10.1 Vulnérabilité aux contrefaçons dans Zcash (2018)

Une vulnérabilité grave a été découverte dans le circuit Sapling de Zcash :

• Un paramètre à l’intérieur du circuit zk-SNARK était mal contraint.
• Cela permettait à un attaquant de créer des coins protégés falsifiés.
• Ces coins étaient indétectables car toutes les valeurs protégées sont cachées.

Faits clés :

• Découverte par le cryptographe Ariel Gabizon.
• Corrigé dans Sapling avant toute exploitation publique.
• Zcash n’a jamais révélé combien de coins contrefaits ont été créés dans le pool Sprout, car il est mathématiquement impossible de vérifier.

Cet incident est l’exemple réel le plus fort de :

Failles dans les systèmes ZK = inflation catastrophique et indétectable.

Il a également motivé des changements de protocole vers :

• De nouveaux circuits (Sapling, Orchard)
• Des systèmes de contraintes plus modulaires
• Plus de relectures par les pairs avant le déploiement

10.2 Attaque académique sur MimbleWimble (2019)

MimbleWimble (utilisé par Grin/Beam) n’utilise pas de zk-SNARKs mais des engagements Pedersen + cut-through + pas d’adresses.

Un chercheur (Ivan Bogatyy) a démontré :

• En surveillant le réseau en temps réel avec ~200 nœuds,
• Il pouvait relier 96 % des transactions Grin aux expéditeurs et destinataires.

Ce n’était pas une faille dans les mathématiques ZK elles-mêmes, mais une faille dans :

• Le modèle d’agrégation des transactions
• L’absence d’entrées “leurres”
• L’exposition des métadonnées au niveau réseau

Leçon importante :

La confidentialité ne réside pas uniquement dans les preuves — la topologie du réseau peut dé-anonymiser même une mathématique ZK parfaite.

10.3 Fuites de temps dans les implémentations du prouveur

Certaines implémentations ZKP (particulièrement les circuits SNARK anciens) divulguent des motifs de temps :

Exemple :

• Lors de la preuve d’une transaction avec de nombreuses entrées, les CPU ou GPU produisent des variations de temps détectables.
• Un observateur avec accès au nœud peut estimer le nombre de notes dépensées, réduisant les ensembles de confidentialité.

Cela a été partiellement observé dans les premiers clients Zcash avant optimisation.

Raison :
Les prouveurs SNARK utilisent souvent des FFT et des multiplications multiscalaires où la structure dépendante des entrées affecte le temps d’exécution.

10.4 Risques multi-courbes dans les systèmes hybrides

Des projets comme Aleo utilisent :

• STARKs → puis compression avec récursion SNARK (Kimchi/Halo/engagements polynomiaux KZG).

Risque rarement discuté :
Si une courbe ou un schéma d’engagement polynomial dans la pile de récursion échoue,
tout le système devient vulnérable.

Cette “fragilité multi-courbes” est presque jamais mentionnée dans les supports marketing.

11. Concevoir un circuit ZK pour une coin de confidentialité (plan général)

Voici une décomposition technique réelle de la manière dont les développeurs construisent réellement un protocole de confidentialité ZK.

Étape 1 : Sélectionner le modèle arithmétique

• R1CS (Zcash Sapling)
• PLONKish (Halo 2, Orchard)
• AIR/FRI (STARKs)

Chacun a ses compromis :

• R1CS → facile à raisonner, contraintes lourdes.
• PLONK → flexible, supporte des portes personnalisées.
• STARK → pas de configuration de confiance, mais preuves plus volumineuses.

Étape 2 : Choisir un corps fini

Exemples :

• Corps scalaire BLS12-381 (255 bits) pour SNARKs.
• Corps Goldilocks (64 bits friendly) pour STARKs (utilisé dans Polygon Miden, RISC Zero).

Le choix du corps affecte directement :

• La taille du circuit
• L’accélération matérielle
• La vitesse de preuve

Étape 3 : Construire les engagements cryptographiques

Un altcoin typique utilisera :

• Engagements Pedersen pour les valeurs
• Engagements SHA pour les chemins Merkle
• Hash Poseidon/Rescue à l’intérieur des circuits (compatible FFT)

Détail peu connu :
Zcash a abandonné SHA-256 à l’intérieur des circuits car SHA-256 est extrêmement coûteux en nombre de contraintes — plus de 25 000 contraintes par hash.
Poseidon réduit cela à ~150 contraintes.

Étape 4 : Implémenter la preuve de propriété (autorisation de dépense)

Cela implique normalement :

• Vérifier les dérivations de clés
• Vérifier la connaissance de la clé privée
• Prévenir les attaques par rejeu

Zcash utilise RedJubjub, un schéma de signature compatible SNARK (style EdDSA mais optimisé pour SNARKs).

Étape 5 : Implémenter la logique des nullifiers

Nullifier = tag unique déterministe pour une note dépensée.

Le circuit ZK doit garantir :

• Chaque note génère exactement un nullifier.
• Le nullifier ne peut pas révéler l’identité de la note.
• Le nullifier ne doit pas permettre de créer plusieurs dépenses.

Cette partie est extrêmement sujette aux erreurs — et a été la cause du plus gros bug de Zcash.

Étape 6 : Construire l’équation de solde

Prouver :
inputs_commitments_sum = outputs_commitments_sum

Plus preuves de plage :

• Valeurs ≥ 0
• Valeurs < 2⁶⁴

Dans les systèmes modernes, les contraintes de plage utilisent :

• Arguments de recherche PLONK
• Bulletproofs à l’intérieur des circuits
• Portes personnalisées

Étape 7 : Agrégation finale & génération de preuve

Exemple SNARK :

• Compiler le circuit → polynôme QAP
• FFT pour évaluer le polynôme
• Multiscalaires EC
• Sortie de la preuve
• Les nœuds on-chain/verificateurs vérifient en millisecondes

Exemple STARK :

• Construire la trace d’exécution
• Appliquer les engagements FRI
• Sortie d’une preuve volumineuse mais transparente
• Vérification par opérations de hash

12. Accélération matérielle ZK (un changeur de jeu)

La plupart des utilisateurs ignorent que la génération de preuves ZKP devient progressivement une course à l’armement matérielle :

Preuves sur GPU

• Les opérations FFT et MSM se mappent extrêmement bien aux GPU.
• Sur le testnet d’Aleo, >50 % du débit de génération de preuves était effectué sur des GPU grand public (série RTX).

Preuves sur ASIC

Plusieurs entreprises (Ingonyama, Cysic) conçoivent des ASIC orientés ZKP pour :

• Les unités MSM
• L’évaluation des polynômes
• Les calculs de chemins Merkle

Détail statistiquement pertinent :

• Un prouveur ASIC spécialisé peut générer des preuves SNARK 20 à 50× plus rapidement qu’un CPU.

Cela signifie que l’avenir des coins de confidentialité pourrait dépendre fortement d’écosystèmes matériels spécialisés, similaire au minage de Bitcoin.

13. Le problème de l’audit transparent dans les coins ZK

Les coins de confidentialité font face à un paradoxe :

1. Les utilisateurs veulent de la confidentialité.
2. Les développeurs doivent garantir l’absence d’inflation ou de vulnérabilités cachées.
3. Les ZK cachent tout.

Plusieurs techniques tentent de résoudre ce problème :

13.1 Clés de visualisation (Zcash, Aztec)

Permettent aux auditeurs d’inspecter des comptes spécifiques sans révéler les autres.

13.2 Audits de l’offre

• Zcash peut auditer l’offre du pool transparent.
• L’offre du pool protégé ne peut pas être auditée directement.
• Les développeurs s’appuient sur la validité des circuits pour garantir l’absence d’inflation.

C’est pourquoi les bugs de protocole ZK sont des menaces existentielles.

14. Faits cryptographiques rares mais importants

14.1 Les premiers articles ZKP utilisaient des protocoles interactifs

Les SNARKs modernes sont non interactifs (via l’heuristique Fiat–Shamir).
Mais les premiers ZKP nécessitaient de nombreux échanges de communication.

14.2 Fiat–Shamir n’est pas prouvablement sûr

Si la fonction de hachage utilisée dans Fiat–Shamir est cassée ou malléable,
la solidité peut s’effondrer.

Cela affecte tous les coins de confidentialité basés sur SNARK.

14.3 Les STARKs reposent uniquement sur des fonctions de hachage

Ce qui signifie :

• Elles sont considérées comme sécurisées post-quantiques.
• Leur sécurité dépend uniquement de la résistance aux collisions des fonctions de hachage (ex. Rescue, Poseidon).

14.4 Les preuves récursives réduisent la charge de la blockchain

Halo 2 (utilisé dans Zcash Orchard) permet :

• Des preuves qui vérifient d’autres preuves
• Une récursion infinie
• Aucun setup de confiance

Cela élimine de nombreuses limitations précédentes des systèmes SNARK.

15. Tableau comparatif : systèmes ZK dans les principales altcoins de confidentialité

Monero est inclus uniquement pour comparaison — il n’utilise pas de preuves à connaissance nulle, ce qui surprend de nombreux débutants.

16. Les vrais compromis de l’utilisation des ZKP dans les coins de confidentialité

Avantages

• Confidentialité maximale avec garanties mathématiques.
• Possibilité de cacher simultanément l’expéditeur, le destinataire et le montant.
• Les preuves sont vérifiables par quiconque.

Inconvénients

• Coût computationnel élevé.
• Risques liés aux bugs de circuit (inflation).
• Transactions plus volumineuses (sauf Groth16).
• Intégration plus difficile dans les portefeuilles légers.
• Cryptographie plus complexe → moins d’experts la comprennent → audits plus lents.

Un problème rarement mentionné :

Les systèmes ZK augmentent les fuites de déterminisme des portefeuilles :
les motifs de génération de preuves peuvent révéler le matériel du portefeuille, le type de CPU/GPU, voire le système d’exploitation, fournissant des métadonnées aux agences de surveillance blockchain.

17. Évolution probable de la confidentialité ZK dans les 5 prochaines années

Directions les plus probables :

17.1 Couches de confidentialité universelles

Au lieu d’intégrer la confidentialité directement dans la couche L1 :

• Des réseaux comme Aztec, Penumbra et RAILGUN visent à fournir la confidentialité pour les chaînes existantes.
• Cela évite la fragmentation entre les altcoins.

17.2 Co-processeurs ZK

Dispositifs auxiliaires gérant toutes les opérations SNARK/STARK pour les portefeuilles ou les nœuds.

17.3 Confidentialité adaptative (sélectionnable par l’utilisateur)

Les utilisateurs peuvent divulguer de manière sélective :

• Les montants
• L’expéditeur
• Le destinataire
• Les champs de mémo

Seulement lorsque requis légalement ou commercialement.

17.4 Écosystèmes de smart contracts entièrement privés

Aleo, Aztec 3 et Penumbra sont activement en train de pionnier dans cette direction.

17.5 Standards de tokens compatibles SNARK

Par exemple, ZK-ERC20 avec :

• Soldes chiffrés
• Preuves de transfert ZK
• Compatibilité avec les outils Ethereum

Ce sera probablement la première adoption ZK véritablement grand public.

18. Réflexions finales

Les preuves à connaissance nulle redéfinissent fondamentalement ce que signifie la “confidentialité” dans les écosystèmes blockchain.
Ce n’est pas magique, et cela comporte des risques d’ingénierie, de complexité cryptographique et des risques opérationnels.
Mais elles permettent quelque chose qu’aucun autre système ne peut atteindre :

confidentialité prouvable mathématiquement combinée à exactitude prouvable mathématiquement.

Pour les altcoins axés sur la confidentialité, les ZKP sont à la fois le bouclier ultime et la responsabilité ultime en cas de mauvaise implémentation.
Comprendre les mécanismes cryptographiques exacts — engagements, circuits, arithmétisation, systèmes de preuves — est essentiel pour évaluer les coins de confidentialité au-delà des narratifs marketing.