BTCについて詳しく説明します：BitVMに必要な背景知識

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

アドバイザー:Bitlayer研究チーム

概要：

最近、Delphi Digitalは、「The Dawn of ビットコイン プログラム可能性: Paving the Way for Rollups」と題したテクニカルリサーチレポートビットコインリリースし、BitVMファミリーバケット、OP_CAT、Covenant Restriction Clauses、ビットコインEcosystem DA Layer、Bridge、Bitlayerなど、ビットコインロールアップに関連するコアコンセプトを体系的に整理しました。 Citrea、Yona、Bob、およびBitVMを使用した他の4つの主要なビットコインレイヤー2。

このレポートは、ビットコインのレイヤー2技術の概要を大まかに示していますが、全体的にはあいまいで詳細な説明が欠けており、理解しにくいです。Geekweb3はDelphiレポートを基に、より多くの人がBitVMなどの技術を体系的に理解できるように、詳細な調査を行っています。

Bitlayer研究チームとBitVM中国コミュニティと共同で「BTCに迫る」シリーズコラムを開催し、BitVM、OP_CATおよびBTCクロスチェーンブリッジなどの重要なトピックに焦点を当て、BTCの第2層技術に魅了される人々に情報提供し、愛好者に道を切り開くことに貢献します。

体：

数ヶ月前、ZeroSyncの責任者であるRobin Linusは、「BitVM: Compute Anything on Bitcoin」という記事を公開し、BitVMの概念を正式に提案し、Bitcoinの第2層技術の進展を推進しました。これはBitcoinエコシステムで最も革命的なイノベーションの一つであり、Bitcoinの第2層エコシステムを爆発させ、Bitlayer、Citrea、BOBなどの有名プロジェクトの参加を引き寄せ、市場全体に活気をもたらしました。

その後、さらに多くの研究者がBitVMの改良に参加し、BitVM1、BitVM2、BitVMX、BitSNARKなどの異なるイテレーションバージョンが順次リリースされました。それらの概要は次のようになります:

1. 去年、Robin Linusが最初に提案したBitVMの実装ホワイトペーパーは、架空の論理回路に基づくBitVMの実装案であり、BitVM0と呼ばれています；
2. ロビン・リヌスは後の講演やインタビューで、非公式に架空のCPUに基づくBitVM1ソリューション（Cannonと呼ばれるOptimismの詐欺証明システムに類似）を紹介しました。これにより、ビットコインスクリプトを使用してオフチェーンで汎用CPUをシミュレートすることができます。
3. Robin Linus氏は、パーミッションレスのシングルステップ、非対話型詐欺証明 プロトコルであるBitVM2も提案した。
4. Rootstock LabsとFairgate Labsのメンバーは、BitVMXホワイトペーパーを発表しました。BitVM1と同様に、彼らはオフチェーンで一般的なCPUの効果をビットコインスクリプトでシミュレートすることを目指しています。

現在、BitVM関連の開発者エコシステムの構築がますます明確になり、周辺ツールの進化も肉眼で確認できるようになりました。昨年と比較して、BitVMのエコシステムは最初の「空中城」から「はっきりと見えるもの」に変化しました。これはますます多くの開発者やVCがビットコインのエコシステムに参入することを引き寄せています。

しかし、多くの人にとって、BitVMやビットコインの第2層に関連する技術用語を理解することは決して簡単ではありません。なぜなら、まず周辺の基本知識を体系的に理解する必要があるからです。特に、ビットコインスクリプトやTaprootなどの背景知識が必要です。現在、オンラインで利用可能な参考資料は、長すぎたりわかりにくい説明が多かったりして、理解しにくい状況です。私たちはこの問題を解決することに尽力し、できるだけ明確な言葉で、多くの人がビットコインの第2層の周辺知識を理解し、BitVMシステムについて体系的な認識を持つのを助けることを目指しています。

MATT と Promise: BitVM の基本的な考え方

まず、私たちは強調する必要があります。 BitVMの基本的な考え方はMATTであり、Merkleize All The Thingsの意味を持ちます。これは、Merkle Treeという木構造のデータストレージ構造を使用して、複雑なプログラムの実行プロセスを表示し、Bitcoin Nativeの詐欺証明を実現することを目的としています。

MATTは複雑なプログラムとデータ処理の痕跡を表現できますが、これらのデータを直接BTCチェーンに公開することはありません。なぜなら、これらのデータの総容量が非常に大きいからです。MATTのアプローチでは、データはオフチェーンのMerkleツリーにのみ保存され、Merkleツリーのトップにある要約（Merkle Root）のみがチェーン上に公開されます。このMerkleツリーには主に3つの主要なコアコンテンツが含まれています：

*スマートコントラクトスクリプトコード

• 契約に必要なデータ
• コントラクトの実行中に残された痕跡（スマートコントラクトがEVMなどの仮想マシンで実行される際に、メモリやCPUレジスタに生成される変更の記録）

MATTソリューションでは、非常に小さなメークルルートのみがオンチェーンに保存され、メークルツリーに含まれる完全なデータセットは「コミットメント」と呼ばれるアイデアを使用するオフチェーンに保存されます。 ここでは、「コミットメント」とは何かを説明します。

「約束」とは、データを圧縮した後に得られる「指紋」として理解できる簡潔な宣言の一種です。一般的に、チェーン上で「約束」を公開する人は、オフチェーンのデータが正確であると主張し、これらのオフチェーンのデータに対応する簡潔な宣言である「約束」が存在するとされます。

ある時点では、データのハッシュはデータ自体の"約束"として機能することがあります。他の約束の方法には、KZGコミットメントやMerkle Treeなどがあります。Layer2で一般的な詐欺証明プロトコルでは、データの発行者はオフチェーンで完全なデータセットを公開し、オンチェーンでデータセットのコミットメントを公開します。オフチェーンのデータセットに無効なデータがあることが発見されると、オンチェーンのデータのコミットメントに対して挑戦が行われます。

承诺（Commitment）により、2層では大量のデータを圧縮処理し、ビットコインチェーン上でのみその「承認」を公開することができます。もちろん、オフチェーンで公開された完全なデータセットが外部から観測可能であることを保証する必要があります。

現在、BitVM0、BitVM1、BitVM2、BitVMXなど、いくつかの主要なBitVMソリューションは、基本的に同様の抽象構造を採用しています。

1. プログラムの分解とコミットメント：まず、複雑なプログラムを多数の基本オペコード（コンパイル）に分解し、そのオペコードが具体的に実行されたときに生成されるトレースを記録します（つまり、プログラムがCPUとメモリで実行されるときの状態の変化を記録したものです。トレースと呼ばれます）。その後、トレースとオペコードを含むすべてのデータを整理し、データセットを作成し、そのデータセットのコミットメントを生成します。

具体の約束案はさまざまな形式を取ることができます。例えば、Merkleツリー、PIOPs（さまざまなZKアルゴリズム）、ハッシュ関数

2. アセットのステークと事前署名：データプロバイダとバリデータは、一定額のアセットをオンチェーンにロックし、制約条件があるプレサイン形式で提供する必要があります。これらの条件は、将来起こりうる状況に対して特定のトリガーを持っており、データプロバイダが悪意を持った場合、バリデータは証拠を提出してデータプロバイダのアセットを取り上げることができます。

3.データとコミットメントの公開：データプロバイダーはオンチェーンでコミットメントを公開し、オフチェーンで完全なデータセットを公開し、バリデータはデータセットを取得し、エラーがないか確認します。オフチェーンのデータセットの各部分はすべてオンチェーンのコミットメントと関連しています。

4. 挑戦と罰：バリデータがデータプロバイダーが提供したデータに誤りがあることを発見した場合、そのデータの一部を特に細かく切り取ってオンチェーンで直接検証します（この部分のデータを特に細かく切り取る必要があります）。これが詐欺証明のロジックです。検証結果が示すように、データプロバイダーがオフチェーンで無効なデータを提供した場合、その資産はバリデータによって取り上げられます。

要約すると、データ発行者であるAliceは、レイヤー2トランザクションの実行中に生成されたすべてのトレースをオフチェーンで開示し、対応するコミットメントをオンチェーンに公開します。 データの一部が間違っていることを証明したい場合は、まず、データがオンチェーンコミットメントに関連していることをビットコイン ノードに証明する、つまり、データがアリス自身によって開示されていることを証明してから、ビットコイン ノードにデータが間違っていると判断させます。

現在、私たちはおおよそのビットVMの全体的な考え方を理解していますが、すべてのビットVMの変種は基本的に上記の範式から逃れることはできません。次に、上記のプロセスで使用されるいくつかの重要な技術を学んで理解していくことにしましょう。最初に、最も基本的なビットコインスクリプトとタップルート、そしてプリサインについて始めましょう。

Bitcoin スクリプトとは何ですか？

ビットコインに関連する知識はイーサリアムよりも理解が難しいです。基本的な送金行為さえ、UTXO（未使用トランザクション出力）、ロックスクリプト（またはPubKeyとも呼ばれる）およびアンロックスクリプト（またはSigとも呼ばれる）などの概念を含んでいます。まずはこれらの主要な概念について説明します。

（ビットコインスクリプトのコードの例 高級言語よりも低レベルのオペコードで構成されています）

イーサリアムの資産表現は、アリペイやWeChatのようであり、各送金は異なるアカウントの残高を増減させるだけであり、この方法はアカウントを中心とし、資産残高は単なるアカウントの数字である。ビットコインの資産表現はむしろ金に似ており、各金塊（UTXO）は所有者を示し、送金は実際には古いUTXOを破棄し、新しいUTXOを生成すること（所有者は変更されます）。

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

金額は「サトシ（Satoshi）」単位で表されます（1億サトシが1BTC）；

ロックスクリプト、または「スクリプト公開鍵（PubKey）」は、UTXOのアンロック条件を定義します。

注意すべきは、ビットコインのUTXOの所有権は、ロックスクリプトを通じて表現されることです。自分のUTXOをSamに譲渡する場合、自分の特定のUTXOを破棄するトランザクションを発行し、新しく生成されたUTXOのアンロック条件を「Samのみがアンロックできる」とします。

その後、SamがこれらのBTCを使用する場合、ロック解除スクリプト（Sig）を提出する必要があります。このロック解除スクリプトで、Samは自分自身のデジタル署名を提示して、自分が本当にSamであることを証明しなければなりません。ロック解除スクリプトが前述のロックスクリプトと一致すれば、Samはロックを解除してこれらのBTCを他の人に転送することができます。

（解锁スクリプトはロックスクリプトと一致する必要があります）

表現形式から見ると、ビットコインのチェーン上の各取引は、複数のInputとOutputに対応しており、各Inputには解除したいUTXOが宣言され、解除スクリプトが提出され、そのUTXOが解除され、破壊されます。Outputには、新しく生成されたUTXO情報が表示され、ロックスクリプトの内容が公開されます。

例えば、取引のInputで、あなたがSamであることを証明し、他人から複数のUTXOをアンロックし、統一して破壊し、その後に複数の新しいUTXOを生成し、将来的にxxxがそれらをアンロックできるよう宣言します。

具体的には、取引のInputデータでは、どのUTXOをアンロックするかを宣言し、これらのUTXOデータの「格納位置」を指定する必要があります。ここで注意することは、ビットコインとイーサリアムはまったく異なり、イーサリアムは契約アカウントとEOAアカウントの2つのアカウントを提供しており、資産残高は数字として、契約アカウントまたはEOAアカウントの名前の下に記録され、統一的に「ワールドステート」と呼ばれるデータベースに配置され、送金時には「ワールドステート」から特定のアカウントを直接変更するため、データの格納位置を特定しやすくなっています。

ビットコインには世界状態のデザインはありません。資産データは過去のブロックに分散して格納されています（つまり、ロックされていないUTXOデータは、各トランザクションのOutPutに個別に格納されています）。

あるUTXOをアンロックしたい場合は、そのUTXOの情報が過去のどのトランザクションのOutputに存在するかを説明し、そのトランザクションのID（つまり、そのハッシュ）を提示してビットコインノードに歴史記録を検索させる必要があります。特定のアドレスのビットコイン残高を検索する場合は、すべてのブロックを順序良く走査して、xxアドレスに関連する未解放UTXOを見つける必要があります。

普段ビットコインウォレットを使うと、あるアドレスのビットコイン残高を素早く確認できます。たいていは、ウォレットサービス自体がブロックをスキャンし、すべてのアドレスにインデックスを付けているため、私たちは迅速に検索できます。

（自分のUTXOを他の人に送る取引ステートメントを生成する場合、そのUTXOが属しているトランザクションのハッシュ/IDに基づいて、そのUTXOのビットコインの履歴の中での位置をマークする必要があります）

面白いのは、ビットコイン取引の結果はオフチェーンで計算され、ユーザーはローカルデバイスで取引を生成する際に、直接InputとOutputをすべて作成する必要があるということです。つまり、取引の出力結果を計算します。取引はビットコインネットワークにブロードキャストされ、ノードによって検証された後にチェーンに追加されます。この「オフチェーン計算-オンチェーン検証」モードはイーサリアムとは全く異なります。イーサリアムでは、取引の入力パラメーターのみを提供すればよく、取引結果はイーサリアムノードによって計算され出力されます。

また、UTXOのロックスクリプト（Locking）はカスタマイズ可能で、UTXOを「あるビットコインアドレスの所有者がアンロックできる」と設定できます。そのアドレスの所有者はデジタル署名と公開鍵（P2PKH）を提供する必要があります。また、Pay-to-Hash（P2SH）トランザクションタイプでは、UTXOのロックスクリプトにハッシュを追加でき、そのハッシュに対応するスクリプト原像を提出し、スクリプト原像に設定された条件を満たす人がUTXOをアンロックできます。 BitVMが依存するTaprootスクリプトは、P2SHに似た特性を使用しています。

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

ここでは、P2PKHを例にして、ビットコインスクリプトのトリガーメカニズムを紹介します。トリガーメカニズムを理解することで、より複雑なTaprootとBitVMを理解することができます。P2PKHは「Pay to Public Key Hash」の略で、この方法では、UTXOのロックスクリプトに公開鍵ハッシュが設定され、アンロックする際にはそのハッシュに対応する公開鍵を提供する必要があります。これは一般的なビットコイン送金のアイデアと基本的に同じです。

この時、ビットコインのノードは、アンロックスクリプトの中の公開鍵と、ロックスクリプトで指定された公開鍵ハッシュが一致するかどうかを確認する必要があります。つまり、アンロック人が提出した「鍵」と、UTXOが予め設定した「ロック」が一致しているか確認する必要があります。

さらに言えば、P2PKH方式では、ビットコインノードは取引を受信すると、ユーザーが提供したアンロックスクリプトSigを、アンロックするUTXOのロックスクリプトPubkeyと結合して、BTCスクリプトの実行環境で実行します。以下の図は、実行前の結合結果を示しています:

読者がBTCのスクリプト実行環境を理解していない場合、ここで簡単に紹介します。まず、BTCスクリプトには2つの要素が含まれています。

データとオペコード。これらのデータとオペコードは、左から右に順番にスタックにプッシュされ、指定されたロジックに従って実行され、最終結果が得られます（スタックとは何かについてはここでは詳しく説明しませんが、読者は自分で調べることができます）。

上記の図を例にとると、左側は誰かがアップロードしたアンロックスクリプトSigで、彼のデジタル署名と公開鍵が含まれています。一方、右側のロックスクリプトPubkeyには、UTXOの作成者がそのUTXOを生成する際に設定したオペレーションコードとデータが含まれています（各オペレーションコードの意味を理解する必要はありませんが、大まかに理解してください）。

図の右側にあるロックスクリプトのDUP、HASH160、EQUALVERIFYなどのオペコードは、左側のアンロックスクリプトに含まれる公開鍵をハッシュ化し、ロックスクリプトにあらかじめ設定された公開鍵ハッシュと比較します。両者が一致する場合、アンロックスクリプトにアップロードされた公開鍵とロックスクリプトに設定された公開鍵ハッシュが一致し、これにより最初の検証がパスされます。

しかし、1つ問題があります。UTXOロックスクリプトの内容は実際にはチェーン上で公開されており、誰もがその中に含まれる公開鍵ハッシュを観察することができます。誰もが対応する公開鍵をアップロードし、自分自身をその"選ばれた"人物であるかのように偽ることができます。そのため、公開鍵と公開鍵ハッシュを検証した後、取引発起者がその公開鍵の実際の所有者であるかどうかを検証する必要があります。これにはデジタル署名の検証が必要です。ロックスクリプト内のCHECKSIGオペコードは、デジタル署名の検証を担当しています。

総括すると、P2PKHスキームでは、取引発信者が提出したアンロックスクリプトには、公開鍵とデジタル署名が含まれており、この公開鍵はロックスクリプトで指定された公開鍵ハッシュと一致し、取引のデジタル署名が正しい場合にのみ、UTXOを正常にアンロックできます。

（この図はダイナミックです：P2PKHスキームに基づくビットコインアンロックスクリプトの概念図

出典:** )

もちろん、ビットコインネットワークでは、Pay to public key/public key hashだけでなく、P2SH（Pay to hash）など、さまざまなトランザクションタイプがサポートされています。これは、UTXOの作成時にカスタムロックスクリプトがどのように設定されているかに依存します。

ここでは、P2SHスキームの場合、ロックスクリプトにはハッシュを事前に設定することができます。そして、アンロックスクリプトは、ハッシュに対応するスクリプトの内容を完全に提出する必要があります。ビットコインノードは、このスクリプトを実行することができます。もし、このスクリプトでマルチ署名の検証ロジックが定義されている場合、ビットコインチェーン上でマルチ署名ウォレットの効果を実現することができます。

もちろん、P2SHスキームでは、UTXOの作成者は、将来のUTXOのアンロックをする人に対して、ハッシュに対応するスクリプトの内容を事前に知ってもらう必要があります。両者がこの部分の内容を知っている限り、マルチサインよりも複雑なビジネスロジックを実現することができます。

ここで説明する必要がありますが、ビットコインのチェーン上（ブロック）は、どのUTXOとどのアドレスが関連しているかを直接記録していません。代わりに、UTXOがどの公開鍵のハッシュ/スクリプトのハッシュでアンロックできるかを記録しています。しかし、公開鍵のハッシュ/スクリプトのハッシュに基づいて対応するアドレスを迅速に計算することができます（ウォレット画面に表示される文字化けのようなもの）。

私たちがブロックエクスプローラーやウォレットのインターフェースでxxアドレスにxx量のBTCを見ることができるのは、ブロックエクスプローラーやウォレットのプロジェクトチームがこれらのデータを解析しているためです。彼らはすべてのブロックをスキャンし、ロックスクリプトで宣言された公開鍵ハッシュ/スクリプトハッシュに基づいて、対応する「アドレス」を計算し、次にxxアドレスにいくつのBTCがあるかを表示します。

セグウィットとWitness

P2SHのアイデアを理解した後、BitVMが依存するTaprootにもっと近づくことができます。しかし、その前に、Witnessと隔離された証明という重要な概念を理解する必要があります。

前述のアンロックスクリプトとロックスクリプト、およびUTXOのアンロックプロセスについて述べましたが、1つの問題が明らかになります。トランザクションのデジタル署名はアンロックスクリプトに含まれており、署名を生成する際にはアンロックスクリプトを上書きすることはできません（署名に使用されるパラメータには署名自体を含めることはできません）。そのため、デジタル署名はアンロックスクリプトの外側の部分のみを上書きすることができ、つまりトランザクションデータの主要部分との関連を確立することができますが、トランザクションデータ全体を完全に上書きすることはできません。

こうすることで、取引のアンロックスクリプトに中間者が手を加えても、検証結果に影響を与えない。例えば、ビットコインのノードやマイニングプールは取引のアンロックスクリプトに他のデータを挿入することができ、検証や取引結果に影響を与えない状態で取引データを微細に変化させ、最終的に算出される取引ハッシュ／取引IDも変更される。これが取引の伸長性問題と呼ばれています。

これによって引き起こされる問題は、連続した複数のトランザクションを送信し、順序的な依存関係がある場合（例えば、トランザクション3はトランザクション2の出力を参照し、トランザクション2はトランザクション1の出力を参照する）、後続のトランザクションは必ず前のトランザクションのID（ハッシュ）を参照する必要があります。マイニングプールやビットコインノードなどの任意の仲介者は、ロックスクリプトの内容を微調整することができ、チェーン上でのハッシュが予想と異なるものになる可能性があります。そのため、あらかじめ作成した複数の順序関連のトランザクションは無効になることがあります。

実際には、DLCブリッジとBitVM2のソリューションでは、順序付けられた取引を一括で構築するため、前述のシナリオは一般的です。

簡単に言えば、トランザクションの拡張性の問題は、トランザクションのID/ハッシュ計算時に、アンロックスクリプトのデータが含まれるため、ビットコインのノードなどの中間人がアンロックスクリプトの内容を微調整でき、トランザクションIDがユーザーの期待と一致しないことになります。実際、これはビットコインの初期設計時の考慮不足による歴史的な遺産です。

後のセグウィット/セグウィットのアップグレードは、実際にはトランザクションIDをロック解除スクリプトから完全に切り離すことであり、トランザクションハッシュを計算するときにロック解除スクリプトデータを含める必要はありません。 セグウィットアップグレードUTXOロックスクリプトに続いて、「OP_0」というオペレーションコードがデフォルトで最初の位置に設定され、マーカーとして機能します。 対応するロック解除スクリプトの名前が Sig から Witness に変更されました。

隔離見証ルールに従うと、トランザクションの拡張性の問題は適切に解決され、ビットコインノードに送信されるトランザクションデータが微調整される心配はありません。もちろん、P2WSHはP2SHと本質的には異なりませんので、UTXOロックスクリプトでスクリプトハッシュを事前に設定し、アンロックスクリプトの送信者がハッシュに対応するスクリプトコンテンツをチェーン上に提出して実行することができます。

しかし、実現するスクリプトの内容が非常に大きく、特に多くのコードを含んでいる場合、通常の方法では完全なスクリプトをビットコインのチェーンに送信することができません（各ブロックにはサイズ制限があります）。どうすればいいですか？Taprootを利用して、チェーン上のスクリプトの内容を簡略化する必要があります。そして、BitVMはTaprootを基にした複雑なソリューションです。