Paiements privés sur Bitcoin rien de lisible on-chain
zkCoins apporte une vraie confidentialité à Bitcoin. Montants, expéditeur, destinataire et historique restent hors chaîne — prouvés par zero-knowledge, tandis que chaque transfert ne publie qu'un nullifier de ~64 octets sur Bitcoin.
Pas de soft forkSelf-custodialZero-knowledgePas de coordinator
~140 vBytes · entièrement public · un par paiement
un ordre de grandeur plus petit
Transfert zkCoins
un nullifier de ~64 octets
~16 vBytes on-chain · données des coins hors chaîne
Les données des coins ne touchent jamais la chaîne. Chaque transfert publie un nullifier de ~64 octets sur Bitcoin — environ 16 vBytes, contre ~140 pour un transfert classique — constant quel que soit le nombre de coins déplacés.
"Use the chain for what the chain is good for — an immutable ordering of commitments to prevent double-spending."
— Robin Linus, co-auteur de Shielded CSV
Whitepaper · ePrint 2025/068
Shielded CSV: Private and Efficient Client-Side Validation
Une variante de Client-Side Validation préservant la confidentialité, réglée directement sur Bitcoin.
Auteurs
Jonas Nick (Blockstream) · Liam Eagen (Alpen Labs) · Robin Linus (ZeroSync)
Publié
janvier 2025 (ePrint) · septembre 2024 (whitepaper)
Client-Side Validation découple la validation des transactions du consensus Bitcoin en la déplaçant vers le destinataire. Shielded CSV améliore les conceptions CSV antérieures en masquant entièrement l'historique des transactions : chaque transfert ne fuit qu'un nullifier de 64 octets vers la chaîne, le reste étant vérifié côté client via des preuves zero-knowledge succinctes. Le protocole est compatible avec Bitcoin tel quel — pas de soft fork, pas de hard fork — et vise environ un ordre de grandeur de plus de transactions par seconde que la base layer seule.
zkCoins v1 implémente fidèlement le modèle du paper : chaque transfert publie son nullifier de ~64 octets directement sur Bitcoin sous forme de signature semi-agrégée, de sorte que la chaîne elle-même garantit chaque nullifier dont un vérifieur a besoin pour ses contrôles de double-spend — pas de données de batch hors chaîne, aucune hypothèse de data-availability. Environ 16 vBytes on-chain par transfert, de l'ordre de ~100 transactions par seconde.
Transferts privés, un minuscule nullifier sur Bitcoin
Les données des coins restent hors chaîne. Chaque transfert ne publie qu'un nullifier de ~64 octets sur Bitcoin, prouvé par zero-knowledge — confidentialité et petite empreinte on-chain gagnent en même temps.
Empreinte on-chain
Un nullifier par transfert
Les données des coins ne touchent jamais la chaîne. Chaque transfert publie un nullifier de ~64 octets sur Bitcoin — rien de lisible sur les montants ou les parties.
Graphe de transactions
Rien de rattachable
Contrairement à RGB ou Taproot Assets, l'historique reste caché sous une preuve zero-knowledge. Les destinataires vérifient la validité sans jamais voir la lignée.
Compatibilité
Bitcoin, inchangé
Pas de soft fork, pas de hard fork. Les protocoles CSV utilisent la chaîne uniquement pour l'ordonnancement et la prévention des double-spends.
Coût
Une fraction d'un transfert Bitcoin
Chaque transfert coûte environ 16 vBytes on-chain — une fraction d'un transfert Bitcoin de ~140 vBytes, environ un ordre de grandeur plus petit — constant quel que soit le nombre de coins déplacés.
Comment ça marche
La chaîne ordonne, le destinataire valide
Les blockchains traditionnelles demandent à chaque nœud de valider chaque transaction. Shielded CSV inverse cela — la validation passe au destinataire, et Bitcoin ne fait que ce pour quoi il est unique.
1
L'expéditeur prouve
L'expéditeur crée un transfert et génère une preuve de validité succincte de toute l'histoire du coin — une taille constante, quel que soit l'âge du coin.
2
La preuve va au destinataire
La preuve voyage directement vers le destinataire, hors chaîne. Seuls l'expéditeur et le destinataire voient les montants, les parties et l'historique — aucun montant ni aucune partie n'est écrit sur la chaîne.
3
Le nullifier est publié sur Bitcoin
Le nullifier de ~64 octets du transfert est publié sur Bitcoin sous forme de signature semi-agrégée. La publication est permissionless — tout wallet peut auto-publier — et la chaîne elle-même détient chaque nullifier dont un vérifieur a besoin.
4
Le destinataire vérifie côté client
Le destinataire re-vérifie localement la preuve zero-knowledge complète du coin — un seul contrôle en temps constant, quelle que soit la longueur de l'historique — et l'accepte sans faire confiance à un tiers.
5
Bitcoin empêche les double-spends
Bitcoin enregistre chaque nullifier dans l'ordre canonique, et la première occurrence on-chain de la clé d'état d'un coin sélectionne son unique transition valide. Le seul rôle de la chaîne : garantir que chaque coin est dépensé exactement une fois — sans aucune donnée hors chaîne requise.
En chiffres
Bitcoin, à côté de Shielded CSV
Métrique
Bitcoin (classique)
zkCoins v1
Données on-chain
transaction complète (~140 vBytes)
nullifier de ~64 octets par transfert
Coût par transfert
~140 vBytes
~16 vBytes par transfert
Confidentialité
Aucune — entièrement public
Complète — rien de lisible on-chain
Vérification
Script complet par tx
1× preuve de transfert
Taille de preuve
N/A
Constante, indépendante de l'historique
Limites
Ce que Shielded CSV n'est pas
Ici, la confidentialité est structurelle, pas un ajout. Cela vaut la peine d'être précis sur ce que ce protocole n'est délibérément pas.
Pas une sidechain
Il utilise Bitcoin L1 directement — pas de consensus séparé, pas de bridge vers une chaîne étrangère.
Pas un rollup
Pas de sequencer, pas de couche de data-availability — les nullifiers vivent sur Bitcoin même. Les validity proofs circulent peer-to-peer entre expéditeur et destinataire ; le nullifier de ~64 octets de chaque transfert est ancré sur Bitcoin L1.
Pas un mixer
La confidentialité est structurelle, pas de l'obfuscation — un ensemble d'anonymat global de chaque coin, pas un petit pool par round.
Pas un token
Pas de token de protocole natif à bootstrapper. La valeur vit dans des coins validés côté client.
Pas un soft fork
Il fonctionne sur Bitcoin tel qu'il existe aujourd'hui — pas de changement de consensus, pas de nouveaux opcodes.
Roadmap
Le chemin vers le mainnet
ActifSuivantPlanifiéHorizon
Phase 01
Fondations
Q2 2026Actif
La stack de proving et la frontière wallet–serveur. Tout le reste en dépend.
Migration du circuit zero-knowledge.Déplacer le circuit de transition d'état vers un système de proving natif pour la récursion avec un hash SNARK-friendly.
Proving côté serveur sur du matériel courant.Cible Apple Silicon single-host — pas de fermes GPU, pas de service de proving cloud. Le wallet ne détient que la clé privée.
Frontière wallet via BIP-340 Schnorr.Le wallet signe un digest SHA-256 de l'état calculé côté serveur. Pas de zero-knowledge dans le navigateur.
Roundtrip de bout en bout sur signet.Créer un compte, minter, envoyer, recevoir — la boucle utilisateur complète tourne sur un testnet Bitcoin public.
Phase 02
Durcissement pré-mainnet
Q3 2026Suivant
Combler les écarts de protocole entre « ça marche sur signet » et « sûr avec du vrai Bitcoin ».
Masquer les commitments des destinataires.Éliminer le lien résiduel entre expéditeur, destinataire et identifiant de coin.
Accumulation de nullifiers sûre face aux reorgs.Se dégrader gracieusement quand la chaîne canonique se réorganise, au lieu de se bloquer.
Preuves de fraîcheur par coin.Les destinataires vérifient l'âge d'un coin localement sans faire confiance à un tiers.
Suite de tests de sécurité dérivée du paper.L'ensemble complet des propriétés formelles du paper Shielded CSV, encodées en tests failing-witness.
Phase 03
Bridge BTC trustless
Q4 2026Planifié
Mint et burn contre du BTC natif sans faire confiance à l'émetteur. Le plus grand écart de confiance côté utilisateur se ferme ici.
Bridge de type BitVM2 / Clementine.Modèle de confiance 1-of-N honesty. La même construction qui tourne sur le mainnet Citrea.
Light client Bitcoin récursif.Une preuve succincte qu'un dépôt a atterri à profondeur ≥ 6 dans la chaîne canonique.
Récursion → wrapping Groth16.Amener nos preuves adaptées à la récursion dans un vérifieur que Bitcoin script peut contrôler.
Mise à l'échelle de la fédération : N=3 → N=100.Démarrer avec une fédération mono-opérateur ; croître jusqu'à cent membres indépendants, où une seule suppression de clé honnête suffit.
Run d'intégration signet.Roundtrip peg-in / peg-out complet, y compris un scénario d'opérateur délibérément malveillant.
Phase 04
Atomic swap Lightning
Q1 2027Planifié
Déplacer de la valeur entre Lightning et zkCoins de façon atomique — pas de confiance au provider, pas de bridge custodial.
HTLC sur la transaction de funding du nullifier.L'atomicité vit sur Bitcoin layer 1, pas sur la couche de coins privés. Primitives standard, pas de soft fork.
Flux LN ↔ zkCoins symétriques.Acheter avec des sats Lightning et revendre en sats Lightning, les deux directions trustless.
Liquidité avancée par des providers.N'importe qui peut faire tourner un swap provider ; le protocole impose l'honnêteté, pas l'opérateur.
Motif de swap préservant la confidentialité.Un swap provider apprend le côté LN, jamais le graphe interne zkCoins.
Phase 05
Positionnement long terme
2027 +Horizon
Remplacer les technologies de bridge d'aujourd'hui par celles de demain — sans changer le protocole.
Système de proving de nouvelle génération.Porter vers un corps plus petit avec un hash plus rapide une fois la stack amont stabilisée. La structure algorithmique reste.
Mise à niveau de la construction de bridge.Les successeurs drop-in de BitVM2 (Glock, Mosaic) réduisent le coût de dispute on-chain de deux ordres de grandeur. Le contrat du circuit est inchangé.
Diversité de la fédération.Recruter des organisations indépendantes comme membres de fédération jusqu'à ce que one-honest-deletion soit une hypothèse significative.
Trusted setup du vérifieur de bridge.Une cérémonie de 30–60 contributeurs remplace le jeu de paramètres Groth16 mono-contributeur utilisé pour tester le vérifieur de bridge — les preuves propres de zkCoins sont transparentes (FRI) et n'ont pas besoin de setup.
Note. Les dates indiquent des fenêtres cibles pour le travail d'ingénierie, pas une date de mainnet garantie. zkCoins tourne dans un environnement de test public jusqu'à la fin du durcissement pré-mainnet ; aucun vrai Bitcoin n'est en risque avant.
zkCoins apporte Shielded CSV à un wallet self-custodial — Bitcoin privé sur L1, pas de soft fork. Nous maintenons une ligne ouverte pour les fonds de venture, family offices et angels stratégiques qui évaluent le projet.
Le protocole s'appuie sur de la recherche publiée (ePrint 2025/068), la stack est open source, et la roadmap est publique. Nous ne levons pas activement — mais nous restons ouverts aux conversations avant le mainnet.
zkCoins est un wallet self-custodial pour Shielded CSV, un protocole de confidentialité pour Bitcoin. Montants, expéditeur, destinataire et historique de transactions restent hors chaîne, prouvés par zero-knowledge et vérifiés côté client. Chaque transfert ne publie qu'un nullifier de ~64 octets sur Bitcoin.
zkCoins est-il un nouveau token ou altcoin ?
Non — zkCoins n'est pas une blockchain séparée, un altcoin, ni un token de protocole natif. C'est une couche de client-side-validation ancrée sur Bitcoin L1 ; la valeur vit dans des coins validés côté client. Faire entrer et sortir du BTC on-chain passe par un bridge, qui figure sur la roadmap.
zkCoins nécessite-t-il un soft fork ?
Non. Shielded CSV fonctionne sur Bitcoin tel qu'il existe aujourd'hui — pas de soft fork, pas de hard fork, pas de nouveaux opcodes. La chaîne n'est utilisée que pour ordonner des commitments et empêcher les double-spends.
Comment zkCoins garde-t-il les transactions privées ?
Chaque spend est prouvé avec une preuve zero-knowledge et partagé hors chaîne. Les données des coins — montants, parties et historique — ne touchent jamais Bitcoin ; seul un nullifier de ~64 octets par transfert est publié sur la chaîne.
zkCoins est-il self-custodial ?
Oui. Les clés sont générées et stockées localement dans votre navigateur et ne quittent jamais votre appareil. zkCoins est peer-to-peer, sans coordinator ni custodian capable de geler des fonds ou d'arrêter le réseau.
Qu'est-ce que Shielded CSV ?
Shielded CSV (Client-Side Validation) est un protocole Bitcoin préservant la confidentialité issu du paper de Jonas Nick, Liam Eagen et Robin Linus (ePrint 2025/068). zkCoins v1 l'implémente fidèlement : chaque transfert publie un nullifier de ~64 octets sur Bitcoin, tout le reste étant vérifié côté client.
Le rôle de publisher est-il vraiment décentralisé ?
La publication est permissionless, et tout wallet peut auto-publier ses propres transferts sur Bitcoin à un coût trivial — cela plafonne ce qu'un publisher dominant peut facturer. L'économie concurrentielle favorise l'opérateur le plus rapide et le mieux capitalisé, donc une certaine concentration est attendue. Ce n'est qu'un risque de liveness : un publisher ne détient jamais la custody et peut au plus censurer ou retarder un transfert, jamais voler ni forger des coins. Analyse complète sur la page Risks des docs.
Où vivent les nullifiers ?
Sur Bitcoin. Chaque transfert publie son nullifier de ~64 octets directement sur la chaîne sous forme de signature semi-agrégée, de sorte que Bitcoin lui-même garantit la disponibilité de chaque nullifier dont un vérifieur a besoin pour contrôler les double-spends — pas de données de batch hors chaîne ni de couche de data-availability séparée à qui faire confiance. Les données des coins — montants, parties et historique — restent quant à elles hors chaîne, prouvées par zero-knowledge, et ne sont jamais nécessaires pour reconstruire la vue publique des double-spends.
Essayez le Bitcoin privé aujourd'hui
Le wallet zkCoins tourne dans votre navigateur. Les clés sont générées et stockées localement — elles ne quittent jamais votre appareil. Actuellement sur un réseau de test public ; aucun vrai Bitcoin n'est en risque.