1 イントロダクション

アルゴリズム f について、互いに信頼しない2人の参加者、アリスとボブは、次の方法で信頼関係を築くことができます:

1. Aliceはxを入力し、アルゴリズムfを実行して結果yを得ます。Bobも同じ入力xを使用してアルゴリズムfを実行し、y'を得ます。yとy'が等しい場合、BobはAliceが提供した入力xと出力yを承認します。これは一般的な有効性の証明メカニズムであり、通常、ブロックチェーンコンセンサスに適用され、Aliceはブロックをパッケージ化するノードであり、Bobはコンセンサスに参加するノードです。
2. Aliceはxを入力し、zk.proveプログラムを実行して結果yと証明proofを得ます。Bobはf、y、およびproofに基づいてzk.verifyプログラムを実行します。結果が真であれば、BobはAliceの結果yを承認し、偽であればAliceの結果yを承認しません。これは有効性の証明であり、Bobはオンチェーンの契約であることができます。
3. Aliceはxを入力し、アルゴリズムfを実行して結果yを得ます。Bobも同じ入力xを使用してアルゴリズムfを実行し、y′を得ます。yとy′が等しい場合、何も行いません。yとy′が等しくない場合、BobはAliceに挑戦します。挑戦のプログラムはfです。AliceとBobの間の対話は1ラウンドまたは複数ラウンドのいずれかです。挑戦-応答メカニズムによって仲裁が実現されます。これは詐欺証明の一種であり、Bobは挑戦者であり、オフラインで監視し、オンラインで挑戦を発動します。
4. Aliceはxを入力し、zk.proveプログラムを実行して結果yと証明proofを得る。Bobはf、y、およびproofに基づいてzk.verifyプログラムを実行する。結果が真であれば何も行わず、偽であればBobはAliceに対して挑戦を行い、そのプログラムはzk.verifyである。AliceとBobの間の相互作用は1ラウンドまたは複数ラウンドである可能性がある。チャレンジ-レスポンスメカニズムによって仲裁が実現される。これは詐欺証明であり、Bobは挑戦者であり、オフラインで監視し、オンラインで挑戦を行う。

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

• 有効性の証明：基于悲観的仮定，受け入れる前にその有効性を証明し、即座に有効にする必要があります。有効性の証明では、正しいL2の状態遷移の証拠を提供する必要があり、世界への悲観的な見方を反映しています-状態が正しいと証明された場合のみ受け入れられます。
• 詐欺証明：楽観的な仮定に基づいて、デフォルトでは受け入れられているものとして扱われますが、誰かがそれが正しくないことを証明するまではです。詐欺証明にはチャレンジウィンドウがあり、チャレンジウィンドウが終了した後にのみ有効になります。詐欺証明では、L2の状態遷移が正しくないことを証明する証拠を提供する必要があります。これは世界に対する楽観的な見方を示しており、状態遷移は逆の証拠がある場合を除いて正しいものと見なされます。

表1:信頼構築へのアプローチ

また、特に注意が必要なのは:

• 詐欺証明と有効性の証明を区別する鍵は、SNARKやSTARKのようなZK証明システムを使用するかどうかではありません。ZK証明システムは、採用された証明方法を示しているだけであり、詐欺または有効性は証明の内容を表しています。したがって、表1のシナリオ1は有効性の証明と呼ばれています。 *有効性の証明はより時間的制約を受けますが、オンチェーン検証の複雑さは高くなります。 一方、不正証明のオンチェーン検証はそれほど複雑ではありませんが、時間的制約は少なくなります。
• 表1のケース2と4については、ZK再帰およびコンビネーション技術を使用して複数のfを計算および圧縮することで、オンチェーンの検証コストをオフチェーンの計算に大幅にドロップさせることができます。

現在、Solidityのチューリング完全スマートコントラクトによって、詐欺証明と有効性の証明技術がEthereumのLayer2拡張で広く使用されています。しかし、BTCのフレームワークでは、BTCのオペコード機能が制限され、スタック要素数が1000であるなど、これらの技術の適用はまだ試行段階にあります。本文はBTCフレームワークの制限と突破技術をまとめ、有効性の証明と詐欺証明技術を研究し、BTCフレームワークのユニークなスクリプト分割技術を概説しています。

2 BTCフレームワークの制限と突破

BTCの枠組みには多くの制限がありますが、これらの制限を克服するために、ビットコインコミットメントを使用してUTXOの状態制限を突破することができます。タップルートはスクリプトスペースの制限を解消し、コネクタ出力はUTXO消費方法の制限を克服することができます。また、スマートコントラクトは事前署名の制限を突破することができます。

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

BTCはUTXOモデルを採用しており、各UTXOはそれぞれロックスクリプトにロックされており、そのスクリプトはUTXOを消費するために満たす必要のある条件を定義しています。BTCスクリプトには次の制限があります：

1. BTCスクリプトは状態を持たない；
2. P2TR出力形式の場合、1つの取引には最大で約400万のオペコードを含めることができ、フルブロックを埋めることができます。他の出力形式の場合、10,000個のオペコードしか使用できません。
3. 単一のUTXOの消費方法は限られており、組み合わせ消費方法の探求が不足しています； 4.柔軟な契約機能はサポートされていません；
4. スタックのサイズは、altstackとstackを含む最大1000要素で、単一要素の最大サイズは520バイトです。
5. 暗号化操作では、算術演算（加算や減算など）は4バイトの要素に制限されており、20バイト以上の長い要素に拡張することはできません。
6. OPMUL および OPCAT のようなオペコードは使用禁止されており、これらをエミュレートするために既存のオペコードを使用するとコストが非常に高くなります。たとえば、BLAKE3 ハッシュをエミュレートすると、スクリプトのサイズが約 75K になります。

2.2 Bit Promise: UTXOのステートレス制限を突破する

現在、BTCスクリプトは完全にステートレスです。 BTCスクリプトを実行すると、各スクリプトの実行環境は完了後にリセットされます。 これにより、BTCスクリプトはネイティブで制約スクリプト1と2が同じx値を共有することをサポートすることができません。 ただし、この問題はいくつかの方法で解決できます。 核心的な考え方は、ある値に対してある方法で署名することです。 値に署名できれば、ステートフルなBTCスクリプトを実現できます。 言い換えれば、スクリプト1と2のx値の署名をチェックすることで、これら2つのスクリプトで同じx値を使用することを確認できます。 衝突する署名が存在する場合、つまり同じ変数xに2つの異なる値が署名されている場合、罰則を科すことができます。 この方法はビットコインコミットメントと呼ばれます。

ビットの約束の原則は比較的単純です。各ビットには、hash0とhash1の2つの異なるハッシュ値が対応しています。署名する必要があるビット値が0の場合、hash0のプレイイメージを公開します。ビット値が1の場合、hash1のプレイイメージを公開します。

単一のビットメッセージm∈{0,1}を例にとると、対応するビットコミットメントのアンロックスクリプトはいくつかのプレイイメージだけで構成されます。ビット値が0の場合、アンロックスクリプトはpreimage0- '0xfa7fa5b1dea37d71a0b841967f6a3b119dbea140'です。ビット値が1の場合、アンロックスクリプトはpreimage1- '0x47c31e611a3bd2f3a7a42207613046703fa27496'です。したがって、ビットコミットメントを介して、UTXOの状態の制限を打破し、状態を持つBTCスクリプトを実現し、様々な興味深い新しい機能を可能にすることができます。

OP_HASH160

OP_DUP

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

OP_EQUAL

OP_DUP

OP_ROT

0x100b9f19ebd537fdc371fa1367d7ccc802dc2524> // これは hash0 です

OP_EQUAL

OP_BOOLOR

OP_VERIFY

// 現在ビット承诺の値がスタック上にあります。"0"または"1"になります。

現在、ビットは2つの実装方法を約束しています:

• Lamport一回限りの署名：Lamport 一回限りの署名：Lamport 一回限りの署名の原理は比較的単純で、ハッシュ関数のみを使用する必要があり、BTCと互換性があります。メッセージ内の各ビットに対して、2つのハッシュ値をコミットする必要があり、これにより署名データが比較的大きくなります。具体的には、長さvビットのメッセージに対して、公開鍵の長さは2vビットであり、署名の長さはvビットです。
• Winternitz一回限りの署名：Lamport署名と比較して、Winternitz署名は署名と公開鍵の長さを大幅に減らす一方で、署名と検証の複雑さを増加させます。このスキームでは、異なるハッシュチェーンの長さdを柔軟に設定することができ、長さと複雑さのバランスを取ることができます。たとえば、d = 15を設定すると、公開鍵と署名の長さが約4倍短くなりますが、検証の複雑さも4倍増加します。これは実際にはBTCのスタックスペースとスクリプトサイズのトレードオフです。d = 1の場合、Lamport署名はWinternitz署名の特殊な場合と見なすことができます。

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

2.3 タップルート：突破脚本空间限制

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

P2TRは、秘密鍵パスまたはスクリプトパスを介して2つの支出方法をサポートしています。 タップルート（BIP 341）の規定によると、スクリプトパスを介して支出する場合、対応するMerkleパスの長さは128を超えることはできません。つまり、taptree内のtapleafの数は2^128を超えることはできません。2017年のSegWitアップグレード以来、BTCネットワークは重み単位でブロックサイズを測定し、最大で400万の重み単位（約4MB）をサポートしています。P2TR出力がスクリプトパスを介して支出される場合、単一のtapleafスクリプトのみを公開する必要があります。つまり、ブロックには1つのtapleafスクリプトのみが含まれます。したがって、P2TR取引では、各tapleafに対応するスクリプトのサイズは最大で約4MBになります。ただし、BTCのデフォルトポリシーにより、多くのノードは400K未満の取引のみを転送します。より大きな取引はマイナーとの協力が必要です。

Taprootがもたらすスクリプト空間プレミアムにより、既存のオペコードをシミュレートすることがより価値があるようになりました。P2TRに基づく検証可能な計算を構築する際、スクリプトのサイズはもはや4MBの制限に制限されず、複数のサブ機能に分割され、複数のtapleafに分散されることができます。実際、現在のBitVM2で実装されているGroth16検証器アルゴリズムのサイズは2GBに達します。ただし、それは約1000のtapleafに分割され、ビット承諾と組み合わせて、各サブ機能の入力と出力の整合性を制約し、全体の計算の完全性と正確性を確保します。

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

現在、BTCは1つの未使用取引出力（UTXO）に対して2つのネイティブな支出方法、すなわちスクリプトまたは公開鍵による支出を提供しています。したがって、正しい公開鍵の署名またはスクリプト条件を満たせば、UTXOは支出できます。2つのUTXOは独立して支出でき、これら2つのUTXOを制限する追加条件を追加することはできません。つまり、それらを支出するために追加の条件を満たす必要があります。

しかし、Arkプロトコルの創始者であるBurakは、SIGHASHフラグを利用してコネクタ出力を実現することを巧みに利用しました。具体的には、Aliceは彼女のBTCをBobに送信する署名を作成することができます。署名は複数の入力を約束できるため、Aliceは彼女の署名を条件として設定できます：2番目の入力が消費された場合にのみ、Taketxトランザクションの署名が有効になります。 2番目の入力はコネクタと呼ばれ、UTXO AとUTXO Bを接続します。言い換えれば、UTXO BがChallengetxトランザクションによって消費されていない場合にのみ、Taketxトランザクションが有効になります。したがって、コネクタ出力を破壊することで、Taketxトランザクションの有効性を防止できます。

図1：コネクタの出力図

BitVM2プロトコルでは、コネクタ出力はif...else関数の役割を果たします。コネクタ出力があるトランザクションによって支出されると、他のトランザクションによって再び支出することはできません。これにより、排他性が保証されます。実際の展開では、チャレンジ-レスポンスサイクルを許可するために、時間制約の付いた追加のUTXOが導入されます。さらに、コネクタ出力は必要に応じて異なる支出戦略を設定することもできます。たとえば、チャレンジトランザクションの場合はどちらの当事者でも支出を許可し、レスポンストランザクションの場合はオペレータのみが支出を許可するか、タイムアウト後に誰でも支出を許可するかなどです。

2.5 契約: 事前署名の制限を破る

現時点では、BTCスクリプトは主に解除条件を制限しており、未使用のトランザクション出力（UTXO）のさらなる支出方法は制限されていません。これは、BTCスクリプトがトランザクション自体の内容を読み取ることができないため、トランザクションの自己検査を行うことができないためです。もしBTCスクリプトがトランザクションのどんな内容（出力を含む）でもチェックすることができれば、契約機能を実現することができます。

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

• プリサイン：既存のBTCスクリプトの機能を利用して、制約付きのプリスケジュール契約を構築します。これは、参加者が将来のすべての可能性を事前に設計し署名する必要があるため、特定の秘密鍵と料金にロックされます。一部のスキームでは、参加者がすべてのプリサイントランザクションのために一時的な秘密鍵を生成する必要があります。プリサインが完了すると、これらの一時的な秘密鍵は安全に削除され、攻撃者が資金を入手して盗むことを防ぎます。ただし、新しい参加者を追加したり操作を更新したりするたびに、このプロセスを繰り返す必要があり、メンテナンスコストが高くなります。たとえば、ライトニングネットワークでは、プリサインを使用して両当事者契約を実現し、ハッシュタイムロックコントラクト（HTLC）技術を使用して複数の両当事者契約のルーティング機能を実現し、最小限の信頼を持つ拡張戦略を実現しています。ただし、ライトニングネットワークでは、複数のトランザクションをプリサインする必要があり、2者に制限されているため、使用が煩雑です。 BitVM1では、初期化ごとに数百のトランザクションをプリサインする必要があり、最適化されたBitVM2でも、初期化ごとに数十のトランザクションをプリサインする必要があります。 BitVM1とBitVM2では、プリサインに参加するオペレーターのみが払い戻しを受ける資格があります。参加者がn人でプリサインする必要がある場合、各参加者のプリサインの複雑さはn * mになります。
• コントラクト操作コードの導入：新しいコントラクト機能操作コードの導入により、コントラクト参加者間の通信の複雑さとメンテナンスコストを著しくドロップし、BTCにより柔軟なコントラクト実装方法を提供することができます。例えば、OPCAT操作コードはバイト文字列を接続するために使用されます。その機能は単純ですが、BitVMの複雑さを著しくドロップすることができます。また、OPTXHASH操作コードを使用すると、コントラクト内の操作をより細かく制御することができます。BitVMで使用する場合、より広範囲の演算子をサポートすることができ、BitVMのセキュリティを著しく向上させ、信頼性を最小化することができます。さらに、プリサイン方法は本質的にはBitVMのオペレーターが報告プロセスしか採用できないことを意味します。これは資本利用効率が低下する要因となります。しかし、新しいコントラクト操作コードにより、peg-inファンドプールから直接出力ユーザーに支払うことができるため、資本利用効率をさらに向上させることができます。したがって、柔軟なコントラクトモデルは従来のプリサイン制限を効果的に打破することができます。

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

有効性の証明と詐欺証明はBTCのLayer2拡張で使用できますが、主な違いは表2を参照してください。

表2:有効性の証明と詐欺の証明

ビットコインをベースにして、詐欺証明を構築することができます。ビットコインの有効性の証明をタップルートを利用して構築することもできます。また、詐欺証明は、Bobがシステムに参加するかどうかに基づいて、許可詐欺証明と無許可詐欺証明に分けることができます。許可詐欺証明では、特定のグループのみがBobとして挑戦を行うことができますが、無許可詐欺証明では、第三者であれば誰でもBobとして挑戦を行うことができます。無許可詐欺証明の方が安全性が高く、参加者間の共謀リスクを排除することができます。

AliceとBobの挑戦-応答インタラクション回数に基づいて、詐欺証明は単一ラウンドの詐欺証明とマルチラウンドの詐欺証明に分類されます。図2を参照してください。

図2:シングルラウンドの不正防止と複数ラウンドの不正防止

表3に示されるように、詐欺証明は、シングルターンのインタラクションモデルとマルチターンのインタラクションモデルを含む、さまざまなインタラクションモデルを使用して実現できます。

表 3：単一のインタラクションと複数のインタラクション

BTCのLayer2拡張のパラダイムでは、BitVM1はマルチラウンド詐欺証明メカニズムを採用していますが、BitVM2はシングルラウンド詐欺証明メカニズムを採用しています。bitcoin-circle starkは有効性の証明を利用しています。これらのメカニズムのうち、BitVM1およびBitVM2はBTCプロトコルを変更することなく実装できますが、bitcoin-circle starkは新しいオペレーションコードOP_CATを導入する必要があります。

大抵の計算タスクにおいて、BTCのsignet、testnet、mainnetは完全に4MBのスクリプトをサポートできないため、スクリプト分割技術が必要です。つまり、完全な計算スクリプトを4MB未満のブロックに分割し、異なるTapleafに分配する必要があります。

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

表3に示されるように、マルチラウンド詐欺証明は、オンチェーンの仲裁計算を減らしたい場合や、問題の計算セグメントを一度に特定できない場合に適しています。マルチラウンド詐欺証明は、証明者とバリデータの間で複数のラウンドのやり取りを行い、問題の計算セグメントを見つけ、それらのセグメントに基づいて仲裁を行います。

Robin Linusの早期BitVMホワイトペーパー（通常称为BitVM1）では、多輪詐欺証明が採用されています。各チャレンジ期間が1週間続くと仮定し、問題計算セグメントを特定するために2分探索法を使用すると、Groth16検証器のオンチェーンチャレンジ応答期間は最大30週に延長され、タイムリーさが低下する可能性があります。2分探索よりも効率的なn-ary検索方法を研究しているチームが現在存在しますが、そのタイムリーさは依然として単一の詐欺証明の2週間サイクルよりも著しく低いです。

現在、BTCの多段詐欺防止機能では、許可されたチャレンジが使用されており、一段詐欺防止機能では非許可のチャレンジ方法が実現されており、参加者のつながりからのリスクをドロップし、セキュリティを強化しています。そのため、Robin Linusはタップルートの利点を最大限に活用して、BitVM1を最適化しました。相互作用のラウンド数を1ラウンドに減らすだけでなく、チャレンジ方法を非許可の方法に拡張しましたが、オンチェーンの仲裁計算のコストが増加することになります。

3.2 ビットコインの詐欺の証拠のラウンド

このモデルでは、詐欺証明の検証は、証明者とバリデータの間で1回のやりとりだけで行われます。バリデータは1回のチャレンジを発信するだけでよく、証明者は1回だけ応答する必要があります。応答の中で、証明者は計算が正しいことを証明する証拠を提供しなければなりません。バリデータが証拠の不整合を見つけた場合、チャレンジは成功し、そうでない場合は失敗します。1ラウンドのやりとりの詐欺証明の特徴は、表3に示されています。

図3:シングルラウンドの不正防止

2024年8月15日、Robin Linusは「BitVM2：BTCを第2層に接続する」技術ホワイトペーパーを公開し、図3に示すような単一のクロスチェーンブリッジを実現し、1回の詐欺証明方法を採用しました。

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

OP_CATはBTCがリリースされたときのスクリプト言語の一部でしたが、2010年にセキュリティ上の脆弱性があったため禁止されました。それでも、BTCコミュニティは長年にわたり、OP_CATを再び使用する可能性について議論してきました。現在、OP_CATは番号347が割り当てられ、BTCのsignetネットワークで有効になっています。

OP_CATの主な機能は、スタック内の2つの要素を結合し、結果をスタックにプッシュすることです。この機能により、BTCの契約とSTARKバリデータに新たな可能性がもたらされます。

• 契約: Andrew Poelstra は、OP_CAT と Schnorr の技術を活用して ビットコイン 上の契約を実装する CAT と Schnorr Tricks I を提案しました。 Schnorr アルゴリズムは、P2TR 出力タイプで動作するデジタル署名の一種です。 他の出力タイプでは、CAT と ECDSA を使用するコントラクトに示されているような、同様の ECDSA 手法を使用できます。 OP_CATコントラクトでは、STARKバリデーターアルゴリズムを複数のトランザクションに分割し、STARKプルーフ全体を段階的に検証することができます。
• STARKバリデータ：STARKバリデータの主な機能は、データを連結し、ハッシュを行うことです。代数演算とは異なり、ハッシュはBTCスクリプトのネイティブな操作であり、オーバーヘッドを大幅に削減できます。例えば、OPSHA256はネイティブな形式では単一のオペコードですが、シミュレートバージョンでは数百のオペコードが必要です。STARKの主なハッシュ操作には、Merkleパスの検証とFiat-Shamir変換が含まれます。したがって、OP_CATはSTARKバリデータのアルゴリズムに非常に適しています。

3.4 BTCスクリプト分割技術

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

OP_CAT契約の場合、STARK検証者は、400KB未満の複数の標準取引に分割することができます。これにより、STARKの有効性の証明の検証全体が、マイナーとの協力なしに完了することができます。

このセクションでは、既存の条件下でのBTCスクリプトの分割技術に重点を置き、新しいオペコードを導入またはアクティブにすることはありません。

スクリプトを分割する際には、次の情報をバランスよく考慮する必要があります：

• 単一のブロックのスクリプトサイズは4MBを超えてはならず、入力ビットコインスクリプト、トランザクション署名などの他のコンテンツを含める必要があります。
• 1つのブロックの最大スタックサイズは1000を超えてはなりません。したがって、各ブロックのスタックは必要最小限の要素のみを保持する必要があります。これにより、スタックサイズの最適化が可能になり、BTCの取引手数料はスタックサイズに関係ありません。
• BTCでは、ビットコストが高くなります。したがって、隣接する2つのブロックの間の入力と出力のビット数をできるだけ減らすべきです。現在、1ビットは26バイトに対応しています。
• 各ブロックの機能は、監査のためにできるだけ明確にする必要があります。

現在、スクリプトの分割方法は以下の3つに分類されます。

• 自動分割：この方法は、スクリプトサイズを約3MBにし、スタックサイズとスクリプトサイズをベースにしてスタックサイズを最小化する分割方法を探します。その利点は、特定の検証アルゴリズムに独立しており、任意の計算のスクリプト分割に拡張できることです。欠点には次のものがあります：(1) 全体のロジックブロックを個別にマーキングする必要があり、例えば分割できないOP_IFコードブロックがあります。そうでないと、分割スクリプトの実行結果が誤ってしまう可能性があります。(2) ブロックの実行結果がスタック上の複数の要素に対応する場合があり、実際の計算ロジックに応じて、スタック要素の数にビットコミットを適用する必要があります。(3) 各ブロックスクリプトのロジック機能の可読性が低く、監査が困難です。(4) スタックには、次のブロックで不要な要素が含まれる可能性があり、スタックスペースが無駄になります。
• 機能分割：この方法は、計算中の機能サブファンクションに基づいて分割し、サブファンクションの入力と出力を明確にします。スクリプトを分割する際に、各ブロックに必要なビットコミットスクリプトを実装して、最終ブロックの総スクリプトサイズが4MB未満、スタックサイズが1000未満であることを確認します。利点は機能が明確で、ロジックが明確で、可読性が高く、監査が容易です。欠点は元の計算ロジックがスクリプトレベルのロジックと一致しない可能性があり、元のサブファンクションが最適であるかもしれませんが、スクリプトレベルでは最適であるとは限りません。 *手動分割：この方法は、機能サブ関数に基づくのではなく、手動で設定されます。この方法は、単一のサブ関数のサイズが4MBを超える場合に特に適しています。利点は、大規模なスクリプトサブ関数を手動で分割できること、例えばFq12計算に関連するサブ関数などです。各ブロックのロジックが明確で読みやすく、監査しやすいという点です。欠点は、手動で最適化する能力に制限があることです。全体のスクリプトが最適化された後、以前に設定した手動分割点が最適でなくなる可能性があるため、再調整が必要です。

例えば、多数の最適化を経て、Groth16検証器のスクリプトサイズは約7GBから約1.26GBにドロップしました。全体的な計算最適化に加えて、各ブロックも個別に最適化することができ、スタックスペースを最大限に活用できます。たとえば、より効率的なルックアップテーブルアルゴリズムを導入し、動的にロードおよびアンロードすることで、各ブロックのスクリプトサイズをさらに縮小することができます。

Web2プログラミング言語の計算コストや動作環境はビットコインスクリプトとは大きく異なるため、既存のアルゴリズム実装を単純にビットコインスクリプトに変換することは現実的ではありません。 したがって、ビットコインシナリオの特定の最適化を検討する必要があります。

• ブロック間の入出力ビット数を減らすために、計算負荷が増加する可能性があるにもかかわらず、メモリの局所性を最適化するアルゴリズムを見つけて、BitVM2のassertTxトランザクションデザインから必要なデータ量を削減する。
• 関連する操作（たとえば、論理演算）を利用して、x＆y = y＆xのように、検索テーブルスペースのほぼ半分を節約します。
• 現在、Fq12 の操作スクリプトのサイズが大きいため、Fiat-Shamir、Schwartz-Zipple、および多項式コミットメントスキームを使用して、Fq12 拡張操作の計算複雑性を顕著にドロップさせることを検討できます。

4 まとめ

本文では、BTCスクリプトの制約について最初に検討し、いくつかの解決策について議論します：BTCのコミットメントを利用してUTXOの状態制約を克服する、タップルートを使用してスクリプトスペースの制約を突破する、出力を接続してUTXOの支出方法の制約を回避する、およびプリスクリプト制約を解決するための契約。次に、詐欺証明と有効性証明の特徴について包括的な概要を提供します。特徴には、許可された詐欺証明と無許可詐欺証明の特徴、単一ラウンドとマルチラウンドの詐欺証明の違い、およびBTCスクリプト分割技術に関連する内容が含まれます。

免責事項:

1. 本文は[から転載されました。aicoin]、著作権は原作者[mutourend & lynndell, Bitlayer Labs]に帰属しますので、転載に異議がある場合は、Gate Learnチームまでご連絡ください。
2. 免责声明：本文に表現された意見や見解は、著者個人のものであり、投資アドバイスを構成するものではありません。
3. 記事の他の言語版はGate Learnチームによって翻訳されています。Gate.ioに言及されていない場合、翻訳された記事を複製、配布、または盗作することはできません。