BTCへのアプローチ：BitVMを理解するために必要な背景知識

著者: Nickqiao &; Faust &; Shew Wang, Geek Web3

概要:最近、Delphi Digitalは「ビットコインのプログラマビリティの夜明け：ロールアップへの道を開く」と題したレポートを発表しました。Delphi Digitalは、「The Dawn of Bitcoin Programmability: Paving the Way for Rollups（ビットコイン・プログラマビリティの夜明け：ロールアップへの道を開く）」と題したビットコイン・レイヤー2関連の技術研究論文を発表しました、OP_CATと規約制限条項、BitcoinエコロジーDAレイヤー、ブリッジ、そしてBitlayer、Citrea、Yona、BobのようなBitVMの4つの主要なBitcoinレイヤー2採用者。

調査報告書は、ビットコインの第2層技術について大まかなイメージを提示しているものの、全体的に一般的で詳細が欠けており、一見理解しにくいものでした。GeekWeb3は、Delphiのリサーチペーパーをベースに、より深く掘り下げ、BitVMやその他の技術について、より体系的な理解を提供しようとしています。

私たちは、Bitlayer研究チームとBitVM中国コミュニティと協力して、BitVM、OP_CAT、Bitcoin Crosschain Bridgeなどの主要なトピックに焦点を当てた「BTCに迫る」と題する一連のコラムを連載する予定です。

本文：数ヶ月前、私たちはビットコインの新技術について話していました。strong>数ヶ月前、ZeroSyncの代表ロビン・ライナスが「BitVM: Compute Anything on Bitcoin」というタイトルの記事を投稿した。BitVMのコンセプトを正式に紹介し、ビットコインのセカンドレイヤー技術の限界を押し広げた。これはビットコインエコシステムにおける最も革命的なイノベーションの1つであり、ビットコインレイヤー2エコシステム全体を爆発させ、Bitlayer、Citrea、BOBなどのスタープロジェクトの参加を引きつけ、市場全体に活気をもたらしたと言えます。

その後、より多くの研究者がBitVMの改良に関わり、BitVM1、BitVM2、BitVMX、BitSNARKなどのさまざまな反復が行われました。

1. 昨年、Robin Linus氏によって初めて発表されたBitVMの実装に関するホワイトペーパーです。

2. ロビン・ライナスは、その後のいくつかのプレゼンテーションやインタビューで、架空のCPUベースのBitVMソリューションを非公式に紹介しました。CPUのBitVMソリューション（BitVM1と呼ばれる）は、Optimismの不正証明システムCannonに似ており、ビットコインスクリプトでオフチェーンシミュレートして、汎用CPUの効果をシミュレートすることができます。

3. ロビン・ライナスはまた、パーミッションレス、シングルステップ、非対話型不正証明プロトコルであるBitVM2を提案しました。

4. ルートストックラボとフェアゲートラボのメンバーは、BitVMXのホワイトペーパーを発表しました。汎用CPU（オフチェーン）の効果をシミュレートしたいと考えています。

現在、BitVM関連の開発者エコシステムの構築は日に日に明らかになり、周辺ツールの反復的な改良が肉眼で見えるようになってきています。 昨年と比較すると、今日のBitVMエコシステムは、最初の"昨年と比較して、今日のBitVMエコシステムは "天空の城 "から "目に見える "ものになり、より多くの開発者やVCがビットコインエコシステムに殺到するようになった。

しかし、ほとんどの人にとって、BitVMとビットコインの第2層に関連する技術用語を理解するのは簡単なことではありません。既存のオンラインリファレンスは、長すぎて入り組んでいるか、理解できるほど十分に説明されていません。私たちはこれらの問題を解決するために尽力し、できるだけ多くの人がビットコインの第2層の周辺知識をできるだけわかりやすい言葉で理解できるようにし、BitVMシステムの体系的な理解を構築することを目指しています。

MATTとコミットメント：BitVMの背後にあるアイデア

まず最初に、BitVMの背後にあるアイデアがMATTであることを強調したいと思います。MATTとは、Merkleize All The Things（すべてのものをMerkle化する）という意味で、主にツリー状のデータ記憶構造であるMerkle Treeを使用して、プログラムの実行の複雑なプロセスを示し、BitVMをより効率的にしようとするものです。プログラムの実行プロセスは、ビットコインネイティブ検証の詐欺防止に成功しました。

MATTは、複雑なプログラムとそのデータ処理トレースを表現していますが、このデータの全体サイズが非常に大きいため、このデータをBTCチェーン上で直接公開していません。MATTを使用するスキームは、チェーン下のMerkleツリーにのみデータを格納し、チェーンにはMerkleツリーの一番上の要約（Merkle Root）のみを公開する。

- スマートコントラクトのスクリプトコード

- 契約に必要なデータ

- 契約に必要なデータ

-コントラクト実行中に残された痕跡（EVMなどの仮想マシンでスマートコントラクトを実行中にメモリやCPUレジスタに加えられた変更の記録）

（単純なメルクルツリーの概略図。ルートは、図の下部にある8つのデータ断片から、何層ものハッシュを経て計算される）

MATTスキームでは、非常に小さなサイズのマークル・ルートのみがチェーンに保存され、マークル・ツリーに含まれる完全なデータセットが保存される。メルクル木に含まれる完全なデータセットは、「コミットメント」として知られるアイデアを使ったチェーンの下に保存される。ここで「コミットメント」とは何かについて説明しよう。

コミットメントは簡潔な宣言のようなもので、圧縮された大量のデータの指紋と考えることができます。一般的に、チェーン上で「約束」を公表する人は、チェーンの外に保存されているデータの一部が正確であり、チェーンの外にあるデータが簡潔な宣言に対応していると主張します。

ある時点で、データのハッシュはデータそのものに関する「約束」として使うことができ、他の約束スキームにはKZG約束やMerkle Treeがあります。Layer2の通常のProof-of-fraudプロトコルでは、データ公開者はオフチェーンで完全なデータセットを公開し、オンチェーンでデータセットを約束する。もし誰かがチェーン下のデータセットに無効なデータがあることを発見したら、チェーン上のデータ約束に対して異議を唱える。

コミットメントによって、レイヤー2は大量のデータをクランチし、その「コミットメント」だけをビットコインチェーン上で公開することができます。もちろん、オフチェーンで公開された完全なデータセットが外部によって観察されることも保証します。

現在、いくつかの主要なBitVM

1.プロシージャの分解とコミットメント:まず、複雑なプロシージャは、より多くの基本的な演算に分解されます。次に、これらのオペコードが具体的に実行されたときに生成されるトレースを記録します（大げさに言えば、プログラムの一部がCPUとメモリで実行されたときに変化する状態の全記録で、トレースと呼ばれます）。その後、トレースやオペコードを含むすべてのデータを照合してデータセットに整理し、そのデータセットに対する約束を生成します。

特定のコミットメントスキームには、メルクルツリー、PIOP（さまざまなZKアルゴリズム）、ハッシュ関数など、さまざまな形式があります。データパブリッシャーと検証者は、事前署名によってチェーン上の一定量の資産をロックする必要があり、そこには制約があります。これらの条件は、将来起こりうる出来事に対応して発動されます。データパブリッシャーが悪事を働いた場合、検証者は証拠を提出してデータパブリッシャーの資産を奪うことができます

3.データとコミットメントの公開:データとコミットメントの公開:データの公開。/strong>データパブリッシャーはチェーン上でコミットメントを公開し、完全なデータセットはチェーン外で公開され、バリデータはデータセットを取得し、エラーがないかチェックする。チェーン下のデータセットの各部分は、チェーン上のコミットメントと相関がある。

4.挑戦と罰則：検証者がデータ公開者から提供されたデータにエラーを見つけると、データのその部分をチェーン上に取り出し、直接検証します（最初にデータのその部分を非常に細かくスライスすることによって）。不正証明の論理。検証の結果、データ公開者が連鎖を下って無効なデータを提供したことがわかれば、その資産は彼に異議を唱えた検証者に奪われます。

要約すると、データ公開者であるアリスは、第2層のトランザクションの実行中に生成されたすべてのトレースをオフチェーンで公開し、対応する約束をチェーンに公開します。もしデータの一部が間違っていることを証明したいのであれば、まずビットコインノードに対して、データのこの部分がチェーン上の約束と関連していることを証明し、つまりこのデータがアリス自身に公開されていることを証明し、次にビットコインノードにデータのこの部分が間違っていると判断させます。

さて、私たちはBitVMの全体的なアイデアを一般的に理解しており、すべてのBitVMの亜種は基本的に上記のパラダイムに従っています。それでは、ビットコイン・スクリプティングとタップルートと事前署名の基本から始めて、上記のプロセスで使用される重要な技術のいくつかを学び、理解しましょう。

ビットコインスクリプトとは

ビットコインはイーサよりも理解するのがはるかに難しく、送金する基本的なことにさえ、UTを含むさまざまな概念が関わっています。UTXO（Unspent Transaction Output）、スクリプトのロック（ScriptPubKeyとも呼ばれる）、スクリプトのロック解除（ScriptSigとも呼ばれる）などです。まず、これらの重要な概念について説明します。

(ビットコインスクリプト)コード例 高級言語よりも低レベルのオペコードで構成される )

イーサーの資産表現は、アリペイやWeChatのようなもので、各送金は異なる口座の残高への加減算に過ぎず、この方法は口座を中心としたもので、資産の残高は口座名の下の数字に過ぎない；ビットコインの資産表現は、アリペイやWeChatのようなもので、各送金は異なる口座の残高への加減算に過ぎない。ビットコインの資産表現は、より金のようなものであり、それぞれの金（UTXO）は所有者をマークし、お金を転送することは、実際には古いUTXOを破壊し、新しいUTXO（所有者が変更されます）を生成します。

ビットコインのUTXOには2つの重要なフィールドがあります：

サトシ（1,000,000）で測定される金額。)」（1億サトシは1BTC）。

「ScriptPubKey」とも呼ばれるロックスクリプトで、UTXOのロック解除条件を定義します。

ビットコインのUTXOの所有権は、ロッキングスクリプトを通じて表現されることに注意することが重要ですUTXOをサムに譲渡したい場合は、トランザクションを開始してUTXOの1つを破棄し、新しく生成されたUTXOをサムに置きます。自分のUTXOをSamに譲渡したい場合は、自分のUTXOの1つを破棄するトランザクションを開始し、新しく生成されたUTXOのロック解除条件を「Samだけがロック解除できる」と書けばよい。

その後、Samはビットコインを使用したい場合、ロック解除スクリプト（ScriptSig）を提出する必要があり、その中で自分がSamであることを証明するためにデジタル署名を提示する必要があります。ロック解除スクリプトが前述のロックスクリプトと一致すれば、サムはそのビットコインのロックを解除し、誰かに再送信することができる。

（ロック解除スクリプトはロックスクリプトと一致しなければなりません。）スクリプトがロックスクリプトと一致する必要があります）

プレゼンテーションの観点から、ビットコインチェーン上の各トランザクションは、複数の入力と出力に対応し、各入力は、ロックを解除したい特定のUTXOを宣言する必要があります。Outputは新しく生成されたUTXOに関する情報を表示し、ロックスクリプトの内容を公開します。

例えば、トランザクションのInputでは、自分がサムであることを証明し、他人から与えられた複数のUTXOのロックを解除し、それらを一律に破棄し、将来的にxxxにロックを解除させるという声明とともに複数の新しいUTXOを生成します。

具体的には、トランザクションの入力データで次のように宣言します。入力データでは、どのUTXOのロックを解除したいかを宣言し、UTXOデータの「保管場所」を指定します。ビットコインがイーサと大きく異なる点として、イーサはデータを保存するための契約口座とEOA口座の両方を提供し、資産の残高は契約口座またはEOA口座の名前の下に数字として記録され、「世界の状態」と呼ばれるデータベースに置かれ、「世界の状態」から直接送金するために使用される点に注意する必要があります。資金を送金する際、「世界の状態」から直接特定の口座に変更を加えることができるため、データがどこに保存されているかを簡単に特定することができます。

ビットコインには世界の状態の設計がなく、資産データは過去のブロックに分散して保存されています（つまり、ロック解除されたUTXOのデータは、各トランザクションのOutPutに個別に保存されています）。トランザクションは別々にOutPutに保存されます）。

UTXOのロックを解除したい場合は、UTXOのどのOutputにロックが解除されたかを指定します。UTXOのロックを解除したい場合、そのUTXO情報が過去のトランザクションのどのOutputに存在するかを述べ、そのトランザクションのID（ハッシュ）を提示し、、ビットコインノードがそれを見つけるために履歴を調べます。

通常ビットコインウォレットを使用する場合、ウォレットサービス自体がブロックをスキャンし、すべてのアドレスのインデックスを作成するため、多くの場合、特定のアドレスが所有するビットコインの残高を素早くチェックすることが可能です。というのも、ウォレットサービス自身がブロックをスキャンし、すべてのアドレスのインデックスを作成するからです。

(トランザクションを生成するとき)ステートメントで自分のUTXOを他の人に渡す場合、それらのUTXOが属するトランザクションのハッシュ/IDに基づいて、ビットコインの履歴にUTXOの位置をマークします）

興味深いことに、ビットコインのトランザクションの結果は、チェーンの下流で計算されます。ユーザーがローカルデバイス上でトランザクションを生成するとき、彼らは直接入力と出力の両方を作成する必要があり、これはトランザクションの出力を計算することと同じです。取引はその後ビットコインネットワークにブロードキャストされ、チェーンにアップロードされる前にノードによって検証される。この「オフチェーンでの計算-オンチェーンでの検証」モデルは、トランザクションの入力パラメータを提供するだけで結果がイーサノードによって計算され出力されるイーサとは完全に異なります。

さらに、UTXOのロックスクリプトはカスタマイズ可能で、UTXOを「ビットコインアドレスの所有者がロック解除可能」に設定できます。デジタル署名と公開鍵（P2PKH）を必要とする「ビットコインアドレスの所有者がロック解除可能」にUTXOを設定できます。また、Pay-to-Script-Hash（P2SH）トランザクションタイプでは、UTXOのロックスクリプトにスクリプトハッシュを追加することができ、このハッシュに対応するオリジナルのスクリプトイメージを提出し、そのオリジナルのスクリプトイメージにプリセットされた条件を満たすことができれば、誰でもUTXOのロックを解除することができます。BitVMが依存しているTaprootスクリプトは、P2SHに似た機能を使用しています。

ビットコインスクリプトのトリガー方法

ここでは、ビットコインスクリプトのトリガーのケーススタディとしてP2PKHを使用します。P2PKHは「Pay to Public Key Hash」と呼ばれ、UTXOのロックスクリプトが公開鍵ハッシュを設定し、ロック解除時にそのハッシュの公開鍵ハッシュを提出する必要があります。この場合、UTXOはロックスクリプトに公開鍵ハッシュを設定し、ロック解除時にそのハッシュに対応する公開鍵を提出する必要があります。

この時点で、ビットコインノードは、ロック解除スクリプトの公開鍵がロックスクリプトで指定された公開鍵ハッシュと一致することを確認する必要があります。つまり、ロック解除者によって提出された「キー」とUTXOプリセットの「ロック」が互いに一致することを確認します。

さらに、P2PKHシナリオでは、ビットコインノードがトランザクションを受信し、ユーザーから与えられたロック解除スクリプトScriptSigをUTXOのロックスクリプトScriptPubkeyとスプライスし、BTCスクリプトの実行環境に置きます。次の図は、実行前のスプライスを示している。

読者はBTCスクリプトをご存知ないかもしれません。BTCスクリプトの実行環境をご存じないかもしれませんので、ここで簡単に紹介します。まず、BTCスクリプトには2つの要素があります:

データとオペコードです。データとオペコードは左から右の順にスタックに押され、指定されたロジックに従って実行され、最終的な結果を得ます（スタックとは何かという詳細には立ち入りませんが、それはChatgptの読者に任せます）。

上の画像を例にとると、左側には誰かがアップロードしたロック解除スクリプトScriptSigがあり、彼のデジタル署名と公開鍵が含まれています。右側にはロックスクリプトScriptPubkeyがあり、UTXOを生成するためにUTXOの作成者によって設定されたオペコードとデータスクリプトが含まれています。オペコードとデータ(ここでは各オペコードの意味を知る必要はなく、一般的な理解でよい)が含まれています。

上の画像の右側にあるロッキングスクリプトのDUP、HASH160、EQUALVERIFYオペコードは、左側にあるアンロッキングスクリプトで運ばれた公開鍵のハッシュを取り出し、ロッキングスクリプトでプリセットされた公開鍵のハッシュと比較し、両者が等しいかどうかを判断する役割を担っています。両者が等しい場合、アンロックスクリプトでアップロードされた公開鍵は、ロックスクリプトでプリセットされた公開鍵ハッシュと一致し、最初の検証をパスします。

しかし、問題があります。UTXOのロックスクリプトの内容は実際にチェーン上で公開されているため、誰でもその中に含まれる公開鍵ハッシュを観察することができ、誰でも対応する公開鍵をアップロードして「指名」された人物であると偽ることができます。したがって、公開鍵と公開鍵ハッシュを検証した後、トランザクションの開始者が 本当に公開鍵の実際の管理者であることを検証する必要がある。これは電子署名の検証を必要とする。lockスクリプトのCHECKSIGオペコードが電子署名の検証を担当する。

要約すると、P2PKHスキームでは、トランザクションの開始者は、公開鍵とデジタル署名を含むロック解除スクリプトを提出します。これは、ロックスクリプトで指定された公開鍵のハッシュと一致する必要があり、トランザクションは正しくデジタル署名されます。

（この図は動的です：P2PKH スキームにおけるビットコインのロック解除スクリプトの概略図 

Source:https://learnmeabitcoin.com/(technical/script )

もちろん、ビットコインネットワークでサポートされているトランザクションの種類は複数あります。ハッシュだけでなく、P2SH (Pay to Script hash)など、UTXOが作成されたときにカスタムロッキングスクリプトが何に設定されるかによります。

ここで重要なのは、UTXOが作成されたときにカスタム ロッキング スクリプトが何に設定されているかということです。P2SHスキームでは、ロックスクリプトにスクリプトハッシュをプリセットすることができ、ロック解除スクリプトはスクリプトハッシュに対応するスクリプトの全内容を送信する必要があります。ビットコインノードはこのスクリプトを実行でき、 マルチシグネチャ検証のロジックがこのスクリプトで定義されている場合、ビットコインチェーン上でマルチシグネチャウォレットの効果を実装するために使用できます。

もちろん、P2SHシナリオでは、UTXOの作成者は、UTXOのロックを解除する未来の人物に、スクリプトに対応するスクリプトハッシュの内容を事前に知らせなければなりませんし、両者がこのスクリプトの内容を知っている限り、マルチシグネチャよりも複雑なビジネスロジックを実装することができます。

明確にしておくと、ビットコインチェーンはどのUTXOがどのアドレスに関連付けられているかを直接記録しているわけではなく、UTXOがどの公開鍵ハッシュ/どのスクリプトハッシュによってロックを解除できるかを記録しているだけですが、公開鍵ハッシュ/スクリプトハッシュに基づいて、どのアドレス（スクリプトを表示するウォレットインターフェイスのセクション）がどのUTXOに対応しているかをすぐに把握することができます。アドレス(ウォレットインターフェイスの表示でちんぷんかんぷんなビット)に基づいて、どのUTXOに対応するかすぐにわかります。

ブロックエクスプローラーとウォレットインターフェースでxxアドレスのxx量のビットコインを見ることができるのは、ブロックエクスプローラーとウォレットプロジェクトがあなたの代わりにデータを解析し、すべてのブロックをスキャンし、ロックスクリプトで宣言された公開鍵ハッシュ/スクリプトハッシュに基づいて対応する "アドレス "を計算するからです。"そして、XXアドレスの名前の下に何枚のビットコインがあるかを表示します。

分離された証人と証人

P2SHの考え方を理解すれば、BitVMが依存するTaprootに一歩近づきます。しかし、その前に重要な概念を理解する必要があります：ウィットネスとアイソレーテッド・ウィットネスです。

前述したロック解除スクリプトとロックスクリプト、およびUTXOのロック解除プロセスを再検討すると、問題があることがわかります。トランザクションのデジタル署名はロック解除スクリプトに含まれており、ロック解除スクリプトは署名を生成するときにカバーすることができない（署名を生成するために使用されるパラメーターは署名自体を含むことができない）ため、デジタル署名はロック解除スクリプトの外側の部分のみをカバーすることができます。デジタル署名はロック解除スクリプトの外側の部分しかカバーできない。つまり、完全なトランザクションデータではなく、トランザクションデータのバックボーンにのみ関連付けることができる。

こうすることで、たとえ取引のロック解除スクリプトが仲介者によって改ざんされたとしても、署名検証の結果は影響を受けない。例えば、ビットコインノードやマイニングプールは、取引のロック解除スクリプトに他のデータを詰め込むことで、署名チェックや取引結果に影響を与えることなく取引データをわずかに変更させることができ、計算終了時に取引ハッシュ/取引IDが変更される。これはトランザクションの拡張性問題として知られている。

この欠点は、連続的な依存関係（例えば、トランザクション3はトランザクション2の出力を参照し、トランザクション2はトランザクション1の出力を参照する）を持つ複数のトランザクションを連続して開始する場合、行の後ろのトランザクションは必然的に前のトランザクションのID（ハッシュ）を参照することになり、マイニングプールやビットコインノードマイニングプールやビットコインノードなどの仲介者は、ロック解除スクリプトの内容を微調整して、アップロード後のトランザクションのハッシュが期待したものと一致しないようにすることができます。

実際、DLC BridgeとBitVM2のシナリオでは、シーケンシャルな相関関係を持つトランザクションは一括で作成されるため、前述のシナリオは珍しいことではありません。

簡単に言うと、トランザクションにはトランザクションと同じ問題があります。スケーラビリティの問題は、トランザクションID/ハッシュがロック解除スクリプトからのデータを含んで計算されるためであり、ビットコインノードなどの仲介者はロック解除スクリプトの中身を微調整できるため、ユーザーが期待するものと一致しないトランザクションIDになります。実際、これはビットコインの初期の設計が不十分だったために残った歴史的なお荷物です。

後に導入されたSegregated Witness/SegWit Upgradeは、取引IDをロック解除スクリプトから完全に切り離し、取引ハッシュを計算する際にロック解除スクリプトのデータを含める必要性をなくしました。SegWitアップグレードに従うUTXOロックスクリプトは、トークンとして機能するように、デフォルトで最初に「OP_0」と呼ばれるオペコードを設定します。

Witnessの分離ルールに従うことで、トランザクションの拡張性の問題が解決されます。は適切に対処され、ビットコインノードに送信されるトランザクションデータの微調整について心配する必要はありません。もちろん、あまり複雑に考える必要はありません。P2WSHの機能は、先ほど説明したP2SHと基本的には変わりません。UTXOのロックスクリプトにスクリプトのハッシュをプリセットしておき、ロック解除スクリプトの送信者がハッシュに対応するスクリプト内容をチェーンに送信して実行するのを待つことができます。

しかし、実装したいスクリプトが特に大きく、多くのコードを含んでいる場合、通常の方法でスクリプト全体をビットコインチェーンに提出することはできません（ブロックごとにサイズ制限があります）。ではどうするか？Taprootを活用して、チェーン用のスクリプトの内容を合理化し、単純化する必要があります。BitVMはTaproot上に構築された洗練されたソリューションです。