À la découverte des solutions d'extension de l'écosystème BTC : BitVM, l'art de l'eau-forte
TechFlow SélectionTechFlow Sélection
À la découverte des solutions d'extension de l'écosystème BTC : BitVM, l'art de l'eau-forte
Les contrats intelligents sur le réseau Bitcoin sont réalisés principalement grâce à des scripts intégrés dans les transactions, qui définissent des conditions prédéfinies que doivent remplir les utilisateurs pour débloquer et dépenser des fonds. Contrairement à des plateformes comme Ethereum où les contrats intelligents sont exécutés via une machine virtuelle puissante, Bitcoin utilise un langage de script simple, non Turing-complet, appelé Script, conçu spécifiquement pour garantir la sécurité et limiter les risques d'exécution infinie ou de vulnérabilités. Grâce à des fonctionnalités telles que Segregated Witness (SegWit) et Taproot (notamment avec Schnorr signatures et Merkleized Abstract Syntax Trees - MAST), Bitcoin a étendu ses capacités de contrat intelligent. Par exemple, Taproot permet de regrouper plusieurs conditions contractuelles en une seule clé publique, rendant les transactions plus efficaces, privées et flexibles. Cela permet d'implémenter des scénarios complexes comme les multisignatures, les contrats d'échange atomique (atomic swaps), ou encore des délais conditionnels, tout en apparaissant comme une transaction standard aux yeux du réseau. De plus, des protocoles de couche 2 comme Lightning Network exploitent ces mécanismes pour offrir des contrats intelligents hautement performants, destinés aux paiements instantanés et aux échanges conditionnels hors chaîne. Ainsi, bien que Bitcoin ne supporte pas les contrats intelligents généralisés, il permet néanmoins l'exécution sécurisée de logiques conditionnelles préprogrammées au sein de son modèle de transaction UTXO.
Dédié à des analyses Web3 approfondiesRédaction : Simon Shieh
Retour sur l’introduction
Dans le précédent article intitulé « Panorama des solutions de mise à l’échelle de l’écosystème BTC : où vont les inscriptions ? », nous avons discuté des principes techniques des écosystèmes populaires d’inscriptions ainsi que des problèmes de sécurité potentiels, tout en mentionnant la possibilité de réaliser des contrats intelligents via des inscriptions récursives. Toutefois, en raison des restrictions imposées par Luke sur les scripts Taproot, les inscriptions récursives semblent rencontrer certains obstacles. Existe-t-il alors d'autres voies possibles pour implémenter des contrats intelligents sur le réseau Bitcoin ?
Le 9 octobre 2023, Robin Linus, cofondateur de la société de développement blockchain ZeroSync, a publié un article intitulé « BitVM : Calculer n'importe quoi sur Bitcoin (BitVM: Compute Anything on Bitcoin) ». Ce document présente un projet visant à introduire des contrats intelligents sur la blockchain Bitcoin.
Ce document propose une idée très intéressante : utiliser Taproot pour effectuer presque tous les calculs arbitraires, et employer ces calculs afin de valider des événements survenus hors chaîne sur Bitcoin. L’astuce consiste à placer toute la logique hors chaîne, puis à contester les résultats inexactes directement sur chaîne en réalisant seulement quelques étapes de calcul.
Autrement dit, il s’agit de placer une logique de vérification (« Verifier ») au sein du réseau Bitcoin, en exploitant la sécurité robuste du consensus de Bitcoin pour en faire une tierce partie de confiance fiable pour toute couche de calcul Turing-complète, puis d’appliquer le principe des Optimistic Rollups afin de valider les résultats de calcul hors chaîne.
Mais comment concrètement intégrer une telle logique de vérification dans le réseau Bitcoin ? Pour faire écho à la section précédente sur « l’inscription », j’aime appeler cela la technique « d’incision » de circuits logiques sur le réseau Bitcoin.
Circuits de portes logiques
À l’intérieur de votre ordinateur ou de votre téléphone portable, le courant transmet une série de 1 et de 0 pour activer toutes les fonctions informatiques. Cela se fait grâce à des millions de minuscules composants appelés portes logiques (« logic gates »), qui constituent les éléments fondamentaux des puces informatiques.
Chaque porte logique reçoit une ou deux informations binaires (bits), chacune étant soit 1, soit 0. Ensuite, selon des règles prédéfinies, la porte exécute une opération logique simple comme « ET (AND) », « OU (OR) » ou « NON (NOT) ». Le résultat produit est également un bit, soit 1, soit 0, puis est transmis à la porte logique suivante.
Ce système basé sur des opérations logiques simples offre une révélation importante : même les calculs et fonctions les plus complexes peuvent être réalisés par combinaison massive d’opérations logiques élémentaires. Cette composition et collaboration entre portes logiques constitue la base permettant aux ordinateurs modernes et aux appareils électroniques d’exécuter des tâches complexes. Grâce à ces opérations logiques fondamentales, les ordinateurs peuvent traiter des calculs arithmétiques avancés, stocker des données, rendre des images, etc.
L'image ci-dessous montre une porte logique particulière appelée « porte NON-ET (NAND gate) ». Elle peut construire n’importe quel type de circuit logique. Bien qu’elle ne soit pas aussi efficace que des portes spécialisées, elle reste capable d’accomplir cette tâche. Les circuits logiques de BitVM sont constitués exclusivement de portes NAND.
Comment graver une porte NAND sur Bitcoin
Construire une porte NON-ET (NAND) dans le script Bitcoin existant peut être réalisé en combinant des verrous de hachage (hash locks) avec deux opcodes peu connus : OP_BOOLAND et OP_NOT.
Premièrement, un verrou de hachage peut créer un script bifurqué, dépensable de deux manières : soit en satisfaisant le verrou A, soit le verrou B. La branche A place alors 1 sur la pile, tandis que la branche B place 0.
En satisfaisant un verrou de hachage spécifique, vous « déverrouillez » un bit qui sert d’entrée à la porte NAND que nous souhaitons construire. Comme seul un chemin peut être satisfait à la fois, cette méthode permet à l’utilisateur de soumettre un seul bit à la fois.
La logique d’une porte NAND consiste à recevoir deux bits en entrée et produire un bit en sortie. Si les deux entrées valent 1, la sortie est 0 ; pour toute autre combinaison, la sortie est 1. En utilisant deux verrous de hachage, on peut soumettre ces deux entrées et vérifier si la sortie est correcte — c’est ici que OP_BOOLAND et OP_NOT entrent en jeu.
OP_BOOLAND fonctionne inversement à une porte NAND : si les deux entrées sont 1, la sortie est 1 ; pour toute autre combinaison, la sortie est 0. OP_NOT renvoie quant à lui la valeur opposée de l’entrée. En combinant ces deux opcodes, on peut prendre deux entrées sur la pile et appliquer une opération logique inversée. Enfin, OP_EQUALVERIFY combiné aux verrous de hachage permet de vérifier la sortie annoncée. Si le résultat réel de l’opération NAND diffère de la sortie déclarée par l’utilisateur, le script échouera à la validation.
Ainsi, une porte NAND est « gravée » dans le script Bitcoin, ce qui revient à forcer l’exécution virtuelle d’une porte NAND via le script Bitcoin.
Comment graver des circuits à grande échelle
Bien que l'idée d'utiliser les scripts Taproot pour graver des circuits soit fascinante, il serait déjà difficile d'implémenter un ensemble de calculs arbitraires nécessitant des milliers, voire des dizaines de milliers de portes NAND. Alors, comment couvrir des calculs complexes dans l'espace limité des scripts Taproot ?
BitVM propose une solution appelée « arbre Taproot » (Taproot Tree). Pour réaliser des processus de calcul complexes dans les scripts Bitcoin, on peut connecter en série des portes logiques afin de construire un circuit de calcul. Dans ce schéma, des verrous de hachage lient chaque porte, permettant ainsi une exécution séquentielle des opérations logiques. Par exemple, si un script de porte produit des sorties différentes C1 ou C2 selon différentes préimages de hachage (valeurs claires), la porte suivante utilise la valeur de verrou de hachage correspondante comme entrée.
Ce mécanisme implémente une sorte de sanction : si quelqu’un tente de falsifier le résultat d’une porte précédente, il ne pourra révéler que la préimage d’un autre verrou de hachage. Ce dispositif convient aux calculs interactifs entre deux utilisateurs qui s’accordent préalablement à participer à une tâche de calcul spécifique, puis décomposent ce calcul en un circuit composé uniquement de portes NAND. Ils doivent alors choisir des verrous de hachage appropriés pour chaque porte du circuit et les encoder dans l’arbre de scripts d’un UTXO verrouillé.
Ensuite, en utilisant plusieurs adresses formant une matrice d’adresses Taproot, et en employant la structure en arbre Taproot Tree, le circuit logique peut être gravé dans une série de transactions UTXO interconnectées sous forme d’arbres, aboutissant finalement à un circuit logique « similaire à un contrat » capable d’exécuter certaines tâches de calcul.
Défi de fraude
Le défi de fraude est au cœur de la technologie OP (Optimism Rollup), bien qu’il n’ait jamais été véritablement mis en œuvre à ce jour. L’idée consiste à permettre à un challenger de contester une transaction erronée avant qu’un lot (batch) de transactions ne soit soumis en bloc. Un contrat « Verifier » sur la blockchain principale examine les modifications de l’état final pour déterminer si le soumissionnaire a agi malhonnêtement, puis redistribue les fonds misés par les deux parties.
Dans BitVM, l’arbre de scripts est conçu avec deux circuits : outre le droit pour le prouveur de soumettre un résultat, il doit aussi permettre au challenger de contester cette affirmation. Cela peut être réalisé en pré-signant une série de transactions, reliées selon un processus itératif « défi → réponse → défi →… ». Si l'une des parties cesse de répondre pendant un certain temps, l'autre remporte le défi et récupère les dépôts des deux côtés.
L’image ci-dessus illustre une série de transactions pré-signées :
-
Défi : Vicky (le challenger / vérificateur) libère une préimage dans le chemin de script (préimages connues uniquement du challenger), servant de défi à la preuve ;
-
Réponse : Paul (le prouveur) exécute la porte logique correspondante et renvoie les fonds au script initial ;
Après plusieurs tours d’interrogation, toute déclaration incohérente peut être rapidement réfutée. Si le prouveur cesse de coopérer hors chaîne avec le challenger, ce dernier peut forcer la coopération sur chaîne : chaque fois que le challenger déverrouille un hash lock, les nœuds feuilles Taproot associés à chaque porte NAND dans l’UTXO du prouveur ne peuvent être dépensés que si le prouveur connaît une préimage détenue par le challenger. Le prouveur peut alors prouver, en révélant ses entrées et sorties, qu’un nœud feuille Taproot donné a été correctement exécuté. Le processus suppose que le challenger dévoile la préimage du hash correspondant à un Tapleaf pour le déverrouiller. Par recherche binaire, le challenger peut localiser l’erreur du prouveur après un nombre limité de tours (O(log n)).
Ce processus implique plusieurs tours d’interaction pour garantir un règlement correct du contrat. Le challenger peut continuer à défier le prouveur jusqu’à ce que celui-ci prouve le bon résultat de chaque porte, ou, si le prouveur ne répond pas, le challenger peut retirer les fonds après un certain délai. Idéalement, toutes les opérations ont lieu hors chaîne, avec une collaboration réussie entre les deux parties. Mais en cas de rupture de coopération, le « jeu de défi » sur chaîne garantit que le contrat sera résolu correctement.
Obstacles pratiques et problèmes de sécurité
Cette proposition implique des volumes massifs de données à traiter et à générer. L’arbre Taproot utilisé pourrait contenir des dizaines de milliards de nœuds feuilles, et le traitement des transactions pré-signées pourrait prendre plusieurs heures pour assurer un règlement précis. Chaque condition de déblocage prédéfinie pour une adresse Taproot entraîne des frais de minage, donc plus il y a d’adresses combinées, plus les coûts augmentent.
Une limitation majeure de cette solution est qu’elle ne s’applique qu’à des interactions entre deux participants : l’un agissant comme prouveur attestant de la justesse de son exécution, l’autre comme vérificateur contestant les affirmations du premier. Bien que des recherches futures pourraient permettre d’impliquer davantage de participants, aucune solution claire n’existe encore aujourd’hui.
Dans un scénario de règlement coopératif, tous les participants doivent rester en ligne, ce qui limite l’utilité pratique et la commodité du protocole.
Sur le plan de la sécurité, on identifie les risques suivants :
1. En raison des contraintes de coût, une grande partie du calcul doit nécessairement être effectuée hors chaîne, exposant ainsi aux risques de sécurité typiques des services centralisés.
2. Le stockage massif de données hors chaîne soulève des préoccupations importantes concernant la disponibilité et la sécurité des données.
3. La présence éventuelle de failles logiques dans les circuits gravés eux-mêmes constitue un autre point de risque. En raison de leur faible lisibilité, ces circuits exigent des coûts accrus en audits ou en vérifications formelles.
Metatrust a déjà assisté Uniswap dans une vérification formelle complète et possède une expérience approfondie dans l’audit de circuits ZK et la vérification formelle, pouvant ainsi assurer la sécurité du déploiement de l’écosystème BitVM.
Les deux solutions présentées précédemment sont des technologies récemment apparues. Dans le prochain article, nous présenterons une solution plus ancienne et plus « orthodoxe » : la version améliorée du réseau Lightning, appelée Taproot Assets.
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
