Zero-knowledge sur Bitcoin : preuves et transferts confidentiels

Curiosité

1. Comment une valeur chiffrée peut-elle circuler sur une chaîne publique sans modifier les règles de consensus ?
2. Que révèle un nullifier sur une note dépensée, et que cache-t-il ?
3. Pourquoi un protocole s’appuierait-il sur un indexeur plutôt que sur des nœuds complets pour valider son état de base ?

Explorer

Partie IShielded Bitcoin : des transferts privés sans soft fork

1. Clara Shikhelman, Mikhail Komarov et Aleksei Moskvin ont publié « Shielded Bitcoin » le 24 septembre 2026. Cet article de 56 pages propose une conception qui reprend l’architecture des pools Sapling et Orchard de Zcash pour l’utiliser sur Bitcoin. La valeur est détenue sous forme de notes chiffrées plutôt que d’UTXO standard. Dépenser une note révèle un nullifier afin d’empêcher la double dépense, mais cet identifiant ne permet pas de remonter à la note en question ni à sa source d’origine.
2. Chaque transfert consiste en une transaction Bitcoin ordinaire comportant une sortie OP_RETURN. Cette sortie contient une enveloppe renfermant une preuve zero-knowledge Groth16 d’environ 192 octets. La preuve démontre que le transfert est valide et équilibré sans exposer les données sous-jacentes. Une enveloppe standard à deux entrées et deux sorties occupe environ 610 octets, et la sortie OP_RETURN environ 625 vB. Les règles de consensus de Bitcoin ignorent entièrement ces données ; elles sont traitées comme une charge utile non dépensable.
3. Comme les nœuds complets ne valident pas le contenu de l’OP_RETURN, les indexeurs doivent rejouer ces enveloppes dans l’ordre des blocs pour reconstruire l’arbre des notes, l’ensemble des nullifiers et les racines de Merkle. Si un transfert invalide apparaît dans un bloc, les indexeurs l’ignorent simplement au lieu de rejeter le bloc. La vérification passe ainsi des nœuds complets au logiciel d’indexation. Un indexeur malhonnête peut servir un état obsolète ou incomplet, mais il ne peut pas prendre les fonds, et chacun peut faire tourner le sien.
4. La conception masque à l’analyse de chaîne les montants, les expéditeurs, les destinataires et les positions dans le graphe. En revanche, le timing, les frais, la structure du support de données et le nombre d’entrées/sorties restent visibles on-chain. Le relais de ces transactions dépend de la limite par défaut plus élevée du data carrier dans Bitcoin Core v30, un changement de politique de relais et non une mise à niveau du consensus. Si de nombreux opérateurs fixaient des limites plus strictes, ces transactions seraient plus difficiles à relayer, même si les mineurs disposés à les accepter pourraient toujours les inclure.
5. L’article exclut explicitement du périmètre de cette première conception les mécanismes de peg-in et de peg-out. Les auteurs prévoient de construire ces composants sur Bitcoin PIPEs v2, en utilisant le chiffrement par témoin (witness encryption) pour verrouiller des clés privées derrière des énoncés cryptographiques. Cette approche permet la programmabilité au moyen des signatures Schnorr existantes plutôt que de nouveaux opcodes. À ce jour, le projet n’a ni implémentation, ni utilisateurs, ni fonds en circulation ; il reste une spécification théorique.
6. La conception a des limites connues. Groth16 nécessite un trusted setup (configuration de confiance) unique, sûr si au moins un participant à la cérémonie a été honnête. Un nouveau pool démarre avec un ensemble d’anonymat nul, si bien que les premiers utilisateurs sont plus faciles à distinguer. Un transfert est estimé à environ 700 vB, soit plusieurs fois la taille d’un paiement ordinaire. Les preuves reposent sur des courbes elliptiques qu’un grand ordinateur quantique pourrait casser. Et tant que les indexeurs ne pourront pas prouver leur état à faible coût, les portefeuilles légers devront faire confiance à l’indexeur qu’ils interrogent, même si celui-ci ne peut pas prendre leurs fonds.

Partie IILes preuves zero-knowledge sur Bitcoin aujourd’hui

7. Bitcoin Script a été conçu pour la simplicité et la sécurité, ce qui limite sa capacité à exécuter du code arbitraire. Une preuve zero-knowledge standard, comme un SNARK Groth16, nécessite une arithmétique de couplages (pairings) sur courbes elliptiques que le jeu d’opcodes actuel de Bitcoin ne peut pas exécuter à un coût raisonnable. Ce fossé de calcul signifie que le réseau lui-même ne peut pas vérifier nativement ces preuves sans soft fork ou sans une dépense importante de ressources par transaction.
8. Les protocoles de type BitVM résolvent ce problème par la vérification optimiste. Au lieu de vérifier immédiatement chaque preuve, ils la présument correcte et ne déclenchent la vérification coûteuse qu’en cas de litige. Si personne ne conteste la transition d’état dans un délai fixé, elle est acceptée comme valide. La sécurité repose sur les incitations : les opérateurs déposent une garantie qu’ils perdent s’ils trichent, et n’importe quel observateur peut contester.
9. Le bridge Clementine de Citrea est arrivé sur le mainnet en janvier 2026 avec cette architecture BitVM2. Son chemin de contestation vérifie une preuve Groth16 à l’aide d’un vérificateur en Script d’environ 1 Go (contre près de 3 Go dans les premières estimations), découpé en fragments qui ne s’exécutent que lorsqu’une contestation est déposée. Cette conception permet de sécuriser des transitions d’état complexes par Bitcoin sous l’hypothèse d’une seule partie honnête, sans exiger que chaque nœud complet effectue les lourdes vérifications cryptographiques pour les transactions courantes.
10. Le projet Glock d’Alpen a démontré une approche alternative fondée sur les circuits brouillés (garbled circuits), arrivée sur un testnet signet en juillet 2026. Glock utilise les circuits brouillés pour rendre la vérification d’une preuve en cas de litige bien moins coûteuse on-chain. Il repose toujours sur les litiges, mais avec une empreinte on-chain bien plus réduite, et les deux approches reconnaissent que la vérification native en Script d’une cryptographie avancée reste d’un coût prohibitif pour un usage général.
11. La validation côté client offre une autre voie, dans laquelle les preuves sont vérifiées par les utilisateurs ou les indexeurs plutôt que par la couche de base. Des protocoles comme RGB et Taproot Assets s’appuient sur les participants pour vérifier localement les preuves de propriété. De même, les conceptions Shielded Bitcoin font rejouer par des indexeurs les enveloppes de transaction pour reconstruire les arbres de notes ; les transferts invalides sont ignorés par le consensus mais détectables par un logiciel de surveillance qui exécute toute la logique de vérification en dehors du nœud.
12. Ces systèmes comportent des compromis précis. Groth16 exige un trusted setup (configuration de confiance), dont la cérémonie doit garantir que personne ne conserve de secrets toxiques qui pourraient invalider les preuves. Dans les systèmes optimistes, les transactions de litige sont volumineuses et complexes, ce qui pose des difficultés de relais. En outre, les courbes compatibles avec les couplages (pairing-friendly) utilisées par Groth16, comme la courbe secp256k1 de Bitcoin elle-même, sont vulnérables à un grand ordinateur quantique : un ordinateur quantique pourrait donc forger des preuves et casser le chiffrement des notes basé sur l’ECDH, même si les preuves Groth16 elles-mêmes ne révèlent aucun secret.

Faits clés

Exercice neuf, six, trois, un

Vérification des faits

Les dates, les chiffres et les affirmations ont été vérifiés à l’aide des sources publiées listées ci-dessous.

• Shikhelman, Komarov & Moskvin, 'Shielded Bitcoin' ([alloc] init, September 24, 2026)
• D. Hopwood et al., Zcash Protocol Specification (Sapling and Orchard)
• Bitcoin Core v30 release notes
• news.bitcoin.com coverage of Shielded Bitcoin (2026)
• R. Linus et al., 'BitVM2: Bridging Bitcoin to Second Layers' (2024)
• Citrea documentation and mainnet announcement (2026)
• Alpen, 'Glock is here' (July 2026)