BitVMのミニマリスト的説明：BTCチェーン上の不正証明を検証する方法

Author: Misty Moon & Faust, ex Web3 Tech Head@Huobi

Advisor: Kevin He, BitVM Chinese community initiator, ex Web3 Tech Head@Huobileft;">Advisor: Kevin He, BitVM Chinese community initiator, ex Web3 Tech Head@Huobi

しかし、助けはありません！BitVMについて入手可能な資料のほとんどは、その原理を平易な言葉で説明していません。

この記事は、私たちがBitVMについて読んだ8ページのホワイトペーパーと、Taproot、MASTツリー、Bitcoin Scriptに関連する情報を簡単にまとめたものです。読者の理解のため、BitVMのホワイトペーパーとは一部表現が異なります。また、読者がLayer2についてある程度の知識を持ち、「不正の証明」という単純な考え方を理解していることを前提としています。

最初に、少しおさらいを。BitVMの考え：チェーン上にある必要のないデータは、まずチェーン外に公開・保存され、コミットメントだけがチェーン上に保存される。

チャレンジ/不正証明が発生すると、チェーン上にある必要があるデータのみをチェーン上に置き、それがチェーン上のコミットメントに関連していることを証明します。その後、BTCメインネットはこれらのon chianデータが不正であるかどうか、そしてデータ生産者（トランザクションを処理するノード）が何らかのいたずらをしたかどうかをチェックする。これらはすべて、オッカムの剃刀の原則に従ったものである。「する必要がなければエンティティを追加しない」（できることならオンチェーンを少なくする、オンチェーンを少なくする）。

本文：いわゆるBitVMベース。BitVM's BTC on-chain fraud proof verification scheme, a layman's summary: 

1.まず第一に、コンピュータ／プロセッサは、多数の論理ゲート回路の組み合わせからなる入出力システムである。BitVMの中核的なアイデアの1つは、ビットコインスクリプトを使用して論理ゲート回路の入出力効果をシミュレートすることです。

論理ゲート回路をシミュレートできる限り、理論的にはチューリングマシンを実装し、すべての計算可能なタスクを完了することができます。言い換えれば、たくさんの人とたくさんのお金さえあれば、たくさんのエンジニアを集めて、簡単なビットコイン・スクリプトのコードで論理ゲートをシミュレートするのを手伝ってもらい、膨大な量の論理ゲートでEVMやWASMを実装することができるのです。

(ビットコインスクリプトのサンプルコード) 

ビットコインレイヤー2がアービトルムのようなイーサリアムレイヤー2のようになるのであれば、次のようになります。もしBitcoin Layer2がArbitrumのようなイーサリアムのLayer2のようにLayer1で不正の証明を検証し、BTCのセキュリティを大きく継承しようとするならば、BTCチェーン上で直接「係争中の取引」や「係争中のオペコード」を検証する必要がある。この場合、Layer2が使用するSolidity言語/EVMのオペコードをビットコインチェーンで再実行する必要があります。

ビットコインネイティブの初歩的なプログラミング言語であるBitcoin ScriptからEVMやその他の仮想マシンを実装する。

つまり、コンパイル原理の観点からBitVMスキームを理解するには、EVM / WASM / Javascriptのオペコードを、論理ゲート回路が"EVM opcodes --> Bitcoin Script opcodes "として機能します。

（BitVMのホワイトペーパーは、ビットコインチェーン上で特定の「物議を醸すコマンド」を実行する一般的なアイデアについて語っています）

。いずれにせよ、シミュレーションの最終結果は、そうでなければEVM / WASM上で処理される命令が、ビットコインチェーン上で直接処理されるということです。これは実現可能ですが、課題は、中間形式として多数の論理ゲートを使用してすべてのEVM / WASMオペコードを表現し、論理ゲートの組み合わせを使用して最も複雑なトランザクション処理フローのいくつかを直接表現することであり、これは膨大な作業量を生み出す可能性があります。

3.こちらはBitVMのホワイトペーパーで言及されている別のコアで、Arbitrumの「インタラクティブ詐欺証明」に非常に似ています。

インタラクティブな不正証明には、アサート（assert）と呼ばれる単語が含まれます。 一般的に言えば、レイヤー2のプロポーザ（多くの場合、シーケンサーによって行動される）は、レイヤー1に対して、特定のトランザクションデータ、状態遷移の結果が有効であるかどうかのアサーションを発行します。

提案者が提出したアサーションに誤りがある（関連するデータが正しくない）と誰かが考えた場合、紛争が発生する。この時点で、提案者と挑戦者はラウンドロビン方式で情報を交換し、極めて詳細な操作命令とそれに関連するデータ断片を素早く見つけるために、争点となったデータの二分ルックアップを行う。

この論争の的になっているOPコードは、入力パラメータとともにレイヤー1で直接実行され、出力が検証される必要があります（レイヤー1のノードは、自身の計算の出力と提案者の前回のリリースの出力を比較します）。アービトラムではこれを「シングルステップ不正証明」と呼んでいます。

(Arbitrum's Interactive Fraud Proof)プロトコルは、提案者が投稿したデータを二分法で取得し、争点となるデータとその実行結果をできるだけ早く特定し、最終的に検証のためにレイヤー1にシングルステップの不正証明を送信する)

参考文献：元Arbitrumテクニカルアンバサダーによる解釈アービトルムのコンポーネント構造（上）

（Arbitrum's Interactive Fraud Proof Flowchart, roughly elaborated）

この時点で、シングルステップ詐欺証明の考え方はよく理解されています。レイヤー2で発生する取引指示の大部分は、BTCチェーン上で再検証する必要はありません。しかし、争われたデータフラグメント/オペコードの1つは、それが挑戦されたときにLayer1で再生されなければならない。

もしテストが、Proverによって以前にリリースされたデータに問題があると結論づけた場合、Proverによって誓約された資産を切り捨てます。

ArbitrumはEther上のコントラクトによって上記の効果を実現しており、BitVMはBitcoin Scriptの助けを借りてタイムロックやマルチシグネチャなどを実装する必要がある。

4.strong>「インタラクティブ不正証明」と「シングルステップ不正証明」について簡単に話した後、MASTツリーとメルクル証明について話します。

前述したように、BitVMのシナリオでは、Layer2のオフチェーン処理に関わる膨大な量のトランザクションデータ/ロジックゲートは、チェーン上には直接存在せず、必要な瞬間にのみチェーン上に存在することになります。

MAST TreeとMerkle Proofについてお話しします。left;">しかし、「元々は連鎖の下にあり、今は連鎖の上にある」というデータが単なるでっち上げでないことを証明する何らかの方法が必要です。これは暗号学ではしばしばコミットメントと呼ばれ、メルクル証明はコミットメントの一種です。

まずMAST Treeについてですが、これはMerkelized Abstract Syntax Treesと呼ばれるもので、コンパイルの原理に関わるAST Treeをメルクルツリーに変換したものです。

では、ASTツリーとは何でしょうか？その中国語名は「抽象構文木」で、簡単に言うと、複雑な命令が字句解析によって基本的な操作ユニットの束に細分化され、ツリー状のデータ構造に整理されることを意味します。

（ASTツリーの単純なケースでは、このASTツリーは、x = 2、y = x * 3このような単純な操作は、基礎となるオペコード+データに細分化されます） 

そして、MASTツリーは、つまり、置く。一方、MASTツリーは、ASTツリーをMerkle化してMerkle Proofをサポートしたもので、効率的な「データ圧縮」ができるという利点がある。例えば、必要であればMerkleツリーからBTCチェーンにデータの一部を投稿したいが、このデータの一部が実際にMerkleツリーに存在し、単に「空中から引っ張り出した」のではないことを外部に確実に知らせたい場合、どうすればよいだろうか？

あらかじめメルクルツリーのルートをチェーン上に記録しておき、将来、メルクル証明でルートに対応するメルクルツリーにデータの一部が存在することを示せばよいのです。

（Merkle Proof/BranchとRootの関係）

そのため、BTCチェーン上に完全なMASTツリーを保存する必要はありません。を進めてコミットメントとして機能させ、必要なときにデータフラグメント＋Merkle Proof /Branchを提示すればよい。これにより、オンチェーンのデータ量を大幅に圧縮し、オンチェーンのデータが本当にMASTツリーに存在することを保証することができる。さらに、BTCチェーン上では、すべてのデータを開示するのではなく、データフラグメント＋Merkle Proofのごく一部のみを開示することで、良好なプライバシー保護効果を得ることができます。

参考：データ保留と不正証明：Plasmaがスマートコントラクトをサポートしない理由

（MASTツリーの例）

BitVMのソリューションでは、すべてのロジックゲートをビットコインスクリプトで表現し、それらを巨大なMASTツリーに整理しようとしています。ツリーの一番下にあるリーフリーフ（図のコンテンツ）は、ビットコインスクリプトで実装されているロジックゲートに対応しています。

レイヤー2のプロポーザは、BTCチェーン上でMASTツリーのルートを頻繁に公開し、各MASTツリーに対して、その入力パラメータ/オペコード /ロジックゲート回路のすべてに関わるトランザクションが関連付けられます。

紛争が発生すると、挑戦者はBTCチェーン上で、挑戦したい提案者が投稿したルートを宣言する。その後、提案者はそのルートに対応するデータを公開するよう求められる。その後、提案者はMerkleプルーフを作成し、チェーン上のMASTツリーから小さなデータの断片を、挑戦者と共同で問題の論理ゲート回路を見つけるまで繰り返し開示する。

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

5.この時点で、BitVMプログラムの最も重要な部分は基本的に終わった。詳細はまだ少し曖昧な部分もありますが、読者はすでにBitVMの本質を理解できると思います。ホワイトペーパーで言及されているビット値のコミットメントは、プロポーザが挑戦され、チェーン上の論理ゲート回路を検証することを強制され、そのゲートの入力値に0と1の両方を割り当て、二項対立の混乱を引き起こすことを防ぐためです。

概要：BitVMのスキームは、ビットコインのスクリプトを使用してロジックゲートを表現し、次にロジックゲートを使用してEVM/他のVMのオペコードを表現し、次にオペコードを使用して任意のトランザクション命令の処理フローを表現し、最後にそれ自体をメルクルツリー/MASTツリーに編成します。ツリーになります。

このようなツリーは、トランザクションの処理フローの表現が非常に複雑な場合、1億の葉を壊すのは簡単なので、コミットメントが占有するブロック領域を最小限に抑えるだけでなく、リップルの不正証明の範囲も最小限に抑えることができます。

シングルステップの不正証明では、オンチェーンからのごく一部のデータとロジックゲートスクリプトしか必要としませんが、完全なメルクルツリーは、誰かがそれに挑戦した場合に備えて、チェーンの下に長期間保存しておかなければならず、ツリー上のデータがあればいつでもオンチェーンできます。

Layer2で発生するすべてのトランザクションは大きなメルクルツリーを生成し、ノードにかかる計算とストレージのプレッシャーは想像に難くなく、ほとんどの人はノードを稼働させるのを嫌がるかもしれません（しかし、この履歴データは期限切れによってなくすことができ、B^2ネットワークではしかし、その信頼モデルは1/Nであり、N個のノードのうち1個が正直であれば、そのノードはそれ自体あまり多くのノードを持つ必要はありません。の1つが正直で、重要な瞬間に不正証明を開始できる限り、Layer2ネットワークは安全です。

しかしながら、BitVMベースのLayer2スキームの設計には、以下のような多くの課題があります。理論的には、レイヤー1で直接オペコードを検証することなくデータをさらに圧縮するために、オペコードの処理フローを再びzk証明に圧縮し、挑戦者がzk証明の検証ステップに挑戦できるようにすることができます。これにより、チェーン上のデータ量を大幅に圧縮することができる。しかし、正確な開発の詳細は複雑であろう。

2.提案者と挑戦者は、チェーンの下で繰り返しインタラクションを生成しなければなりません。多くの脳細胞を消費する。

参考文献：

1.BitVMホワイトペーパー

https://bitvm.org/bitvm.pdf

2.BitVMのディープダイブ -チューリングを表現するコンピューティングパラダイム-

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

3.メルケル化された抽象的な構文木

https://hashingit.com/elements/research-resources/2014-12-11-merkelized-abstract-syntax-trees.pdf