MSTR Cat

Blockchain/Niveau IV · Le protocole en profondeur/4.2 Évolutions du protocole/Leçon 6

La frontière cryptographique : chiffrement par témoin et PIPEs

Verrouiller une clé dans une preuve quand l’opcode n’arrive jamais

MatérielUne copie de BIP-119 et BIP-347Accès à un explorateur de blocs avec des fonctionnalités de débogage de scriptsUn carnet pour suivre l’état des propositionsUn exemplaire de l’IACR ePrint 2026/186

Curiosité

  1. Pourquoi Bitcoin peut-il vérifier une signature, mais pas restreindre la destination suivante des pièces qui en résultent ?
  2. Quel est le coût pour prouver que l’on connaît un secret sans révéler le secret lui-même ?
  3. Comment les protocoles maintiennent-ils la sécurité lorsque les règles de base restent statiques et immuables ?

Explorer

    Partie ILa frontière cryptographique : covenants et chiffrement par témoin

  1. Bitcoin Script est délibérément limité. Il peut vérifier qu’une signature correspond à une clé publique, mais ne peut pas examiner la destination des pièces une fois dépensées. Cette restriction rend Script simple et prévisible. Cependant, elle bloque aussi certaines conceptions dans lesquelles les conditions de dépense dépendent de la structure de transactions futures.
  2. La proposition de Jeremy Rubin pour OP_CHECKTEMPLATEVERIFY (BIP-119) vise à combler cette lacune. Cet opcode permettrait à un script d’exiger que la transaction de dépense corresponde à un modèle (template) préalablement engagé, en fixant ses sorties et certains autres champs. Cela rend possibles des covenants non récursifs : des règles sur la destination suivante des pièces, comme verrouiller des fonds dans des coffres (vaults) ou restreindre les voies de rachat. Il n’est toujours pas activé et reste l’objet de débats au sein de la communauté Bitcoin.
  3. Une proposition distincte, OP_CAT (BIP-347), porte sur la concaténation de données sur la pile plutôt que sur l’imposition directe de contraintes de destination, bien que, combinée aux signatures Schnorr, elle puisse aussi permettre des covenants. Cette opération simple rend possibles des constructions cryptographiques complexes, notamment des signatures en arbre qui expriment de manière compacte des politiques multisignatures très étendues. Elle facilite également les signatures de Lamport, résistantes au quantique, en permettant de manipuler directement des hashs et des valeurs dans le moteur de script.
  4. Au-delà des nouveaux opcodes, la recherche explore le chiffrement par témoin comme voie alternative vers la programmabilité. Le chiffrement par témoin permet à un expéditeur de verrouiller des données de sorte que seule une personne capable de prouver qu’elle possède un secret précis (un témoin) puisse les déverrouiller. En théorie, cela pourrait permettre de ne révéler des clés bitcoin que sur preuve d’un énoncé, sans que le réseau ait à vérifier directement le calcul.
  5. Les premières constructions de chiffrement par témoin existent dans la littérature académique, mais restent impraticables pour un déploiement sur Bitcoin. Il n’existe encore aucune construction pratique pour des énoncés généraux : les schémas connus sont énormes et reposent sur des hypothèses cryptographiques qui ne bénéficient pas encore d’une confiance générale. Si les fondements théoriques sont solides, l’écart d’ingénierie entre une preuve de concept et un protocole prêt pour la production reste considérable.
  6. Le compromis est clair : les covenants ajoutent de l’expressivité mais introduisent de nouvelles règles de consensus qui exigent un examen attentif ; le chiffrement par témoin apporte confidentialité et flexibilité, mais impose de lourds coûts de stockage et de calcul. Les deux approches cherchent à étendre les capacités de Bitcoin sans abandonner son modèle de sécurité fondamental : une émission fixe et prévisible et une capacité de script limitée.

    7. Partie IIFaire entrer et sortir des bitcoins : PIPEs et chiffrement par témoin

  7. Shielded Bitcoin, présenté en détail dans la leçon précédente, gère les transferts privés au sein de son propre système de notes. Il laisse hors de son périmètre le peg-in et le peg-out : comment faire passer de la valeur du Bitcoin ordinaire et transparent vers la couche protégée, puis l’en faire ressortir. Le plan de conception de ces passerelles repose sur un mécanisme appelé chiffrement par témoin (witness encryption), plus précisément Bitcoin PIPEs v2 (IACR ePrint 2026/186, février 2026).
  8. Le chiffrement par témoin verrouille des données derrière un énoncé mathématique. Dans ce contexte, une clé privée Bitcoin est chiffrée de telle sorte qu’elle ne peut être déchiffrée que si quelqu’un présente un témoin valide — une preuve que l’énoncé est vrai. Le texte chiffré est publié hors chaîne, et la clé qu’il contient reste inaccessible à quiconque ne peut pas produire le témoin correspondant.
  9. Le mécanisme déplace la programmabilité du consensus vers la cryptographie. Au lieu d’exiger de nouveaux opcodes ou des soft forks pour imposer des conditions de dépense complexes, la logique réside entièrement dans le schéma de chiffrement. Quiconque présente un témoin valide, comme une preuve SNARK, récupère la clé privée et dépense les pièces avec une signature Schnorr ordinaire. Pour les règles de consensus de Bitcoin, il s’agit d’une simple transaction standard ; la complexité est invisible.
  10. Cette approche peut émuler des restrictions de type covenant, comme CheckTemplateVerify ou les mécanismes de vault, sans modifier le protocole. Les conditions sont imposées par l’impossibilité de déchiffrer la clé tant que le témoin ne satisfait pas à des critères précis. Elle ouvre la voie à des conditions de dépense avancées qui restent compatibles avec les règles de validation existantes de Bitcoin, à condition que la cryptographie sous-jacente tienne.
  11. Le principal obstacle est l’échelle. L’article de février 2026 estimait chaque texte chiffré à environ 338 téraoctets ; des travaux ultérieurs des auteurs annoncent environ 10 téraoctets, ce qui reste irréaliste à stocker et à distribuer. Aucune implémentation n’existe : il ne s’agit donc que d’estimations, et la question de savoir si les PIPEs pourront être déployés tout court reste une question de recherche ouverte.
  12. On en est encore au stade de la recherche, pas à celui d’une fonctionnalité implémentée. Aucune date de déploiement n’existe, et les chiffres de taille contradictoires soulignent l’incertitude qui règne dans ce domaine. Tant que les textes chiffrés ne seront pas suffisamment réduits, le chiffrement par témoin reste un pont théorique entre le registre transparent de Bitcoin et des engagements cryptographiques complexes, plutôt qu’un outil opérationnel pour les utilisateurs.

Faits clés

  • OP_CHECKTEMPLATEVERIFY (BIP-119) propose un mécanisme de covenant pour restreindre les destinations futures des pièces.
  • OP_CAT (BIP-347) permet la concaténation sur la pile, ce qui rend possibles les signatures en arbre et les signatures fondées sur des hashs (Lamport).
  • Le chiffrement par témoin verrouille les données derrière une preuve d’un témoin secret sans révéler ce dernier.
  • Il n’existe encore aucune construction pratique de chiffrement par témoin pour des énoncés généraux.
  • Les covenants restent des propositions non activées, soumises au débat de consensus.
  • Les limites de Bitcoin Script empêchent, par conception, de nombreuses catégories d’attaques.
  • Bitcoin PIPEs v2 utilise le chiffrement par témoin pour verrouiller des clés privées derrière des énoncés mathématiques.
  • Pour récupérer la clé, il faut présenter un témoin valide, tel qu’une preuve SNARK.
  • La dépense s’effectue au moyen d’une signature Schnorr ordinaire une fois la clé récupérée.
  • Le mécanisme émule des covenants sans nécessiter de nouveaux opcodes ni de soft forks.
  • Les tailles estimées des textes chiffrés sont passées d’environ 338 To (selon l’article) à environ 10 To (selon des annonces ultérieures), ce qui reste irréaliste en pratique.
  • Les plans de peg-in et de peg-out de Shielded Bitcoin reposent sur cette infrastructure de chiffrement par témoin.

Exercice neuf, six, trois, un

9RassemblerListez 9 contraintes techniques ou caractéristiques de Bitcoin Script qui définissent ses capacités et ses limites actuelles.
6RegrouperRegroupez les 9 en 6 selon ce que chacun permet ou empêche.
3DistillerRéduisez les 6 groupes à 3 raisons fondamentales pour lesquelles il est difficile d’étendre Bitcoin Script, malgré des avantages théoriques évidents.
1CristalliserRédigez 1 phrase sur la tension fondamentale entre l’ajout de programmabilité et le maintien de la stabilité du consensus dans un système décentralisé.

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.

Ouvrir dans l'académie interactive →

EN PT ES ZH JA KO RU DE MS