著者: Nickqiao & Faust & Shew Wang、オタク web3

コンサルタント: ビットレイヤー研究チーム

まとめ：

最近、Delphi Digital は、「ビットコイン プログラマビリティの夜明け: ロールアップへの道を開く」と題したビットコインの第 2 層に関する技術調査レポートをリリースしました。このレポートでは、BitVM ファミリ バケット、OP_CAT、およびビットコイン ロールアップに関連する中心的な概念が体系的に整理されています。コベナントの制限、ビットコインのエコロジカル DA レイヤー、ブリッジ、および Bitlayer、Citrea、Yona、Bob を含む BitVM を使用する 4 つの主要なビットコインの第 2 レイヤー。

研究報告書はビットコインの第2層技術の全体像を概ね示しているものの、比較的一般的な内容で詳細な説明が不足しており、わかりにくい。 Geek web3 は、より多くの人が BitVM やその他のテクノロジを体系的に理解できるように、Delphi 研究レポートに基づいて広範囲にわたる詳細な調査を実施しました。

私たちは、Bitlayer 研究チームおよび BitVM 中国コミュニティと共同で「BTC へのアプローチ」と呼ばれる一連のコラムを立ち上げ、BitVM、OP_CAT、ビットコイン クロスチェーン ブリッジなどの重要なトピックを中心に長期的な科学普及を実施し、BTC の魔法を解くことに尽力します。ビットコインをより多くの人に。コイン レイヤー 2 関連テクノロジーは、より多くの愛好家への道を切り開くのに役立ちます。

文章：

数か月前、ZeroSync の責任者である Robin Linus は、「BitVM: Compute Anything on Bitcoin」という記事を発表し、BitVM の概念を正式に提案し、ビットコインの第 2 層テクノロジーの進歩を促進しました。これは、ビットコインエコシステムの中で最も革新的なイノベーションの1つであると言え、ビットコインの第2層エコシステム全体を爆発させ、Bitlayer、Citrea、BOBなどのスタープロジェクトの参加を引き付け、ビットコインエコシステムに活力をもたらしました。市場全体。

その後、より多くの研究者が BitVM の改良に参加し、BitVM1、BitVM2、BitVMX、BitSNARK などのさまざまな反復バージョンを次々と立ち上げました。一般的な状況は次のとおりです。

  1. 昨年 Robin Linus によって最初に提案された BitVM 実装のホワイト ペーパーは、BitVM0 と呼ばれる架空の論理ゲート回路に基づく BitVM 実装です。

  2. その後のいくつかのスピーチやインタビューで、Robin Linus は、Optimism の不正防止システム Cannon に似た、ビットコイン スクリプトを使用して汎用のオフチェーン効果をシミュレートできる、架空の CPU に基づく BitVM ソリューション (BitVM1 と呼ばれる) を非公式に紹介しました。 。

  3. Robin Linus は、許可不要のシングルステップの非対話型不正防止プロトコルである BitVM2 も提案しました。

  4. Rootstock Labs と Fairgate Labs のメンバーは、BitVM1 と同様に、ビットコイン スクリプトを通じて汎用 CPU (オフチェーン) の効果をシミュレートしたいと考えています。

現在、BitVM関連の開発者エコシステムの構築はますます明確になってきており、周辺ツールの反復的な改善も目に見えて分かるようになり、昨年に比べて現在のBitVMエコシステムは初期の「城」から「ぼんやりと見える」ようになってきました。また、より多くの開発者やベンチャーキャピタルがビットコインエコシステムに殺到しています。

しかし、ほとんどの人にとって、BitVM とビットコイン レイヤ 2 に関連する技術用語を理解するのは簡単ではありません。それは、まず、それに関する基本的な知識、特にビットコイン スクリプトやタップルートの知識などの背景を体系的に理解する必要があるからです。現在、インターネット上で公開されている参考資料は、長すぎて意味不明なことばかりであったり、説明が不十分で、わかっているようで理解できていないものがあります。私たちは上記の問題を解決することに尽力し、より多くの人々がビットコインの第 2 層に関する周辺知識を理解し、BitVM システムの体系的な理解を確立できるよう、可能な限り明確な言語を使用するよう努めています。

MATT とコミットメント: BitVM の基本的な考え方

まず最初に強調しておきたいのは、BitVM の基本的な考え方は MATT、つまり Merkleize All The Things を意味し、主に Merkle Tree などのツリー状のデータ ストレージ構造を使用して複雑なプログラムの実行プロセスを表示することを指します。ビットコインネイティブの検証詐欺を証明しようとします。

MATT は複雑なプログラムとそのデータ処理トレースを表現できますが、これらのデータ全体の規模が非常に大きいため、これらのデータを BTC チェーンに直接公開することはありません。 MATT を使用するソリューションは、オフチェーンのマークル ツリーにデータのみを保存し、マークル ツリーのトップ サマリー (マークル ルート) のみをチェーンに公開します。このマークル ツリーには主に 3 つのコア コンテンツが含まれています。

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

  • 契約で必要なデータ

  • コントラクト実行時に残るトレース（EVMなどの仮想マシンでスマートコントラクトを実行する際のメモリやCPUレジスタの変更記録）

MATT スキームでは、非常に小さいマークル ルートのみがチェーン上に保存され、マークル ツリーに含まれる完全なデータ セットはオフチェーンに保存されます。これは、「コミットメント」と呼ばれる考え方を使用します。ここでは「コミットメント」とは何かについて説明します。

Promise は簡潔なステートメントに似ており、大量のデータを圧縮して得られる「フィンガープリント」と考えることができます。一般に、チェーン上で「コミットメント」を発行する人は、オフチェーンに保存されている特定のデータが正確であると主張し、このステートメントが「コミットメント」となります。

ある時点で、データのハッシュは、データ自体に対する「コミットメント」として使用できます。他のコミットメント スキームには、KZG コミットメントまたはマークル ツリーが含まれます。レイヤ 2 の通常の不正防止プロトコルでは、データ発行者は完全なデータセットをオフチェーンで公開し、そのデータセットをオンチェーンで公開することを約束します。誰かがオフチェーン データセット内で無効なデータを発見した場合、オンチェーン データ コミットメントに異議が唱えられます。

コミットメントを通じて、2 番目のレイヤーは大量のデータを圧縮し、その「コミットメント」のみをビットコイン チェーンに公開できます。もちろん、オフチェーンにリリースされた完全なデータセットが外部から観察できるようにすることも必要です。

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

1. プログラムの分解とコミット: まず、複雑なプログラムを多数の基本的なオペレーション コードに分解 (コンパイル) し、特定の実行中にこれらのオペレーション コードによって生成されるトレースを記録します (端的に言えば、プログラムは CPU 上で実行されます)。メモリ内では、状態変化全体が記録され、トレースと呼ばれます)。その後、トレースやオペコードを含むすべてのデータをデータ セットに編成し、データ セットのコミットメントを生成します。

特定のコミットメント スキームは、マークル ツリー、PIOP (さまざまな ZK アルゴリズム)、ハッシュ関数など、さまざまな形式を取ることができます。

2. アセットのプレッジと事前署名: データ発行者と検証者は、事前署名を通じてチェーン上の一定量のアセットをロックする必要があり、制限があります。これらの条件は、特に将来発生する可能性のある状況に対してトリガーされ、データ発行者が悪事を行った場合、検証者は証明書を送信してデータ発行者の資産を奪うことができます。

3. データとコミットメントの公開: データ公開者はチェーン上でコミットメントを公開し、完全なデータセットはチェーン外で公開され、検証者はデータセットを取得してエラーがあるかどうかを確認します。オフチェーン データセットのすべての部分は、オンチェーン コミットメントと相関関係があります。

4. 課題とペナルティ: データ発行者が提供したデータにエラーがあることを検証者が発見すると、直接検証するためにデータのこの部分をチェーンに取り込みます (データのこの部分は最初に非常に細かく切り取られる必要があります) ）これが不正行為の証明のロジックです。検証の結果、データ発行者が実際に無効なデータをオフチェーンに提供したことが示された場合、その資産は、データ発行者に異議を申し立てたバリデーターによって取り上げられます。

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

これで、BitVM の全体的な考え方が大まかに理解でき、すべての BitVM バリアントは基本的に上記のパラダイムから切り離すことができません。次に、最も基本的なビットコイン スクリプトであるタップルートと事前署名から始めて、上記のプロセスで使用されるいくつかの重要なテクノロジを学習して理解しましょう。

ビットコインスクリプトとは何ですか?

ビットコイン関連の知識は、最も基本的な転送動作でさえ、UTXO (未使用のトランザクション出力)、ロック スクリプト (ScriptPubKey とも呼ばれます)、アンロック スクリプト (ScriptSig とも呼ばれます) などの一連の概念を必要とします。まずはこれらの主な概念について説明しましょう。

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

イーサリアムでの資産の表現方法は、Alipay や WeChat に似ています。この方法は、さまざまなアカウントの残高を加算および減算するだけであり、資産残高は、ビットコインの資産の下にある単なる数値です。この表現は、より金に似ています。各金 (UTXO) にはその所有者がマークされます。転送により、古い UTXO が破壊され、新しい UTXO が生成されます (所有者は変わります)。

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

「サトシ」で表した金額（1億サトシは1BTC）。

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

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

その後、サムがこれらのビットコインを使用したい場合は、ロック解除スクリプト (ScriptSig) を送信する必要があります。このロック解除スクリプトでは、サム自身であることを証明するためにデジタル署名を提示する必要があります。ロック解除スクリプトが前述のロック スクリプトと一致する場合、サムはビットコインのロックを解除して他の人に転送できます。

(ロック解除スクリプトはロック スクリプトと一致する必要があります)

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

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

具体的には、トランザクションの入力データで、どの UTXO をロック解除するかを宣言し、これらの UTXO データの「保管場所」を指定する必要があります。ここで注意していただきたいのは、ビットコインとイーサリアムは、データを保存するための契約アカウントとEOAアカウントの2種類のアカウントを提供しており、資産残高は契約アカウントまたはEOAアカウントの名前で数値として記録されます。 「World State」のデータベースでは、「World State」という統合ファイルに配置されます。送金の際、データの保存場所を見つけやすくするために、「World State」から特定のアカウントを直接変更できます。

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

UTXO のロックを解除したい場合は、過去にどのトランザクションの UTXO 情報が存在するかを示し、トランザクションの ID (ハッシュ) を表示し、ビットコイン ノードに履歴レコードでそれを検索させる必要があります。特定のアドレスのビットコイン残高をクエリする場合は、最初からすべてのブロックを走査して、xx アドレスに関連付けられているロック解除された UTXO を見つける必要があります。

通常、ビットコインウォレットを使用すると、特定のアドレスが所有するビットコイン残高をすぐに確認できます。これは、多くの場合、ウォレットサービス自体がブロックをスキャンすることですべてのアドレスにインデックスを作成し、迅速なクエリが容易になるためです。

(UTXO を他の人に渡すトランザクション ステートメントを生成するときは、これらの UTXO が属するトランザクション ハッシュ/ID に基づいて、ビットコイン履歴内の UTXO の位置をマークする必要があります)

興味深いことに、ビットコイン トランザクションの結果はオフチェーンで計算されます。ユーザーがローカル デバイスでトランザクションを生成する場合、入力と出力の両方を直接作成する必要があります。これは、トランザクションの出力結果を計算するのと同じです。トランザクションはビットコイン ネットワークにブロードキャストされ、チェーンに追加される前にノードによって検証されます。この「オフチェーン計算オンチェーン検証」モデルは、イーサリアムとはまったく異なります。イーサリアムでは、トランザクション入力パラメーターを指定するだけで、トランザクション結果はイーサリアム ノードによって計算され、出力されます。

さらに、UTXO ロック スクリプト (Locking Script) はカスタマイズ可能で、「特定のビットコイン アドレスの所有者がロックを解除できる」ように UTXO を設定できます。アドレスの所有者はデジタル署名と公開キー (P2PKH) を提供する必要があります。 。 Pay-to-Script-Hash (P2SH) トランザクション タイプでは、UTXO ロック スクリプトにスクリプト ハッシュを追加できます。このハッシュに対応するスクリプト オリジナル イメージを送信でき、スクリプト オリジナル イメージ内の事前設定された条件を満たすことができます。 UTXOのロックを解除できます。 BitVM が依存する Taproot スクリプトは、P2SH と同様の機能を使用します。

ビットコインスクリプトをトリガーする方法

ここでは、まず P2PKH を例として、ビットコイン スクリプトのトリガー方法を紹介します。そのトリガー方法を理解することによってのみ、より複雑な Taproot と BitVM を理解することができます。 P2PKH の正式名は「Pay to Public Key Hash」です。このスキームでは、UTXO ロック スクリプトに公開キー ハッシュが設定され、ロックを解除するときにそのハッシュに対応する公開キーを送信する必要があります。従来のビットコイン送金の考え方と同じです。

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

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

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

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

上の図を例にとると、左側は誰かがアップロードしたロック解除スクリプト ScriptSig (デジタル署名と公開キーを含む) で、右側のロック スクリプト ScriptPubkey には、UTXO 作成者が生成時に設定したオペコードとデータが含まれています。 UTXO (ここでは各オペコードの意味を理解する必要はありません。大まかに理解するだけです)。

上の図の右側のロック スクリプト内の DUP、HASH160、EQUALVERIFY およびその他のオペレーション コードは、左側のロック解除スクリプトに含まれる公開キーをハッシュし、それをロック スクリプト内のプリセット公開キー ハッシュと比較する役割を果たします。 2 つの値が等しい場合、ロック解除スクリプトでアップロードされた公開キーが、ロック スクリプトで事前に設定された公開キー ハッシュと一致し、最初の検証に合格したことを意味します。

ただし、問題があります。UTXO ロック スクリプトの内容は実際にはチェーン上で公開されており、誰でもその中に含まれる公開キーのハッシュを観察して、自分が「」であると偽ることができます。皇帝によって任命された」。したがって、公開鍵と公開鍵ハッシュを検証した後、トランザクションの開始者が本当に公開鍵の実際の管理者であるかどうかを検証する必要があり、これにはデジタル署名の検証が必要です。ロック スクリプト内の CHECKSIG オペコードは、デジタル署名を検証する役割を果たします。

要約すると、P2PKH スキームでは、トランザクション開始者によって送信されたロック解除スクリプトには公開キーとデジタル署名が含まれている必要があり、その公開キーはロック スクリプトで指定された公開キー ハッシュと一致する必要があり、トランザクションのデジタル署名のみが正しいということになります。これらの条件が満たされると、UTXO のロックをスムーズに解除できます。

(この画像は動的です: P2PKH スキームに基づくビットコインのロック解除スクリプトの概略図

出典: https://learnmeabitcoin.com/technical/script)

もちろん、ビットコイン ネットワークは、公開鍵/公開鍵ハッシュへの支払いだけでなく、P2SH (スクリプト ハッシュへの支払い) など、複数のトランザクション タイプをサポートしています。すべては、UTXO の作成時にカスタム ロック スクリプトがどのように設定されているかによって決まります。 。

ここで、P2SH スキームでは、ロック スクリプトにスクリプト ハッシュを事前に設定でき、ロック解除スクリプトでは、スクリプト ハッシュに対応するスクリプト コンテンツの完全な送信が必要であることに注意してください。ビットコインノードはこのスクリプトを実行でき、マルチシグネチャ検証のロジックがこのスクリプトで定義されている場合、ビットコインチェーン上でマルチシグネチャウォレットの効果を実現できます。

もちろん、P2SH スキームでは、UTXO 作成者は、将来 UTXO のロックを解除する人に、スクリプト ハッシュに対応するスクリプトの内容を事前に知らせる必要があります。このスクリプトの内容を双方が知っていれば、実装することができます。マルチ署名よりも複雑なビジネス ロジック。

ここで注意すべき点の 1 つは、ビットコイン チェーン (ブロック) は、どの UTXO がどのアドレスに関連付けられているかを直接記録するのではなく、UTXO のロックを解除できる公開キー ハッシュとスクリプト ハッシュのみを記録することですが、公開キー ハッシュに基づいています。 /script Hash は、対応するアドレスを迅速に計算できます (ウォレットのインターフェイスに表示されるセクションは文字化けのように見えます)。

ブロックエクスプローラーとウォレットインターフェイスでxxアドレスの下にxx量のビットコインが表示される理由は、ブロックエクスプローラーとウォレットプロジェクトがデータの解析、すべてのブロックのスキャン、および公開キーハッシュ/スクリプトハッシュに従ってスクリプトをロックするのに役立つためです。で宣言され、対応する「アドレス」を計算し、xx アドレスの名前の下にビットコインが何枚あるかを表示します。

隔離された証人および証人

P2SH の考え方を理解すると、BitVM が依存する Taproot に一歩近づきます。しかしその前に、「証人」と「隔離された証人」という重要な概念を理解する必要があります。

前述のロック解除スクリプトとロック スクリプト、および UTXO ロック解除プロセスを確認すると、問題が見つかります。トランザクションのデジタル署名はロック解除スクリプトに含まれており、署名の生成時にロック解除スクリプトを上書きすることはできません ( (署名の生成に使用されるパラメータには署名自体を含めることはできません)、そのため、デジタル署名はロック解除スクリプト以外の部分のみをカバーできます。つまり、デジタル署名はトランザクション データの主要部分にのみ関連付けることができ、トランザクションを完全にカバーすることはできません。データ。

このように、仲介者によってトランザクションロック解除スクリプトが多少改ざんされても、署名検証結果には影響を与えません。たとえば、ビットコイン ノードやマイニング プールは、トランザクションのロック解除スクリプトに他のデータを挿入する可能性があり、署名検証やトランザクション結果に影響を与えることなく、トランザクション データに微妙な変更が生じる可能性があり、最終的に計算されたトランザクション ハッシュ/トランザクション ID も変更されます。これは、トランザクションの順応性の問題として知られています。

この欠点は、複数のトランザクションを連続して開始する予定で、逐次依存関係がある場合 (たとえば、トランザクション 3 がトランザクション 2 の出力を参照し、トランザクション 2 がトランザクション 1 の出力を参照する)、後続のトランザクションが以前のトランザクションの ID (ハッシュ) を引用する必要があります。マイニング プールやビットコイン ノードなどの仲介者は、トランザクションがアップロードされた後のハッシュが期待したものと一致しないように、ロック解除スクリプトの内容を微調整できます。事前に作成した複数のトランザクションは、連続して関連するトランザクションは無効になります。

実際、DLC ブリッジと BitVM2 ソリューションでは、逐次相関のあるトランザクションがバッチで構築されるため、上記のシナリオは珍しいことではありません。

簡単に言うと、トランザクションのスケーラビリティの問題は、トランザクション ID/ハッシュを計算するときにロック解除スクリプトのデータが含まれるため、ビットコイン ノードなどの仲介者がロック解除スクリプトの内容を微調整できるため、トランザクション ID がユーザーが予期したものと異なる場合は、互換性がありません。実際、これはビットコインの初期設計における不十分な考慮によって残された歴史的な荷物です。

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

SegWit ルールに従えば、トランザクションのスケーラビリティの問題は適切に解決され、ビットコイン ノードに送信されるトランザクション データが微調整されることを心配する必要はありません。もちろん、P2WSH の機能は前述の P2SH と本質的には変わりません。UTXO ロック スクリプトにスクリプト ハッシュを設定し、ロック解除スクリプトの送信者が送信するのを待つことができます。ハッシュに対応するスクリプトの内容をチェーンに追加して実行します。

ただし、実装したいスクリプトの内容が特に大きく、多くのコードが含まれている場合、従来の方法では完全なスクリプトをビットコイン チェーンに送信できません (各ブロックにはサイズ制限があります)。何をするか？これには、Taproot を使用してチェーン上のスクリプト コンテンツを合理化する必要があり、BitVM は Taproot に基づいて構築された複雑なソリューションです。