Approche du BTC : connaissances préalables nécessaires pour comprendre BitVM (1)
TechFlow SélectionTechFlow Sélection
Approche du BTC : connaissances préalables nécessaires pour comprendre BitVM (1)
Cet article présente les idées fondamentales du BitVM, le script de Bitcoin et la SegWit.
Dédié à des analyses Web3 approfondiesRédaction : Nickqiao, Faust, Shew Wang, Geek web3
Conseil : Équipe de recherche Bitlayer
Résumé : Récemment, Delphi Digital a publié un rapport technique intitulé « The Dawn of Bitcoin Programmability: Paving the Way for Rollups », portant sur les technologies des couches 2 de Bitcoin. Ce rapport présente systématiquement les concepts clés liés aux rollups Bitcoin, tels que la suite BitVM, OP_CAT et les clauses restrictives (Covenants), la couche de disponibilité des données (DA) dans l'écosystème Bitcoin, les ponts, ainsi que les quatre principaux projets de couche 2 basés sur BitVM — Bitlayer, Citrea, Yona et Bob.
Bien que ce rapport donne une vue d'ensemble des technologies des couches 2 de Bitcoin, son contenu reste assez général et manque de détails techniques, ce qui le rend difficile à comprendre pleinement. Geek web3 approfondit ici l'analyse au-delà du rapport Delphi, afin de permettre à davantage de personnes de comprendre de manière structurée les technologies comme BitVM.
Nous allons lancer conjointement avec l'équipe de recherche Bitlayer et la communauté chinoise BitVM une série d'articles intitulée « Approcher BTC », centrée à long terme sur des sujets clés comme BitVM, OP_CAT et les ponts inter-chaînes Bitcoin, dans le but de démystifier les technologies des couches 2 de Bitcoin et d'ouvrir la voie à plus d'enthousiastes.
Il y a quelques mois, Robin Linus, responsable de ZeroSync, a publié un article intitulé « BitVM: Compute Anything on Bitcoin », introduisant officiellement le concept de BitVM et propulsant ainsi l'avancement des technologies des couches 2 de Bitcoin. On peut considérer cette innovation comme l'une des plus révolutionnaires dans l'écosystème Bitcoin, ayant dynamisé toute la scène des couches 2 et attiré des projets phares tels que Bitlayer, Citrea et BOB, redonnant vie au marché.
Par la suite, davantage de chercheurs ont participé à l'amélioration de BitVM, lançant successivement différentes versions itératives telles que BitVM1, BitVM2, BitVMX et BitSNARK. Voici un aperçu général :
-
La première spécification publiée par Robin Linus l'année dernière, fondée sur un circuit logique fictif, est appelée BitVM0 ;
-
Dans plusieurs discours et interviews ultérieurs, Robin Linus a informellement présenté une variante de BitVM basée sur un CPU fictif (appelée BitVM1), similaire au système de preuves de fraude Cannon d’Optimism, capable de simuler hors chaîne un processeur universel via des scripts Bitcoin.
-
Robin Linus a également proposé BitVM2, un protocole de preuve de fraude non interactive en une étape, sans permission.
-
Des membres de Rootstock Labs et Fairgate Labs ont publié le livre blanc BitVMX, similaire à BitVM1, visant également à simuler hors chaîne un processeur universel à l’aide de scripts Bitcoin.
Actuellement, l’écosystème des développeurs autour de BitVM devient de plus en plus clair, et l’amélioration des outils annexes progresse visiblement. Comparé à l’année dernière, l’écosystème BitVM est passé d’une « chimère » à une réalité désormais « perceptible ». Cela attire de plus en plus de développeurs et de capital-risque vers l’écosystème Bitcoin.
Toutefois, pour la majorité des gens, comprendre BitVM et les technologies connexes des couches 2 de Bitcoin n’est pas chose aisée, car cela nécessite d’abord une compréhension systématique de connaissances fondamentales comme les scripts Bitcoin et Taproot. Les ressources disponibles en ligne sont souvent trop longues ou insuffisamment claires, laissant le lecteur dans un état de demi-compréhension. Nous nous engageons à résoudre ces problèmes, en utilisant un langage aussi clair que possible pour aider davantage de personnes à comprendre les technologies périphériques des couches 2 de Bitcoin, et à construire une connaissance systématique du système BitVM.
MATT et les engagements : les fondements de BitVM
Tout d’abord, soulignons que l’idée fondamentale de BitVM repose sur MATT, signifiant « Merkleize All The Things » (Merkle-tout). Elle consiste à utiliser une structure arborescente de type Arbre de Merkle pour représenter des processus complexes d’exécution de programmes, permettant ainsi à Bitcoin de vérifier nativement des preuves de fraude.
Bien que MATT puisse exprimer un programme complexe et ses traces de traitement de données, il ne publie pas directement ces données sur la chaîne BTC, car leur volume serait trop important. Les solutions MATT stockent les données uniquement dans un arbre de Merkle hors chaîne, ne publiant sur la chaîne que le résumé (Merkle Root) situé au sommet de l’arbre. Cet arbre contient principalement trois éléments clés :
-
Le code du script du contrat intelligent
-
Les données requises par le contrat
-
Les traces laissées lors de l'exécution du contrat (enregistrement des modifications apportées à la mémoire et aux registres du CPU durant l'exécution du contrat dans une machine virtuelle comme EVM)
(Schéma simplifié d’un arbre de Merkle, dont le Merkle Root est obtenu par hachage en plusieurs étapes des 8 fragments de données situés à la base)
Dans le cadre de MATT, seul le Merkle Root, de taille très réduite, est stocké sur la chaîne, tandis que l’intégralité du jeu de données est conservée hors chaîne, selon un principe appelé « engagement » (commitment). Expliquons maintenant ce qu’est un « engagement ».
Un engagement ressemble à une déclaration condensée, que l’on peut assimiler à l’« empreinte digitale » d’un grand ensemble de données. Généralement, celui qui publie un engagement sur la chaîne affirme que certaines données stockées hors chaîne sont exactes, et que ces données correspondent à cette déclaration simplifiée, appelée « engagement ».
Dans certains cas, le hachage des données peut servir d’engagement à ces données elles-mêmes. D'autres méthodes d'engagement existent, comme les engagements KZG ou les arbres de Merkle. Dans les protocoles de preuves de fraude utilisés par les couches 2, l'émetteur des données publie l'intégralité du jeu de données hors chaîne, tout en publiant sur la chaîne un engagement relatif à ces données. Si quelqu'un détecte des données invalides dans le jeu hors chaîne, il peut alors contester l'engagement publié sur la chaîne.
Grâce aux engagements, les couches 2 peuvent compresser de grandes quantités de données, ne publiant sur la chaîne de Bitcoin que leur « engagement ». Bien entendu, il faut garantir que l'intégralité du jeu de données hors chaîne reste accessible à l'extérieur.
Les principales variantes de BitVM, telles que BitVM0, BitVM1, BitVM2 et BitVMX, adoptent globalement une structure abstraite similaire :
1. Décomposition du programme et engagement : Le programme complexe est d'abord décomposé en un grand nombre d'opcodes élémentaires (compilation), puis les traces générées lors de l'exécution concrète de ces opcodes sont enregistrées (autrement dit, l’enregistrement complet des changements d’état pendant l’exécution d’un programme dans un CPU et une mémoire, appelé Trace). Ensuite, tous ces éléments — traces et opcodes — sont regroupés en un jeu de données unique, dont on génère un engagement.
Les schémas d'engagement peuvent prendre diverses formes : arbre de Merkle, PIOPs (divers algorithmes ZK), fonctions de hachage.
2. Mise en gage d'actifs et pré-signature : L'émetteur et le vérificateur doivent verrouiller un certain montant d'actifs sur la chaîne via une pré-signature, sous certaines conditions. Ces conditions s'activent selon des scénarios futurs prédéfinis. Si l'émetteur agit malicieusement, le vérificateur peut soumettre une preuve et récupérer les actifs de l'émetteur.
3. Publication des données et de l'engagement : L'émetteur publie l'engagement sur la chaîne et le jeu complet des données hors chaîne. Le vérificateur consulte les données hors chaîne et vérifie leur exactitude. Chaque partie des données hors chaîne est associée à l'engagement publié sur la chaîne.
4. Contestation et sanction : Dès qu’un vérificateur découvre une erreur dans les données fournies par l’émetteur, il peut extraire cette portion spécifique pour la valider directement sur la chaîne (après l’avoir divisée très finement), c’est là le cœur de la logique de preuve de fraude. Si la validation confirme que l’émetteur a fourni des données invalides hors chaîne, ses actifs sont transférés au vérificateur contestataire.
En résumé, l’émetteur Alice publie hors chaîne toutes les traces générées par l’exécution des transactions de la couche 2, tout en publiant l’engagement correspondant sur la chaîne. Pour prouver qu’une partie des données est erronée, il faut d’abord démontrer auprès d’un nœud Bitcoin que ces données sont bien liées à l’engagement sur la chaîne — autrement dit, qu’elles ont bien été publiées par Alice — puis faire confirmer par le nœud que ces données sont incorrectes.
Nous avons maintenant une bonne idée de la logique générale de BitVM. Toutes les variantes de BitVM s’inscrivent essentiellement dans ce paradigme. Passons maintenant à l’étude des technologies clés utilisées dans ce processus, en commençant par les bases : les scripts Bitcoin, Taproot et la pré-signature.
Qu'est-ce qu'un script Bitcoin ?
Les concepts liés à Bitcoin sont plus difficiles à comprendre que ceux d’Ethereum. Même une simple transaction implique plusieurs notions : UTXO (sortie de transaction non dépensée), script de verrouillage (aussi appelé ScriptPubKey) et script de déverrouillage (aussi appelé ScriptSig). Commençons par expliquer ces concepts clés.
(Exemple de code de script Bitcoin, composé d'opcodes plus bas niveau que les langages évolués)
Le modèle de gestion des actifs d’Ethereum ressemble à Alipay ou WeChat : chaque transaction consiste simplement à ajouter ou soustraire des soldes de comptes. Cette méthode, centrée sur les comptes, fait du solde un simple nombre attaché à un compte. En revanche, le modèle de Bitcoin ressemble à l’or physique : chaque lingotin (UTXO) porte la marque de son propriétaire. Une transaction revient à détruire un ancien UTXO et en créer un nouveau (avec un nouveau propriétaire).
Un UTXO Bitcoin contient deux champs clés :
-
Un montant exprimé en « satoshis » (100 millions de satoshis = 1 BTC) ;
-
Un script de verrouillage, aussi appelé « clé publique de script (ScriptPubKey) », définissant les conditions de déverrouillage de l’UTXO.
Notez que la propriété d’un UTXO Bitcoin est exprimée par son script de verrouillage. Si vous souhaitez transférer votre UTXO à Sam, vous pouvez initier une transaction détruisant votre UTXO, et créer un nouveau UTXO dont la condition de déverrouillage stipule « uniquement Sam peut le débloquer ».
Ensuite, si Sam veut utiliser ces bitcoins, il doit soumettre un script de déverrouillage (ScriptSig), incluant sa signature numérique, prouvant qu’il est bien Sam. Si le script de déverrouillage correspond au script de verrouillage, Sam peut alors débloquer les fonds et les transférer à d’autres.
(Le script de déverrouillage doit correspondre au script de verrouillage)
D’un point de vue structurel, chaque transaction sur la chaîne Bitcoin comporte plusieurs entrées (Input) et sorties (Output). Chaque Input déclare l’UTXO qu’il souhaite déverrouiller et soumet le script de déverrouillage pour le détruire. Chaque Output expose les informations du nouvel UTXO créé, en précisant publiquement le contenu de son script de verrouillage.
Par exemple, dans un Input de transaction, vous prouvez être Sam, déverrouillez plusieurs UTXOs reçus, les détruisez, puis générez de nouveaux UTXOs destinés à être débloqués plus tard par xxx.
Plus précisément, dans les données d’un Input, vous devez indiquer quels UTXOs vous souhaitez déverrouiller et préciser leur « emplacement » dans l’historique des blocs. Attention : Bitcoin diffère fondamentalement d’Ethereum. Ce dernier dispose de deux types de comptes (contrats et EOA) pour stocker des données. Les soldes sont des nombres enregistrés sous ces comptes, centralisés dans une base appelée « état mondial ». Les transactions modifient directement cet état, facilitant la localisation des données.
Bitcoin n’a pas de concept d’« état mondial ». Les données des actifs sont dispersées dans les blocs passés (les UTXOs non déverrouillés, stockés individuellement dans les Outputs des transactions).
Pour déverrouiller un UTXO, vous devez indiquer dans quelle transaction passée il figure en Output, et fournir l’ID de cette transaction (son hash), permettant au nœud Bitcoin de le retrouver dans l’historique. Pour consulter le solde d’une adresse, il faut parcourir tous les blocs depuis le début, identifiant tous les UTXOs non déverrouillés liés à cette adresse.
Lorsque vous utilisez un portefeuille Bitcoin, le solde s’affiche rapidement parce que le service du portefeuille a déjà scanné les blocs et indexé les adresses, facilitant ainsi les recherches.
(Lorsque vous créez une transaction pour transférer vos UTXOs, vous devez marquer leur emplacement dans l’historique Bitcoin à l’aide du hash/ID de la transaction d’origine)
Fait intéressant, le résultat d’une transaction Bitcoin est calculé hors chaîne. Lorsque l’utilisateur génère une transaction localement, il crée directement les Inputs et Outputs, ayant ainsi calculé le résultat final. La transaction est ensuite diffusée sur le réseau Bitcoin, validée par les nœuds avant d’être ajoutée à la chaîne. Ce modèle de « calcul hors chaîne – validation sur chaîne » contraste totalement avec Ethereum, où seuls les paramètres d’entrée sont fournis, et le résultat est calculé par les nœuds d’Ethereum.
De plus, le script de verrouillage d’un UTXO (Locking Script) peut être personnalisé. Vous pouvez définir qu’un UTXO soit déverroulable par « le propriétaire d’une adresse Bitcoin », ce dernier devant fournir sa signature numérique et sa clé publique (P2PKH). Dans le type de transaction Pay-to-Script-Hash (P2SH), vous pouvez insérer un hash de script dans le script de verrouillage : toute personne pouvant fournir le script correspondant à ce hash et satisfaisant ses conditions pourra déverrouiller l’UTXO. Le script Taproot, sur lequel repose BitVM, exploite une fonctionnalité similaire à P2SH.
Comment déclencher un script Bitcoin ?
Commençons par examiner le cas P2PKH pour illustrer le déclenchement des scripts Bitcoin. Comprendre ce mécanisme est essentiel pour appréhender Taproot et BitVM. P2PKH signifie « Pay to Public Key Hash ». Avec ce schéma, le script de verrouillage d’un UTXO contient un hash de clé publique. Pour le déverrouiller, il faut fournir la clé publique correspondante — une logique similaire aux transferts Bitcoin classiques.
À ce stade, le nœud Bitcoin doit vérifier que la clé publique du script de déverrouillage correspond bien au hash spécifié dans le script de verrouillage, c’est-à-dire que la « clé » fournie par le demandeur correspond bien au « verrou » prédéfini dans l’UTXO.
Plus précisément, dans le cas P2PKH, après avoir reçu la transaction, le nœud Bitcoin concatène le script de déverrouillage (ScriptSig) fourni par l’utilisateur avec le script de verrouillage (ScriptPubKey) de l’UTXO à débloquer, puis exécute l’ensemble dans l’environnement d’exécution du script Bitcoin. L’image ci-dessous montre le résultat de cette concaténation avant exécution :
Le lecteur peut ne pas connaître l’environnement d’exécution des scripts BTC. Voici une brève introduction : un script BTC contient deux types d’éléments :
des données et des opcodes. Ces éléments sont empilés de gauche à droite et exécutés selon une logique définie, produisant un résultat final (nous n’expliquons pas ici le fonctionnement de la pile ; le lecteur peut consulter ChatGPT pour plus de détails).
Dans l’exemple ci-dessus, à gauche figure le script de déverrouillage (ScriptSig) envoyé par une personne, contenant sa signature numérique et sa clé publique, tandis qu’à droite, le script de verrouillage (ScriptPubKey) contient des opcodes et des données définis par le créateur de l’UTXO. (Il n’est pas nécessaire de comprendre chaque opcode ; une compréhension globale suffit.)
Dans le script de verrouillage de droite, les opcodes DUP, HASH160, EQUALVERIFY calculent le haché de la clé publique du script de gauche, puis le comparent au hash de clé publique prédéfini. S’ils sont égaux, cela signifie que la clé publique fournie correspond bien au hash attendu, première étape validée.
Mais un problème subsiste : le contenu du script de verrouillage est public sur la chaîne. N’importe qui peut voir le hash de clé publique et fournir une clé correspondante, prétendant être le destinataire légitime. Après vérification de la clé, il faut encore confirmer que l’initiateur contrôle bien la clé privée associée, via la vérification de la signature. L’opcode CHECKSIG dans le script de verrouillage est justement chargé de cette vérification.
En résumé, avec P2PKH, le script de déverrouillage doit contenir une clé publique correspondant au hash attendu, et la signature numérique doit être valide. Seules ces conditions permettent de déverrouiller l’UTXO.
(Illustration animée : schéma du script de déverrouillage Bitcoin selon P2PKH)
Source : https://learnmeabitcoin.com/technical/script
Bien sûr, le réseau Bitcoin supporte plusieurs types de transactions, pas seulement P2PK/P2PKH, mais aussi P2SH (Pay to Script Hash), tout dépend de la configuration personnalisée du script de verrouillage au moment de la création de l’UTXO.
Notez que dans P2SH, le script de verrouillage peut prévoir un hash de script, et le script de déverrouillage doit fournir intégralement le script correspondant. Le nœud Bitcoin peut alors exécuter ce script. Si ce script définit une logique de validation multisignature, cela permet de réaliser un portefeuille multisig sur Bitcoin.
Bien sûr, dans P2SH, le créateur de l’UTXO doit s’assurer que le futur déverrouilleur connaît le contenu du script associé au hash. Dès lors que les deux parties connaissent ce script, des logiques métier plus complexes que le multisig peuvent être implémentées.
Précisons que la chaîne Bitcoin (blocs) n’enregistre pas directement quels UTXOs sont liés à quelles adresses. Elle indique seulement quels UTXOs peuvent être déverrouillés par quel hash de clé publique / hash de script. Toutefois, à partir d’un hash de clé publique / hash de script, on peut rapidement calculer l’adresse correspondante (cette chaîne de caractères alphanumériques affichée dans les portefeuilles).
La raison pour laquelle les explorateurs de blocs et les interfaces de portefeuille affichent le solde d’une adresse, c’est qu’ils analysent automatiquement ces données, scannent tous les blocs, et calculent les adresses correspondant aux hashes de clé publique / de script présents dans les scripts de verrouillage, affichant ainsi combien de bitcoins sont associés à chaque adresse.
SegWit et Witness
Après avoir compris P2SH, nous sommes plus proches de Taproot, sur lequel repose BitVM. Mais auparavant, abordons un concept crucial : Witness et SegWit (Segregated Witness).
En reprenant les notions de script de déverrouillage, de script de verrouillage et du processus de déverrouillage d’un UTXO, on constate un problème : la signature numérique est incluse dans le script de déverrouillage. Or, lors de la génération de la signature, le script de déverrouillage ne peut pas être inclus (un paramètre utilisé pour générer la signature ne peut pas contenir la signature elle-même). Par conséquent, la signature ne peut couvrir que les parties extérieures au script de déverrouillage, c’est-à-dire qu’elle est liée uniquement à la structure principale de la transaction, sans couvrir complètement toutes les données.
Ainsi, même si un intermédiaire modifie légèrement le script de déverrouillage, cela n’affectera pas la vérification de la signature. Par exemple, un nœud Bitcoin ou un pool de minage peut insérer d’autres données dans le script de déverrouillage, modifiant légèrement les données de transaction sans altérer la signature ni le résultat, changeant ainsi le hash/ID de la transaction. C’est le problème dit de malléabilité des transactions.
Cela pose problème lorsque vous souhaitez envoyer plusieurs transactions en séquence dépendantes les unes des autres (par exemple, la transaction 3 référence la sortie de la transaction 2, qui elle-même référence celle de la transaction 1). La transaction suivante doit référencer l’ID (hash) de la précédente. Un intermédiaire (pool de minage, nœud Bitcoin, etc.) peut modifier légèrement le script de déverrouillage, rendant le hash de transaction différent de celui attendu, invalidant ainsi vos transactions en chaîne prédéfinies.
En réalité, dans les solutions DLC Bridge et BitVM2, on construit souvent par lots des transactions en séquence dépendante, donc ce scénario est fréquent.
En bref, le problème de malléabilité vient du fait que le calcul du hash/ID de transaction inclut les données du script de déverrouillage, que des intermédiaires peuvent modifier, rendant le hash final différent de celui attendu par l’utilisateur. C’est un héritage historique dû à une conception imparfaite de Bitcoin à ses débuts.
La mise à jour SegWit (Segregated Witness) a précisément pour but de dissocier complètement le hash de transaction du script de déverrouillage. Le calcul du hash de transaction n’inclut plus les données du script de déverrouillage. Les UTXOs conformes à SegWit ont par défaut un opcode « OP_0 » en tête de leur script de verrouillage, servant de marqueur ; le script de déverrouillage est renommé « Witness » (témoin).
Avec SegWit, le problème de malléabilité est résolu : plus besoin de craindre que les données de transaction soient modifiées par un nœud Bitcoin. Inutile de trop compliquer : la fonction de P2WSH est essentiellement identique à celle de P2SH. Vous pouvez définir un hash de script dans le script de verrouillage, et demander au soumissionnaire de fournir le script correspondant pour exécution.
Mais si le script à exécuter est très volumineux, impossible à soumettre entièrement sur Bitcoin par les méthodes classiques (taille limitée par bloc). Que faire ? Il faut alors utiliser Taproot, qui permet de simplifier le contenu du script à publier sur chaîne. C’est précisément sur Taproot que BitVM construit ses schémas complexes.
Dans le prochain article de la série « Approcher BTC », nous expliquerons en détail d'autres technologies avancées liées à BitVM, comme Taproot et la pré-signature. Restez à l’écoute !
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
@godrealmx
