ビットコインのレイヤー2スケーリング技術を解説：有効性証明と詐称証明
TechFlow厳選深潮セレクト
ビットコインのレイヤー2スケーリング技術を解説：有効性証明と詐称証明
ビットコインのパラダイムには多くの制約があるが、それらの制約を突破するためにさまざまな巧妙な手法や技術を使用することができる。
Web3業界の深掘り報道に専念し潮流を洞察執筆：mutourend & lynndell, Bitlayer Labs
1 はじめに
あるアルゴリズム f に対して、相互に信頼しない参加者 Alice と Bob は以下の方法で信頼を構築できる：
-
Alice が入力 x を与え、アルゴリズム f を実行して結果 y を得る。Bob も同じ入力 x に基づきアルゴリズム f を実行し、結果 y′ を得る。もし y = y′ ならば、Bob は Alice が提供した入力 x および出力 y を認める。これは一種の有効性証明メカニズムであり、ブロックチェーンコンセンサスでよく用いられる。ここで、Alice はブロックを生成するノード、Bob はコンセンサスに参加するノードである。
-
Alice が入力 x を与え、アルゴリズム f に対して zk.prove プログラムを実行し、結果 y と証明 proof を得る。Bob は f、y、proof を基に zk.verify プログラムを実行する。結果が true であれば、Bob は Alice の結果 y を認める。false であれば、認めない。これが有効性証明（Validity Proof）である。ここで Bob はオンチェーンコントラクトである可能性がある。
-
Alice が入力 x を与え、アルゴリズム f を実行して結果 y を得る。Bob も同じ入力 x に基づき f を実行し、結果 y′ を得る。y = y′ なら何もしない。y ≠ y′ なら、Bob は Alice に対してチャレンジを発動し、対象となるプログラムは f である。Alice と Bob のインタラクション回数は1回以上可能であり、チャレンジ応答プロセスによって裁定を行う。これが不正検出証明（Fraud Proof）である。ここで Bob は挑戦者であり、オフチェーンで監視し、オンチェーンでチャレンジを発動する。
-
Alice が入力 x を与え、zk.prove プログラムを実行して結果 y と証明 proof を得る。Bob は f、y、proof を基に zk.verify を実行する。結果が true なら何もしない。false なら、Bob は Alice に対してチャレンジを発動し、対象プログラムは zk.verify である。Alice と Bob のインタラクション回数は1回以上可能であり、チャレンジ応答プロセスによって裁定を行う。これも不正検出証明（Fraud Proof）である。Bob は挑戦者として、オフチェーンで監視し、オンチェーンでチャレンジを行う。
上記のケース2,3,4において、x をレイヤー2のトランザクションおよび初期状態、f をレイヤー2のコンセンサスプログラム、y をトランザクション終了時の状態とすると、これらはブロックチェーンL2スケーリングソリューションに対応する。すなわち：
-
**有効性証明（Validity Proof）**：悲観的仮定に基づき、有効であることを証明して初めて受容され、即時的に有効となる。有効性証明では、L2の状態遷移が正しいことの証拠を提供する必要があり、これは「世界」に対する悲観的見方を反映している――ある状態が正しいと証明されるまで、その状態は受け入れられない。
-
**不正検出証明（Fraud Proof）**：楽観的仮定に基づき、デフォルトで受容され、誤りが証明された場合のみ拒否される。チャレンジウィンドウ期間があり、この期間を経過してから正式に有効となる。不正検出証明では、L2の状態遷移が正しくないことを示す証拠を提供する必要があり、これは「世界」に対する楽観的見方を反映している――状態遷移はデフォルトで正しいとみなされ、誤りが証明されない限りは受け入れられる。
表1：信頼構築方式
さらに注意すべき点は以下の通りである：
-
不正検出証明と有効性証明を区別する鍵は、SNARK/STARKなどのZK証明システムを使用しているかどうかではない。ZK証明システムは使用する証明方式を示すものであり、不正か有効かは証明の内容を意味する。そのため、表1のシナリオ1が有効性証明を表すと言われる理由である。
-
有効性証明は即時性に優れるが、オンチェーンでの検証複雑度が高い。一方、不正検出証明はオンチェーンでの検証複雑度が低いが、即時性は劣る。
-
表1のケース2および4では、ZK再帰および組み合わせ技術を活用することで、複数の f の計算を圧縮し、オフチェーン計算のオンチェーン検証コストを大幅に削減できる。
現在、Solidityのチューリング完全スマートコントラクトの恩恵により、不正検出証明および有効性証明技術はイーサリアムL2スケーリングで広く利用されている。しかし、ビットコインパラダイムでは、操作コードの機能制限、スタック要素1000個の上限などにより、これらの技術の適用はまだ探索段階にある。本稿ではビットコインL2スケーリングの文脈において、ビットコインパラダイムの制約とそれを突破する技術をまとめ、有効性証明および不正検出証明技術を調査し、ビットコイン特有のスクリプト分割技術を整理する。
2 ビットコインパラダイムにおける制約と突破口
ビットコインパラダイムには多くの制約があるが、巧妙な手法や技術によりこれらを乗り越えることができる。例えば、ビットコミットメントによりUTXOのステートレス制限を突破、Taprootによりスクリプト容量制限を突破、connector outputによりUTXO消費方法の制限を突破、コベナンツによりプリサイン制限を突破することが可能である。
2.1 UTXOモデルとスクリプト制限
ビットコインはUTXOモデルを採用しており、各UTXOはlockingスクリプトにロックされており、そのUTXOを消費するために満たすべき条件を定義している。ビットコインスクリプトには以下のような制限がある：
-
ビットコインスクリプトはステートレスである；
-
P2TR出力タイプの場合、単一トランザクションに含まれる操作コードの総数は最大約400万個であり、これはブロック全体を埋め尽くす量である。他の出力タイプでは1万個程度に制限される；
-
単一UTXOの消費方法は限定されており、組み合わせ消費方法の探求が不足している；
-
柔軟なコベナンツ機能がサポートされていない；
-
スタックサイズは最大1000要素（altstack + stack）に制限され、単一要素の最大サイズは520バイト；
-
算術演算（加算・減算）は4バイト要素に限定されており、20バイト以上といった長要素への変更は不可能であるが、暗号演算にはこれが必須である；
-
OP_MUL や OP_CAT などの操作コードはすべて無効化されており、既存の操作コードで模倣するとコストが非常に高くなる。例えば、1ラウンドのBLAKE3ハッシュを模倣する場合、スクリプトサイズは約75KBとなる。
2.2 ビットコミットメント：UTXOのステートレス制限の突破
現在のビットコインスクリプトは完全にステートレスである。スクリプト実行時には、各スクリプトの実行環境が毎回リセットされる。これにより、スクリプト1とスクリプト2が同じ x 値を持つことを制約することが不可能になる。しかし、いくつかの方法で回避可能であり、その核心思想は、ある値に対して署名を行うことであり、値に署名できれば、ステートフルなビットコインスクリプトを実現できる。つまり、スクリプト1とスクリプト2で x 値の署名を検証することで、両スクリプトで同じ x 値を使用することを強制できる。同一変数 x に対して異なる2つの値が署名された場合（衝突署名）、これを罰則の対象とすることができる。この解決策がビットコミットメント（bit commitment）である。
ビットコミットメントの原理は比較的単純である。「bit」とは、署名対象メッセージの各ビットに対して2つの異なるハッシュ値（hash0 と hash1）を設定することを指す。署名したいビット値が0であれば、hash0の原像 preimage0 を開示する。ビット値が1であれば、hash1の原像 preimage1 を開示する。
1ビットのメッセージ m ∈ {0,1} を例にすると、対応するビットコミットメントのアンロックスクリプトは単なる原像である：ビット値が0ならアンロックスクリプトは preimage0 ――「0xfa7fa5b1dea37d71a0b841967f6a3b119dbea140」；ビット値が1ならアンロックスクリプトは preimage1 ――「0x47c31e611a3bd2f3a7a42207613046703fa27496」。したがって、ビットコミットメントを用いることでUTXOのステートレス制限を突破し、ステートフルなビットコインスクリプトを実現でき、さまざまな新しい特性の実現が可能となる。
OP_HASH160
OP_DUP
<0xf592e757267b7f307324f1e78b34472f8b6f46f3> // This is hash1
OP_EQUAL
OP_DUP
OP_ROT
<0x100b9f19ebd537fdc371fa1367d7ccc802dc2524> // This is hash0
OP_EQUAL
OP_BOOLOR
OP_VERIFY
// Now the value of the bit commitment is on the stack. Either "0" or "1".
ビットコミットメントには現在2種類の実装方式がある：
-
**Lamport 一時署名**：原理は比較的単純で、ハッシュ関数のみを使用すればよいので、ビットコインに適している。メッセージの各ビットに対して2つのハッシュ値をコミットする必要があるため、署名データが比較的大きくなる。つまり、v ビットのメッセージに対して、公開鍵長は 2v ビット、署名長は v ビットとなる。
-
**Winternitz 一時署名**：Lamport署名と比べて、署名および公開鍵の長さを大幅に短縮できるが、署名および検証の複雑度が増加する。この方式では、異なるハッシュチェーン長 d を柔軟に設定でき、長さと複雑度のトレードオフが可能である。例えば、d=15 とすると、公開鍵および署名長は約4分の1に短縮されるが、検証複雑度は4倍になる。これは本質的にビットコインのスタックスペースとスクリプトサイズの間のトレードオフである。Lamport署名は Winternitz 署名の d=1 の特殊ケースと見なせる。
現在、BitVM2ライブラリでは、Blake3ハッシュ関数に基づくWinternitz署名を実装している。1ビットあたりの署名長は約26バイトである。したがって、ビットコミットメントで状態を導入することは高コストであることがわかる。そのため、BitVM2の工学的実装では、まずメッセージをハッシュして256ビットのハッシュ値を得た後、そのハッシュ値に対してビットコミットメントを行い、コストを節約している。つまり、元の長いメッセージの各ビットに対して直接コミットメントを行わない。
2.3 Taproot：スクリプト容量制限の突破
2021年11月にアクティベートされたビットコインTaprootのソフトフォークアップグレードには3つの提案が含まれる：Schnorr署名（BIP 340）、Taproot（BIP 341）、TapScript（BIP 342）。これにより、新しい取引タイプ「Pay-to-Taproot（P2TR）取引」が導入された。P2TR取引は、Taproot、MAST（Merkle Abstract Syntax Tree）、Schnorr署名の利点を統合することで、よりプライベートで柔軟かつスケーラブルな取引形式を実現する。
P2TRは2種類の消費方法をサポートしている：key path または script path による消費である。
Taproot（BIP 341）の規定によると、script path 消費時に該当するMerkleパスの最大長は128を超えない。つまり、taptree内のtapleaf数は2^128個以下である。2017年のsegwitアップグレード以来、ビットコインネットワークはweight unitsでブロックサイズを測定しており、最大400万weight units（約4MB）をサポートしている。あるP2TR出力をscript pathで消費する際、実際に開示されるのは単一のtapleafスクリプトのみであり、ブロックに格納されるのも単一のtapleafスクリプトである。つまり、P2TR取引では、各tapleafのスクリプトサイズは最大約4MBである。ただし、ビットコインのデフォルトポリシーでは、多くのノードが400KB未満の取引しか中継しないため、それ以上の取引をブロックに含めるにはマイナーとの協力が必要となる。
Taprootがもたらすスクリプト容量の余裕により、既存のopcodeで乗算やハッシュなどの暗号演算を模倣することがより価値あるものとなる。
P2TR上で検証可能な計算を構築する際、スクリプトサイズはもはや4MBの制限を受けず、計算を複数のサブ関数に分割し、複数のtapleafに分散させることで、4MBのスクリプト容量制限を突破できる。実際、現在BitVM2で実装されているGroth16 verifierアルゴリズムのサイズは2GBに達するが、これを約1000個のtapleafに分割し、ビットコミットメントと組み合わせることで、各サブ関数の入出力間の一貫性を制約し、全体の計算の完全性と正しさを保証できる。
2.4 Connector output：UTXO消費方法の制限突破
ビットコインが現在提供する単一UTXOのネイティブ消費方法は、スクリプトによる消費または公開鍵による消費の2つである。したがって、対応する正しい公開鍵署名またはスクリプト条件を満たせば、UTXOを消費できる。2つのUTXOは独立して消費可能であり、追加条件を満たすまで消費できないように制約をかけることはできない。
しかし、Arkプロトコルの創設者Burakは、SIGHASHフラグを巧みに活用してconnector outputを実現した。具体的には、Aliceはある署名を作成し、BTCをBobに送金できる。しかし、署名は複数のInputsをcommitできるため、Aliceはその署名に条件を設定できる：Take_tx取引に対してのみ有効であり、かつその取引が2番目のinputを消費しているときに限り有効とする。この2番目のinputがconnectorとなり、UTXO A と UTXO B を接続する。言い換えれば、Take_tx取引が有効であるのは、UTXO B がChallenge_txで消費されていない場合に限る。したがって、connector outputを破棄することで、Take_tx取引の成立を阻止できる。
図1：connector outputの概念図
BitVM2プロトコルでは、connector outputはif...else機能を果たす。一旦connector outputが何らかの取引で消費されると、別の取引では消費できず、排他的消費が保証される。実際の展開では、チャレンジ応答期間を確保するため、timelock付きUTXOが追加で導入される。また、対応するconnector outputは必要に応じて異なる消費戦略を設定でき、例えばチャレンジ取引では誰でも消費可能とし、応答取引ではオペレータのみが消費可能、あるいは期限切れ後に誰でも消費可能とする。
2.5 コベナンツ：プリサイン制限の突破
現在のビットコインスクリプトは主にアンロック条件を制限しており、UTXOがどのようにさらに消費されるかについては制限していない。その理由は、ビットコインスクリプトが取引自体の内容を読み取れない（＝トランザクションの自己検査が不可能）ためである。もしビットコインスクリプトが取引のあらゆる内容（outputを含む）をチェックできれば、コベナンツ機能を実現できる。
現在のコベナンツ実装方法は2種類に大別される：
-
**プリサイン**：既存のビットコインスクリプト能力に基づき、事前に設計され署名された限られた機能のコベナンツを構築する。つまり、将来起こりうるすべての取引を事前に設計・署名し、参加者を特定の秘密鍵やレートにロックインする。一部のスキームでは、すべてのプリサイン取引に使用する短期秘密鍵を参加者が生成することさえ要求する。プリサイン完了後、これらの短期秘密鍵を安全に削除することで、攻撃者が短期秘密鍵を取得して資金を盗むのを防ぐ。しかし、新たな参加者の追加や更新操作のたびに、このプロセスを繰り返す必要があり、メンテナンスコストが重くなる。例えば、ライトニングネットワークはプリサインにより2者間コベナンツを実現し、ハッシュタイムロックコントラクト（HTLC）技術を活用して複数の2者間コベナンツをルーティングすることで、信頼最小化されたスケーリング戦略を実現している。しかし、ライトニングネットワークは多数の取引をプリサインする必要があり、2者間に限定されるため、やや重たい。BitVM1では、初期化ごとに数百の取引をプリサインする必要があるが、最適化されたBitVM2でも数十の取引のプリサインが必要である。BitVM1でもBitVM2でも、プリサインに参加したオペレータのみが報酬請求資格を持つ。n人の参加者がm件の取引をプリサインする場合、各参加者のプリサイン複雑度は n × m となる。
-
**コベナンツ操作コードの導入**：新しいコベナンツ機能操作コードを導入することで、コベナンツ参加者間の通信複雑度とメンテナンスコストを大幅に削減でき、ビットコインにより柔軟なコベナンツ実装をもたらす。例えば、OP_CAT：バイト列の連結に使用。機能は非常にシンプルだが、非常に強力であり、BitVMの複雑度を大幅に低減できる。OP_TXHASH：コベナンツ内での動作をより細かい粒度で制御できる。BitVMで使用すれば、より大きなオペレータ集合をサポートでき、BitVMのセキュリティ仮定を大幅に改善し、信頼最小化を進められる。また、プリサイン方式ではBitVM設計において、オペレータが前払い→償還のプロセスしか採用できず、資金効率が低い。一方、新しいコベナンツ操作コードにより、peg-in資金プールから直接出金ユーザーに支払うことが可能になり、資金効率をさらに高められる。したがって、柔軟なコベナンツ方式は、従来のプリサイン制限を効果的に突破できる。
3 ビットコインL2スケーリング：有効性証明と不正検出証明
有効性証明と不正検出証明はいずれもビットコインL2スケーリングに利用可能であり、主な違いは表2の通りである。
表2：有効性証明と不正検出証明
ビットコミットメント、Taproot、プリサイン、connector outputに基づき、ビットコイン上の不正検出証明を構築できる。Taprootに加え、OP_CATなどのコベナンツ操作コードを導入することで、ビットコイン上の有効性証明を構築できる。また、Bobに参加制限があるかどうかにより、不正検出証明は許可型と無許可型に分けられる。許可型では、特定のグループのみがBobとしてチャレンジを発動できる。無許可型では、任意の第三者がBobとしてチャレンジを発動できる。無許可型のセキュリティは許可型より優れており、許可参加者同士の共謀リスクを低減できる。
AliceとBobのチャレンジ応答インタラクション回数により、不正検出証明は1ラウンド型と多ラウンド型に分けられ、図2の通りである。
図2：1ラウンド不正検出証明と多ラウンド不正検出証明
表3に示すように、不正検出証明は1ラウンドインタラクションモデルと多ラウンドインタラクションモデルという異なるインタラクションモデルで実現できる。
表3：1ラウンドインタラクションと多ラウンドインタラクション
ビットコインL2スケーリングパラダイムにおいて、BitVM1は多ラウンド不正検出証明メカニズムを採用し、BitVM2は1ラウンド不正検出証明メカニズムを採用し、bitcoincircle starkは有効性証明を採用している。BitVM1およびBitVM2はビットコインプロトコルの一切の変更なしに実施可能であるが、bitcoin-circle starkは新しい操作コードOP_CATの導入が必要である。
ほとんどの計算タスクにおいて、ビットコインのsignet、testnet、mainnetでは4MBのスクリプトで完全に表現できないため、スクリプトSplit技術――つまり、完全な計算を表現するスクリプトを4MB未満のチャンクに分割し、各tapleafに分散させる――を使用する必要がある。
3.1 ビットコイン上での多ラウンド不正検出証明
表3に示すように、多ラウンド不正検出証明は、オンチェーン仲裁計算量を削減したい、または一度に問題のある計算断片を特定できないようなシナリオに適している。多ラウンド不正検出証明とは文字通り、証明者と検証者の間で複数回のインタラクションを通じて問題のある計算断片を特定し、その後その断片に基づいて仲裁を行うものである。
Robin Linusの初期のBitVMホワイトペーパー（通常BitVM1と呼ばれる）では、多ラウンド不正検出証明が使用されていた。各チャレンジ期間を1週間と仮定し、二分探索法で問題のある計算断片を特定する場合、Groth16 Verifierのオンチェーンチャレンジ応答サイクルは最大30週間にもなり、即時性が極めて悪い。現在、二分法より効率的なn分探索法を研究するチームもあるが、1ラウンド不正検出証明の2週間サイクルと比べると、依然として即時性が大きく劣る。
現在、ビットコインパラダイムにおける多ラウンド不正検出証明はすべて許可型チャレンジを採用しているが、1ラウンド不正検出証明は無許可型チャレンジを実現し、参加者間の共謀リスクを低減することで、より高いセキュリティを実現している。このため、Robin LinusはTaprootの利点を十分に活用し、BitVM1を最適化した。インタラクション回数を1ラウンドに削減するだけでなく、チャレンジ方式を無許可型に拡張したが、その代償としてオンチェーン仲裁計算量が増加している。
3.2 ビットコイン上での1ラウンド不正検出証明
証明者と検証者の間で1回のインタラクションのみで不正検出証明の検証を完了する。このモデルでは、検証者は1回のチャレンジを発動し、証明者は1回の応答を行うだけでよい。この応答の中で証明者は、自身の計算が正しいと主張する証拠を提供する。検証者がこの証拠から矛盾を見つけ出せればチャレンジ成功、そうでなければ失敗となる。1ラウンドインタラクション不正検出証明の特徴は表3の通りである。
図3：1ラウンド不正検出証明
Robin Linusは2024年8月15日、「BitVM2: Bridging Bitcoin to Second Layers」技術ホワイトペーパーを発表し、図3と同様の方式で1ラウンド不正検出証明を用いてBitVM2クロスチェーンブリッジを実現した。
3.3 ビットコイン + OP_CAT による有効性証明の実現
OP_CATはビットコイン初回リリース時のスクリプト言語の一部であったが、セキュリティ脆弱性の問題で2010年に無効化された。しかし、長年にわたりビットコインコミュニティはその再活性化を議論してきた。現在、OP_CATは番号347が割り当てられ、ビットコインsignet上で有効化されている。
OP_CATの主な機能は、スタック内の2つの要素を結合し、その結果をスタックに戻すことである。この機能により、ビットコイン上でのコベナンツおよびSTARK Verifierの実現が可能になる：
-
**コベナンツ**：Andrew Poelstraは「CAT and Schnorr Tricks I」で、OP_CATとSchnorrの技巧を用いてビットコイン上にコベナンツを実現した。ここでSchnorrアルゴリズムはP2TR出力タイプのデジタル署名である。他の出力タイプでは、ECDSAの技巧を用いることも可能（Covenants with CAT and ECDSA参照）。OP_CATコベナンツにより、STARK Verifierアルゴリズムを複数の取引に分割し、段階的にSTARK proof全体を検証できる。
-
**STARK Verifier**：STARK Verifierは本質的にデータを連結し、ハッシュ演算を行うものである。代数演算とは異なり、ハッシュ演算はビットコインスクリプトのネイティブ操作であり、大幅なコスト削減が可能である。OP_SHA256を例にすると、ネイティブ方式は1つの操作コードにすぎないが、模倣方式では数十万の操作コードが必要になる。STARKにおける主要なハッシュ演算はMerkleパスの検証とFiat-Shamir変換である。したがって、OP_CATはSTARK Verifierアルゴリズムにとって非常に好都合である。
3.4 ビットコインスクリプトSplit技術
SNARK/STARKで証明された後、対応するverifierアルゴリズムを用いてproofを検証する計算量は、元の計算fを直接実行するよりもはるかに少ない。しかし、これをビットコインスクリプトで実装する際のスクリプト量は依然として巨大である。現在、既存のビットコイン操作コードを最適化しても、Groth16 verifierスクリプトサイズやFflonk verifierスクリプトサイズはいずれも2GBを超えている。しかし、ビットコインの単一ブロックサイズは4MBに過ぎず、単一ブロック内でverifierスクリプト全体を実行することは不可能である。しかし、Taprootアップグレード後、ビットコインはtapleaf単位でのスクリプト実行をサポートしており、verifierスクリプトを複数のチャンクに分割し、各チャンクをtapleafとしてtaptreeを構築できる。各チャンク間は、ビットコミットメントにより値の一貫性を保証する。
OP_CATコベナンツがある場合、STARK Verifierを400KB未満の標準取引に分割でき、マイナーとの協力なしにSTARK有効性証明全体の検証を完了できる。
本節では、新規操作コードの活性化を一切導入しない現状における、ビットコインスクリプトのSplit技術に注目する。
スクリプト分割を行う際、以下の次元情報をバランスさせる必要がある：
-
単一チャンクのスクリプトサイズは4MBを超えてはならず、inputビットコミットメントスクリプト、取引署名などのスペースを含む必要がある。
-
単一チャンクのスタックサイズは最大1000を超えてはならない。したがって、各チャンクのスタック上には必要な要素のみを残し、スクリプトサイズ最適化のために十分なスタックスペースを確保すべきである。ビットコイン取引手数料は使用スタックサイズに依存しないため。
-
ビットコイン上のビットコミットメントは高コストである。現在、1ビットあたり26バイトであるため、隣接する2つのチャンク間の入出力ビット数を最小化すべきである。
-
監査を容易にするため、各チャンクの機能はできるだけ明確であるべきである。
現在、スクリプト分割方式は主に以下の3種類に大別される：
-
**自動分割**：スタックサイズとスクリプトサイズに基づき、スクリプトサイズが約3MBでスタックサイズが最小となる分割方式を探す。この方式の利点は、特定のverifierアルゴリズムに依存せず、任意の計算のスクリプト分割に拡張可能であること。欠点は：(1) OP_IFなどのブロック全体を別途マークする必要があり、分割されるとスクリプト実行結果が正しくなくなる；(2) チャンクの実行結果がスタック上の複数要素に対応する場合、実際の計算ロジックに基づきビットコミットメントを適用すべきスタック要素数をマークする必要がある；(3) 各チャンクスクリプトのロジック機能の可読性が悪く、監査が困難；(4) スタック上に次のチャンクで不要な要素が含まれる可能性があり、スタックスペースを浪費する。
-
**機能的分割**：計算中の各機能サブ関数に基づいて分割する。サブ関数の入出力値が明確であり、スクリプト分割と同時に各チャンクに必要なビットコミットメントスクリプトも実現され、最終的なチャンクスクリプト総サイズが4MB未満、スタックサイズが1000未満になればよい。利点は、機能が明確で、単一チャンクのロジックが明確であり、可読性が高く、監査が容易であること。欠点は、元の計算ロジックの表現とスクリプトレベルの表現が一致せず、元の計算サブ関数が最適でも、スクリプトレベルで最適とは限らない。
-
**手動分割**：スクリプト分割ポイントが機能サブ関数ではなく、人為的に設定される。特に単一サブ関数サイズが4MBを超える場合に適している。利点は、Fq12関連計算サブ関数など、スクリプトサイズが大きいサブ関数を人為的に分割でき、単一チャンクのロジックが明確で可読性が高く、監査が容易であること。欠点は、人為的な調整能力に依存しており、全体スクリプトの最適化後、以前に設定した各分割ポイントが最適でなくなる可能性があり、再調整が必要となる。
例えば、Groth16 verifierは複数回の最適化を経て、スクリプトサイズが約7GBから約1.26GBに削減された。このような全体計算最適化に加え、各チャンクを個別に最適化し、スタックスペースを十分に活用することも可能である。例えば、より優れたルックアップテーブルベースのアルゴリズムを導入し、ルックアップテーブルを動的にロード・アンロードすることで、各チャンクのスクリプトサイズをさらに削減できる。
web2プログラミング言語の計算コストと実行環境は、ビットコインスクリプトのコストと実行環境とは全く異なるため、各種アルゴリズムのビットコインスクリプト実装において、既存実装を単に翻訳するだけでは通用しない。したがって、ビットコインのシナリオに応じて以下の最適化を検討する必要がある：
-
メモリ局所性が最適なアルゴリズムを探す。計算量を犠牲にしても、チャンク間の入出力ビット数を削減し、BitVM2設計におけるassertTx取引がコミットするデータ量を削減できる。
-
関連演算（論理演算など）の交換法則を活用する。x&y = y&x により、ルックアップテーブルをほぼ半分に節約できる。
-
現在、Fq12演算に対応するスクリプト量は非常に大きいため、Fiat-Shamir、Schwartz-Zipple、多項式コミットメントスキームを活用して、Fq12拡大体演算の計算複雑度を大幅に削減できる。
4 まとめ
本稿ではまず、ビットコインスクリプトの制限について紹介し、ビットコミットメントによるUTXOのステートレス制限の突破、Taprootによるスクリプト容量制限の突破、connector outputによるUTXO消費方法の制限突破、コベナンツによるプリサイン制限の突破について述べた。続いて、不正検出証明と有効性証明の特徴、許可型と無許可型不正検出証明の特徴、1ラウンド型と多ラウンド型不正検出証明の特徴、ビットコインスクリプト分割技術について包括的に整理・要約した。
TechFlow公式コミュニティへようこそ
Telegram購読グループ：https://t.me/TechFlowDaily
Twitter公式アカウント：https://x.com/TechFlowPost
Twitter英語アカウント：https://x.com/BlockFlow_News
@BitlayerLabs
