La sainte coupe du réseau de deuxième couche du Bitcoin : introspection et contrat
TechFlow SélectionTechFlow Sélection
La sainte coupe du réseau de deuxième couche du Bitcoin : introspection et contrat
Un article détaillé sur les propositions populaires de codes d'opération (opcodes) pour l'écosystème BTC : OP_CAT, CTV, APO, MATT
Dédié à des analyses Web3 approfondiesRédaction : Chakra Research
Aperçu
Comparé à des blockchains Turing-complètes comme Ethereum, le script de Bitcoin est considéré comme très limité, ne permettant que des opérations basiques et ne supportant même pas les multiplications ou divisions. Plus important encore, les données propres à la blockchain sont presque impossibles à lire directement depuis un script, ce qui réduit fortement sa flexibilité et son niveau de programmabilité. Depuis longtemps, la communauté cherche donc des moyens d'accorder au script Bitcoin une capacité d'introspection (Introspection).
L'introspection désigne la capacité du script Bitcoin à inspecter et contraindre les données transactionnelles. Cela permet aux scripts de contrôler l'utilisation des fonds selon les détails spécifiques d'une transaction, rendant possible des fonctionnalités plus complexes. Actuellement, la plupart des opcodes Bitcoin ont uniquement deux fonctions : pousser des données fournies par l'utilisateur sur la pile, ou manipuler les données déjà présentes sur celle-ci. En revanche, un opcode d'introspection peut pousser sur la pile des informations provenant de la transaction en cours (comme l'horodatage, le montant, l'ID de transaction, etc.), offrant ainsi un contrôle plus fin sur la manière dont un UTXO est dépensé.
Actuellement, seuls trois opcodes principaux dans le script Bitcoin supportent l'introspection : CHECKLOCKTIMEVERIFY, CHECKSEQUENCEVERIFY et CHECKSIG — ce dernier ayant plusieurs variantes telles que CHECKSIGVERIFY, CHECKSIGADD, CHECKMULTISIG et CHECKMULTISIGVERIFY.
Un covenant (contrat) est, en termes simples, une restriction sur la manière dont un jeton peut être transféré. Les utilisateurs peuvent ainsi spécifier comment un UTXO doit être distribué. De nombreux covenants s'appuient sur des opcodes d'introspection, et aujourd'hui, Bitcoin Optech classe l'introspection sous la rubrique des covenants.
Bitcoin dispose actuellement de deux covenants : CSV (CheckSequenceVerify) et CLTV (CheckLockTimeVerify), tous deux étant des covenants temporels. Ils constituent la base de nombreuses solutions de mise à l'échelle, telles que le réseau Lightning. On peut donc constater que les solutions de scaling de Bitcoin dépendent largement de l'introspection et des covenants.
Comment ajouter des conditions aux transferts de jetons ? Dans le monde cryptographique, la méthode la plus courante consiste à utiliser un engagement (commitment), généralement réalisé via un hachage (hash). Pour prouver que nous respectons les conditions de transfert, nous utilisons ensuite un mécanisme de signature. Par conséquent, les covenants impliquent souvent des ajustements liés aux hachages et aux signatures.
Nous allons maintenant décrire certaines propositions d'opcodes pour covenants largement discutées.
CTV (CheckTemplateVerify) BIP-119
CTV (CheckTemplateVerify) est une mise à jour très débattue au sein de la communauté Bitcoin, incluse dans le BIP-119. CTV permet à un script de sortie de spécifier un « modèle » pour la transaction de dépense future de ces fonds. Ce modèle inclut des champs tels que nVersion, nLockTime, hash de scriptSig, nombre d'entrées, hash des séquences, nombre de sorties, hash des sorties et index d'entrée. Ces restrictions sont mises en œuvre via un engagement de hachage. Lors d'un futur dépense, le script vérifie que les valeurs de hachage des champs spécifiés dans la transaction de dépense correspondent au hachage présent dans le script d'entrée. En pratique, ce modèle fixe précisément les détails du dépense futur de cet UTXO : moment, méthode et montant.
Il est important de noter que l'ID de transaction (TXID) d'entrée est exclu de l'engagement de hachage. Cette exclusion est nécessaire : que ce soit dans les transactions Legacy ou Segwit, avec le type de signature par défaut SIGHASH_ALL, le TXID dépend de la valeur de scriptPubKey. Inclure le TXID créerait donc une boucle circulaire empêchant la construction réussie du hachage.
CTV réalise l'introspection en utilisant un nouvel opcode pour récupérer directement certaines informations de la transaction, les hacher, puis comparer le résultat au hachage engagé sur la pile. Cette méthode consomme peu d'espace sur la chaîne, mais manque de flexibilité.
Les solutions de deuxième couche Bitcoin, comme le réseau Lightning, reposent sur des transactions pré-signées. Une pré-signature consiste à générer et signer une transaction à l'avance, sans pour autant la diffuser immédiatement sur le réseau, jusqu'à ce que certaines conditions soient remplies. En essence, CTV implémente une forme plus stricte de pré-signature : l'engagement est publié directement sur la chaîne, et la transaction ne peut avoir lieu que selon le modèle prédéfini.
CTV a été initialement proposé pour atténuer la congestion sur Bitcoin, aussi appelé contrôle de congestion. Lorsque le réseau est saturé, CTV permet d'engager plusieurs futures transactions via une seule transaction, évitant ainsi de diffuser plusieurs transactions en pleine congestion. Les transactions réelles peuvent ensuite être finalisées lorsque la congestion diminue. Ce contrôle de congestion pourrait s'avérer utile lors d'une ruée massive sur une bourse. De plus, les modèles peuvent servir à implémenter des coffres-forts (vaults), protégeant contre les piratages. Puisque la destination des fonds est fixée, un pirate ne peut pas rediriger un UTXO verrouillé par un script CTV vers son propre adresse.
CTV peut considérablement améliorer les réseaux de deuxième couche. Par exemple, pour implémenter des Timeout Trees ou des usines de canaux (channel factories) dans le réseau Lightning, un seul UTXO peut se déployer en un arbre CTV, permettant d'ouvrir plusieurs canaux d'état simultanément, tout en n'exigeant qu'une seule transaction et une seule confirmation sur la chaîne. De plus, CTV soutient également les transactions atomiques ATLC dans le protocole Ark.
APO (SIGHASH_ANYPREVOUT) BIP-118
Le BIP-118 propose un nouveau drapeau de hachage de signature pour Tapscript, permettant une logique de dépense plus flexible : SIGHASH_ANYPREVOUT. APO partage de nombreux points communs avec CTV. Face au problème de circularité entre scriptPubKeys et TXID, la solution d'APO consiste à exclure les informations relatives aux entrées, en signant uniquement les sorties, permettant ainsi à la transaction de s'attacher dynamiquement à différents UTXOs.
Du point de vue logique, l'opération de vérification de signature OP_CHECKSIG (et ses opcodes similaires) remplit trois fonctions :
-
Assembler différentes parties de la transaction de dépense
-
Calculer leur hachage
-
Vérifier que ce hachage a bien été signé par la clé donnée
Le contenu exact de la signature offre une grande souplesse. Quels champs de transaction assembler avant la signature est déterminé par les drapeaux SIGHASH. Selon la définition du BIP 342, les drapeaux incluent SIGHASH_ALL, SIGHASH_NONE, SIGHASH_SINGLE et SIGHASH_ANYONECANPAY. Parmi ceux-ci, SIGHASH_ANYONECANPAY contrôle les entrées, tandis que les autres concernent les sorties.
SIGHASH_ALL est le drapeau par défaut, signant toutes les sorties ; SIGHASH_NONE ne signe aucune sortie ; SIGHASH_SINGLE signe uniquement une sortie spécifique. SIGHASH_ANYONECANPAY peut être combiné avec les trois premiers : s'il est activé, seul l'entrée spécifiée est signée, sinon toutes les entrées doivent être signées.
Manifestement, aucun de ces drapeaux ne supprime complètement l'impact des entrées — même SIGHASH_ANYONECANPAY exige un engagement sur au moins une entrée.
C'est pourquoi le BIP 118 introduit SIGHASH_ANYPREVOUT. Une signature APO n'a pas besoin d'engager l'UTXO d'entrée (appelé PREVOUT), mais signe uniquement les sorties, offrant ainsi une plus grande flexibilité au contrôle des fonds Bitcoin. En construisant à l'avance une transaction accompagnée d'une signature à usage unique et d'une clé publique correspondante, tout actif envoyé à cette adresse devra être dépensé via cette transaction pré-construite, réalisant ainsi un covenant. La flexibilité d'APO peut aussi servir à corriger des transactions bloquées : si une transaction reste coincée en raison de frais trop bas, il est facile d'en créer une autre avec des frais plus élevés, sans nécessiter de nouvelle signature. Pour les portefeuilles multisignatures, le fait que la signature ne dépende pas de l'entrée à dépenser simplifie grandement les opérations.
En éliminant la circularité entre scriptPubKeys et TXID d'entrée, APO peut réaliser l'introspection en ajoutant des données de sortie dans le witness. Toutefois, cela implique une consommation supplémentaire d'espace dans le witness.
Pour des protocoles hors chaîne comme le réseau Lightning ou les coffres-forts, APO réduit significativement le nombre d'états intermédiaires à conserver, diminuant ainsi la complexité et les besoins de stockage. Son cas d'usage le plus direct est Eltoo, qui simplifie les usines de canaux, permet de construire des tours de surveillance (watchtowers) légères et économiques, et autorise des sorties unilatérales sans laisser d'états erronés, améliorant globalement les performances du réseau Lightning. APO peut aussi simuler la fonctionnalité de CTV, mais cela exige de stocker personnellement les signatures et transactions pré-signées, ce qui est plus coûteux et moins efficace que CTV.
Les critiques d'APO portent principalement sur le besoin d'une version de clé entièrement nouvelle, impossible à réaliser par simple compatibilité descendante. De plus, un nouveau type de hachage de signature pourrait poser des risques potentiels de double dépense. Après de vastes discussions communautaires, APO a été modifié pour exiger une signature standard en plus, atténuant les problèmes de sécurité, ce qui lui a permis d'obtenir le numéro BIP-118.
OP_VAULT BIP-345
Le BIP-345 propose deux nouveaux opcodes : OP_VAULT et OP_VAULT_RECOVER. Combinés avec CTV, ils permettent de créer un covenant spécialisé, imposant un délai obligatoire avant le dépense de certains jetons, avec possibilité de « révoquer » ce dépense durant la période de délai via un chemin de récupération.
Un utilisateur peut créer une adresse Taproot spécifique pour construire un coffre-fort. Le MAST doit contenir au moins deux scripts : un script OP_VAULT pour permettre un retrait planifié, et un script OP_VAULT_RECOVER pour garantir la récupération des fonds à tout moment avant la finalisation du retrait.
Comment OP_VAULT permet-il un retrait avec verrouillage temporel interrompable ? En résumé, OP_VAULT effectue ceci : remplacer le script OP_VAULT dépensé par un script spécifié, mettant ainsi à jour un seul nœud feuille du MAST, les autres restant inchangés. Similaire au design TLUV, sauf qu'OP_VAULT ne permet pas de mettre à jour la clé interne.
En introduisant un modèle durant la mise à jour du script, on peut limiter les paiements possibles. Le paramètre de verrouillage temporel est défini par OP_VAULT, tandis que l'opcode CTV limite, via son modèle, l'ensemble des sorties accessibles par ce chemin de script.
BIP-345 est né pour les coffres-forts. Grâce à OP_VAULT et OP_VAULT_RECOVER, les utilisateurs disposent d'un mécanisme de garde sécurisé : une clé très sûre (portefeuille papier, multisignature distribuée) sert de chemin de récupération, tandis que les paiements quotidiens bénéficient d'un délai de dépense. Un dispositif surveille continuellement les tentatives de retrait du coffre ; en cas de transfert non autorisé, l'utilisateur peut intervenir pour récupérer les fonds.
Lors de l'implémentation de BIP-345, la question des frais, notamment pour la transaction de récupération, doit être prise en compte. Des solutions envisageables incluent CPFP, des ancres temporaires, ou de nouveaux drapeaux de hachage de signature comme SIGHASH_GROUP.
TLUV (TapleafUpdateVerify)
La proposition TLUV s'appuie sur Taproot pour résoudre efficacement le problème de sortie d'un UTXO partagé. Son principe directeur est que, lorsqu'un output Taproot est dépensé, on peut, grâce à des étapes de mise à jour décrites par le script TLUV et aux transformations cryptographiques internes de l'adresse Taproot, mettre à jour partiellement la clé interne et le MAST, réalisant ainsi des fonctionnalités de covenant.
L'idée de TLUV repose sur un nouvel opcode TAPLEAF_UPDATE_VERIFY, capable de créer une nouvelle adresse Taproot basée sur l'entrée actuelle, en effectuant une ou plusieurs des opérations suivantes :
-
Mettre à jour la clé publique interne
-
Élaguer le chemin Merkle
-
Supprimer le nœud feuille actuellement exécuté
-
Ajouter un nouveau nœud feuille à la fin du chemin Merkle
Plus précisément, TLUV prend trois entrées :
-
Une indiquant comment mettre à jour la clé publique interne
-
Une spécifiant un nouveau nœud feuille pour le chemin Merkle
-
Une indiquant si le nœud feuille actuel doit être supprimé, et combien de nœuds du chemin Merkle doivent l'être
L'opcode TLUV calcule alors le scriptPubKey mis à jour, et vérifie que la sortie correspondant à l'entrée actuelle est bien envoyée vers ce scriptPubKey.
Le scénario d'inspiration de TLUV est le CoinPool (piscine de pièces commune). Aujourd'hui, on peut créer un pool commun avec des transactions pré-signées, mais pour permettre des retraits sans permission, il faudrait générer exponentiellement plus de signatures. TLUV permet des retraits sans permission sans aucune signature préalable. Par exemple, un groupe d'amis construit ensemble un UTXO partagé via Taproot, regroupant leurs fonds. Ils peuvent déplacer des fonds internement via la clé Taproot, ou payer ensemble vers l'extérieur. Chacun peut à tout moment quitter le pool, supprimant son propre chemin de paiement, tandis que les autres conservent leurs chemins initiaux. Le départ d'une personne n'expose aucune information supplémentaire sur les autres membres. Comparé aux transactions non mutualisées, cette approche est plus efficace et plus privée.
L'opcode TLUV impose des restrictions de dépense partielle en mettant à jour le MAST d'origine, mais ne permet pas l'introspection du montant des sorties. Un opcode supplémentaire IN_OUT_AMOUNT est donc nécessaire : il pousse deux données sur la pile — le montant de l'UTXO d'entrée et celui de la sortie correspondante — permettant à l'utilisateur de vérifier par des opérateurs mathématiques que les fonds sont correctement conservés dans le scriptPubKey mis à jour.
L'introspection du montant de sortie ajoute une complexité : les montants Bitcoin, exprimés en satoshis, peuvent atteindre 51 bits, mais les scripts ne gèrent que des opérations arithmétiques sur 32 bits. Il faudrait donc redéfinir le comportement des opcodes pour étendre les opérateurs, ou utiliser SIGHASH_GROUP à la place de IN_OUT_AMOUNT.
TLUV pourrait offrir une solution aux pools de fonds décentralisés pour les Layer 2, bien que la fiabilité du « tweak » de la clé publique Taproot doive encore être confirmée.
MATT
MATT (Merkleize All The Things) vise trois objectifs : Merkliser l'état, Merkliser les scripts, et Merkliser l'exécution, afin de permettre des contrats intelligents universels.
Merkleiser l'état : construire un Merkle Trie où chaque nœud feuille contient le hachage d'un état, et le Merkle Root représente l'état complet du contrat.
Merkleiser les scripts : utiliser un MAST constitué de Tapscripts, chaque nœud feuille représentant un chemin possible de transition d'état.
Merkleiser l'exécution : implémenter l'exécution via des engagements cryptographiques et un mécanisme de défi de fraude. Pour toute fonction de calcul, les participants peuvent calculer hors chaîne, publier un engagement f(x)=y, et si un participant détecte une erreur f(x)=z, il peut lancer un défi, arbitré par dichotomie — similaire au principe des Optimistic Rollups.
Défi de fraude pour l'exécution Merklisée
Pour implémenter MATT, le langage de script Bitcoin doit disposer des fonctionnalités suivantes :
-
Forcer une sortie à avoir un script spécifique (ainsi que son montant)
-
Attacher des données arbitraires à une sortie
-
Lire les données de l'entrée courante (ou d'autres entrées)
Le second point est crucial : des données dynamiques signifient que l'état peut être calculé à partir des données fournies par le dépensier, permettant ainsi de simuler une machine à états, et de déterminer l'état suivant et les données attachées. MATT propose l'opcode OP_CHECKCONTRACTVERIFY (OP_CCV), fusionnant les anciens OP_CHECKOUTPUTCONTRACTVERIFY et OP_CHECKINPUTCONTRACTVERIFY, avec un paramètre flags pour préciser l'objet de l'opération.
Contrôle du montant de sortie : la façon la plus directe serait l'introspection immédiate, mais le montant est un entier de 64 bits, nécessitant des opérations 64 bits, ce qui est très complexe dans le script Bitcoin. CCV adopte plutôt une vérification différée, similaire à OP_VAULT : tous les inputs vers la même sortie avec CCV voient leurs montants additionnés, formant une borne inférieure pour le montant de sortie. Cette vérification est différée car elle se produit pendant le traitement de la transaction, et non durant l'évaluation du script d'entrée.
Compte tenu du caractère universel des preuves de fraude, certaines variantes de covenants MATT devraient pouvoir implémenter tous types de contrats intelligents ou constructions de deuxième couche, bien que des exigences supplémentaires (comme blocage de capital et délais de défi) doivent être soigneusement évaluées. Des recherches complémentaires sont nécessaires pour déterminer quelles applications sont acceptables. Par exemple, en combinant engagements cryptographiques et mécanismes de défi, on pourrait simuler une fonction OP_ZK_VERIFY, réalisant un Rollup de confiance minimale sur Bitcoin.
En réalité, cela commence déjà. Johan Torås Halseth a utilisé l'opcode OP_CHECKCONTRACTVERIFY issu de la proposition soft fork MATT pour implémenter elftrace, permettant de valider sur la chaîne Bitcoin tout programme compilable en RISC-V, autorisant ainsi à une partie d'un contrat de retirer des fonds après validation — une passerelle avec vérification native sur Bitcoin.
CSFS (OP_CHECKSIGFROMSTACK)
D'après la description de l'opcode APO, nous savons que OP_CHECKSIG (et ses variantes) assemble la transaction, calcule son hachage, puis vérifie la signature. Toutefois, le message vérifié est toujours obtenu par la sérialisation de la transaction utilisant cet opcode, sans possibilité de spécifier un autre message. En résumé, OP_CHECKSIG (et apparentés) servent à vérifier, via un mécanisme de signature, qu'un UTXO donné est bien autorisé à être dépensé par le détenteur de la signature, assurant ainsi la sécurité de Bitcoin.
CSFS, comme son nom l'indique, vérifie une signature provenant de la pile (Stack). L'opcode CSFS prend trois arguments depuis la pile : une signature, un message et une clé publique, puis vérifie la validité de la signature. Cela permet de transmettre via le witness n'importe quel message sur la pile, et de le vérifier avec CSFS, ouvrant ainsi la voie à de nombreuses innovations sur Bitcoin.
La souplesse de CSFS permet d'implémenter divers mécanismes : signatures de paiement, délégation de permissions, contrats oracle, obligations anti-double-dépense, etc. Plus important encore, il permet l'introspection de transaction. Le principe est simple : si l'on pousse sur la pile, via le witness, le contenu de la transaction utilisé par OP_CHECKSIG, puis que l'on vérifie ce contenu avec la même clé publique et signature à la fois via CSFS et OP_CHECKSIG, et que les deux vérifications passent, alors le message passé à CSFS correspond exactement à la transaction sérialisée (et autres données) implicitement utilisée par OP_CHECKSIG. On obtient ainsi sur la pile des données transactionnelles vérifiées, sur lesquelles d'autres opcodes peuvent imposer des restrictions.
CSFS apparaît souvent avec OP_CAT, car ce dernier permet de concaténer différents champs de la transaction pour la sérialiser, facilitant une sélection plus précise des champs à introspecter. Sans OP_CAT, le script ne peut pas recalculer le hachage à partir de données individuelles vérifiables, et ne peut donc que vérifier l'égalité du hachage avec une valeur fixe, ce qui signifie que la pièce ne peut être dép
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
@ChakraChain
