著者: mutourend & lynndell、Bitlayer Labs

原題:「ビットコイン Layer2 スケーリング技術の分析: 有効性の証明と不正の証明」

元のリンク: https://blog.bitlayer.org/Analysis_of_Bitcoin_Layer2_Scaling_Techniques_Validity_Proofs_and_Fraud_Proofs/

特定のアルゴリズム f では、お互いを信頼していない 2 人の参加者アリスとボブは、次の方法で信頼を確立できます。

上記の 2、3、4 について、x をレイヤー 2 トランザクションと開始状態、f をレイヤー 2 コンセンサス プログラム、y をトランザクション終了状態とします。これは、ブロックチェーンのレイヤー 2 拡張計画に対応します。で：

上記の 2、3、4 について、x をレイヤー 2 トランザクションと開始状態、f をレイヤー 2 コンセンサス プログラム、y をトランザクション終了状態とします。これは、ブロックチェーンのレイヤー 2 拡張計画に対応します。で：

表 1: 信頼を築く方法

さらに、次の点にも注意してください。

現在、堅牢性チューリング完全スマート コントラクトの恩恵を受けて、不正防止および有効性証明テクノロジーがイーサリアム レイヤ 2 拡張で広く使用されています。ただし、ビットコインのパラダイムの下では、ビットコインの限られたオペコード機能や 1,000 個のスタック要素などの制限により、これらの技術的アプリケーションはまだ探索段階にあります。この記事では、ビットコイン レイヤ 2 の拡張シナリオを考慮して、ビットコイン パラダイムにおける限界と画期的なテクノロジを要約し、正当性証明および不正証明テクノロジについて研究し、ビットコイン パラダイムにおける独自のスクリプト セグメンテーション テクノロジを整理します。

ビットコインのパラダイムには多くの制限がありますが、さまざまな賢い方法やテクノロジーを使用してこれらの制限を突破できます。たとえば、ビット コミットメントは UTXO ステートレス制限を突破でき、タップルートはスクリプト スペース制限を突破でき、コネクタ出力は UTXO 支払い方法制限を突破でき、コントラクトは署名前の制限を突破できます。

ビットコインは UTXO モデルを採用しており、各 UTXO は、UTXO を使用するために満たさなければならない条件を定義するロック スクリプトでロックされます。ビットコイン スクリプトには次の制限があります。

現在のビットコイン スクリプトは完全にステートレスです。ビットコイン スクリプトを実行すると、各スクリプトの後に実行環境がリセットされます。その結果、ビットコイン スクリプトは、同じ x 値を持つ制約スクリプト 1 とスクリプト 2 をネイティブにサポートできなくなります。ただし、この問題を回避する方法はあります。その中心的な考え方は、何らかの方法で値に署名することです。値に署名を作成できれば、ステートフルなビットコイン スクリプトを実装できます。つまり、スクリプト 1 とスクリプト 2 の x 値の署名をチェックすることで、スクリプト 1 とスクリプト 2 で同じ x 値を強制できます。競合する署名がある場合、つまり、同じ変数 x が 2 つの異なる値で署名されている場合、これにはペナルティが課される可能性があります。解決策はちょっとしたコミットメントです。

ビットコミットメントの原理は比較的単純です。いわゆるビットとは、署名メッセージの各ビットに 2 つの異なるハッシュ値、つまり hash0 と hash1 を設定することを指します。署名が必要なビット値が 0 の場合は、hash0 の preimage0 が公開され、署名が必要なビット値が 1 の場合は、hash1 の preimage1 が公開されます。

単一ビット メッセージ m ∈ {0,1} を例にとると、対応するビット コミットメント ロック解除スクリプトは単なるプリイメージです。ビット値が 0 の場合、対応するロック解除スクリプトは preimage0 - "0xfa7fa5b1dea37d71a0b841967f6a3b119dbea140" になります。 1 の場合、対応するロック解除スクリプトは preimage1——「0x47c31e611a3bd2f3a7a42207613046703fa27496」です。したがって、ビット コミットメントの助けを借りて、UTXO のステートレス制限を破り、ステートフルなビットコイン スクリプトを実装することができ、さまざまな興味深い新機能が可能になります。

OP_HASH160

OP_DUP

<0xf592e757267b7f307324f1e78b34472f8b6f46f3> // これはハッシュ 1 です

OP_EQUAL

OP_DUP

OP_ROT

<0x100b9f19ebd537fdc371fa1367d7ccc802dc2524> // これは hash0 です

OP_EQUAL

OP_BOOLOR

OP_VERIFY

// ビットコミットメントの値は「0」または「1」のいずれかになります。

ビット コミットメントには現在 2 つの実装方法があります。

現在、BitVM2 ライブラリでは、Blake3 に基づくハッシュ関数が Winternitz シグネチャを実装しています。 1 ビットに対応する署名の長さは約 26 バイトです。ビットコミットメントによるステータスの導入コストが高いことがわかります。したがって、BitVM2 プロジェクトの実装では、最初にメッセージをハッシュして 256 ビットのハッシュ値を取得し、次にそのハッシュ値に対してビット コミットメントを実行することで、メッセージの各ビットに対してハッシュ演算を直接実行する代わりに、オーバーヘッドを節約します。オリジナルの長いメッセージ。

2021 年 11 月以降に有効化された Bitcoin Taproot ソフト フォーク アップグレードには、Schnorr 署名 (BIP 340) 、Taproot (BIP 341)、 TapScript (BIP 342) の 3 つの提案が含まれています。新しいトランザクション タイプである Pay-to-Taproot (P2TR) トランザクションが導入されました。 P2TR トランザクションは、Taproot、MAST (マークル抽象構文ツリー)、および Schnorr 署名の利点を組み合わせることで、よりプライベートで柔軟かつスケーラブルなトランザクション形式を作成できます。

P2TR は、キー パスまたはスクリプト パスに基づく支出という 2 つの支出方法をサポートしています。

Taproot (BIP 341) の規定によれば、スクリプト パスで使用する場合、対応するマークル パスの最大長は 128 を超えません。これは、タップツリー内のタップリーフの数が 2128 を超えないことを意味します。 2017 年の segwit アップグレード以来、ビットコイン ネットワークはブロック サイズを重量単位で測定し、最大 400 万重量単位 (つまり約 4MB) をサポートしています。 P2TR 出力がスクリプト パスを通じて使用される場合、公開する必要があるのは 1 つのタップリーフ スクリプトだけです。つまり、ブロックは 1 つのタップリーフ スクリプトでパッケージ化されます。これは、P2TR トランザクションの場合、各タップリーフに対応する最大スクリプト サイズは約 4MB であることを意味します。ただし、ビットコインのデフォルト戦略では、多くのノードは 400K 未満のトランザクションのみを転送します。より大きなトランザクションをパッケージ化したい場合は、マイナーと協力する必要があります。

Taproot によってもたらされたスクリプト スペースのプレミアムにより、既存のオペコードを使用して乗算やハッシュなどの暗号化操作をシミュレートする価値が高まります。

P2TR に基づいて検証可能な計算を構築する場合、対応するスクリプト サイズは 4MB に制限されなくなり、代わりに計算を複数のサブ関数に分割して複数のタップリーフに分散できるため、4MB のスクリプト サイズのスペース制限を突破できます。実際、現在 BitVM2 に実装されている Groth16 検証アルゴリズムのサイズは 2GB にもなります。ただし、ビットコミットメントと組み合わせることで、各サブ関数の入力と出力の一貫性を制約することで、計算全体の完全性と正確性を制約できます。

ビットコインは現在、単一の UTXO に対してネイティブな支払い方法 (スクリプトによる支払いまたは公開キーによる支払い) を提供しています。したがって、対応する正しい公開鍵署名が提供されているか、スクリプト条件が満たされている限り、UTXO を使用できます。 2 つの UTXO は独立して使用できますが、2 つの UTXO を制約する制限を追加することはできません。そのため、使用する前に追加の条件が満たされる必要があります。

しかし、Ark プロトコルの創設者である Burak は、SIGHASH フラグを巧みに使用してコネクタ出力を実現しました。具体的には、アリスは自分の BTC をボブに送信するための署名を作成できます。ただし、署名は複数の入力をコミットできるため、Alice は自分の署名を条件付きに設定できます。署名は、トランザクションが 2 番目の入力を消費する場合に限り、Take_tx トランザクションに対して有効になります。 2 番目の入力はコネクタと呼ばれ、UTXO A と UTXO B を接続します。言い換えれば、Take_tx トランザクションは、UTXO B が Challenge_tx によって消費されていない場合にのみ有効です。したがって、コネクタ出力を破棄することで、Take_tx トランザクションの有効化をブロックできます。

図 1: コネクタ出力図

BitVM2 プロトコルでは、コネクタ出力は if...else 関数として機能します。コネクタ出力がトランザクションによって使用されると、排他性を確保するために別のトランザクションによって使用されることはできません。実際の導入では、チャレンジレスポンス期間を確保するために、タイムロック付きUTXOを追加導入します。さらに、対応するコネクタ出力では、必要に応じてさまざまな支出戦略を設定することもできます。たとえば、チャレンジ トランザクションは誰でも支出できるように設定でき、一方、レスポンス トランザクションはオペレータのみが支出できるように設定したり、期限切れ後に誰でも支出できるように設定したりできます。 。

現在のビットコイン スクリプトは主にロック解除の条件を制限していますが、UTXO のさらなる使用方法は制限していません。その理由は、ビットコイン スクリプトがトランザクション自体の内容を読み取ることができない、つまりトランザクション イントロスペクションを実装できないためです。ビットコインスクリプトでトランザクションの内容（出力も含む）を確認できればコントラクト機能が実現できます。

現在の契約の履行方法は、次の 2 つのカテゴリに分類できます。

有効性証明と不正証明の両方をビットコイン L2 拡張に使用できます。この 2 つの主な違いを表 2 に示します。

有効性証明と不正証明の両方をビットコイン L2 拡張に使用できます。この 2 つの主な違いを表 2 に示します。

表 2: 有効性の証明と不正の証明

ビットコミットメント、タップルート、事前署名、コネクタ出力に基づいて、ビットコインベースの不正証明を構築できます。タップルートに基づいて、OP_CAT などのコントラクト オペレーション コードを導入することにより、ビットコイン ベースの有効性証明書を構築できます。さらに、ボブがアクセス システムを持っているかどうかに応じて、不正行為の証明は、許可された不正の証明と許可のない不正の証明に分類できます。このうち、許可型不正証明では、特定のグループのみがボブとして異議を申し立てることができますが、許可なし不正証明では、任意の第三者がボブとして異議を申し立てることができます。パーミッションレス システムのセキュリティはパーミッション型システムよりも優れており、パーミッション型の各参加者が悪行為を行うリスクを軽減できます。

図 2 に示すように、アリスとボブの間のチャレンジ応答インタラクションの回数に応じて、不正証明は 1 ラウンドの不正証明と複数ラウンドの不正証明に分けることができます。

表 3 に示すように、不正行為の証明は、1 ラウンド インタラクション モデルやマルチラウンド インタラクション モデルなど、さまざまなインタラクション モデルを通じて実現できます。

ビットコイン レイヤ 2 拡張パラダイムの下では、BitVM1 はマルチラウンドの不正防止メカニズムを使用し、BitVM2 は 1 ラウンドの不正防止メカニズムを使用し、 bitcoincircle stark は有効性証明を使用します。このうち、BitVM1 と BitVM2 はビットコイン プロトコルを変更することなく実装できますが、ビットコイン サークル スタークは新しいオペコード OP_CAT の導入が必要です。

ほとんどのコンピューティング タスクでは、ビットコイン シグネット、テストネット、メインネットを 4 MB のスクリプトで完全に表現することはできません。つまり、完全な計算を表すスクリプトは 4 MB 未満のチャンクに分割され、各タップリーフに分散されます。 。

表 3 に示すように、マルチラウンド不正証明は、オンチェーン調停計算の量を削減したいシナリオ、および/または 1 ステップで問題のある計算フラグメントを特定することが不可能なシナリオに適しています。マルチラウンド不正証明では、その名前が示すように、証明者と検証者の間で複数ラウンドのやり取りを行って問題のある計算の断片を特定し、特定された計算の断片に基づいて仲裁を行う必要があります。

表 3 に示すように、マルチラウンド不正証明は、オンチェーン調停計算の量を削減したいシナリオ、および/または 1 ステップで問題のある計算フラグメントを特定することが不可能なシナリオに適しています。マルチラウンド不正証明では、その名前が示すように、証明者と検証者の間で複数ラウンドのやり取りを行って問題のある計算の断片を特定し、特定された計算の断片に基づいて仲裁を行う必要があります。

Robin Linus の初期のBitVM ホワイト ペーパー (BitVM1 と呼ばれることが多い) では、複数回の不正行為の証明が使用されていました。各ラウンドのチャレンジ期間を 1 週間とし、問題の計算フラグメントを見つけるために二分探索法が使用されると仮定すると、Groth16 Verifier のオンチェーンのチャレンジ応答期間は 30 週間にもなり、適時性が非常に劣ります。現在、二分法よりも効率的な n 分検索法に取り組んでいるチームがありますが、その適時性は、不正行為の証明のラウンドにおける 2 週間のサイクルよりもはるかに低いです。

現在、ビットコインパラダイムに基づく複数ラウンドの不正証明はすべて許可付きチャレンジを使用しますが、1 ラウンドの不正証明では許可なしチャレンジ方式が実装されており、これにより参加者間の共謀のリスクが軽減され、セキュリティが向上します。この目的を達成するために、Robin Linus はタップルートを最大限に活用して BitVM1 を最適化しました。インタラクションラウンドの数が 1 つに減るだけでなく、チャレンジ方法が許可のないものに拡張されますが、その代償としてオンチェーンのアービトレーション計算量が増加します。

検証不正の証明は、証明者と検証者の間で 1 回の対話だけで完了できます。このモデルでは、検証者は一度だけチャレンジを開始する必要があり、証明者は一度だけ応答する必要があります。この応答では、証明者は計算が正しいと主張する証拠を提供する必要があります。検証者がこの証拠から矛盾を見つけることができればチャレンジは成功し、そうでない場合はチャレンジは失敗します。インタラクティブな不正行為の証明の 1 ラウンドの特性を表 3 に示します。

Robin Linus は、2024 年 8 月 15 日に「BitVM2: ビットコインを第 2 層にブリッジする」テクニカル ホワイト ペーパーをリリースしました。このペーパーでは、図 3 と同様の方法を使用して、一連の不正行為を防止する BitVM2 クロスチェーン ブリッジを実装しました。

OP_CAT は、ビットコインが最初にリリースされたときのスクリプト言語の一部でしたが、セキュリティの脆弱性のため 2010 年に無効になりました。しかし、ビットコインコミュニティは数年前からビットコインの活性化について議論してきました。現在、 OP_CAT には 347 番が割り当てられており、ビットコイン シグネットで有効になっています。

OP_CAT の主な機能は、スタック内の 2 つの要素を結合し、結合された結果をスタックにプッシュすることです。この機能により、ビットコインでのコントラクトと STARK Verifier が有効になります。

SNARK/STARK によって証明された後、証明を検証するために対応する検証アルゴリズムを実行するのに必要な計算量は、元の計算 f を直接実行するのに必要な計算量よりもはるかに少なくなります。ただし、これをビットコイン スクリプトでの検証アルゴリズムの実装に変換すると、必要なスクリプトの量は依然として膨大になります。現在、既存のビットコイン オペコードに基づいて、最適化後の実現された Groth16 検証スクリプト サイズと Fflonk 検証スクリプト サイズは依然として 2 GB を超えています。ただし、単一のビットコイン ブロックのサイズはわずか 4MB であり、検証スクリプト全体を単一のブロックで実行することは不可能です。ただし、タップルートのアップグレード後、ビットコインはタップリーフによるスクリプトの実行をサポートします。検証スクリプトは複数のチャンクに分割でき、各チャンクはタップツリーを構築するためのタップリーフとして使用されます。各チャンク間では、ビットコミットメントが使用され、チャンク間の値の一貫性が保証されます。

OP_CAT コントラクトを使用すると、STARK Verifier を 400KB 未満の複数の標準トランザクションに分割できるため、マイナーと協力することなく STARK 有効性証明書全体の検証を完了できます。

このセクションでは、既存の状況を活性化するための新しいオペコードを導入することなく、ビットコイン スクリプトの関連する分割テクノロジに焦点を当てます。

スクリプトをセグメント化するときは、次の次元情報のバランスを取る必要があります。

現在、スクリプトの分割方法は主に次の 3 つのカテゴリに分類されます。

現在、スクリプトの分割方法は主に次の 3 つのカテゴリに分類されます。

たとえば、複数回の最適化を経て、Groth16 ベリファイアはスクリプト サイズを約 7 GB から約 1.26 GB に削減しました。この全体的な計算の最適化に加えて、スタック スペースを最大限に活用するために各チャンクを個別に最適化することもできます。たとえば、ルックアップ テーブルに基づいたより優れたアルゴリズムを導入し、ルックアップ テーブルを動的にロードおよびアンロードすることにより、各チャンクのスクリプト サイズをさらに削減できます。

Web2 プログラミング言語の計算コストと実行環境は、ビットコイン スクリプトのコストと実行環境とはまったく異なるため、さまざまなアルゴリズムのビットコイン スクリプト実装では、既存の実装を翻訳するだけでは機能しません。したがって、ビットコインのシナリオでは次の最適化を考慮する必要があります。

この記事では、まずビットコイン スクリプトの制限を紹介し、UTXO ステートレス制限を突破するためのビットコイン プロミスの使用、スクリプト スペースの制限を突破するための Taproot の使用、UTXO の支出方法の制限を突破するためのコネクタ出力の使用、および署名前の制限を突破するための契約の使用。そして、不正証明と正当性証明の特徴、許可型不正証明と許可なし型不正証明の特徴、1回の不正証明と複数回の不正証明の特徴、ビットコインスクリプトセグメンテーション技術などを包括的に整理してまとめました。