1 イントロダクション

アルゴリズムfの場合、相互に信用しない参加者であるアリスとボブは、以下の方法で信頼関係を確立することができます:

1. アリスはxを入力し、アルゴリズムfを実行し、結果yを得ます。ボブも同じ入力xでアルゴリズムfを実行し、結果y'を得ます。y = y'ならば、ボブはアリスの提供した入力xと出力yを認めます。これはブロックチェーンのコンセンサスでよく使用される特別な有効性証明メカニズムであり、アリスはブロックをパッケージングするノードであり、ボブはコンセンサスに参加するノードです。
2. Aliceは、xを入力し、アルゴリズムfでzk.proveプログラムを実行し、結果yと証明proofを得ます。Bobは、f、y、およびproofに基づいてzk.verifyプログラムを実行します。結果がtrueの場合、BobはAliceの結果yを承認します。結果がfalseの場合、BobはAliceの結果yを承認しません。これは有効性の証明であり、Bobはオンチェーンの契約であることができます。
3. アリスはxを入力し、アルゴリズムfを実行し、結果yを得ます。ボブも同じ入力xでアルゴリズムfを実行し、結果y′を得ます。y = y′であれば何も行われません。y ≠ y′であれば、ボブはfをチャレンジし、チャレンジされたプログラムはfです。アリスとボブの間の相互作用の回数は1回または複数回になります。仲裁はチャレンジ・レスポンス・プロセスによって達成されます。これは詐欺証明であり、ボブはオフチェーンでリッスンし、オンチェーンでチャレンジします。
4. アリスはxを入力し、アルゴリズムfでzk.proveプログラムを実行し、結果yと証明proofを取得します。ボブはf、y、およびproofに基づいてzk.verifyプログラムを実行します。結果がtrueの場合、何も行われません。結果がfalseの場合、ボブはzk.verifyを挑戦プログラムとしてアリスに挑戦します。アリスとボブの間の相互作用の回数は1回または複数回になります。仲裁は挑戦-応答プロセスを通じて達成されます。これは、Bobがチャレンジャーであり、オフチェーンでリスニングし、オンチェーンで挑戦する詐欺証明です。

上記の2、3、4について、xをレイヤー2トランザクションと初期状態、fをレイヤー2コンセンサスプログラム、yをトランザクションの終了状態とします。これはブロックチェーンのレイヤー2スケーリングソリューションに対応しています。

• 有効性の証明：悲観的な仮定に基づいて、受け入れられる前に有効であることを証明しなければならず、即座に効力を発揮します。有効性の証明では、正しいL2状態遷移の証拠を提供する必要があり、世界の悲観的な見方を反映しています。状態が正しいことが証明されたときにのみ受け入れられます。
• 詐欺証明：楽観的な仮定に基づいて、デフォルトで受け入れられますが、誰かがそれが間違っていることを証明するまでです。チャレンジウィンドウ期間があり、チャレンジウィンドウ期間後にのみ効果があります。詐欺証明では、L2の状態遷移が正しくないことの証拠を提供する必要があり、楽観的な世界観を反映しています。つまり、状態遷移は正しいと仮定されますが、証明されなければなりません。

表1：信頼を確立する方法

さらに、重要なことに注意することが重要です:

• 詐欺証明と有効性証明を区別する鍵は、SNARK/STARKなどのZK証明システムが使用されているかどうかではありません。ZK証明システムは使用される証明方法を表し、詐欺または有効性は証明される内容を表します。これが、表1のシナリオ1が有効性証明を表すと言われる理由です。
• 有効性の証明はよりタイムリーですが、オンチェーンの検証の複雑さは比較的高いです。一方、詐欺証明はオンチェーンの検証の複雑さが低いですが、タイムリネスは比較的低いです。
• 表1のケース2および4の場合、ZK再帰と組み合わせ技術を使用して、複数のfを計算および圧縮することができ、オフチェーン計算の検証コストを大幅に削減することができます。

現在、Solidityのチューリング完全スマートコントラクトから利益を得て、詐欺証明および有効性証明技術は、Ethereum Layer2スケーリングで広く使用されています。しかし、Bitcoinの範囲内では、Bitcoinの限られたオペコード機能、1000のスタック要素、およびその他の制限により、これらの技術の適用はまだ試験的な段階にあります。この記事では、Bitcoinの範囲内でのBitcoin Layer2スケーリングの文脈での制限とブレークスルー技術をまとめ、有効性証明と詐欺証明技術を研究し、Bitcoinの範囲内でのユニークなスクリプトセグメンテーション技術を概説しています。

ビットコインパラダイムの下での2つの制限と突破口

ビットコインのパラダイムの下では多くの制限がありますが、これらの制限を克服するためにさまざまな巧妙な方法やテクニックを使うことができます。例えば、ビットコミットメントはUTXOの状態制限を突破することができ、タップルートはスクリプト空間の制限を突破することができ、コネクタ出力はUTXOの支出方法の制限を突破することができ、契約は事前署名の制限を突破することができます。

2.1 UTXOモデルとスクリプトの制限

ビットコインはUTXOモデルを採用しており、各UTXOはロックスクリプトにロックされており、そのUTXOを支払うために満たす必要がある条件を定義しています。ビットコインスクリプトには以下の制限があります:

1. ビットコインスクリプトは状態を持たず、
2. P2TR出力タイプの場合、1つのトランザクションに収容できるオペコードの最大数は約400万で、ブロック全体を埋め尽くしますが、他の出力タイプの場合はわずか1万のオペコードしかありません。
3. 単一のUTXOの支出方法は限られており、組み合わせた支出方法の探求が不足しています；
4. 柔軟な契約機能はサポートされていません;
5. スタックサイズは、最大1000要素（altstack + stack）に制限されており、単一要素の最大サイズは520バイトです。
6. 算術演算（加算や減算など）は、4バイトの要素に制限されています。これらは、暗号操作に必要な20バイト以上の長い要素に変更することはできません。
7. OPMULやOPCATのようなオペコードは無効化されており、既存のオペコードでシミュレートすると非常に高いコストがかかります。たとえば、スクリプトサイズが約75Kの場合、1ラウンドのBLAKE3ハッシュをシミュレートすると、非常に高いコストがかかります。

2.2 ビットコミットメント: UTXOステートレス制限の突破

現在、ビットコインスクリプトは完全にステートレスです。ビットコインスクリプトを実行すると、その実行環境は各スクリプトの後にリセットされます。これにより、ビットコインスクリプトは、同じx値を持つ制約スクリプト1と2をネイティブにサポートできなくなります。ただし、この問題はいくつかの方法で回避でき、核となる考え方は何らかの方法で値に署名することです。値に対して署名を作成できる場合は、ステートフルなビットコインスクリプトを実現できます。つまり、スクリプト 1 と 2 の x 値の署名をチェックすることで、両方のスクリプトで同じ x 値が使用されるように強制できます。矛盾するシグネチャがある場合、つまり、同じ変数 x に対して 2 つの異なる値に符号が付けられている場合、ペナルティが適用される可能性があります。このソリューションは、ビットコミットメントと呼ばれます。

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

単一のビットメッセージm ∈{0,1}を例に取ると、対応するビットコミットメントアンロックスクリプトはいくつかのプレイイメージです。ビットの値が0の場合、対応するアンロックスクリプトはpreimage0である「0xfa7fa5b1dea37d71a0b841967f6a3b119dbea140」です。ビットの値が1の場合、対応するアンロックスクリプトはpreimage1である「0x47c31e611a3bd2f3a7a42207613046703fa27496」です。したがって、ビットコミットメントを使用することで、UTXOの状態制限を突破し、状態を持つBitcoinスクリプトを実現し、さまざまな興味深い新機能を実現することが可能です。

OP_HASH160

OP_DUP

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

OP_EQUAL

OP_DUP

OP_ROT

0x100b9f19ebd537fdc371fa1367d7ccc802dc2524> // これはhash0です

OP_EQUAL

OP_BOOLOR

OP_VERIFY

これで、ビットコミットメントの値がスタック上にあります。「0」または「1」のいずれか。

現在、ビットコミットメントの実装は2つあります：

• Lamport One-Time Signature: その原理は比較的単純で、ハッシュ関数の使用のみが必要であり、これはビットコインに対して友好的です。メッセージの各ビットについて、2つのハッシュ値をコミットする必要があり、比較的大きな署名データが生成されます。言い換えれば、長さvビットのメッセージの場合、公開鍵の長さは2vビットであり、署名の長さはvビットです。
• ヴィンターニッツのワンタイム署名:Lamportの署名と比較して、署名と公開鍵の長さは大幅に短縮されますが、署名と検証の複雑さが増します。このスキームでは、異なるハッシュチェーン長dを柔軟に設定できるため、長さと複雑さのバランスが取れます。たとえば、d = 15 と設定すると、公開鍵の長さと署名の長さの両方が約 4 倍短くなりますが、検証の複雑さは 4 倍になります。これは本質的に、ビットコインのスタックスペースとスクリプトサイズのトレードオフです。ランポート署名は、d = 1 の場合、ヴィンターニッツ署名の特殊なケースと見なすことができます。

現在、BitVM2ライブラリは、Blake3ハッシュ関数に基づいたWinternitz署名を実装しています。1ビットに対応する署名の長さは約26バイトです。したがって、ビットコミットメントを介して状態を導入することはコストがかかることがわかります。したがって、BitVM2の実装では、メッセージはまず256ビットのハッシュ値にハッシュ化され、その後、ハッシュ値に対してビットコミットメントが行われ、元の長いメッセージの各ビットに直接コミットメントするのではなく、オーバーヘッドを節約します。

2.3 Taproot：スクリプトスペースの制限を突破する

2021年11月にアクティブ化されたBitcoin Taprootソフトフォークアップグレードには、3つの提案が含まれています：Schnorr署名（BIP 340）、Taproot（BIP 341）、およびTapScript（BIP 342）。新しいトランザクションタイプであるPay-to-Taproot（P2TR）トランザクションを導入します。P2TRトランザクションは、Taproot、MAST（Merkel Abstract Syntax Tree）、およびSchnorr署名の利点を組み合わせることで、よりプライベート、柔軟でスケーラブルなトランザクションフォーマットを作成できます。

P2TRは、キーパスまたはスクリプトパスに従って支出する2つの方法をサポートしています。

Taproot（BIP 341）の規定によれば、スクリプトパスを介して支出する場合、対応するMerkleパスの長さは最大128を超えることはできません。これは、taptree内のtapleafの数が2^128を超えることはできないことを意味します。2017年のSegWitアップグレード以来、Bitcoinネットワークはブロックサイズをウェイトユニットで測定し、最大サポートは4百万ウェイトユニット（約4MB）です。P2TR出力がスクリプトパスを介して支出される場合、1つのtapleafスクリプトのみを公開する必要があります。つまり、ブロックには1つのtapleafスクリプトがパックされています。これは、P2TRトランザクションの場合、各tapleafに対応するスクリプトサイズは最大約4MBになる可能性があることを意味します。ただし、Bitcoinのデフォルトポリシーでは、多くのノードが400K未満のトランザクションのみを転送します。より大きなトランザクションは、マイナーと協力してパックする必要があります。

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

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

2.4コネクタ出力：UTXO支出方法の制限を突破する

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

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

図1: コネクタ出力のイラスト

BitVM2プロトコルでは、コネクタの出力はif...else関数として機能します。コネクタの出力がトランザクションによって使用されると、他のトランザクションによって使用されることはできず、排他的な使用が確保されます。実際の展開では、チャレンジ・レスポンス期間を許可するために、タイムロック付きの追加のUTXOが導入されます。さらに、対応するコネクタの出力は必要に応じて異なる支出戦略を設定することも可能であり、チャレンジトランザクションの場合は任意の当事者が支出できるようにし、レスポンストランザクションのタイムアウト後にオペレータのみが支出できるようにすることもできます。

2.5 契約：事前署名の制限を突破する

現在、ビットコインスクリプトは、UTXOをさらに使用する方法を制限することなく、主にロック解除の条件を制限しています。これは、ビットコインスクリプトがトランザクション自体の内容を読み取ることができないため、トランザクションのイントロスペクションを実現できないためです。ビットコインスクリプトがトランザクションの内容(アウトプットを含む)をチェックできれば、コントラクト機能を実現できます。

現在の契約の実装は2つのカテゴリに分けることができます:

• 事前署名:既存のビットコインスクリプト機能に基づいて、機能が制限された事前決定された契約が事前署名によって構築されます。これは、将来起こりうるすべての取引を事前に設計して署名し、参加者を特定の秘密鍵と手数料率に縛り付けることを意味します。一部のスキームでは、参加者がすべての署名済みトランザクションに対して短期間の秘密鍵を生成する必要があります。事前署名が完了すると、これらの短期間の秘密鍵は安全に削除され、攻撃者がそれらを入手して資金を盗むのを防ぎます。しかし、新しい参加者が追加されたり、作業が更新されたりするたびに、上記のプロセスを繰り返す必要があり、メンテナンスコストが高くなっていました。たとえば、ライトニングネットワークは、事前署名によって2者間契約を実現し、Hash Time-Locked Contracts(HTLC)テクノロジーを使用して複数の2者間契約のルーティング機能を実装することで、信頼を最小限に抑えたスケーリング戦略を実現します。ただし、ライトニングネットワークは複数のトランザクションに事前に署名する必要があり、2つの当事者に制限されているため、やや面倒です。BitVM1 では、初期化のたびに数百のトランザクションに事前署名する必要がありますが、最適化された BitVM2 では、各初期化で事前署名する必要があるトランザクションの数も数十に達します。BitVM1 と BitVM2 の両方で、事前署名に参加しているオペレーターのみが払い戻しの対象となります。n 人の参加者が事前署名に関与し、各参加者が m 個のトランザクションに事前署名する必要がある場合、各参加者の事前署名の複雑さは n * m になります。
• コントラクトオペコードの導入:新しいコントラクト機能オペコードを導入することで、コントラクト参加者間の通信の複雑さとメンテナンスコストを大幅に削減できるため、ビットコインのより柔軟なコントラクト実装方法を導入できます。たとえば、OPCAT: はバイト文字列を連結するために使用されます。その機能は非常にシンプルですが、非常に強力で、BitVMの複雑さを大幅に軽減できます。OPTXHASH: コントラクト内のアクションをよりきめ細かく制御できます。BitVM で使用すると、より多くの演算子をサポートできるため、BitVM のセキュリティの前提が大幅に改善され、信頼性が最小限に抑えられます。さらに、事前署名方式は本質的に、BitVMのオペレーターが償還プロセスのみを採用できることを意味し、資本利用効率の低下につながります。一方、新しい契約オペコードにより、ペグインファンドプールからアウトプットユーザーに直接支払いが可能になり、資本効率がさらに向上する可能性があります。したがって、柔軟な契約モデルは、従来の事前署名の制限を効果的に突破します。

3 ビットコイン レイヤー2 スケーリング: 有効性の証明と詐欺証明

有効性の証明と詐欺証明の両方がビットコインのレイヤー2スケーリングに使用されることがあります。主な違いは表2に示されています。

表2：有効性証明 vs 詐欺証明

ビットコミットメント、Taproot、事前署名、およびコネクタ出力に基づいて、ビットコインに基づく詐欺の証拠を構築できます。Taprootをベースに、 ビットコインに基づく有効性の証明は、 OP_CATなどのコントラクトオペコードを導入することで構築することもできます。さらに、ボブにアドミッションシステムがあるかどうかに応じて、詐欺の証拠は許可された詐欺の証拠と許可のない詐欺の証拠に分けることができます。許可制の不正証明では、特定のグループのみがボブとしてチャレンジを開始できますが、パーミッションレスの不正証明では、第三者がボブとして行動してチャレンジを開始できます。パーミッションレスの不正証明のセキュリティは、許可されたものよりも優れており、許可された参加者間の共謀のリスクを軽減します。

AliceとBobの間のチャレンジレスポンスインタラクションの数に応じて、詐欺証明は1ラウンドの詐欺証明とマルチラウンドの詐欺証明に分けることができます。図2に示すように。

図2：ワンラウンドの詐欺証明対マルチラウンドの詐欺証明

表3に示されているように、詐欺証明は、1ラウンドの相互作用モデルとマルチラウンドの相互作用モデルを含むさまざまな相互作用モデルを介して実装することができます。

表3: ワンラウンドインタラクション対マルチラウンドインタラクション

BitcoinのLayer2スケーリングパラダイムでは、BitVM1はマルチラウンドの詐欺証明メカニズムを採用し、BitVM2はワンラウンドの詐欺証明メカニズムを使用しています。また、bitcoin-circle starkは有効性の証明を利用しています。これらのうち、BitVM1とBitVM2はBitcoinプロトコルに変更を加えることなく実装することができますが、bitcoin-circle starkでは新しいopcode OP_CATの導入が必要です。

ほとんどの計算タスクでは、Bitcoinのシグネット、テストネット、およびメインネットでは4MBのスクリプトを完全に表すことができません。そのため、完全な計算スクリプトを4MB未満のチャンクに分割し、さまざまなtapleafに分散するスクリプト分割技術が必要となります。

3.1 ビットコイン上のマルチラウンド詐欺証明

表3に示すように、マルチラウンドの詐欺証明は、オンチェーンの仲裁計算を削減したい場合や、1回で問題のある計算セグメントを特定することができない場合に適しています。名前が示すように、マルチラウンドの詐欺証明には、問題のある計算セグメントを特定し、その後特定されたセグメントに基づいて仲裁を行うために、証明者と検証者の間で複数のラウンドのやり取りが必要です。

Robin Linusの初期のBitVMホワイトペーパー（一般的にはBitVM1と呼ばれる）では、マルチラウンド詐欺証明が使用されていました。各チャレンジ期間が1週間続き、問題のある計算セグメントを特定するためにバイナリサーチメソッドを使用すると、Groth16 Verifierのオンチェーンチャレンジ応答期間は最大30週間になり、タイムリネスが悪くなります。バイナリサーチよりも効率的なn-aryサーチメソッドを研究しているチームも現在ありますが、そのタイムリネスは1ラウンドの詐欺証明の2週間サイクルと比較して依然として著しく低いです。

現在、Bitcoinパラダイムのマルチラウンド詐欺証明では、許可されたチャレンジを使用していますが、ワンラウンド詐欺証明では許可されていないチャレンジ手法が採用されており、参加者間の共謀のリスクを低減し、セキュリティを向上させています。このため、Robin LinusはTaprootの利点を最大限に活用してBitVM1を最適化しました。インタラクションラウンドの数は1つに減少し、チャレンジ手法も許可されていないアプローチに拡大されましたが、オンチェーンの仲裁計算の増加が発生しました。

3.2 ビットコイン上のワンラウンド詐欺証明

このモデルでは、詐欺証明の検証はプルーバとベリファイヤーの間で単一のインタラクションを通じて完了することができます。ベリファイヤーはただ1つのチャレンジを開始するだけでよく、プルーバは1回だけ応答するだけでよいです。この応答では、プルーバは計算が正しいと主張する証拠を提供しなければなりません。もしベリファイヤーがその証拠に矛盾点を見つけることができれば、チャレンジは成功となります。そうでなければ、失敗となります。ワンラウンドのインタラクティブ詐欺証明の特徴は、表3に示されています。

図3：1ラウンドの詐欺証明

2024年8月15日、Robin LinusはBitVM2：ビットコインをセカンドレイヤーに接続する技術的なホワイトペーパーを発表しました。このホワイトペーパーでは、図3に示されているようなワンラウンドの詐欺証明メソッドを使用したクロスチェーンブリッジが実装されています。

3.3 OP_CATによるビットコインの有効性の証明

OPCATは、Bitcoinがリリースされた当初のスクリプト言語の一部でしたが、2010年にセキュリティの脆弱性のために無効化されました。しかし、Bitcoinコミュニティは何年もの間、その再活性化について議論してきました。OPCATは現在、番号347が割り当てられ、Bitcoinのsignetで有効化されています。

OP_CATの主な機能は、スタック内の2つの要素を結合し、結合された結果をスタックに戻すことです。この機能により、Bitcoin上の契約とSTARK検証者の可能性が広がります。

• コントラクト:Andrew Poelstraは、OPCATとSchnorrのテクニックを使用してビットコインにコントラクトを実装するCATとSchnorrのトリックIを提案しました。Schnorr アルゴリズムは、P2TR 出力タイプのデジタル署名です。他の出力タイプについては、CATおよびECDSAに関する規約に見られるように、同様のECDSA技術を使用できます。OPCATコントラクトの助けを借りて、STARK Verifierアルゴリズムを複数のトランザクションに分割し、STARKプルーフ全体を徐々に検証することができます。
• STARK検証者：STARK検証者は基本的にデータを結合してハッシュ化します。代数演算とは異なり、ハッシングはネイティブなビットコインスクリプト操作であり、膨大なオーバーヘッドを節約できます。たとえば、OPSHA256はそのネイティブ形式では単一のオペコードですが、シミュレートされたバージョンでは数百のKオペコードが必要です。STARKの主なハッシング操作には、MerkleパスとFiat-Shamir変換の検証が含まれます。したがって、OPCATはSTARK検証者アルゴリズムに非常にフレンドリーです。

3.4 ビットコインスクリプトの分割技術

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

OP_CAT契約の存在下では、STARK検証者を400KB以下の複数の標準トランザクションに分割することができ、マイナーとの協力なしにSTARK有効性証明の検証を完了することができます。

このセクションでは、新しいオペコードを導入またはアクティブ化することなく、既存の条件下でのビットコインスクリプトの関連する分割技術に焦点を当てます。

スクリプト分割を実行する際には、次の情報の次元をバランスする必要があります:

• 単一のチャンクスクリプトのサイズは4MBを超えてはならず、入力ビットコミットスクリプト、トランザクション署名、およびその他のスペースを含める必要があります。
• 1 つのチャンクの最大スタック サイズは 1000 を超えてはなりません。したがって、ビットコインのトランザクション手数料は使用されるスタックサイズに依存しないため、各チャンクのスタックは、スクリプトサイズの最適化に十分なスタックスペースを確保するために必要な要素のみを保持する必要があります。
• ビットコミットメントはビットコイン上で高価です。そのため、隣接する2つのチャンク間の入力と出力のビット数を最小限にする必要があります。現在、1ビットが26バイトに相当しています。
• 監査の容易さのために、各チャンクの機能はできるだけ明確にする必要があります。

現在、スクリプト分割の方法は次の3つの主なカテゴリに分けることができます:

• 自動分割: この方法では、スクリプト サイズが約 3 MB で、スタック サイズとスクリプト サイズに基づいてスタック サイズが最小化される分割アプローチが模索されています。この方法の利点は、特定の検証アルゴリズムに依存せず、任意の計算のスクリプト分割に拡張できることです。欠点は、(1)分割できないOP_IFコードブロックなど、論理ブロック全体を個別にマークする必要があります。そうしないと、分割スクリプトの実行結果が正しくなくなります。(2)チャンクの実行結果は、スタック上の複数の要素に対応する場合があり、実際の計算ロジックに基づいてビットコミットメントを適用する必要があるスタック要素の数をマークする必要があります。(3)各チャンクスクリプトによって実装された論理機能の可読性が低く、監査が困難である。(4) スタックに次のチャンクに必要のない要素が含まれていて、スタックスペースが無駄になることがあります。
• 機能分割：この方法は、計算におけるさまざまな機能のサブ機能に基づいて分割します。サブ機能の入力と出力の値が明確です。スクリプトを分割する際に、各チャンクの必要なビットコミットメントスクリプトも実装し、最終的なチャンクの合計スクリプトサイズが4MB未満、スタックサイズが1000未満であることを保証します。利点は、明確な機能性、各チャンクの明確なロジック、読みやすさ、監査の容易さです。欠点は、元の計算ロジックの表現がスクリプトレベルのロジックに一致しない可能性があり、元の計算のサブ機能が最適であるが、スクリプトレベルの最適性を表していないことです。
• マニュアル分割: この方法では、分割ポイントは機能サブ機能にもとづかず、マニュアルで設定されます。これは、1 つのサブ関数のサイズが 4 MB を超える場合に特に適しています。利点は、Fq12計算に関連するものなど、重いスクリプトサイズのサブ関数を手動で分割できることです。各チャンクのロジックが明確で、読みやすく、監査が容易です。欠点は、手動チューニング機能によって制限され、スクリプト全体が最適化されている場合、以前に設定された手動分割ポイントが最適ではなく、再調整が必要になる可能性があることです。

例えば、複数の最適化ラウンドの後、Groth16検証者のスクリプトサイズは約7GBから約1.26GBに削減されました。この全体的な計算最適化に加えて、各チャンクはスタックスペースを最大限に活用するために個別に最適化することもできます。たとえば、より良いルックアップテーブルベースのアルゴリズムを導入したり、ルックアップテーブルの動的な読み込みとアンロードを行うことで、各チャンクのスクリプトサイズをさらに削減することができます。

web2プログラミング言語の計算コストとランタイム環境は、ビットコインスクリプトとはまったく異なるため、さまざまなアルゴリズムの既存の実装を単純にビットコインスクリプトに翻訳することは不可能です。そのため、ビットコインのシナリオに特化した最適化が考慮される必要があります:

• BitVM2のassertTxトランザクションデザインにおいて、チャンク間の入出力ビット数を減らし、コミットメントに必要なデータ量を減らすために、計算負荷をいくらか犠牲にしてメモリの局所性を最適化するアルゴリズムを探します。
• 関連する操作（例：論理演算）の可換性（例：x&y = y&x）を利用して、ルックアップテーブルのほぼ半分を節約します。
• 現在、Fq12演算に対応するスクリプトサイズが大きいため、Fiat-Shamir、Schwartz-Zipple、および多項式コミットメントスキームを活用して、Fq12拡張演算の計算複雑性を大幅に削減することを検討してください。

4 サマリー

この記事はまず、Bitcoinスクリプトの制限について説明し、UTXOの状態制限を克服するためにBitcoinコミットメントを使用し、スクリプト空間の制限を突破するためにTaprootを使用し、UTXOの支出方法の制限を回避するためにコネクタ出力を使用し、事前署名の制限を克服するために契約を使用する方法について議論します。その後、詐欺証明と有効性証明の特徴、許可された詐欺証明と許可されていない詐欺証明の特徴、1ラウンドとマルチラウンドの詐欺証明の区別、およびBitcoinスクリプト分割の技術の包括的な概要と要約を提供します。

免責事項：

1. この記事は[から転載されましたaicoin]. All copyrights belong to the original author [mutourend & lynndell、Bitlayer Labs]. この転載に異議がある場合は、お問い合わせください。ゲートラーンチーム、そして彼らは迅速に対処します。
2. 責任の免除：本記事に表現される見解や意見は、著者個人のものであり、投資アドバイスを提供するものではありません。
3. 記事の翻訳は、Gate Learnチームによって他の言語に翻訳されます。特に言及がない限り、翻訳された記事の複製、配布、または盗用は禁止されています。