À ; DR

Introduction :

Cet article propose une interprétation du livre blanc de BitVM et explique l'approche de BitVM : les données n'ont pas besoin d'être intégrées à la chaîne au départ ; elles sont publiées et stockées hors chaîne, seul un engagement étant stocké sur la blockchain.

Titre original de l'article transféré : Une interprétation simplifiée de BitVM : comment vérifier les preuves de fraude sur la blockchain BTC (exécution d'EVM ou d'autres opcodes de machine virtuelle)

Préface : Actuellement, Bitcoin Layer 2 est devenu une tendance, des dizaines de projets s'identifiant comme « Bitcoin Layer 2 ». Beaucoup d'entre eux, prétendant être des « rollups », affirment qu'ils utilisent l'approche proposée dans le livre blanc BitVM, positionnant BitVM comme un élément important de l'écosystème Bitcoin.

Cependant, la plupart de la littérature existante sur BitVM n'explique pas ses principes en termes simples. Cet article, basé sur notre lecture du livre blanc de 8 pages sur BitVM et après avoir consulté des ressources relatives à Taproot, MAST trees et Bitcoin Script, propose un résumé simplifié. Pour faciliter la compréhension, nous avons modifié certaines expressions par rapport à celles que l'on trouve dans le livre blanc de BitVM, en supposant que le lecteur possède une certaine connaissance de la couche 2 et qu'il comprend le concept de base des « preuves antifraude ».

Le concept préliminaire de BitVM peut être résumé en quelques phrases : il élimine le besoin de données sur la chaîne, en publiant et en stockant initialement des données hors chaîne, seul un engagement étant stocké sur la blockchain. En cas de contestation ou de preuve de fraude, seules les données nécessaires sont intégrées à la chaîne pour démontrer leur association avec l'Engagement sur la blockchain. Ensuite, le réseau principal BTC vérifie les données de la chaîne pour détecter tout problème et vérifier si le producteur des données (le nœud qui traite les transactions) s'est livré à des activités malveillantes. Cette approche est conforme au principe d'Occam's Razor : « Les entités ne doivent pas être multipliées inutilement » (si cela peut être hors chaîne, gardez-le hors chaîne).

Texte principal : Le système de vérification antifraude de la blockchain BTC, basé sur BitVM, en termes simples :

1. Tout d'abord, un ordinateur/processeur est un système d'entrée-sortie composé d'un grand nombre de circuits de portes logiques. L'une des idées fondamentales de BitVM est d'utiliser Bitcoin Script pour simuler les effets d'entrée-sortie des circuits de portes logiques. Tant que les circuits de la porte logique peuvent être simulés, en théorie, il est possible de créer une machine de Turing qui effectuerait toutes les tâches calculables. Cela signifie que si vous disposez de suffisamment de ressources et de main-d'œuvre, vous pouvez réunir une équipe d'ingénieurs pour simuler d'abord les circuits des portes logiques à l'aide du code rudimentaire Bitcoin Script, puis utiliser un grand nombre de circuits de portes logiques pour implémenter les fonctionnalités d'EVM ou de WASM.

(Cette capture d'écran provient d'un jeu éducatif : « Turing Complete », dont le contenu principal est de créer un processeur complet, en utilisant notamment des circuits de portes logiques tels que des portes NAND.)

Certains ont comparé l'approche de BitVM qui consiste à créer un processeur M1 dans « Minecraft » à l'aide de circuits Redstone. Ou c'est comme construire l'Empire State Building à New York avec des blocs LEGO.

(On dit que quelqu'un a passé un an à créer un « processeur » dans « Minecraft ».)

1. Alors, pourquoi utiliser Bitcoin Script pour simuler l'EVM ou le WASM ? N'est-ce pas très encombrant ? La raison en est que la plupart des solutions Bitcoin Layer 2 choisissent souvent de prendre en charge des langages de haut niveau tels que Solidity ou Move, alors que le seul langage qui peut actuellement fonctionner directement sur la blockchain Bitcoin est Bitcoin Script. Ce langage est primitif, composé d'un tas d'opcodes uniques, et Turing n'est pas complet.

(Un exemple de code Bitcoin Script)

Si Bitcoin Layer 2 vise à vérifier les preuves de fraude sur la couche 1, comme les solutions de couche 2 d'Ethereum telles qu'Arbitrum, pour mieux hériter de la sécurité de BTC, elle doit vérifier directement « une transaction contestée » ou « un opcode contesté » sur la blockchain BTC. Cela signifie que les opcodes Solidity Language/EVM utilisés par la couche 2 doivent être réexécutés sur la blockchain Bitcoin. Le défi se résume à :

Utiliser Bitcoin Script, un langage de programmation natif mais rudimentaire de Bitcoin, pour obtenir les effets d'EVM ou d'autres machines virtuelles.

Du point de vue des principes de compilation, l'approche BitVM traduit les opcodes EVM/WASM/JavaScript en opcodes Bitcoin Script, les circuits de portes logiques servant de représentation intermédiaire (IR) entre les « opcodes EVM — > Bitcoin Script opcodes ».

(Le livre blanc BitVM décrit l'approche générale à suivre pour exécuter certaines « instructions contestées » sur la blockchain Bitcoin)

Quoi qu'il en soit, l'effet ultime simulé est de traiter des instructions, qui ne pouvaient à l'origine être gérées que sur EVM/WASM, directement sur la blockchain Bitcoin. Bien que cette solution soit faisable, la difficulté réside dans la manière d'utiliser un grand nombre de circuits de portes logiques comme forme intermédiaire pour exprimer tous les opcodes EVM/WASM. De plus, l'utilisation de combinaisons de circuits de portes logiques pour représenter directement des flux de traitement de transactions extrêmement complexes peut entraîner une charge de travail énorme.

1. Discutons d'un autre concept de base mentionné dans le livre blanc de BitVM, à savoir les « preuves de fraude interactives » très similaires à celles utilisées par Arbitrum.

Les preuves de fraude interactives utilisent un terme appelé assertion. Généralement, le proposant de la couche 2 (souvent interprété par un séquenceur) publie une assertion sur la couche 1, déclarant que certaines données de transaction et certains résultats de transition d'état sont valides et exempts d'erreurs.

Si quelqu'un pense que l'assertion soumise par le proposant pose problème (les données associées sont incorrectes), un litige survient. À ce stade, le proposant et le challenger échangent des informations par tours et utilisent une méthode de recherche binaire sur les données contestées afin de localiser rapidement une instruction d'opération très précise et le segment de données associé.

Pour cette instruction d'opération contestée (code OP), il faut l'exécuter directement sur la couche 1 avec ses paramètres d'entrée et valider le résultat de sortie (les nœuds de couche 1 comparent le résultat de sortie qu'ils ont calculé avec le résultat de sortie publié précédemment par le proposant). Dans Arbitrum, cela est connu sous le nom de « preuves de fraude en une seule étape ». (Dans le protocole interactif anti-fraude d'Arbitrum, la recherche binaire est utilisée pour localiser rapidement l'instruction contestée et le résultat de son exécution, puis une preuve de fraude en une seule étape est envoyée à la couche 1 pour vérification finale).

À la suite de cela :

1. Le processus est interactif, les deux parties se relaient. L'une des parties segmente les données historiques contenues dans un bloc cumulatif, et l'autre indique quel segment de données pose problème. Cela s'apparente à une méthode binaire (en réalité, il s'agit d'un processus de réduction progressive de la plage, N/K).

2. Par la suite, il est possible de mieux localiser la transaction et le résultat qui posent problème, puis de se concentrer sur une instruction automatique spécifique relative à la transaction contestée.

3. Le contrat ChallengeManager vérifie uniquement si le « segment de données » produit en subdivisant les données d'origine est valide.

4. Une fois que le challenger et le challenger ont trouvé l'instruction machine à contester, le challenger invoque OneStepProveExecution (), en envoyant une preuve de fraude en une seule étape démontrant qu'il y a un problème avec le résultat de l'exécution de cette instruction automatique.

(Dans le protocole interactif anti-fraude d'Arbitrum, le processus consiste à utiliser une recherche binaire pour localiser rapidement l'instruction contestée et le résultat de son exécution à partir des données publiées par le proposant. Après avoir identifié la donnée ou l'opcode litigieux, une preuve de fraude en une seule étape est envoyée à la couche 1 pour vérification finale.)

Références :

L'ancien ambassadeur technique d'Arbitrum explique la structure des composants d'Arbitrum (première partie)

(L'organigramme interactif anti-fraude d'Arbitrum, l'explication est relativement approximative)

À ce stade, le concept des preuves de fraude en une seule étape devient assez simple : la grande majorité des instructions de transaction qui apparaissent sur la couche 2 n'ont pas besoin d'être revérifiées sur la blockchain BTC. Cependant, si un segment de données/un opcode contesté en particulier est contesté, il doit être rejoué en couche 1.

Si le résultat de la vérification indique que les données publiées précédemment par le proposant posent problème, les actifs mis en jeu du proposant sont réduits. S'il est établi que le Challenger est fautif, ses actifs mis en jeu sont réduits. Les testeurs qui ne répondent pas aux défis en temps voulu peuvent également être réduits.

Arbitrum met en œuvre les effets susmentionnés par le biais de contrats sur Ethereum, tandis que BitVM vise à obtenir des fonctionnalités similaires en utilisant Bitcoin Script pour implémenter les blocages temporels, le multisig et d'autres fonctionnalités.

4. Après avoir discuté des « preuves de fraude interactives » et des « preuves de fraude en une seule étape », nous parlerons des arbres MAST et des preuves Merkle. Nous avons déjà mentionné que dans la solution BitVM, la grande quantité de données de transaction et de circuits de portes logiques traités hors chaîne au niveau de la couche 2 ne sont pas directement intégrés à la chaîne. Seule une quantité minimale de circuits de données et de portes logiques est mise en chaîne lorsque cela est nécessaire. Cependant, nous avons besoin d'un moyen de prouver que ces données, qui étaient initialement hors chaîne et doivent maintenant être intégrées à la chaîne, ne sont pas fabriquées de toutes pièces. C'est là que le concept d'engagement entre en jeu en matière de cryptographie, et Merkle Proof en est l'une des formes.

Tout d'abord, parlons des arbres MAST. Le nom complet de MAST est Merkelized Abstract Syntax Trees, qui est une transformation des AST (arbres syntaxiques abstraits), qui sont passés du domaine des principes des compilateurs à des arbres de Merkle. Alors, qu'est-ce qu'un AST ? En termes simples, il s'agit d'une structure de données arborescente qui décompose une commande complexe en un ensemble d'unités opérationnelles de base grâce à une analyse lexicale.

(Un exemple d'arbre AST serait de décomposer des calculs simples tels que « x=2, y=x*3 » en codes d'opération et en données sous-jacents. )

L'arbre MAST est donc le résultat de l'application de la merkleisation à un arbre AST, en soutien à Merkle Proofs. L'un des avantages des arbres de Merkle est leur capacité à « compresser » les données de manière efficace. Par exemple, si vous souhaitez publier un segment de données de l'arbre de Merkle sur la blockchain BTC si nécessaire, tout en faisant croire que ce segment de données existe réellement dans l'arbre de Merkle et qu'il n'a pas été choisi arbitrairement, que faites-vous ?

Il vous suffit d'enregistrer à l'avance la racine de l'arbre Merkle sur la blockchain. À l'avenir, il suffira de présenter une preuve Merkle prouvant l'existence d'une donnée correspondant à la racine de l'arbre Merkle.

(La relation entre Merkle Proof/Branch et Root)

Il n'est donc pas nécessaire de stocker l'arbre MAST complet sur la blockchain BTC ; il suffit d'indiquer sa racine à l'avance en tant qu'engagement. Si nécessaire, la présentation du segment de données + Merkle Proof/Branch est suffisante. Cela réduit considérablement la quantité de données en chaîne tout en garantissant leur véritable existence dans l'arborescence MAST. De plus, le fait de ne divulguer qu'une petite partie des segments de données + Merkle Proof sur la blockchain BTC, au lieu de la totalité des données, peut améliorer de manière significative la protection de la vie privée.

Références :Retenue de données et protection contre les fraudes : pourquoi Plasma ne prend pas en charge les contrats intelligents

(Exemple d'arbre MAST)

Dans la solution de BitVM, tous les circuits des portes logiques sont exprimés à l'aide de scripts Bitcoin, organisés selon un énorme arbre MAST. Les feuilles inférieures de cet arbre, indiquées comme Contenu dans le schéma, correspondent aux circuits de porte logique implémentés dans le script Bitcoin. Layer 2 Proposer publie fréquemment la racine de l'arbre MAST sur la blockchain BTC, chaque arbre MAST étant associé à une transaction impliquant tous ses paramètres d'entrée, ses codes d'opération/ses circuits de porte logique. C'est un peu similaire à la publication de Rollup Blocks par Arbitrum par Proposer sur la blockchain Ethereum.

En cas de litige, un adversaire indique sur la blockchain BTC quelle racine il souhaite contester, puis demande au proposant de révéler un segment de données spécifique correspondant à la racine. Ensuite, le proposant présente une preuve Merkle, divulguant en continu de petits segments des données de l'arbre MAST en chaîne jusqu'à ce que le circuit de porte logique contesté soit localisé conjointement avec le challenger. Ensuite, une barre oblique peut être exécutée.

(Source :https://medium.com/crypto-garage/deep-dive-into-bitvm-computing-paradigm-to-express-turing-complete-bitcoin-contracts-1c6cb05edfca)

1. Jusqu'à présent, les aspects les plus cruciaux de la solution BitVM ont été largement abordés. Bien que certains détails soient encore un peu obscurs, on pense que les lecteurs peuvent comprendre l'essence et les principaux points de BitVM. En ce qui concerne « l'engagement de valeur binaire » mentionné dans son livre blanc, il est conçu pour empêcher un proposant d'attribuer 0 et 1 aux valeurs d'entrée d'une porte logique lorsqu'il est invité à vérifier le circuit de la porte logique en chaîne, créant ainsi de l'ambiguïté et de la confusion.

En résumé, le schéma BitVM commence par utiliser un script Bitcoin pour exprimer les circuits des portes logiques, puis utilise ces circuits pour exprimer les opcodes de l'EVM/autres machines virtuelles, qui expriment à leur tour le flux de traitement d'une instruction de transaction donnée, et enfin les organisent dans un arbre Merkle Tree/Mast. Si le flux de traitement des transactions représenté par un tel arbre est très complexe, il peut facilement dépasser les 100 millions de feuilles. Il est donc crucial de minimiser l'espace de blocage occupé par les engagements et la portée des preuves de fraude.

Bien qu'une preuve de fraude en une seule étape ne nécessite qu'une très petite quantité de données et un script Logic Gate en chaîne, l'intégralité de Merkle Tree doit être stockée hors chaîne pendant une longue période, afin d'être accessible sur la chaîne à tout moment si quelqu'un le conteste. Chaque transaction dans une couche 2 génère un grand arbre de Merkle, et on peut imaginer la pression de calcul et de stockage qui s'exerce sur les nœuds. La plupart des utilisateurs ne voudront peut-être pas gérer de nœuds (cependant, ces données historiques peuvent être supprimées progressivement, et le réseau B^2 introduit spécifiquement des preuves zk-storage similaires à Filecoin pour inciter les nœuds de stockage à préserver les données historiques à long terme).

Cependant, les rollups optimistes basés sur des preuves de fraude ne nécessitent pas trop de nœuds car leur modèle de confiance est 1/N, ce qui signifie que tant que l'un des N nœuds est honnête et peut lancer une procédure de prévention des fraudes à un moment critique, le réseau de couche 2 est sécurisé.

La conception de solutions de couche 2 basées sur BitVM se heurte néanmoins à de nombreux défis, tels que :

1) Théoriquement, pour compresser davantage les données, il n'est pas nécessaire de vérifier les opcodes directement sur la couche 1. Le flux de traitement des opcodes peut être encore compressé dans un zk-proof, ce qui permet aux joueurs de contester les étapes de vérification du zk-proof. Cela pourrait réduire de manière significative la quantité de données en chaîne. Cependant, les détails spécifiques du développement peuvent être très complexes.

2) Les proposants et les challengers doivent générer des interactions hors chaîne à plusieurs reprises. La manière dont le protocole doit être conçu et la manière dont le processus d'engagement et de challenge doit être optimisé davantage dans le flux de traitement demanderont beaucoup d'efforts intellectuels.

Avertissement：

1. Cet article est repris de [Geek Web3], Forward the Original Title « A minimalist interpretation of BitVM : How to verify fraud proof on the BTC chain (execute the operation code of EVM or other VM) ». Les droits d'auteur appartiennent à l'auteur original [Faust & Misty Moon].
   En cas d'objection à cette réimpression, contactez l'équipe de Gate Learn, elle s'en occupera rapidement.
2. Avertissement en matière de responsabilité : Les points de vue et opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent en aucun cas un conseil d'investissement.
3. Les traductions de l'article dans d'autres langues sont effectuées par l'équipe de Gate Learn. Sauf mention contraire, il est interdit de copier, de distribuer ou de plagier les articles traduits.