出典: Bitlayer Research Group原作者：リンデル、ミュートゥーレンド。##1 はじめにビットコインは、分散型で安全かつ信頼できるデジタル資産です。ただし、支払いやその他のアプリケーションのスケーラブルなネットワークになることを妨げる重大な制限があります。ビットコインのスケーリング問題は、その誕生以来懸念されてきました。ビットコイン UTXO モデルは、各トランザクションを独立したイベントとして扱うため、複雑な状態依存の計算を実行する機能が欠如したステートレス システムになります。したがって、ビットコインは単純なスクリプトと複数署名トランザクションを実行できますが、ステートフル ブロックチェーン プラットフォームで一般的な複雑で動的なコントラクト インタラクションを容易にするのは困難です。この問題により、ビットコイン上に構築できる分散型アプリケーション (dApps) と複雑な金融商品の範囲が大幅に制限される一方、状態モデル プラットフォームは、機能豊富なスマート コントラクトを展開および実行するためのより多様な環境を提供します。ビットコインの拡張には、主にステートチャネル、サイドチェーン、クライアント検証などのテクノロジーがあります。その中で、国家チャネルは安全で多様な支払いソリューションを提供しますが、任意の複雑な計算を検証する能力には限界があります。この制限により、複雑な条件付きロジックと対話を必要とするさまざまなシナリオでの使用が減少します。サイドチェーンは、幅広いアプリケーションをサポートし、ビットコインを超える多様な機能を提供しますが、セキュリティは低くなります。このセキュリティの違いは、サイドチェーンがビットコインのコンセンサス メカニズムよりもはるかに堅牢でない独立したコンセンサス メカニズムを使用しているという事実に起因しています。ビットコイン UTXO モデルを使用したクライアント側検証は、より複雑なトランザクションを処理できますが、ビットコインの双方向チェックサム制約機能がないため、セキュリティはビットコインよりも低くなります。クライアント検証プロトコルのオフチェーン設計はサーバーまたはクラウド インフラストラクチャに依存しているため、侵害されたサーバーによる集中化や検閲が発生する可能性があります。クライアント側検証のオフチェーン設計により、ブロックチェーン インフラストラクチャがさらに複雑になり、スケーラビリティの問題が発生する可能性があります。2023 年 12 月、ZeroSync プロジェクト リーダーの Robin Linus は「BitVM: Compute Anything On Bitcoin」と呼ばれるホワイト ペーパーを発表し、これをきっかけにビットコインのプログラマビリティの向上について誰もが考えるようになりました。この論文では、ビットコイン ネットワークのコンセンサスを変更することなくチューリング完全性を達成できるビットコイン コントラクト ソリューションを提案します。これにより、ビットコインの基本ルールを変更することなく、あらゆる複雑な計算をビットコイン上で検証できます。 BitVM は、Bitcoin Script と 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 テクノロジーを使用してチャレンジ レスポンス モードを採用し、より複雑な計算検証をサポートできます。Optimistic Rollup や MATT 提案 (Merkelize All The Things) と同様に、BitVM システムは不正防止およびチャレンジ/レスポンス プロトコルに基づいていますが、ビットコインのコンセンサス ルールを変更する必要はありません。 BitVM の基礎となるプリミティブは単純で、主にハッシュ ロック、タイム ロック、および大きなタップルート ツリーに基づいています。証明者はバイトごとにコミットしますが、すべての計算をオンチェーンで検証するにはコストがかかりすぎます。したがって、検証者は、証明者の誤った主張を簡潔に反論するために、慎重に設計された一連のチャレンジを実行します。証明者と検証者は、紛争の解決に使用される一連のチャレンジとレスポンスのトランザクションに共同で事前署名し、ビットコインの普遍的な計算検証を可能にします。BitVM の主要なコンポーネントは次のとおりです。* **回路のコミットメント:** 証明者と検証者は、プログラムを大規模なバイナリ回路にコンパイルします。証明者はタップルート アドレスで回路にコミットし、このアドレスの下の各リーフ スクリプトは回路内の各論理ゲートに対応します。コアはビット コミットメントに基づいて、ロジック ゲート コミットメントと回路コミットメントを実装します。* **チャレンジ アンド レスポンス:** 証明者と検証者は、チャレンジ レスポンス ゲームを実装するために一連のトランザクションに事前署名します。理想的には、この対話はオフチェーンで実行されますが、証明者が非協力的な場合はオンチェーンで実行することもできます。* **あいまいなペナルティ:** 証明者が間違った発言をした場合、検証者は証明者の邪悪な行為を阻止するための挑戦に成功した後、証明者の保証金を取り上げることができます。## 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 の 1 回限りの署名スキームは、d= 1 の特殊な場合の Winternitz 1 回限りの署名スキームです。 Winternitz ワンタイム署名方式では、n、d、v の関係は n ≈ v/log 2(d+ 1) を満たします。 d= 15 の場合、n≈(v/4)+ 1 となります。 n 個の要素を含む Winternitz 署名の場合、公開鍵の長さと署名の長さは、Lamport の 1 回限りの署名スキームよりも 4 倍短くなります。ただし、署名検証の複雑さは 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 Witness の規格の上限は 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 バイトは単一のチャンク内に割り当てることができ、BLAKE 3 ハッシュ操作全体で単一のチャンクに圧縮関数を 1 回適用するだけで済みます。 BLAKE 3の圧縮関数では、round関数を7回、permutation関数を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 未満の BitVMless s は、Schnorr 署名を使用してスマート コントラクトをオフチェーンで実行する方法です。 Scripless の概念は、カーネルとその署名以外の永続的なデータを保存しない Mimblewimble から生まれました。s が少ないことの利点は、機能性、プライバシー、効率性です。* **特徴: ** が少ないと、スマート コントラクトの範囲と複雑さが増大する可能性があります。ビットコインのスクリプト機能は、ネットワーク内で有効になっている OP\_CODES の数によって制限されており、ビットコイン ネットワークのフォークが有効になるのを待たずに、スマート コントラクトの仕様と実行をチェーンから設計契約参加者間でのみ議論するように移行することが少なくなります。新しいオペコード。* **プライバシー:**スマート コントラクトの仕様と実行をオンチェーンからオフチェーンに移行すると、プライバシーが向上します。チェーン上では、参加者の数やアドレス、転送金額など、契約の多くの詳細がネットワーク全体に共有されます。スマート コントラクトをオフチェーンに移動することで、ネットワークは、参加者が契約条件が満たされ、基礎となるトランザクションが有効であることに同意していることだけを認識します。* **効率: **s が少ないため、オンチェーンで検証および保存されるデータの量が最小限に抑えられます。スマートコントラクトをオフチェーンに移行することで、フルノードの管理手数料が削減され、ユーザーの取引手数料も削減されます。less s は、明示的なスマート コントラクトを実行する必要を回避する、ビットコイン上の暗号プロトコルを設計するアプローチです。中心的なアイデアは、スクリプトを使用して機能を実現するのではなく、暗号アルゴリズムを使用して目的の機能を実現することです。アダプター署名とマルチ署名は、less の元の構成要素です。少ない s を使用すると、通常の取引よりも小規模な取引を実現し、取引手数料を削減できます。レスの助けを借りて、Schnorr マルチ署名とアダプター署名を使用できます。これにより、BitVM ソリューションのようなハッシュ値とハッシュ プリイメージが提供されなくなり、BitVM 回路でのロジック ゲート コミットメントも実現できるため、BitVM を節約できます。スクリプトスペースと BitVM 効率の向上。既存のless sスキームはBitVMスクリプトスペースを削減できますが、公開キーを結合するために証明者と挑戦者の間で大量の対話が必要になります。将来的には、このソリューションを改善し、特定の BitVM 機能モジュールに Scripless を導入することを試みる予定です。### 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 Championships」という論文では、ゲームを変える紛争解決アルゴリズムが提案されており、1 人の正直な参加者が紛争に勝つコストは、対戦相手の数に応じて線形ではなく対数的に増加します。* **遅延攻撃:** 悪意のある当事者または悪意のある当事者のグループは、L1 での正しい結果 (L1 への資産の引き出しなど) の確認を防止または遅延させる特定の戦略に従い、誠実な証明者に L1 料金の支払いを強制します。この問題は、挑戦者に事前にステークを要求することで軽減できます。挑戦者が遅延攻撃を開始した場合、その賭け金は没収されます。ただし、攻撃者が遅延攻撃を追求するために一定の制限内でステーキングを犠牲にする場合は、遅延攻撃の影響を軽減するための対策が必要です。論文「BoLD: Bounded Liquidity Delay in a Rollup Challenge Protocol」で提案されているアルゴリズムでは、攻撃者がどれだけのプレッジを失うことをいとわないとしても、最悪の場合の攻撃は一定の上限の遅延しか引き起こさないようにしています。将来的には、ビットコインの特性に適し、上記の攻撃問題に対抗できる BitVM パーミッションレス マルチパーティ チャレンジ モデルを検討していきます。＃＃４ 結論BitVM テクノロジーの探求はまだ始まったばかりですが、将来的には、ビットコインの拡大を達成し、ビットコイン エコシステムを繁栄させるために、さらなる最適化の方向性が探究され、実装されるでしょう。参考文献1. BitVM: ビットコインで何でも計算2. BitVM：オフチェーンビットコインコントラクト3. BitVM のロビン・ライナス4. [bitcoin-dev] BitVM: ビットコインで何でも計算5. 奇妙なカップル: スケーラビリティ日付の ZK と楽観的なロールアップ6. ビットコインの取引と制限は何ですか?7. BIP-342: Taproot の検証8. \_linus/status/17653371862226863479. 応用暗号大学院コース10. BLAKE 3: 1 つの機能でどこでも高速11. [bitcoin-dev] ビットコインでの Blake 3 の実装12.13.less の紹介14. BitVM の使用量が少なくなる15. ロールアップに対する攻撃を遅らせるための解決策16.デイブの紹介。 Cartesi の Permissionless Fault-Proof 。17. ロールアップに対する遅延攻撃18. ロールアップに対する攻撃を遅らせるための解決策 - Arbitrum Research19. マルチプレイヤー対話型計算ゲームに関する注意事項20. 太字: ロールアップ チャレンジ プロトコルにおける有界流動性遅延21. 許可のない審判ありトーナメント元のリンク
BitVM の原理分析と最適化に関する考慮事項
出典: Bitlayer Research Group
原作者：リンデル、ミュートゥーレンド。
##1 はじめに
ビットコインは、分散型で安全かつ信頼できるデジタル資産です。ただし、支払いやその他のアプリケーションのスケーラブルなネットワークになることを妨げる重大な制限があります。ビットコインのスケーリング問題は、その誕生以来懸念されてきました。ビットコイン UTXO モデルは、各トランザクションを独立したイベントとして扱うため、複雑な状態依存の計算を実行する機能が欠如したステートレス システムになります。したがって、ビットコインは単純なスクリプトと複数署名トランザクションを実行できますが、ステートフル ブロックチェーン プラットフォームで一般的な複雑で動的なコントラクト インタラクションを容易にするのは困難です。この問題により、ビットコイン上に構築できる分散型アプリケーション (dApps) と複雑な金融商品の範囲が大幅に制限される一方、状態モデル プラットフォームは、機能豊富なスマート コントラクトを展開および実行するためのより多様な環境を提供します。
ビットコインの拡張には、主にステートチャネル、サイドチェーン、クライアント検証などのテクノロジーがあります。その中で、国家チャネルは安全で多様な支払いソリューションを提供しますが、任意の複雑な計算を検証する能力には限界があります。この制限により、複雑な条件付きロジックと対話を必要とするさまざまなシナリオでの使用が減少します。サイドチェーンは、幅広いアプリケーションをサポートし、ビットコインを超える多様な機能を提供しますが、セキュリティは低くなります。このセキュリティの違いは、サイドチェーンがビットコインのコンセンサス メカニズムよりもはるかに堅牢でない独立したコンセンサス メカニズムを使用しているという事実に起因しています。ビットコイン UTXO モデルを使用したクライアント側検証は、より複雑なトランザクションを処理できますが、ビットコインの双方向チェックサム制約機能がないため、セキュリティはビットコインよりも低くなります。クライアント検証プロトコルのオフチェーン設計はサーバーまたはクラウド インフラストラクチャに依存しているため、侵害されたサーバーによる集中化や検閲が発生する可能性があります。クライアント側検証のオフチェーン設計により、ブロックチェーン インフラストラクチャがさらに複雑になり、スケーラビリティの問題が発生する可能性があります。
2023 年 12 月、ZeroSync プロジェクト リーダーの Robin Linus は「BitVM: Compute Anything On Bitcoin」と呼ばれるホワイト ペーパーを発表し、これをきっかけにビットコインのプログラマビリティの向上について誰もが考えるようになりました。この論文では、ビットコイン ネットワークのコンセンサスを変更することなくチューリング完全性を達成できるビットコイン コントラクト ソリューションを提案します。これにより、ビットコインの基本ルールを変更することなく、あらゆる複雑な計算をビットコイン上で検証できます。 BitVM は、Bitcoin Script と 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 テクノロジーを使用してチャレンジ レスポンス モードを採用し、より複雑な計算検証をサポートできます。
Optimistic Rollup や MATT 提案 (Merkelize All The Things) と同様に、BitVM システムは不正防止およびチャレンジ/レスポンス プロトコルに基づいていますが、ビットコインのコンセンサス ルールを変更する必要はありません。 BitVM の基礎となるプリミティブは単純で、主にハッシュ ロック、タイム ロック、および大きなタップルート ツリーに基づいています。
証明者はバイトごとにコミットしますが、すべての計算をオンチェーンで検証するにはコストがかかりすぎます。したがって、検証者は、証明者の誤った主張を簡潔に反論するために、慎重に設計された一連のチャレンジを実行します。証明者と検証者は、紛争の解決に使用される一連のチャレンジとレスポンスのトランザクションに共同で事前署名し、ビットコインの普遍的な計算検証を可能にします。
BitVM の主要なコンポーネントは次のとおりです。
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 の 1 回限りの署名スキームは、d= 1 の特殊な場合の Winternitz 1 回限りの署名スキームです。 Winternitz ワンタイム署名方式では、n、d、v の関係は n ≈ v/log 2(d+ 1) を満たします。 d= 15 の場合、n≈(v/4)+ 1 となります。 n 個の要素を含む Winternitz 署名の場合、公開鍵の長さと署名の長さは、Lamport の 1 回限りの署名スキームよりも 4 倍短くなります。ただし、署名検証の複雑さは 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 Witness の規格の上限は 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 バイトは単一のチャンク内に割り当てることができ、BLAKE 3 ハッシュ操作全体で単一のチャンクに圧縮関数を 1 回適用するだけで済みます。 BLAKE 3の圧縮関数では、round関数を7回、permutation関数を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 未満の BitVM
less s は、Schnorr 署名を使用してスマート コントラクトをオフチェーンで実行する方法です。 Scripless の概念は、カーネルとその署名以外の永続的なデータを保存しない Mimblewimble から生まれました。
s が少ないことの利点は、機能性、プライバシー、効率性です。
less s は、明示的なスマート コントラクトを実行する必要を回避する、ビットコイン上の暗号プロトコルを設計するアプローチです。中心的なアイデアは、スクリプトを使用して機能を実現するのではなく、暗号アルゴリズムを使用して目的の機能を実現することです。アダプター署名とマルチ署名は、less の元の構成要素です。少ない s を使用すると、通常の取引よりも小規模な取引を実現し、取引手数料を削減できます。
レスの助けを借りて、Schnorr マルチ署名とアダプター署名を使用できます。これにより、BitVM ソリューションのようなハッシュ値とハッシュ プリイメージが提供されなくなり、BitVM 回路でのロジック ゲート コミットメントも実現できるため、BitVM を節約できます。スクリプトスペースと BitVM 効率の向上。既存のless sスキームはBitVMスクリプトスペースを削減できますが、公開キーを結合するために証明者と挑戦者の間で大量の対話が必要になります。将来的には、このソリューションを改善し、特定の BitVM 機能モジュールに Scripless を導入することを試みる予定です。
3.5 許可のないマルチパーティチャレンジ
現在の BitVM チャレンジがデフォルトで許可を必要とする理由は、ビットコインの UTXO が 1 回しか実行できないため、悪意のある検証者が誠実な証明者にチャレンジして契約を「無駄にする」可能性があるためです。 BitVM は現在、2 者間チャレンジ モードに制限されています。悪事を行おうとする証明者は、自分が制御する検証者と同時にチャレンジを開始することができ、それによって契約を「無駄」にして邪悪な行為を成功させ、他の検証者はその行為を阻止することができません。したがって、Bitcoin に基づいて、BitVM の既存の 1-of-n 信頼モデルを 1-of-N に拡張できる、パーミッションレスのマルチパーティ OP チャレンジ プロトコルを研究する必要があります。このうち、N は n よりもはるかに大きいです。さらに、異議申し立て者が証明者と共謀したり、「無駄な」契約に悪意を持って異議を申し立てたりする問題を研究し、解決する必要がある。最終的には信頼性の低い BitVM プロトコルを実装します。
許可のないマルチパーティチャレンジ。許可リストなしで誰でも参加できます。これは、ユーザーが信頼できる第三者の関与なしに L2 からコインを引き出すことができることを意味します。さらに、OP チャレンジプロトコルに参加したいユーザーは、無効な出金に異議を申し立て、削除することができます。
BitVM をパーミッションレスなマルチパーティ チャレンジ モデルに拡張するには、次の攻撃を解決する必要があります。
将来的には、ビットコインの特性に適し、上記の攻撃問題に対抗できる BitVM パーミッションレス マルチパーティ チャレンジ モデルを検討していきます。
＃＃４ 結論
BitVM テクノロジーの探求はまだ始まったばかりですが、将来的には、ビットコインの拡大を達成し、ビットコイン エコシステムを繁栄させるために、さらなる最適化の方向性が探究され、実装されるでしょう。
参考文献
13.less の紹介 14. BitVM の使用量が少なくなる 15. ロールアップに対する攻撃を遅らせるための解決策 16.デイブの紹介。 Cartesi の Permissionless Fault-Proof 。 17. ロールアップに対する遅延攻撃 18. ロールアップに対する攻撃を遅らせるための解決策 - Arbitrum Research 19. マルチプレイヤー対話型計算ゲームに関する注意事項 20. 太字: ロールアップ チャレンジ プロトコルにおける有界流動性遅延 21. 許可のない審判ありトーナメント
元のリンク