ビットVMとその最適化に関する考慮事項

1. イントロダクションBitcoinは中央集権的で安全で信頼性のあるデジタル資産ですが、支払いやその他のアプリケーションのためのスケーラブルなネットワークになるのを阻む重要な制約に直面しています。 Bitcoinのスケーリングの問題は創設以来懸念されてきました。 BitcoinのUTXO（未使用取引出力）モデルは、各取引を独立したイベントとして扱い、複雑で状態に依存した計算を実行する能力を欠いた状態レスシステムにつながります。 その結果、Bitcoinは単純なスクリプトやマルチシグネチャ取引を実行できる一方で、状態を持つブロックチェーンプラットフォームで一般的な複雑で動的な契約の相互作用を促進するのに苦労します。 この制約は、Bitcoin上に構築できる分散型アプリケーション（dApps）や複雑な金融機器の範囲を制限し、一方で状態を持つプラットフォームモデルは、機能豊富なスマート契約を展開および実行するためのより多様な環境を提供します。

ビットコインのスケーリングの場合、主なテクノロジーには、ステートチャネル、サイドチェーン、およびクライアント側の検証が含まれます。ステートチャネルは、安全で多様な決済ソリューションを提供しますが、任意に複雑な計算を検証する能力は限られています。この制限により、複雑で条件付きのロジックと相互作用を必要とするさまざまなシナリオでの適用性が低下します。サイドチェーンは幅広いアプリケーションをサポートし、ビットコインの機能を超えた多様性を提供しますが、セキュリティは低くなります。このセキュリティの違いは、独立したコンセンサスメカニズムを使用するサイドチェーンに起因しており、ビットコインのコンセンサスメカニズムよりもはるかに堅牢ではありません。ビットコイン UTXOモデルを使用したクライアント側の検証は、より複雑なトランザクションを処理できますが、ビットコインとの双方向のチェックと制約がないため、セキュリティが低下します。クライアント側の検証プロトコルのオフチェーン設計は、サーバーまたはクラウドインフラストラクチャに依存しているため、中央集権化や、侵害されたサーバーによる検閲の可能性につながる可能性があります。また、クライアント側の検証をオフチェーンで設計すると、ブロックチェーンのインフラがより複雑になり、スケーラビリティの問題につながる可能性があります。

2023年12月、ZeroSyncのプロジェクトリーダーであるロビン・リヌスが、「」というタイトルのホワイトペーパーを公開しました。BitVM：Bitcoin上で何でも計算ビットのプログラマビリティを向上させるために多くの考察を呼び起こした。論文では、ネットワークの合意ルールを変更することなく、Bitcoinの基本原則を変更することなく、どのような複雑な計算も実行できるチューリング完全Bitcoin契約ソリューションが提案されています。BitVMは、BitcoinスクリプトとTaprootを利用して楽観的なロールアップを実装します。 Lamport署名（ビットコミットメントとしても知られています）を使用して、2つのBitcoin UTXO間の接続を確立し、状態を持つBitcoinスクリプトを可能にします。大規模なプログラムはTaprootアドレス内にコミットされ、オペレータとバリデータは包括的なオフチェーンの相互作用に従事し、ブロックチェーンにほとんどの足跡を残しません。両当事者が協力すれば、どのような複雑な状態を持つオフチェーン計算も、ブロックチェーンに痕跡を残すことなく実行できます。ただし、当事者が協力しない場合、紛争が発生した場合にはオンチェーンの実行が必要です。そのため、BitVMはBitcoinの潜在的なユースケースを大幅に拡大し、通貨だけでなく、さまざまな分散型アプリケーションや複雑な計算タスクの検証プラットフォームとしても機能するようにしています。

しかし、ビットVM技術の利点にもかかわらず、ビットコインのスケーリングにおける技術はまだ初期段階にあり、いくつかの効率性およびセキュリティの問題に直面しています。たとえば、(1)課題と応答には複数のやり取りが必要で、高い取引手数料と長い課題期間をもたらします。(2) Lamportワンタイム署名はデータ長が長く、データサイズを削減する必要があります。(3)高いハッシュ関数の複雑さにより、コスト削減のためにビットコインに適したハッシュ関数が必要です。(4)既存のビットVM契約は大きく、ビットコインのブロック容量が限られているため、スクリプトレススクリプトを使用することでスクリプトレススクリプトビットVMを実現し、ビットコインのブロックスペースを節約し、ビットVMの効率を向上させるのに役立ちます。(5)現在のビットVMは許可モデルで動作し、課題はコンソーシアムメンバーによってのみ開始され、2者に限定されていますが、これを許可されていない多者間の課題モデルに拡張することで、信頼仮定をさらに削減できます。これらの問題に対処するため、論文ではビットVMの効率性とセキュリティを向上させるためのいくつかの最適化アイデアを提案しています。

2. ビットVMの原則BitVMは、ビットコインのオフチェーン契約システムとして位置付けられており、ビットコインの契約機能の向上を目指しています。現在、ビットコインスクリプトは完全に状態を持たないため、各スクリプトの実行環境がリセットされます。ビットコインスクリプトには、スクリプト1とスクリプト2がxの同じ値を持つことを保証するネイティブな方法はありません。しかし、既存のオペコードとLamportワンタイム署名を使用して、ビットコインスクリプトを状態を持つものにすることが可能で、スクリプト1とスクリプト2のxが同じであることを強制することができます。参加者がxの相反する値に署名した場合、罰せられる可能性があります。

BitVMの計算はオフチェーンで発生しますが、これらの計算の検証はオンチェーンで行われます。 Bitcoinブロックの1MB制限があるため、複雑な計算の検証が必要な場合、OPテクノロジーをチャレンジレスポンスモードで使用して、より高い複雑さの計算検証をサポートできます。

Optimistic RollupやMATT提案（Merkelize All The Things）に類似して、BitVMシステムは詐欺証明と挑戦応答プロトコルに基づいていますが、Bitcoinのコンセンサスルールの変更は必要ありません。 BitVMの基本的なプリミティブはシンプルで、主にハッシュロック、タイムロック、および大規模なTaprootツリーに基づいています。

プルーバーはプログラムをバイト単位でコミットしますが、すべての計算をチェーン上で検証することはコストがかかりすぎます。そのため、検証者は、プルーバーの誤った主張を簡潔に反論するために、注意深く設計された一連のチャレンジを行います。プルーバーと検証者は、紛争を解決するために一連のチャレンジとレスポンストランザクションに共同で署名し、ビットコイン上での一般的な計算検証を可能にします。

BitVMの主要なコンポーネントには、次のものがあります:

• 回路の確約：証明者と検証者はプログラムを大規模なバイナリ回路にコンパイルします。証明者は、この回路をTaprootアドレスに確約し、そのアドレスの各リーフスクリプトが回路内の各論理ゲートに対応しています。重要なのは、ビット確約に基づく論理ゲートの確約を達成することです。- チャレンジとレスポンス：証明者と検証者は、チャレンジ・レスポンス・ゲームを実装するために、事前に署名された一連の取引を行います。理想的には、このやり取りはオフチェーンで行われますが、証明者が協力しない場合はオンチェーンでも実行できます。- 曖昧な罰金：証明者が誤った主張を行った場合、検証者は成功裏に挑戦し、証明者の悪質な行為を妨害した後、証明者の預金を取ることができます。## 3. ビットVMの最適化### ZKに基づいてOPインタラクション数を削減する3.1Rollupには、ZK RollupとOptimistic Rollup（OP Rollup）の2つの主要なタイプがあります。 ZK RollupはZero-Knowledge（ZK）プルーフの妥当性検証に依存しており、これは正しい実行の暗号証明です。 彼らのセキュリティは計算複雑性の仮定に依存しています。 Optimistic Rollupは、不正プルーフに依存しており、すべての提出された状態が正しいと仮定し、通常は約7日間のチャレンジ期間を設定しています。 彼らのセキュリティは、システム内の少なくとも1つの正直なパーティが不正確な状態を検出し、不正プルーフを提出できるという前提に依存しています。

BitVMのチャレンジプログラムの最大ステップ数が2^{32}であると仮定すると、約17GBのメモリ（2^{32}×4バイト）が必要になります。最悪の場合、約40ラウンドのチャレンジとレスポンスが約6ヶ月かかる可能性があり、合計スクリプトサイズは約150KBです。このようなシナリオではインセンティブが不十分ですが、実際にはまれにしか発生しません。

BitVMでのチャレンジの数を減らすためにゼロ知識証明を使用すると、その効率が向上する可能性があります。ゼロ知識証明理論によれば、データDataがアルゴリズムFを満たす場合、証明が検証アルゴリズムVerifyを満たすとTrueが出力されます。逆に、DataがFを満たさない場合、証明はVerifyを満たさずFalseが出力されます。BitVMシステムでは、チャレンジャーがプローバーのデータを受け入れない場合、チャレンジが開始されます。

アルゴリズムFについて、2^n回の反復が必要であると仮定し、バイナリサーチアプローチを使用すると、エラーポイントを見つけるのに2^n回の反復が必要です。アルゴリズムの複雑さが高すぎ、nが大きいため、完了に長い時間がかかります。ただし、Zero-Knowledge Proof検証アルゴリズムVerifyの複雑さは固定されています。証明および検証プロセスVerifyを公開することで、Falseの出力を見ることが可能です。Zero-Knowledge Proofsの利点は、バイナリサーチを使用して元のアルゴリズムFを開く際に必要な計算量よりも、検証アルゴリズムVerifyを開くのに必要な計算量が低いことにあります。したがって、Zero-Knowledge Proofsを使用すると、BitVMは元のアルゴリズムFに挑戦するのではなく、検証アルゴリズムVerifyに挑戦し、挑戦ラウンドの数を減らし、挑戦期間を短縮することができます。

ゼロ知識証明と詐欺証明の有効性は異なるセキュリティの前提に依存していますが、これらを組み合わせてZK詐欺証明を構築し、オンデマンドZK証明を実装することができます。完全なZKロールアップとは異なり、オンデマンドモデルではチャレンジが発生したときにのみZK証明が必要で、生成された状態がチャレンジされるまで有効であると仮定される楽観的な設計が維持されます。状態がチャレンジされない場合、ZK証明は必要ありません。ただし、チャレンジが発生すると、チャレンジされたブロック内のすべてのトランザクションの正確性のためにZK証明が生成される必要があります。将来的には、個々の争議中の命令に対してZK詐欺証明を生成することが可能になり、ZK証明を継続的に生成する計算コストを回避できます。

3.2 ビットコインに対応したワンタイム署名Bitcoinネットワークでは、コンセンサスルールに従う取引は有効と見なされますが、これらのルールを超えて、標準性という追加の概念があります。 Bitcoinノードは標準的な取引のみを伝播およびブロードキャストし、有効だが標準でない取引がブロックに含まれる唯一の方法は、マイナーとの直接の協力を通じてです。

コンセンサスルールによると、レガシー（非Segwit）トランザクションの最大サイズは1MBであり、これはブロック全体を埋めることができます。しかし、レガシートランザクションの標準限界は100kBに設定されています。Segwitトランザクションの場合、コンセンサスルールによる最大サイズは4MBで、これは重みの限界として知られていますが、標準限界は400kBです。

ランポート署名はBitVMの基本的な構成要素であり、署名と公開鍵の長さを短縮することは取引データサイズを減らし、取引手数料を削減するのに役立ちます。ランポートワンタイム署名にはハッシュ関数（1方向の置換関数fのようなもの）が必要です。ランポートワンタイム署名方式では、メッセージ長はvビットであり、公開鍵と署名の長さは両方とも2vビットです。これらの長い署名と公開鍵は大量のストレージガスを消費します。したがって、署名と公開鍵の長さを短縮できる署名方式を探ることが必要です。ランポートワンタイム署名と比較して、ウィンタニッツワンタイム署名は署名と公開鍵の長さを大幅に短縮しますが、署名と検証の計算複雑さを増加させます。

ヴィンターニッツのワンタイム署名方式では、特殊関数 P が v ビット メッセージを長さ n のベクトル s にマッピングし、s の各要素は {0,...,d} の値を取ります。ランポートのワンタイム署名方式は、ヴィンターニッツ方式の特殊なケースで、d=1 です。ヴィンターニッツスキームでは、n、d、v の関係はほぼ n≈v/log2(d+1) です。d=15 のとき、n≈(v/4)+1 です。n 個の要素を持つ Winternitz 署名の場合、公開鍵と署名の長さは Lamport の 1 回限りの署名スキームよりも 4 倍短くなりますが、検証の複雑さは 4 倍になります。ヴィンターニッツのワンタイム署名に BitVM で d=15,v=160,f=ripemd160(x) を使用すると、ビットコミットメントサイズを 50% 削減できるため、BitVM のトランザクション手数料を少なくとも 50% 削減できます。将来的には、既存のヴィンターニッツビットコインスクリプトの実装を最適化しながら、ビットコインスクリプトで表現可能なよりコンパクトなワンタイム署名スキームの探求を追求することができます。

3.3 ビットコインフレンドリーハッシュ関数コンセンサスルールによると、P2TRスクリプトの最大サイズは10kBであり、P2TRスクリプトウィットネスの最大サイズはSegwitトランザクションの最大サイズと同じ4MBです。ただし、P2TRスクリプトウィットネスの標準制限は400kBです。

現在、BitcoinネットワークはOP_CATをサポートしていないため、Merkleパスの検証のために文字列を連結することはできません。したがって、既存のBitcoinスクリプトを使用して、スクリプトサイズとスクリプトウィットネスサイズの両方において最もサイズ効率の良い方法でBitcoinに対応したハッシュ関数を実装する必要があります。Merkle検証証明をサポートするために。

BLAKE3は、BLAKE2ハッシュ関数の最適化バージョンであり、Baoツリーモードを導入しています。BLAKE2sベースと比較して、その圧縮関数のラウンド数は10から7に削減されています。BLAKE3ハッシュ関数は、入力を1024バイトのチャンクに分割し、最後のチャンクは短くても空ではない可能性があります。1つのチャンクのみの場合、それはルートノードとツリーの唯一のノードとして機能します。これらのチャンクはバイナリツリーの葉ノードとして配置され、各チャンクは独立して圧縮されます。

BitVMを使用してMerkle包含証明を検証する場合、ハッシュ操作の入力は、合計64バイトの2つの連結された256ビットハッシュ値で構成されています。 BLAKE3ハッシュ関数を使用すると、これらの64バイトは単一のチャンク内に収まるため、BLAKE3ハッシュ操作はこの単一のチャンクに対して圧縮関数を1回だけ適用する必要があります。BLAKE3の圧縮関数では、7つのラウンド関数と6つの置換関数が必要です。

BitVMは、u32値に基づいてXOR、モジュラー加算、および右ビットシフトなどの基本操作をすでに実装しており、Bitcoinスクリプトを使用してBLAKE3ハッシュ関数を組み立てるのは簡単です。スタックは、u32ワードを表すために4つの別々のバイトを使用し、BLAKE3で必要とされるu32加算、u32ビット単純XOR、およびu32ビット回転を容易にします。 Bitcoinスクリプト内のBLAKE3ハッシュ関数は現在約100kBで、BitVMのおもちゃバージョンを構築するのに十分です。

さらに、これらのBLAKE3コードを分割することで、検証者と証明者は、全体を実行するのではなく、チャレンジ・レスポンスゲームに分割することで、オンチェーンデータ要件を大幅に削減することができます。最後に、Keccak-256やGrøstlのようなハッシュ関数をBitcoinスクリプトに実装することで、最もBitcoinに優しいハッシュ関数を特定し、他の新しいBitcoinに優しいハッシュ関数を探索します。

3.4 スクリプトレススクリプト ビットVMScriptless Scriptsは、Schnorr署名を使用してオフチェーンでスマートコントラクトを実行する方法です。Scriptless Scriptsの概念は、Mimblewimbleから発祥しており、カーネルとその署名以外に永続的なデータは保存されません。

Scriptless Scriptsの利点には、機能性、プライバシー、効率性が含まれています：

• 機能：スクリプトなしのスクリプトは、スマートコントラクトの範囲と複雑さを拡大することができます。ビットコインスクリプトの機能は、ネットワーク上で有効になっているOP_CODEの数に制限されています。それに対して、スクリプトなしのスクリプトは、スマートコントラクトの仕様と実行を、ビットコインネットワークが新しいOP_CODEを有効にするためにフォークするのを待つことなく、契約当事者間の議論にオフチェーンに移動させます。- プライバシー：スマートコントラクトの仕様と実行をオンチェーンからオフチェーンに移動すると、プライバシーが向上します。オンチェーンでは、契約の多くの詳細がネットワーク全体と共有されます。 参加者の数、アドレス、転送金額などが含まれます。スマートコントラクトをオフチェーンに移動することで、ネットワークは参加者が契約条件を満たし、関連する取引が有効であることだけを知ることになります。- 効率：スクリプトレススクリプトは、チェーン上で検証および保存する必要があるデータ量を最小限に抑えます。スマートコントラクトをオフチェーンに移動することで、フルノードの管理コストが削減され、ユーザーの取引手数料も低く抑えられます。スクリプトレススクリプトは、明示的なスマートコントラクトを実行せずにビットコイン上で暗号プロトコルを設計する方法を表しています。核心のアイディアは、スクリプトの代わりに暗号アルゴリズムを使用して、所望の機能を実現することです。アダプタ署名とマルチ署名は、スクリプトレススクリプトの基礎的な構築要素です。スクリプトレススクリプトを使用すると、取引が従来の取引よりも小さくなり、取引手数料が削減されることがあります。

Scriptless Scriptsは、Schnorrマルチサインチャーとアダプターシグネチャーを使用して、BitVM回路内でロジックゲートのコミットメントを実装するために使用できます。これにより、BitVMスクリプトスペースを節約し、BitVMの効率を向上させることができます。現在のScriptless Scriptsスキームは、BitVMスクリプトスペースを削減できますが、公開鍵の組み合わせにはproverとchallengerの間で広範なやり取りが必要です。将来の改善点は、Scriptless Scriptsを特定のBitVM機能モジュールに統合することを目指しています。

3.5 パーミッションレスなマルチパーティチャレンジ現在のBitVMチャレンジは許可が必要です。なぜなら、Bitcoin UTXOは1回しか実行できないため、悪意のある検証者が正直な証明者を挑発して契約を「無駄に」する可能性があります。BitVMは現在、二者間のチャレンジモデルに制限されています。悪意のある証明者は、自分の制御下にある検証者を使用して挑戦を開始し、契約を「無駄に」することができ、その結果、他の検証者がこの行動を防ぐことはできません。したがって、Bitcoinの上に、BitVMの既存の1対N信頼モデルを1対Nに拡張できる許可なしの多者間OPチャレンジプロトコルを研究する必要があります。さらに、挑戦者と証明者の共謀や契約を「無駄に」する悪意のある挑戦などの問題に対処することは重要です。これにより、より信頼度の低いBitVMプロトコルが実現されます。

ホワイトリストなしで誰でも参加できる許可なしのマルチパーティチャレンジは、信頼された第三者の関与なしにL2から引き出すことができることを意味します。さらに、OPチャレンジプロトコルに参加したいユーザーは、無効な引き出しを疑問視して削除することができます。

BitVMを許可されていないマルチパーティチャレンジモデルに拡張することは、次の攻撃に対処することを意味します:

• シビル攻撃：攻撃者が複数のアイデンティティを作成して紛争を挑む場合でも、1人の誠実な参加者は紛争に勝つことができるはずです。誠実な参加者の正しい結果を守るためのコストが攻撃者の数とともに線形的に増加する場合、誠実な参加者が紛争に勝つためのコストは実用的でなく、多数の攻撃者が関与するとシビル攻撃に対して脆弱になります。論文「許可されていない審判付きトーナメント「1人の正直な参加者が紛争に勝つためのコストが、対戦相手の数が線形ではなく対数的に増加する」ゲームルールを変更する紛争解決アルゴリズムを提案します。- 遅延攻撃：悪意のある個人またはグループが、正しい結果の確認（資産をL1に引き出すなど）を遅らせる戦略に従うことで、L1での正直な証明者にL1取引手数料を支払わせることを試みる攻撃。この問題を緩和するために、チャレンジャーは前払いステークを行う必要があるかもしれません。チャレンジャーが遅延攻撃を開始した場合、そのステークは没収されるでしょう。ただし、攻撃者がある程度まで自らのステークを犠牲にして遅延攻撃を行うことを望んでいる場合、これらの攻撃の影響を軽減する戦略があるべきです。論文で提案されているアルゴリズム"BoLD: ロールアップチャレンジプロトコル内のバウンデッド流動性遅延攻撃者が失うことを望んでいるステークがいくらであろうと、”最悪の遅延が制限されることを保証します。将来、これらの攻撃に耐性があり、ビットコインの特性に適したBitVMパーミッションレスマルチパーティチャレンジモデルの探求が行われる予定です。

4. 結論BitVMテクノロジーの探求は始まったばかりであり、将来的には、ビットコインのスケーリングを実現し、ビットコインエコシステムを豊かにするためにさらなる最適化が探求され、実践されるでしょう。

免責事項：- この記事は[から転載されました@Bitlayer/bitvm-and-its-optimization-considerations-007da599d8ac">ビットレイヤー], すべての著作権は元の著者に帰属します[LynndellとMutourend]. If there are objections to this reprint, please contact the ゲート レアンチームが promptly します。- 免責事項：この記事で表現される意見は、著者個人のものであり、投資アドバイスを構成するものではありません。- 他の言語への記事の翻訳は Gate Learn チームによって行われます。特に言及がない限り、翻訳された記事のコピー、配布、または盗用は禁止されています。