BTCに近づく：BitVMを理解するために必要な背景知識（1）
TechFlow厳選深潮セレクト
BTCに近づく：BitVMを理解するために必要な背景知識（1）
本稿では、BitVMの基本的な考え方とビットコインスクリプトおよび分離Witness（セグウィット）について紹介する。
Web3業界の深掘り報道に専念し潮流を洞察執筆：Nickqiao、Faust、Shew Wang、Geek web3
アドバイザー：Bitlayer リサーチチーム
概要：最近Delphi Digitalは「The Dawn of Bitcoin Programmability: Paving the Way for Rollups」と題するビットコインL2に関する技術レポートを発表した。このレポートではBitVMファミリー、OP_CATおよびCovenant制限条項、ビットコインエコシステムのDAレイヤー、ブリッジ、そしてBitlayer、Citrea、Yona、BobといったBitVMを採用する主要なビットコインL2プロジェクトなど、ビットコインRollupに関連する主要概念を体系的に整理している。
同レポートはビットコインL2技術の全体像をある程度示しているが、内容はやや漠然としており詳細に欠けるため、読んでも曖昧な理解にとどまりやすい。極客web3はDelphiのレポートをもとにさらに踏み込んだ分析を行い、BitVMなどの技術をより多くの人々が体系的に理解できるようにすることを目指す。
私たちはBitlayerリサーチチームおよびBitVM中国語コミュニティと共同で、「BTCへ近づく」というシリーズ連載を開始する。今後長期にわたり、BitVM、OP_CAT、ビットコインクロスチェーンブリッジなどの重要トピックを中心に解説を展開し、ビットコインL2関連技術への過剰な神格化を解きほぐし、関心を持つ人々にとっての道筋を整えることを目指す。
数ヶ月前、ZeroSyncの責任者であるRobin Linusが「BitVM: Compute Anything on Bitcoin」という記事を発表し、正式にBitVMという概念を提唱した。これはビットコインL2技術の進展を推し進め、ビットコインエコシステムにおいて最も革新的なイノベーションの一つと言えるだろう。この提唱により、ビットコインL2エコシステム全体が活性化し、Bitlayer、Citrea、BOBといった注目プロジェクトが参入し、市場全体に活気をもたらした。
その後、より多くの研究者がBitVMの改良に参加し、BitVM1、BitVM2、BitVMX、BitSNARKなど、さまざまなバージョンが次々と登場した。その概要は以下の通りである：
-
Robin Linusが昨年最初に提案したBitVMの実装ホワイトペーパーは、仮想的な論理ゲート回路に基づくBitVMの実現方式であり、通称BitVM0と呼ばれる。
-
Robin Linusはその後の講演やインタビューで、非公式ながら仮想CPUに基づくBitVM方式（BitVM1）を紹介した。これはOptimismの詐欺証明システム「Cannon」に類似しており、ビットコインスクリプトを使ってオフチェーンで汎用CPUのような動作を模倣するものである。
-
Robin Linusはまた、許可不要（Permissionless）の単段非対話型詐欺証明プロトコルであるBitVM2を提案している。
-
Rootstock LabsとFairgate LabsのメンバーはBitVMXホワイトペーパーを発表した。BitVM1と同様に、彼らもビットコインスクリプトを用いてオフチェーンで汎用CPUの効果を再現しようとしている。
現在、BitVM関連の開発者エコシステムの構築は徐々に明確になり、周辺ツールの反復的改善も目に見える形で進んでいる。昨年に比べて、BitVMエコシステムはかつての「空中楼閣」から「かすかに姿が見える存在」へと変化している。これにより、ますます多くの開発者やVCがビットコインエコシステムに参入するようになっている。
しかし、大多数の人々にとって、BitVMやビットコインL2に関連する技術用語を理解することは決して容易ではない。なぜなら、まずビットコインスクリプトやTaprootといった基礎知識について体系的に理解する必要があるからだ。現時点でのネット上の参考資料は、長すぎて要点がないか、十分に明快でなく、結局曖昧な理解にとどまってしまうことが多い。我々はこうした問題の解決を目指し、可能な限り明確な言語でビットコインL2周辺の知識を解説することで、読者がBitVM体系に対して体系的な認知を構築できるようにしたい。
MATTとコミットメント：BitVMの基本思想
まず強調すべき点は、BitVMの基盤となる思想がMATT（Merklize All The Things）であるということだ。これは複雑なプログラムの実行プロセスをMerkle Treeという木構造のデータストレージ形式で表現し、ビットコインネイティブの方法で詐欺証明を検証可能にしようとする考え方である。
MATTは複雑なプログラムとそのデータ処理履歴を表現できるが、これらのデータを直接BTCチェーン上に掲載しない。なぜなら、データ量が非常に膨大になるためだ。MATT方式では、データをオフチェーンのMerkle Tree内に保存し、チェーン上にはMerkle Tree最上位の要約（Merkle Root）のみを掲載する。このMerkle Treeは主に以下の3つの核心要素を含む：
-
スマートコントラクトのスクリプトコード
-
コントラクトが必要とするデータ
-
コントラクト実行中に残された痕跡（EVMなどの仮想マシン内でスマートコントラクトが実行される際のメモリやCPUレジスタの変更記録）
（単純なMerkle Tree（メルクル木）の模式図。Merkle Rootは図下部にある8つのデータ断片を複数回ハッシュ計算して得られる）
MATT方式では、極めて小さなサイズのMerkle Rootだけがオンチェーンに保存され、Merkle Treeに含まれる完全なデータセットはオフチェーンに保存される。これは「コミットメント（Commitment）」と呼ばれる考え方を利用している。ここで「コミットメント」とは何であるかを説明しよう。
コミットメントとは、ある種の簡潔な宣言のようなものであり、大量のデータを圧縮した「指紋」と考えてよい。一般的に、オンチェーンにコミットメントを掲載する者は、オフチェーンに正確なデータが存在すると主張する。そして、そのオフチェーンのデータは簡潔な宣言に対応しており、それがまさに「コミットメント」である。
場合によっては、データのハッシュ値自体がそのデータに対する「コミットメント」となる。他のコミットメント方式としてはKZGコミットメントやMerkle Treeなどがある。L2で一般的に使われる詐欺証明プロトコルでは、データ提供者はオフチェーンに完全なデータセットを公開し、オンチェーンにそのデータセットのコミットメントを掲載する。誰かがオフチェーンのデータセットに無効なデータを見つけた場合、オンチェーンのデータコミットメントに対して異議を唱えることができる。
このようにコミットメント（Commitment）を通じて、L2は大量のデータを圧縮処理し、ビットコインチェーン上にはその「コミットメント」だけを掲載できる。もちろん、オフチェーンに保存された完全なデータセットが外部から観測可能であることも保証されなければならない。
現在の主要なBitVM方式（BitVM0、BitVM1、BitVM2、BitVMXなど）は、基本的に似たような抽象構造を採用している：
1. プログラムの分解とコミットメント：まず複雑なプログラムを多数の基本的なオペコードに分解し（コンパイル）、その実行時に生じる痕跡を記録する。（要するに、あるプログラムがCPUやメモリ上で実行されるときの状態変化の記録であり、Traceと呼ばれる）。その後、Traceやオペコードを含むすべてのデータを整理し、データセットとして構成し、そのデータセットのコミットメントを生成する。
具体的なコミットメント方式には、Merkle Tree、PIOPs（様々なZKアルゴリズム）、ハッシュ関数などがある。
2. 資産のステーキングと事前署名：データ提供者と検証者は事前署名を通じて一定額の資産をオンチェーンにロックする必要があり、特定の条件が設けられる。これらの条件は将来発生しうる状況に応じて発動されるもので、もしデータ提供者が悪意を持って行動した場合、検証者は証明を提出してその資産を没収できる。
3. データとコミットメントの公開：データ提供者はオンチェーンにコミットメントを掲載し、オフチェーンに完全なデータセットを公開する。検証者はデータセットを取得し、エラーがないか確認する。オフチェーンデータセットの各部分は、オンチェーンのコミットメントと関連付けられている。
4. 挑戦と罰則：検証者がデータ提供者のデータに誤りを発見した場合、その部分のデータをオンチェーンに持ち込んで直接検証する（そのデータを非常に細かく分割する必要がある）。これが詐欺証明のロジックである。検証結果がデータ提供者がオフチェーンで無効なデータを提供していたことを示した場合、その資産は挑戦した検証者に渡る。
まとめると、データ提供者AliceはオフチェーンでL2取引実行中のすべての痕跡を公開し、対応するコミットメントをオンチェーンに掲載する。ある部分のデータが間違っていることを証明したい場合、まずそのデータがオンチェーンのコミットメントに関連していることをビットコインノードに証明しなければならない（つまり、それらのデータがAlice自身が公開したものであることを証明する）。その後、ビットコインノードがそのデータに誤りがあることを確認する。
以上により、BitVMの全体的な考え方を大まかに理解できた。すべてのBitVM派生バージョンは、基本的に上記の枠組みから逸脱していない。次に、上記プロセスで使用されるいくつかの重要な技術について学んでいこう。まずは最も基礎的なビットコインスクリプト、Taproot、および事前署名から始める。
ビットコインスクリプト（Bitcoin Script）とは何か
ビットコインに関する知識はイーサリアムよりも理解が難しい。最も基本的な送金行為さえ、UTXO（未使用取引出力）、ロックスクリプト（ScriptPubKeyとも呼ばれる）、アンロックスクリプト（ScriptSigとも呼ばれる）など、一連の概念を含んでいる。まずこれら主要な概念について説明しよう。
（ビットコインスクリプトコードの例。より高水準な言語よりも低水準なオペコードで構成されている）
イーサリアムの資産表現方法は支付宝やWeChatに近く、送金ごとに異なるアカウントの残高を加算・減算するだけであり、これはアカウント中心のモデルであり、資産残高は単にアカウント名義の数字にすぎない。一方、ビットコインの資産表現は黄金に似ており、各塊の黄金（UTXO）には所有者が明記されており、送金は古いUTXOを破棄し、新しいUTXOを生成する（所有者は変わる）ことである。
ビットコインUTXOは2つの重要なフィールドを含む：
-
額（「サトシ（satoshi）」単位。1億サトシ＝1BTC）；
-
ロックスクリプト（「スクリプト公開鍵（ScriptPubKey）」とも呼ばれる）。UTXOのアンロック条件を定義する。
注意すべき点は、ビットコインUTXOの所有権はロックスクリプトによって表現されることだ。自分が所有するUTXOをSamに譲渡したい場合、自分のあるUTXOを破棄する取引を発行し、新たに生成されるUTXOのアンロック条件を「Samのみがアンロック可能」と設定すればよい。
その後、Samがこれらのビットコインを使用するには、アンロックスクリプト（ScriptSig）を提出する必要があり、その中で自分のデジタル署名を提示して、自分こそがSam本人であることを証明しなければならない。アンロックスクリプトが前述のロックスクリプトと一致すれば、SamはUTXOをアンロックし、他人に転送できる。
（アンロックスクリプトはロックスクリプトと一致していなければならない）
形式面から見ると、ビットコインチェーン上の各取引は複数の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 Script）はカスタマイズ可能である。UTXOを「あるビットコインアドレスの所有者がアンロック可能」と設定でき、その所有者はデジタル署名と公開鍵を提供する必要がある（P2PKH）。一方、Pay-to-Script-Hash（P2SH）取引タイプでは、UTXOのロックスクリプトにScript Hashを追加でき、そのHashに対応するスクリプトの原像を提出し、かつその原像に予め設定された条件を満たせば、UTXOをアンロックできる。BitVMが依拠するTaprootスクリプトは、P2SHに類似した特性を利用している。
ビットコインスクリプトのトリガー方法
ここではまずP2PKHを例に取り、ビットコインスクリプトのトリガー方法を紹介する。これを理解しない限り、より複雑なTaprootやBitVMを理解することはできない。P2PKHは「Pay to Public Key Hash」の略で、この方式ではUTXOのロックスクリプトに公開鍵ハッシュが設定され、アンロック時にはそのハッシュに対応する公開鍵を提出する必要がある。これは通常のビットコイン送金の考え方とほぼ同じである。
このとき、ビットコインノードは、アンロックスクリプト内の公開鍵が、ロックスクリプトに指定された公開鍵ハッシュと一致するかどうかを確認する必要がある。つまり、アンロック者が提出した「鍵」が、UTXOに予め設定された「錠」に合致しているかを確認する。
さらに言えば、P2PKH方式では、ビットコインノードが取引を受け取った後、ユーザーが提供するアンロックスクリプトScriptSigと、アンロック対象のUTXOのロックスクリプトScriptPubkeyを連結し、BTCスクリプトの実行環境内で実行する。下図は連結前の結果を示す：
読者はBTCスクリプトの実行環境に馴染みがないかもしれない。ここで簡単に紹介する。まず、BTCスクリプトは2種類の要素からなる：
データとオペコード。これらは左から右へ順にスタックにプッシュされ、指定されたロジックに従って実行され、最終結果を得る（スタックとは何かについてはここでは詳述しない。読者はChatgptなどで調べてほしい）。
上図の例では、左側は誰かがアップロードしたアンロックスクリプトScriptSigであり、デジタル署名と公開鍵を含む。一方、右側のロックスクリプトScriptPubkeyには、UTXO作成者がそのUTXOを作成する際に設定した一連のオペコードとデータが含まれている。（ここでは各オペコードの意味を理解する必要はない。大まかな理解でよい）。
上図右側のロックスクリプトにあるDUP、HASH160、EQUALVERIFYなどのオペコードは、左側のアンロックスクリプトに含まれる公開鍵をハッシュ化し、ロックスクリプトに予め設定された公開鍵ハッシュと比較する役割を担う。両者が等しければ、アンロックスクリプトにアップロードされた公開鍵がロックスクリプトの公開鍵ハッシュと一致することになり、第一段階の検証を通過したことになる。
しかし、問題がある。ロックスクリプトの内容はオンチェーンで公開されており、誰でもその中に含まれる公開鍵ハッシュを観測できる。そのため、誰でも対応する公開鍵をアップロードし、「自分が選ばれた人物だ」と偽ることができてしまう。そのため、公開鍵と公開鍵ハッシュの検証後に、取引発信者が本当にその公開鍵の実際の所有者であるかを検証する必要がある。これにはデジタル署名の検証が必要である。ロックスクリプトのCHECKSIGオペコードは、まさにデジタル署名の検証を担当している。
まとめると、P2PKH方式では、取引発信者が提出するアンロックスクリプトには公開鍵とデジタル署名が含まれ、その公開鍵はロックスクリプトに指定された公開鍵ハッシュと一致し、かつ取引のデジタル署名が正しい場合にのみ、UTXOを正常にアンロックできる。
（この図は動的である：P2PKH方式におけるビットコインアンロックスクリプトの模式図
出典：https://learnmeabitcoin.com/technical/script ）
もちろん、ビットコインネットワークではP2PKH以外にも複数の取引タイプがサポートされており、P2SH（Pay to Script hash）などもある。それはすべて、UTXO作成時にカスタマイズされたロックスクリプトの設定内容による。
ここで注意すべき点は、P2SH方式では、ロックスクリプトにScript Hashを事前に設定でき、アンロックスクリプトではそのScript Hashに対応するスクリプト内容を完全に提出する必要がある。ビットコインノードはそのスクリプトを実行できる。もしスクリプト内にマルチシグ検証のロジックが定義されていれば、ビットコインチェーン上でマルチシグウォレットを実現できる。
もちろん、P2SH方式では、UTXO作成者は将来UTXOをアンロックする相手に、事前にScript Hashに対応するスクリプト内容を知らせる必要がある。双方がそのScriptの内容を知っていれば、マルチシグよりも複雑なビジネスロジックを実現できる。
一点補足しておくと、ビットコインチェーン上（ブロック）には、どのUTXOがどのアドレスに関連しているかが直接記録されていない。記録されるのは、UTXOがどの公開鍵ハッシュ／どのスクリプトハッシュでアンロックできるかだけである。ただし、公開鍵ハッシュ／スクリプトハッシュから対応するアドレス（ウォレット画面に表示される乱数のような文字列）を迅速に計算できる。
なぜブロックエクスプローラーやウォレット画面でxxアドレスにxx数量のビットコインがあると見えるのか。それはブロックエクスプローラーやウォレットの運営者がデータを解析し、すべてのブロックをスキャンし、ロックスクリプトに宣言された公開鍵ハッシュ／スクリプトハッシュから対応する「アドレス」を計算し、xxアドレス名義にいくらのビットコインがあるかを表示しているからである。
セグウィットとウィットネス（Witness）
P2SHの考え方を理解した後、BitVMが依拠するTaprootにさらに近づくことができる。しかし、その前に重要な概念を理解しておく必要がある：ウィットネス（Witness）とセグウィット（SegWit）である。
これまで説明したアンロックスクリプトとロックスクリプト、およびUTXOのアンロックプロセスを振り返ると、一つの問題に気づくだろう。デジタル署名はアンロックスクリプトに含まれており、署名生成時にはアンロックスクリプト全体をカバーできない（署名に使うパラメータに署名自体を含めることはできない）。したがって、デジタル署名はアンロックスクリプト以外の部分しかカバーできず、取引データの主幹部分とのみ関連付けられ、取引データ全体を完全にカバーすることはできない。
この結果、中間者が取引のアンロックスクリプトをわずかに改ざんしても、署名検証結果には影響しない。例えば、ビットコインノードやマイニングプールは取引のアンロックスクリプトに他のデータを挿入でき、署名検証や取引結果に影響を与えないまま、取引データに微小な変化を加え、最終的に算出される取引ハッシュ／取引IDも変わってしまう。これを取引のmalleability問題（取引延展性問題）と呼ぶ。
これによる悪影響は、複数の取引を連続して発行し、順序に依存関係がある場合（例えば、取引3が取引2の出力を参照し、取引2が取引1の出力を参照する）に顕著になる。後続の取引は必然的に先行取引のID（ハッシュ）を参照するが、マイニングプールやビットコインノードなどの任意の中間者がアンロックスクリプトの内容を微調整し、取引がチェーンに記録された後のハッシュ値がユーザーの期待と一致しなくなると、あらかじめ作成した複数の順序付き取引が無効になってしまう。
実際に、DLCブリッジやBitVM2の方式では、順序付きの取引を一括して構築するため、前述のシナリオは珍しくない。
簡単に言うと、取引延展性問題は、取引ID／ハッシュの計算時にアンロックスクリプトのデータが含まれるため、ビットコインノードなどの中間者がアンロックスクリプトの内容を微調整し、取引IDがユーザーの期待と一致しなくなることに起因する。これはビットコインの初期設計時の考慮不足による歴史的負債である。
後に導入されたセグウィット（SegWit）アップグレードは、取引IDとアンロックスクリプトを完全に分離するものであり、取引ハッシュの計算時にアンロックスクリプトのデータを含めない。SegWitアップグレードに従うUTXOのロックスクリプトは、先頭に「OP_0」というオペコードを設定し、マークとして機能する。対応するアンロックスクリプトは、SigScriptからWitness（証人）と名称が変更された。
セグウィット規則に従えば、取引延展性問題は適切に解決され、ビットコインノードに送信する取引データが微調整されることを心配する必要がなくなる。もちろん、あまり複雑に考える必要はない。P2WSHの機能は前述のP2SHと本質的に差異はない。UTXOのロックスクリプトにスクリプトハッシュを事前設定し、アンロックスクリプトの提出者が対応するスクリプト内容をチェーン上に提出して実行できる。
しかし、実現したいスクリプト内容が非常に大きく、非常に多くのコードを含む場合、通常の方法では完全なスクリプトをビットコインチェーンに提出できない（各ブロックにはサイズ制限がある）。どうすればよいのか？そこでTaprootの助けを借りる必要がある。上リンクのスクリプト内容を精緻に処理するものであり、BitVMはまさにTaprootに基づいて構築された複雑な方式である。
次回の「BTCへ近づく」シリーズでは、Taprootや事前署名など、BitVMに関連するより複雑な技術について詳しく解説するので、ぜひお楽しみに！
TechFlow公式コミュニティへようこそ
Telegram購読グループ：https://t.me/TechFlowDaily
Twitter公式アカウント：https://x.com/TechFlowPost
Twitter英語アカウント：https://x.com/BlockFlow_News
@godrealmx
