Approfondir BTC: Explication des connaissances préalables nécessaires à BitVM

Auteurs : Nickqiao & Faust & Shew Wang, geek web3

Consultant: Équipe de recherche Bitlayer

Résumé :

Récemment, Delphi Digital a publié un rapport de recherche sur les technologies de deuxième couche de Bitcoin intitulé “The Dawn of Bitcoin Programmability: Paving the Way for Rollups”. Ce rapport examine de manière systématique les concepts fondamentaux liés à Bitcoin Rollup, tels que la suite complète BitVM, les opérations OP_CAT et les clauses restrictives de Covenant, la couche DA de l’écosystème Bitcoin, les ponts et les quatre grandes couches de Bitcoin utilisant BitVM, à savoir Bitlayer, Citrea, Yona et Bob.

Bien que ce rapport de recherche présente généralement une vue d’ensemble approximative de la technologie de couche 2 de Bitcoin, il est plutôt vague et manque de détails, ce qui rend les gens perplexes. Geek web3 a approfondi l’exploration sur la base du rapport Delphi, dans le but d’aider un plus grand nombre de personnes à comprendre de manière systématique des technologies telles que BitVM.

Nous collaborerons avec l’équipe de recherche Bitlayer et la communauté chinoise BitVM pour lancer une série de colonnes intitulée « Se rapprocher de BTC », qui se concentrera sur des sujets clés tels que BitVM, OP_CAT et les ponts de chaîne croisée Bitcoin. Nous nous engageons à démystifier les technologies connexes de la couche 2 de Bitcoin et à aider davantage d’amateurs à parcourir ce chemin.

Texte principal :

Il y a quelques mois, Robin Linus, le responsable de ZeroSync, a publié un article intitulé “BitVM: Compute Anything on Bitcoin”, proposant officiellement le concept de BitVM et faisant avancer les technologies de la deuxième couche de Bitcoin. On peut dire que c’est l’une des innovations les plus révolutionnaires de l’écosystème Bitcoin, qui a déclenché tout l’écosystème de la deuxième couche de Bitcoin, attirant la participation de projets stars tels que Bitlayer, Citrea, BOB, et insufflant une nouvelle vie à l’ensemble du marché.

Par la suite, un plus grand nombre de chercheurs ont participé à l’amélioration de BitVM, et ont successivement lancé différentes versions itératives telles que BitVM1, BitVM2, BitVMX, BitSNARK, etc. Voici un aperçu général de la situation :

1. Le livre blanc de l’implémentation BitVM proposée par Robin Linus l’année dernière, appelée BitVM0, repose sur un circuit logique fictif de portes et de circuits.
2. Dans ses discours et interviews ultérieurs, Robin Linus a informellement présenté le projet BitVM basé sur un CPU fictif (appelé BitVM1), similaire au système de preuve de fraude Cannon d’Optimism, qui peut simuler l’effet d’un CPU général à l’aide de scripts Bitcoin en dehors de la chaîne.
3. Robin Linus a également proposé BitVM2, un protocole de preuve de fraude d’étape unique sans permission ni interaction.
4. Les membres de Rootstock Labs et Fairgate Labs ont publié le livre blanc de BitVMX, similaire à BitVM1, dans lequel ils espèrent simuler l’effet d’un CPU universel en utilisant le script Bitcoin (hors chaîne).

La construction de l’écosystème de développement BitVM est de plus en plus claire, et l’itération et l’amélioration des outils périphériques sont également visibles à l’œil nu. Par rapport à l’année dernière, l’écosystème BitVM est maintenant devenu “vaguement visible” depuis son début comme une “tour dans le ciel”, attirant de plus en plus de développeurs et de VC dans l’écosystème Bitcoin.

Cependant, pour la plupart des gens, comprendre les termes techniques liés à BitVM et la couche 2 de Bitcoin n’est pas facile, car il faut d’abord avoir une compréhension systématique des connaissances de base qui l’entourent, en particulier le script Bitcoin et les connaissances de base de Taproot. Les références disponibles en ligne sont soit trop longues et pleines de bavardages, soit expliquées de manière insuffisante, ce qui rend difficile à comprendre. Nous nous efforçons de résoudre ces problèmes et de vous aider à comprendre les connaissances périphériques de la couche 2 de Bitcoin et à établir une compréhension systématique du système BitVM, en utilisant un langage aussi clair que possible.

MATT et Promise : La pensée fondamentale de BitVM

Tout d’abord, nous tenons à souligner que l’idée de base de BitVM est MATT, ce qui signifie Merkleize All The Things, et cela se réfère principalement à l’utilisation de la structure de stockage des données en arbre de Merkle pour représenter le processus d’exécution complexe des programmes, afin de permettre la preuve de fraude de vérification native de Bitcoin.

MATT can express a complex program and its data processing traces, but will not directly publish these data on the BTC chain, because the overall scale of these data is very large. The MATT scheme only stores data in the off-chain Merkle tree and only publishes the summary (Merkle Root) of the top of the Merkle tree on-chain. This Merkle tree mainly contains three core contents:

• Code de script de contrat intelligent
• Données requises pour le contrat
• Les traces laissées par l’exécution du contrat (les enregistrements de changement de mémoire, de registre CPU, etc. générés par l’exécution de contrats intelligents dans des machines virtuelles telles que EVM)

Dans le cadre du plan MATT, seule la Merkle Root de taille extrêmement petite est stockée hors chaîne, et l’ensemble complet des données contenues dans l’arbre de Merkle est stocké hors chaîne, ce qui nécessite une approche appelée ‘engagement’. Voici une explication de ce qu’est un ‘engagement’ (Commitment).

L’engagement s’apparente à une déclaration succincte, qui peut être comprise comme une « empreinte digitale » d’une grande quantité de données compressées. D’une manière générale, les personnes qui publient des « promesses » sur la chaîne off-chain vont prétendre que certaines données stockées off-chain sont exactes, et que ces données off-chain correspondent à une déclaration concise, appelée « engagement ».

Parfois, le hachage des données peut servir de “promesse” pour les données elles-mêmes, d’autres schémas de promesse incluent KZG ou Merkle Tree. Dans les protocoles de preuve de fraude couramment utilisés dans Layer2, le fournisseur de données publiera l’ensemble complet des données hors chaîne, et publiera la promesse des données sur la chaîne. Si quelqu’un découvre des données invalides dans l’ensemble de données hors chaîne, il contestera la promesse des données sur la chaîne.

En promettant (Commitment), la couche 2 peut compresser et traiter de grandes quantités de données, ne publiant que ses ‘promesses’ sur la chaîne Bitcoin. Bien sûr, il est également nécessaire de s’assurer que l’ensemble de données complet publié hors chaîne peut être observé par le monde extérieur.

Les principaux schémas BitVM tels que BitVM0, BitVM1, BitVM2 et BitVMX utilisent tous une structure abstraite similaire :

1. Décomposition et engagement du programme: Tout d’abord, décomposez un programme complexe en une grande quantité d’opcodes de base (compilation), puis enregistrez les traces produites lors de l’exécution concrète de ces opcodes (en d’autres termes, l’ensemble des changements d’état lorsque le programme s’exécute dans l’UC et la mémoire, appelé Trace). Ensuite, nous organisons toutes les données, y compris les traces et les opcodes, en un ensemble de données, puis générons l’engagement de cet ensemble de données.

Les schémas d’engagement spécifiques peuvent prendre des formes plus longues, telles que : arbres de Merkle, PIOP (divers algorithmes ZK), fonctions de hash

2. Stake and Pre-signing: Data publishers and validators need to lock a certain amount of assets off-chain in the form of pre-signing, and there will be limiting conditions. These conditions will be specifically triggered for potential future occurrences. If the data publisher behaves maliciously, validators can submit evidence to take away the data publisher’s assets.

3. Publication de données et d’engagements : les éditeurs de données publient des engagements sur la chaîne, tandis que les données complètes sont publiées hors chaîne. Les validateurs récupèrent les ensembles de données et vérifient s’il y a des erreurs. Chaque partie de l’ensemble de données hors chaîne est liée aux engagements sur la chaîne.

4. Défis et sanctions : Une fois qu’un validateur découvre des erreurs dans les données fournies par le fournisseur de données, il les soumettra directement à la chaîne pour validation (en les découpant en morceaux très fins au préalable), c’est la logique de la preuve de fraude. Si les résultats de la validation montrent que le fournisseur de données a effectivement fourni des données invalides en dehors de la chaîne, ses actifs seront saisis par le validateur le mettant au défi.

En résumé, le data publisher Alice publie hors chaîne toutes les traces générées lors de l’exécution des transactions de couche 2, puis publie les engagements correspondants sur la chaîne. Si vous devez prouver qu’une partie des données est erronée, commencez par prouver à un nœud Bitcoin que ces données sont liées aux engagements sur la chaîne, c’est-à-dire prouver que ces données sont publiques pour Alice, puis demandez au nœud Bitcoin de confirmer que ces données sont erronées.

Maintenant, nous comprenons globalement l’idée directrice de BitVM, et toutes les variantes de BitVM ne peuvent pas vraiment s’écarter de ce paradigme. Alors, commençons par apprendre et comprendre certaines technologies importantes utilisées dans le processus ci-dessus, en commençant par les scripts Bitcoin de base, Taproot et les pré-signatures.

Qu’est-ce que le script Bitcoin

La connaissance liée au Bitcoin est plus difficile à comprendre que celle liée à l’Éthereum. Même l’action de transfert la plus fondamentale implique une série de concepts, notamment UTXO (Sortie de Transaction Non Dépensée), script de verrouillage (également appelé PubKey) et script de déverrouillage (également appelé Sig). Commençons par expliquer ces principaux concepts.

（Un exemple de code de script Bitcoin composé d’opcodes plus bas niveau que les langages de haut niveau）

La façon dont les actifs d’Ethereum sont exprimés ressemble davantage à Alipay ou WeChat, où chaque transaction n’implique qu’un simple ajustement des soldes entre les comptes. Ce modèle est centré sur les comptes, où le solde des actifs n’est qu’un chiffre associé au nom du compte ; quant à la façon dont les actifs de Bitcoin sont exprimés, elle ressemble davantage à celle de l’or. Chaque lingot d’or (UTXO) est marqué de son propriétaire, et une transaction consiste en réalité à détruire l’ancien UTXO pour en générer un nouveau (avec un changement de propriétaire).

Le UTXO de Bitcoin contient deux champs clés :

Quantité, mesurée en unité de “Satoshi” (un milliard de Satoshi équivaut à un BTC) ;

Le script de verrouillage, également appelé “clé publique de script (PubKey)”, définit les conditions de déverrouillage de l’UTXO.

Il convient de noter que la propriété d’UTXO de Bitcoin est exprimée par un script de verrouillage. Si vous souhaitez transférer votre UTXO à Sam, vous pouvez lancer une transaction pour détruire l’un de vos UTXO et écrire les conditions de déverrouillage du nouveau UTXO comme “seul Sam peut déverrouiller”.

Par la suite, si Sam souhaite utiliser ces BTC, il doit soumettre un script de déverrouillage (Sig) dans lequel il doit présenter sa signature digitale pour prouver qu’il est bien Sam lui-même. Si le script de déverrouillage correspond au script de verrouillage mentionné ci-dessus, Sam peut alors déverrouiller les BTC et les transférer à quelqu’un d’autre.

(Le script de déverrouillage doit correspondre au script de verrouillage.)

D’un point de vue de la forme, chaque transaction sur la chaîne Bitcoin correspond à plusieurs Inputs et Outputs. Chaque Input doit déclarer l’UTXO qu’il souhaite débloquer, soumettre un script de déverrouillage, déverrouiller et détruire ledit UTXO ; les Outputs affichent les informations des nouveaux UTXO générés et rendent public le contenu du script de verrouillage.

Par exemple, dans l’entrée d’une transaction, vous prouvez que vous êtes Sam, déverrouillez plusieurs UTXO que d’autres vous ont donnés, les détruisez uniformément, puis générez plusieurs nouveaux UTXO et déclarez les laisser xxx les déverrouiller à l’avenir.

Plus précisément, dans les données d’entrée de la transaction, vous déclarez les UTXO que vous souhaitez déverrouiller et indiquez où ces UTXO sont « stockés ». Il convient de noter ici que Bitcoin et Ethereum sont complètement différents, Ethereum fournit deux comptes de compte de contrat et d’EOA compte de stocker des données, le solde d’actif est enregistré sous forme de nombre, enregistré au nom du contrat compte ou de l’EOA compte, uniformément placé dans la base de données nommée « état mondial », et le compte spécifique est modifié directement à partir de « l’état mondial » lors du transfert, ce qui est pratique pour localiser l’emplacement de stockage des données ;

Bitcoin n’a pas été conçu pour avoir un état mondial, les données d’actifs sont stockées de manière dispersée dans les blocs précédents (c’est-à-dire les données UTXO non dépensées, stockées séparément dans chaque sortie de transaction).

Si vous souhaitez débloquer une sortie non dépensée (UTXO), vous devez spécifier que les informations de cette UTXO se trouvent dans la sortie d’une transaction passée, en présentant l’identifiant de cette transaction (son hachage) pour permettre aux nœuds Bitcoin de chercher dans l’historique. Pour consulter le solde Bitcoin d’une adresse spécifique, il faut parcourir tous les blocs depuis le début et trouver les UTXO non dépensées associées à l’adresse xx.

Lorsque vous utilisez un portefeuille Bitcoin habituellement, vous pouvez vérifier rapidement le solde de Bitcoin détenu par une adresse. C’est souvent parce que le service de portefeuille a lui-même indexé toutes les adresses en scannant les blocs, ce qui nous permet de faire des recherches rapides.

Lorsque vous créez une transaction qui envoie vos UTXO à quelqu’un d’autre, vous devez marquer la position de ces UTXO dans l’historique des transactions Bitcoin en fonction du hachage/ID de transaction auquel ils appartiennent.

Il est intéressant de noter que le résultat des transactions Bitcoin est calculé hors chaîne. Lorsque l’utilisateur génère une transaction sur son appareil local, il doit créer directement toutes les entrées et sorties, ce qui revient à calculer le résultat de la transaction. La transaction est diffusée dans le réseau Bitcoin, validée par les nœuds et finalement inscrite dans la chaîne. Ce modèle de « calcul hors chaîne - validation sur chaîne » est totalement différent de celui d’Ethereum, où vous devez simplement fournir les paramètres d’entrée de la transaction et où le résultat de la transaction est calculé et sorti par les nœuds d’Ethereum.

De plus, le script de verrouillage (Locking) de l’UTXO peut être personnalisé, vous pouvez définir l’UTXO comme “déverrouillable par le propriétaire d’une certaine adresse Bitcoin”, et le propriétaire de cette adresse doit fournir une signature numérique et une clé publique (P2PKH). Dans le type de transaction Pay-to-Hash (P2SH), vous pouvez ajouter un hachage dans le script de verrouillage de l’UTXO. Celui qui peut soumettre le pré-image de ce hachage et satisfaire les conditions prédéfinies dans cette pré-image peut déverrouiller l’UTXO. Le script Taproot sur lequel BitVM est basé utilise des fonctionnalités similaires à P2SH.

Comment déclencher un script Bitcoin

Ici, nous allons d’abord prendre l’exemple de P2PKH pour expliquer le mode de déclenchement du script Bitcoin. Il n’est qu’en comprenant ce mode de déclenchement que l’on peut comprendre des mécanismes plus complexes tels que Taproot et BitVM. P2PKH est l’abréviation de “Pay to Public Key Hash”. Dans ce schéma, le script de verrouillage de l’UTXO contient un hachage de clé publique, et pour le déverrouiller, il faut soumettre la clé publique correspondante à ce hachage, ce qui est fondamentalement similaire à l’approche classique de transfert de Bitcoin.

À ce stade, le nœud Bitcoin doit vérifier que la clé publique dans le script de déverrouillage correspond au hachage de la clé publique spécifié dans le script de verrouillage, c’est-à-dire vérifier que la “clé” soumise par la personne qui déverrouille correspond à la “serrure” prédéfinie de l’UTXO.

En outre, dans le schéma P2PKH, lorsqu’un nœud Bitcoin reçoit une transaction, il concatène le script de déverrouillage Sig fourni par l’utilisateur avec le script de verrouillage Pubkey de l’UTXO à déverrouiller, puis l’exécute dans l’environnement d’exécution du script BTC. Le résultat de la concaténation avant l’exécution est présenté dans le diagramme ci-dessous:

Les lecteurs peuvent ne pas être familiers avec l’environnement d’exécution de script BTC, nous allons donc faire une brève introduction ici. Tout d’abord, le script BTC comprend deux éléments :

Données et codes d’opération. Ces données et codes d’opération sont empilés dans l’ordre de gauche à droite, exécutés selon une logique spécifiée et donnent un résultat final (la définition de la pile n’est pas développée ici, le lecteur peut se référer à ChatGPT).

Dans l’exemple ci-dessus, à gauche se trouve le script de déverrouillage Sig téléchargé par quelqu’un, qui comprend sa signature numérique et sa clé publique, tandis qu’à droite se trouve le script de verrouillage Pubkey, qui contient un code opérationnel et des données définis par le créateur de l’UTXO lors de la création de l’UTXO (nous n’avons pas besoin de comprendre la signification de chaque code opérationnel, une compréhension générale suffit).

Les opérations DUP, HASH160, EQUALVERIFY, etc. dans le script de verrouillage à droite de la figure sont responsables de prendre le hash de la clé publique portée dans le script de déverrouillage à gauche, de le comparer au hash de la clé publique prédéfini dans le script de verrouillage, et si les deux sont égaux, cela signifie que la clé publique transmise dans le script de déverrouillage correspond au hash de la clé publique prédéfini dans le script de verrouillage, ce qui passe la première vérification.

Cependant, il y a un problème, le contenu du script de verrouillage UTXO est en fait publié off-chain, tout le monde peut observer le hachage de la clé publique qu’il contient, n’importe qui peut télécharger la clé publique correspondante, prétendant être la personne “désignée”. Par conséquent, après avoir vérifié la clé publique et le hachage de la clé publique, il est nécessaire de vérifier si l’expéditeur de la transaction est réellement le contrôleur réel de cette clé publique, ce qui nécessite une vérification de la signature numérique. L’opération CHECKSIG dans le script de verrouillage est responsable de la vérification de la signature numérique.

Pour résumer, dans le cadre du schéma P2PKH, le script de déverrouillage soumis par l’expéditeur de la transaction contient une clé publique et une signature digitale. Cette clé publique doit correspondre au hachage de la clé publique spécifiée dans le script de verrouillage, et la signature digitale de la transaction doit être correcte pour que ces conditions soient remplies et que l’UTXO soit déverrouillé avec succès.

(Cette image est dynamique: schéma de script de déverrouillage Bitcoin sous le schéma P2PKH)

Source: ** )

Bien sûr, le réseau Bitcoin prend en charge plusieurs types de transactions, non seulement Pay to public key/public key hash, mais aussi P2SH (Pay to hash), tout dépend de la façon dont le script de verrouillage personnalisé lors de la création de l’UTXO est configuré.

Il convient de noter ici que, dans le cadre du schéma P2SH, un hachage peut être prédéfini dans le script de verrouillage, et le script de déverrouillage doit soumettre intégralement le contenu du script correspondant au hachage. Les nœuds Bitcoin peuvent exécuter ce script, et s’il définit une logique de vérification de plusieurs signatures, il peut réaliser l’effet d’un portefeuille à signatures multiples sur la chaîne Bitcoin.

Bien sûr, dans le cadre du schéma P2SH, le créateur de l’UTXO doit informer à l’avance la personne qui déverrouillera l’UTXO du contenu du script correspondant au hash. Tant que les deux parties connaissent ce contenu, nous pouvons mettre en œuvre une logique métier plus complexe que la multi-signature.

Il convient de noter ici que la chaîne Bitcoin (bloc) ne consigne pas directement les UTXO et les adresses associées. Elle enregistre uniquement les UTXO qui peuvent être déverrouillés par le hachage de clé publique/script, mais nous pouvons calculer rapidement l’adresse correspondante (la partie apparaissant comme du texte illisible sur l’interface du portefeuille) en fonction du hachage de clé publique/script.

La raison pour laquelle nous pouvons voir sur l’interface du navigateur de blocs et du portefeuille que l’adresse xx contient une quantité de bitcoins xx est que le navigateur de blocs et les développeurs du portefeuille ont analysé ces données pour vous. Ils scannent tous les blocs et calculent les « adresses » correspondantes en fonction du hash/clé publique déclaré dans le script de verrouillage, puis affichent combien de bitcoins sont détenus par l’adresse xx.

SegWit et Witness

Une fois que nous avons compris l’idée du P2SH, nous nous rapprochons encore plus du Taproot sur lequel repose BitVM. Mais avant cela, nous devons comprendre un concept important : le témoin et SegWit.

En revisitant les scripts de déverrouillage et de verrouillage mentionnés précédemment, ainsi que le processus de déverrouillage UTXO, on constate un problème : la signature numérique de la transaction est incluse dans le script de déverrouillage, et lors de la génération de la signature, il est impossible de couvrir le script de déverrouillage (les paramètres utilisés pour générer la signature ne peuvent pas inclure la signature elle-même). Par conséquent, la signature numérique ne peut couvrir que la partie en dehors du script de déverrouillage, c’est-à-dire qu’elle ne peut être associée qu’à la partie principale des données de la transaction, sans pouvoir couvrir intégralement les données de la transaction.

Ainsi, même si le script de déverrouillage de la transaction est manipulé par un intermédiaire, cela n’affectera pas le résultat de la vérification. Par exemple, un nœud Bitcoin ou un pool de minage peut insérer d’autres données dans le script de déverrouillage de la transaction, ce qui entraînera des changements mineurs dans les données de la transaction sans affecter la vérification et les résultats de la transaction, et finalement le hachage de la transaction/l’ID de la transaction calculé sera également modifié. Cela est appelé le problème d’extensibilité des transactions.

Le désavantage est que si vous prévoyez d’effectuer plusieurs transactions consécutives avec une dépendance d’ordre (par exemple, la transaction 3 fait référence à la sortie de la transaction 2, la transaction 2 fait référence à la sortie de la transaction 1), alors la transaction en fin de liste doit nécessairement faire référence à l’ID (hash) de la transaction précédente. La piscine minière, le nœud Bitcoin ou tout autre intermédiaire peut ajuster le contenu du script de déverrouillage pour que le hash de la transaction après la mise en chaîne ne corresponde pas à ce que vous attendiez, ce qui rendra inutilisables les transactions multiples que vous avez créées en prévision de la dépendance d’ordre.

En fait, dans les solutions DLC Bridge et BitVM2, des transactions avec des relations de séquence sont construites en lots, donc le scénario mentionné précédemment n’est pas rare.

En termes simples, le problème de scalabilité des transactions est dû au fait que l’ID/hash de la transaction inclut les données du script de déverrouillage lors du calcul, et les intermédiaires tels que les nœuds Bitcoin peuvent ajuster subtilement le contenu du script de déverrouillage, ce qui entraîne une incohérence entre l’ID de transaction et les attentes de l’utilisateur. En réalité, il s’agit d’un fardeau historique laissé par une conception insuffisamment réfléchie de Bitcoin à ses débuts.

La mise à niveau SegWit qui a été introduite plus tard consiste en fait à découpler complètement l’ID de transaction et le script de déverrouillage, de sorte qu’il n’est pas nécessaire d’inclure les données du script de déverrouillage lors du calcul du hachage de transaction. Les scripts de verrouillage UTXO conformes à la mise à niveau SegWit auront par défaut un opérateur appelé “OP_0” en première position, agissant comme un marqueur ; et les scripts de déverrouillage correspondants, autrefois nommés Sig, sont maintenant appelés Witness (témoins).

Après avoir suivi les règles de SegWit, les problèmes de scalabilité des transactions seront résolus de manière adéquate, vous n’avez pas à craindre que les données de transaction envoyées aux nœuds Bitcoin soient modifiées. Bien sûr, nous n’avons pas besoin de compliquer les choses, les fonctionnalités de P2WSH n’ont aucune différence fondamentale par rapport à celles de P2SH mentionnées précédemment. Vous pouvez prédéfinir un hash de script dans le script de verrouillage UTXO, puis le soumetteur du script de déverrouillage soumet le contenu du script correspondant au hash sur la chaîne et l’exécute.

Mais si vous devez mettre en œuvre un contenu de script particulièrement volumineux, contenant beaucoup de code, il est impossible de soumettre le script complet à la chaîne Bitcoin de manière conventionnelle (chaque bloc a une limite de taille). Que faire ? Cela nécessite l’utilisation de Taproot, qui simplifie le contenu du script destiné à être intégré à la chaîne, et BitVM est précisément une solution complexe construite sur Taproot.