BitVM の原理分析と最適化に関する考慮事項
出典: Bitlayer Research Group
原作者：リンデル、ミュートゥーレンド。
1 はじめに
ビットコインは、分散型で安全かつ信頼できるデジタル資産です。ただし、支払いやその他のアプリケーションのスケーラブルなネットワークになることを妨げる重大な制限があります。ビットコインのスケーリング問題は、その誕生以来懸念されてきました。ビットコイン UTXO モデルは、各トランザクションを独立したイベントとして扱うため、複雑な状態依存の計算を実行する機能が欠如したステートレス システムになります。したがって、ビットコインは単純なスクリプトと複数署名トランザクションを実行できますが、ステートフル ブロックチェーン プラットフォームで一般的な複雑で動的なコントラクト インタラクションを容易にするのは困難です。この問題により、ビットコイン上に構築できる分散型アプリケーション (dApps) と複雑な金融商品の範囲が大幅に制限される一方、状態モデル プラットフォームは、機能豊富なスマート コントラクトを展開および実行するためのより多様な環境を提供します。
ビットコインの拡張には、主にステートチャネル、サイドチェーン、クライアント検証などのテクノロジーがあります。その中で、国家チャネルは安全で多様な支払いソリューションを提供しますが、任意の複雑な計算を検証する能力には限界があります。この制限により、複雑な条件付きロジックと対話を必要とするさまざまなシナリオでの使用が減少します。サイドチェーンは、幅広いアプリケーションをサポートし、ビットコインを超える多様な機能を提供しますが、セキュリティは低くなります。このセキュリティの違いは、サイドチェーンがビットコインのコンセンサス メカニズムよりもはるかに堅牢でない独立したコンセンサス メカニズムを使用しているという事実に起因しています。ビットコイン UTXO モデルを使用したクライアント側検証は、より複雑なトランザクションを処理できますが、ビットコインの双方向チェックサム制約機能がないため、ビットコインよりもセキュリティが低くなります。クライアント検証プロトコルのオフチェーン設計はサーバーまたはクラウド インフラストラクチャに依存しているため、侵害されたサーバーによる集中化や検閲が発生する可能性があります。クライアント側検証のオフチェーン設計により、ブロックチェーン インフラストラクチャがさらに複雑になり、スケーラビリティの問題が発生する可能性があります。
2023 年 12 月、ZeroSync プロジェクト リーダーの Robin Linus は、「BitVM：Compute Anything On Bitcoin「このホワイトペーパーは、ビットコインのプログラマビリティの向上について誰もが考えるきっかけになりました。この論文では、ビットコイン ネットワークのコンセンサスを変更することなくチューリング完全性を達成できるビットコイン コントラクト ソリューションを提案します。これにより、ビットコインの基本ルールを変更することなく、あらゆる複雑な計算をビットコイン上で検証できます。 BitVM は、ビットコイン スクリプトと Taproot を活用して楽観的なロールアップを実装します。 Lamport 署名 (ビット コミットメントとも呼ばれる) に基づいて、2 つのビットコイン UTXO 間で接続が確立され、ステートフル ビットコイン スクリプトが実装されます。 Taproot アドレスの大規模なプログラムにコミットすることで、オペレーターとバリデーターは広範なオフチェーンのやり取りに従事し、結果としてオンチェーンのフットプリントが小さくなります。双方が協力すれば、任意の複雑なステートフルなオフチェーン計算をチェーン上に痕跡を残さずに実行できます。双方が協力しない場合、紛争が発生した場合、オンチェーンでの実行が必要になります。その結果、BitVM はビットコインの潜在的なユースケースを大幅に広げ、ビットコインが通貨としてだけでなく、さまざまな分散アプリケーションや複雑なコンピューティング タスクの検証プラットフォームとしても機能できるようになります。
ただし、BitVM テクノロジーはビットコインの拡大において大きな利点を持っていますが、まだ初期段階にあり、効率とセキュリティの点でまだいくつかの問題があります。例: (1) チャレンジとレスポンスには複数の対話が必要であり、その結果、高額な手数料と長いチャレンジサイクルが発生します; (2) Lamport のワンタイム署名データは長いため、データ長を減らす必要があります; (3) ハッシュ関数は複雑でビットコインに優しいハッシュ関数が必要なため、コストが削減されます (4) 既存の BitVM 契約は巨大で、ビットコイン ブロックの容量は限られているため、スクリプトレス スクリプトを使用してスクリプトレス スクリプト BitVM を実装でき、BitVM の効率を向上させながらビットコイン ブロック スペースを節約できます (5)既存の BitVM はパーミッション モデルを採用しています。アライアンス メンバーのみがチャレンジを開始でき、2 者のみに制限されています。信頼の前提をさらに軽減するには、パーミッションレスのマルチパーティ チャレンジ モデルに拡張する必要があります。この目的を達成するために、この記事では BitVM の効率とセキュリティをさらに向上させるためのいくつかの最適化アイデアを提案します。
2.BitVMの原理
BitVM はビットコインのオフチェーン コントラクトとして位置付けられており、ビットコイン コントラクト機能の促進に取り組んでいます。現在、ビットコイン スクリプトは完全にステートレスであるため、ビットコイン スクリプトが実行されると、スクリプトごとに実行環境がリセットされます。スクリプト 1 とスクリプト 2 に同じ x 値を持たせるネイティブな方法はなく、ビットコイン スクリプトではネイティブにサポートされていません。ただし、既存のオペコードを使用して、Lamport のワンタイム署名を通じてビットコイン スクリプトをステートフルにすることはできます。たとえば、スクリプト 1 とスクリプト 2 の x を強制的に同じ値にすることができます。参加者が矛盾する x 値に署名すると、ペナルティが課される可能性があります。 BitVM プログラムの計算はオフチェーンで行われ、計算結果の検証はオンチェーンで行われます。現在のビットコイン ブロックには 1 MB の制限があり、検証計算が複雑すぎる場合、OP テクノロジーを使用してチャレンジ レスポンス モードを採用し、より複雑な計算検証をサポートできます。
オプティミスティック ロールアップや MATT 提案 (Merkelize All The Things) と同様に、BitVM システムは不正防止とチャレンジ/レスポンス プロトコルに基づいていますが、ビットコインのコンセンサス ルールを変更する必要はありません。 BitVM の基礎となるプリミティブは単純で、主にハッシュ ロック、タイム ロック、および大きなタップルート ツリーに基づいています。
証明者はバイトごとにコミットしますが、すべての計算をオンチェーンで検証するにはコストがかかりすぎます。したがって、検証者は、証明者の誤った主張を簡潔に反論するために、慎重に設計された一連のチャレンジを実行します。証明者と検証者は、紛争の解決に使用される一連のチャレンジとレスポンスのトランザクションに共同で事前署名し、ビットコインの普遍的な計算検証を可能にします。
BitVM の主要なコンポーネントは次のとおりです。
サーキットへの取り組み:証明者と検証者は、プログラムを大きなバイナリ回路にコンパイルします。証明者は、回路内の各論理ゲートに対応する、そのアドレスの下の各リーフ スクリプトに対して、Taproot アドレスで回路にコミットします。コアはビット コミットメントに基づいて、ロジック ゲート コミットメントと回路コミットメントを実装します。
課題と対応:証明者と検証者は、チャレンジ-レスポンス ゲームを実装するために一連のトランザクションに事前署名します。理想的には、この対話はオフチェーンで実行されますが、証明者が非協力的な場合はオンチェーンで実行することもできます。
あいまいさのペナルティ:証明者が誤った主張をした場合、検証者は、証明者の邪悪な行為を阻止するための挑戦に成功した後、証明者の保証金を取り上げることができます。
3.BitVMの最適化
3.1 ZK に基づいて OP インタラクションの数を削減する
現在、主流のロールアップには、ZK ロールアップと OP ロールアップの 2 つがあります。このうち、ZK Rollups は ZK Proof の有効性検証、つまり正しい実行の暗号証明に依存し、その安全性は計算複雑性の仮定に依存し、OP Rollups は提出された状態が正しいことを前提とした Fraud Proof に依存します。チャレンジ期間は通常 7 日間で、そのセキュリティでは、システム内の少なくとも 1 人の誠実な関係者が不正な状態を検出し、不正行為の証拠を提出できることが前提となっています。 BitVM チャレンジ プログラムの最大ステップ数は 2 ^{ 32 }、必要なメモリは 2 ^{ 32 }* 4 バイト、つまり約 17 GB であると仮定します。最悪の場合、チャレンジとレスポンスを約 40 回、約半年かかり、スクリプトの合計は約 150 KB になります。この状況ではインセンティブが著しく欠如していますが、実際にはそのようなことはほとんどありません。
ゼロ知識証明を使用して BitVM チャレンジの数を減らし、BitVM の効率を向上させることを検討してください。ゼロ知識証明理論によれば、データがDataアルゴリズムを満たすF、証明が検証アルゴリズムを満たしていることを証明しますVerifyつまり、データが一致する場合、検証アルゴリズムは True を出力します。Dataアルゴリズムを満たしていませんF、証明も検証アルゴリズムを満たしていないことが証明されます。Verifyつまり、検証アルゴリズムは False を出力します。 BitVM システムでは、証明者が提出したデータを挑戦者が認識しない場合、チャレンジが開始されます。
アルゴリズムについてF、必要であると仮定して、二分法を使用して分割します。2 ^n何度もエラー箇所を見つけることができますが、アルゴリズムの複雑さが高すぎると、n が大きくなり、完了までに時間がかかります。ただし、ゼロ知識証明の検証アルゴリズムは、Verify複雑さは修正され、証明と検証のアルゴリズムは公開されていますVerifyプロセス全体を通じて、出力は False であることが判明しました。ゼロ知識証明の利点は、検証アルゴリズムをオープンにすることです。Verify二分開オリジナルアルゴリズムと比較した必要な計算量F、 はるかに低いです。したがって、ゼロ知識証明により、BitVM は元のアルゴリズムに挑戦しなくなります。F、しかし検証アルゴリズムVerify、チャレンジラウンド数を減らし、チャレンジ期間を短縮します。
最後に、ゼロ知識証明の有効性と不正証明は異なるセキュリティ前提に依存しますが、これらを組み合わせて ZK 不正証明を構築し、オンデマンド ZK 証明を実装することができます。個別の状態遷移ごとに ZK プルーフを生成する必要がなくなった完全な ZK ロールアップとは異なり、オンデマンド モデルでは、ロールアップ設計全体が楽観的なままで、課題がある場合にのみ ZK プルーフが必要になります。したがって、結果として得られる状態は、誰かがそれに異議を唱えるまで、デフォルトで引き続き有効です。状態に異議が唱えられていない場合、ZK プルーフを生成する必要はありません。ただし、参加者がチャレンジを開始した場合、チャレンジ ブロック内のすべてのトランザクションが正しいかどうかを確認するために ZK プルーフを生成する必要があります。将来的には、常に ZK Proof を生成する計算コストを回避するために、物議を醸している単一の命令に対して ZK Fraud Proof を生成することを検討できます。
3.2 ビットコインに優しいワンタイム署名
ビットコインネットワークでは、コンセンサスルールに従ったトランザクションが有効なトランザクションとなりますが、コンセンサスルールに加えて標準性ルールも導入されています。ビットコインノードはブロードキャスト標準トランザクションのみを転送します。有効ではあるが非標準トランザクションをパッケージ化する唯一の方法は、マイナーと直接連携することです。
コンセンサス ルールによれば、レガシー (非 Segwit) トランザクションの最大サイズは 1 MB で、ブロック全体を占有します。ただし、レガシー トランザクションの標準性は 100 KB に制限されています。コンセンサス ルールによれば、Segwit トランザクションの最大サイズは 4 MB であり、これが重量制限です。ただし、Segwit トランザクションの標準性は 400 KB に制限されています。
Lamport 署名は BitVM の基本コンポーネントであり、署名と公開キーの長さが短縮されるため、トランザクション データが削減され、それによって手数料が削減されます。 Lamport のワンタイム署名では、ハッシュ関数 (一方向置換関数 f など) を使用する必要があります。 Lamport のワンタイム署名方式では、メッセージ長は v ビット、公開鍵の長さは 2 v ビット、署名の長さも 2 v ビットです。署名と公開キーは長く、大量のストレージ ガスを必要とします。したがって、署名と公開キーの長さを短縮するために、同様の機能を持つ署名スキームを見つける必要があります。 Lamport ワンタイム署名と比較して、Winternitz ワンタイム署名は署名と公開鍵の長さを大幅に短縮しますが、署名と署名検証の計算の複雑さは増加します。
Winternitz ワンタイム署名スキームでは、特別な関数を使用しますP意思vビットのメッセージは、次の長さにマッピングされます。nのベクトルs。sの各要素の値は { 0,...,d}。 Lamport のワンタイム署名スキームは、d= 1 Winternitz ワンタイム署名スキームの特殊なケース。 Winternitz の 1 回限りの署名スキームでは、n, d, v間の関係は次のとおりです。n≈v/log 2(d+ 1)。 d= 15 の場合、次のようになります。n≈(v/4)+ 1 。を含む場合n要素の Winternitz 署名は、Lamport のワンタイム署名スキームの公開鍵の長さと署名の長さの 4 分の 1 です。ただし、署名検証の複雑さは 4 倍になります。 BitVMで使用されるd= 15, v= 160, f=ripemd 160(x) Winternitz ワンタイム署名を実装すると、ビット コミットメント サイズが 50% 削減され、BitVM のトランザクション手数料が少なくとも 50% 削減されます。将来的には、既存の Winternitz Bitcoin Script 実装を最適化しながら、Bitcoin Script で表現されるよりコンパクトなワンタイム署名スキームを検討することができます。
3.3 ビットコインに適したハッシュ関数
コンセンサス ルールによれば、P 2 TR スクリプトの最大サイズは 10 KB で、P 2 TR スクリプト監視の最大サイズは Segwit トランザクションの最大サイズと同じ 4 MB です。ただし、P 2 TR スクリプト監視の標準制限は 400 KB です。
現在のビットコイン ネットワークは OP_CAT をサポートしておらず、マークル パス検証のために文字列を結合することはできません。したがって、マークル包含証明検証機能をサポートするには、既存のビットコイン スクリプトを使用して、最適なスクリプト サイズとスクリプト監視サイズでビットコイン フレンドリーなハッシュ関数を実装する必要があります。
BLAKE 3 は BLAKE 2 ハッシュ関数の最適化されたバージョンであり、Bao ツリー モードが導入されています。 BLAKE 2 sベースと比較して、圧縮機能のラウンド数が10ラウンドから7ラウンドに削減されています。 BLAKE 3 ハッシュ関数は、入力をサイズ 1024 バイトの連続したチャンクに分割します。最後のチャンクは短い場合がありますが、空ではありません。チャンクが 1 つだけある場合、そのチャンクはルート ノードであり、ツリーの唯一のノードです。これらのチャンクをバイナリ ツリーのリーフ ノードとして配置し、各チャンクを個別に圧縮します。
BitVM を使用してマークル包含証明シナリオを検証する場合、ハッシュ演算の入力は 2 つの 256 ビット ハッシュ値で構成されます。つまり、ハッシュ演算の入力は 64 バイトです。 BLAKE 3 ハッシュ関数を使用する場合、これらの 64 バイトは 1 つのチャンク内に割り当てることができ、BLAKE 3 ハッシュ操作全体で圧縮関数を 1 つのチャンクに 1 回適用するだけで済みます。 BLAKE 3 の圧縮関数では、7 つのラウンド関数と 6 つの置換関数を実行する必要があります。
現時点では、u32値に基づくXOR、モジュラー加算、ビット右シフトなどの基本演算がBitVM上で完了しており、Bitcoinスクリプトで実装されるBLAKE3ハッシュ関数を簡単に組み立てることができます。スタック内の 4 つの個別のバイトを使用して u 32 ワードを表し、BLAKE 3 で必要な u 32 の加算、u 32 のビットごとの XOR、および u 32 のビットごとの回転を実装します。現在の BLAKE 3 ハッシュ関数 Bitcoin スクリプトの合計は約 100 KB で、おもちゃ版の BitVM を構築するには十分な量です。
さらに、これらの BLAKE 3 コードは分割できるため、Verifier と Prover は、チャレンジ レスポンス ゲームの実行を完全に実行するのではなく半分に分割することで、必要なオンチェーン データを大幅に削減できます。最後に、ビットコイン スクリプトを使用して Keccak-256 や Grøstl などのハッシュ関数を実装し、最もビットコインに適したハッシュ関数を選択し、他の新しいビットコインに適したハッシュ関数を探索します。
3.4 Scriptless Scripts BitVM
スクリプトレス スクリプトは、Schnorr 署名を使用してスマート コントラクトをオフチェーンで実行する方法です。 Scripless Scripts の概念は Mimblewimble から生まれ、カーネルとその署名以外には永続的なデータは保存されません。
スクリプトレス スクリプトの利点は、機能性、プライバシー、効率性です。
関数：スクリプトレス スクリプトにより、スマート コントラクトの範囲と複雑さが増大します。ビットコインのスクリプト機能は、ネットワーク内で有効になっている OP_CODES の数によって制限され、スクリプトレス スクリプトは、新しいものが有効になるためにビットコイン ネットワークのフォークを待つことなく、スマート コントラクトの仕様と実行をチェーンから設計コントラクトの参加者間でのみ議論するように転送します。 .オペコード。
プライバシー：スマートコントラクトの仕様と実行をオンチェーンからオフチェーンに移行すると、プライバシーが向上します。チェーン上では、参加者の数やアドレス、転送金額など、契約の多くの詳細がネットワーク全体に共有されます。スマート コントラクトをオフチェーンに移動することで、ネットワークは、参加者が契約条件が満たされ、基礎となるトランザクションが有効であることに同意していることだけを認識します。
効率：スクリプトレス スクリプトは、オンチェーンで検証および保存されるデータの量を最小限に抑えます。スマートコントラクトをオフチェーンに移行することで、フルノードの管理手数料が削減され、ユーザーの取引手数料も削減されます。
スクリプトレス スクリプトは、明示的なスマート コントラクトの実行を回避する、ビットコイン上の暗号プロトコルを設計するためのアプローチです。中心的なアイデアは、スクリプトを使用して機能を実現するのではなく、暗号アルゴリズムを使用して目的の機能を実現することです。アダプターの署名とマルチ署名は、スクリプトレス スクリプトの元の構成要素です。スクリプトレス スクリプトを使用すると、通常のトランザクションよりも小規模なトランザクションを実現し、トランザクション手数料を削減できます。
スクリプトレス スクリプトを使用すると、Schnorr マルチ署名とアダプター署名を使用できます。これにより、BitVM ソリューションのようなハッシュ値とハッシュ プリイメージが提供されなくなり、BitVM 回路でロジック ゲート コミットメントを実現できるため、BitVM スクリプト スペースとBitVM の効率が向上します。既存のスクリプトレス スクリプト スキームは BitVM スクリプトのスペースを削減できますが、公開キーを結合するために証明者と挑戦者の間で多くの対話が必要になります。将来的には、このソリューションを改善し、特定の BitVM 機能モジュールに Scripless Script を導入することを試みる予定です。
3.5 許可のないマルチパーティチャレンジ
現在、BitVM チャレンジにデフォルトで許可が必要な理由は、ビットコインの UTXO が 1 回しか実行できないため、悪意のある検証者が誠実な証明者にチャレンジして契約を「無駄にする」可能性があるためです。 BitVM は現在、2 者間チャレンジ モードに制限されています。悪を行おうとする証明者は、自身が管理する検証者と同時に異議を申し立てることができ、それによって契約を「無駄」にし、悪事を成功させ、他の検証者はその行為を阻止できなくなります。したがって、Bitcoin に基づいて、BitVM の既存の 1-of-n 信頼モデルを 1-of-N に拡張できる、パーミッションレスのマルチパーティ OP チャレンジ プロトコルを研究する必要があります。このうち、N は n よりもはるかに大きいです。さらに、異議申し立て者が証明者と共謀したり、悪意を持って「無駄な」契約に異議を唱えたりする問題に対処するための研究も必要です。最終的には、信頼性の低い BitVM プロトコルを実装します。
許可のないマルチパーティチャレンジ。許可リストなしで誰でも参加できます。これは、ユーザーが信頼できる第三者の関与なしに L2 からコインを引き出すことができることを意味します。さらに、OP チャレンジ プロトコルへの参加を希望するユーザーは、無効な出金に異議を申し立て、削除することができます。
BitVM をパーミッションレスなマルチパーティ チャレンジ モデルに拡張するには、次の攻撃を解決する必要があります。
魔女の攻撃:攻撃者が複数の ID を偽造して紛争の申し立てに参加した場合でも、単一の正直な当事者が紛争に勝つことができます。正直な当事者が正しい結果を守るためのコストが攻撃者の数に線形関係がある場合、多数の攻撃者が関与すると、紛争に勝つためのコストは非現実的となり、魔女の攻撃に対して脆弱になります。紙 Permissionless Refereed Tournamentsは、単一の正直な当事者が紛争に勝つコストが、相手の数に応じて線形ではなく対数的に増加する、ゲームを変える紛争解決アルゴリズムを提案しています。
遅延攻撃:悪意のある当事者、または悪意のある当事者のグループは、L1 での正しい結果の確認 (L1 への資産の引き出しなど) を防止または遅らせる戦略に従い、誠実な証明者に L1 料金の支払いを強制します。この問題は、挑戦者に事前にステークを要求することで軽減できます。挑戦者が遅延攻撃を開始した場合、その賭け金は没収されます。ただし、攻撃者が遅延攻撃を追求するために一定の制限内でステーキングを犠牲にする場合は、遅延攻撃の影響を軽減するための対策が必要です。紙 BoLD: Bounded Liquidity Delay in a Rollup Challenge Protocol提案されたアルゴリズムでは、攻撃者がどれだけのプレッジを失うことをいとわないとしても、最悪の場合の攻撃は一定の上限の遅延しか引き起こさないようにします。
将来的には、ビットコインの特性に適し、上記の攻撃問題に対抗できる BitVM パーミッションレス マルチパーティ チャレンジ モデルを検討していきます。
4 結論
BitVM テクノロジーの探求はまだ始まったばかりですが、将来的には、ビットコインの拡大を達成し、ビットコイン エコシステムを繁栄させるために、さらなる最適化の方向性が探究され、実装されるでしょう。
参考文献
