出典: ビットレイヤー研究グループ

著者: リンデル、ミュートゥーレンド。

メール: [email protected]、[email protected]

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 ワンタイム署名を通じてビットコイン スクリプトをステートフルにすることはできます (たとえば、script1 と script2 の x を強制的に同じ値にすることができます)。参加者が矛盾する x 値に署名すると、ペナルティが課される可能性があります。 BitVM プログラムの計算はオフチェーンで行われ、計算結果の検証はオンチェーンで行われます。現在のビットコインブロックには1MBの制限があり、検証計算が複雑すぎる場合、OPテクノロジーを使用してチャレンジレスポンスモードを採用し、より複雑な計算検証をサポートできます。

オプティミスティック ロールアップや 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 バイト、つまり約 17GB であるとします。最悪の場合、チャレンジとレスポンスを約 40 回、約半年かかり、スクリプトの合計は約 150KB になります。この状況ではインセンティブが著しく欠如していますが、実際にはそのようなことはほとんどありません。

ゼロ知識証明を使用して 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) トランザクションの最大サイズは 1MB で、ブロック全体を占有します。ただし、レガシー トランザクションの標準制限は 100kB です。コンセンサス ルールによれば、Segwit トランザクションの最大サイズは 4MB であり、これが重量制限です。ただし、Segwit トランザクションの標準性は 400kB に制限されています。

Lamport 署名は BitVM の基本コンポーネントであり、署名と公開キーの長さを短縮するとトランザクション データが削減され、手数料が削減されます。 Lamport ワンタイム署名では、ハッシュ関数 (一方向置換関数 f など) を使用する必要があります。 Lamport のワンタイム署名方式では、メッセージ長は v ビット、公開鍵の長さは 2v ビット、署名の長さも 2v ビットです。署名と公開キーは長く、大量のストレージ ガスを必要とします。したがって、署名と公開キーの長さを短縮するために、同様の機能を持つ署名スキームを見つける必要があります。 Lamport ワンタイム署名と比較して、Winternitz ワンタイム署名は署名と公開鍵の長さを大幅に短縮しますが、署名と署名検証の計算の複雑さは増加します。

Winternitz ワンタイム署名方式では、特殊関数Pを使用して、 vビットのメッセージを長さnのベクトルsにマッピングします。 s の各要素の値は {0,..., d } です。 Lamport ワンタイム署名スキームは、 d =1 の特殊な場合の Winternitz ワンタイム署名スキームです。 Winternitz ワンタイム署名方式では、 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) を使用して Winternitz のワンタイム署名を実装すると、ビット コミットメント サイズを 50% 削減でき、それによって BitVM のトランザクション手数料を少なくとも 50% 削減できます。将来的には、既存の Winternitz Bitcoin Script 実装を最適化しながら、Bitcoin Script で表現されるよりコンパクトなワンタイム署名スキームを検討することができます。

3.3 ビットコインに適したハッシュ関数

コンセンサス ルールによれば、P2TR スクリプトの最大サイズは 10kB で、P2TR スクリプト監視の最大サイズは Segwit トランザクションの最大サイズと同じ 4MB です。ただし、P2TR スクリプト監視の標準の上限は 400kB です。

現在、ビットコイン ネットワークは OP_CAT をサポートしておらず、マークル パス検証のために文字列を結合することはできません。したがって、マークル包含証明検証機能をサポートするには、既存のビットコイン スクリプトを使用して、最適なスクリプト サイズとスクリプト監視サイズでビットコイン フレンドリーなハッシュ関数を実装する必要があります。

現在、ビットコイン ネットワークは OP_CAT をサポートしておらず、マークル パス検証のために文字列を結合することはできません。したがって、マークル包含証明検証機能をサポートするには、既存のビットコイン スクリプトを使用して、最適なスクリプト サイズとスクリプト監視サイズでビットコイン フレンドリーなハッシュ関数を実装する必要があります。

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

BitVM を使用してマークル包含証明シナリオを検証する場合、ハッシュ演算の入力は 2 つの 256 ビット ハッシュ値で構成されます。つまり、ハッシュ演算の入力は 64 バイトです。 BLAKE3 ハッシュ関数を使用する場合、これらの 64 バイトは 1 つのチャンク内に割り当てることができ、BLAKE3 ハッシュ操作全体で圧縮関数を 1 つのチャンクに 1 回適用するだけで済みます。 BLAKE3の圧縮関数では、ラウンド関数を7回、ディスプレイスメント関数を6回実行する必要があります。

現時点では、u32値に基づくXOR、モジュラー加算、ビット右シフトなどの基本演算がBitVM上で完了しており、Bitcoinスクリプトで実装されたBLAKE3ハッシュ関数を簡単に組み立てることができます。 BLAKE3 で必要な u32 加算、u32 ビットごとの XOR、および u32 ビットごとの回転を実装するには、スタック内の 4 つの個別のバイトを使用して u32 ワードを表します。現在の BLAKE3 ハッシュ関数 Bitcoin スクリプトの合計は約 100kB で、おもちゃ版の BitVM を構築するには十分です。

さらに、これらの BLAKE3 コードは分割できるため、Verifier と Prover は、チャレンジ レスポンス ゲームの実行を完全に実行するのではなく半分に分割することで、必要なオンチェーン データを大幅に削減できます。最後に、ビットコイン スクリプトを使用して Keccak-256 や Grøstl などのハッシュ関数を実装し、最もビットコインに適したハッシュ関数を選択し、他の新しいビットコインに適したハッシュ関数を探索します。

3.4 スクリプトレススクリプト BitVM

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

スクリプトレス スクリプトの利点は、機能性、プライバシー、効率性です。

スクリプトレス スクリプトは、明示的なスマート コントラクトの実行を回避する、ビットコイン上の暗号プロトコルを設計する方法です。中心的なアイデアは、スクリプトを使用して機能を実現するのではなく、暗号アルゴリズムを使用して目的の機能を実現することです。アダプターの署名とマルチ署名は、スクリプトレス スクリプトの元の構成要素です。スクリプトレス スクリプトを使用すると、通常のトランザクションよりも小規模なトランザクションを実現し、トランザクション手数料を削減できます。

スクリプトレス スクリプトを使用すると、Schnorr マルチ署名とアダプター署名を使用できます。これにより、BitVM ソリューションのようなハッシュ値とハッシュ プリイメージが提供されなくなり、BitVM 回路内でロジック ゲート コミットメントを実現できるため、BitVM スクリプト スペースとBitVM の効率が向上します。既存のスクリプトレス スクリプト ソリューションは BitVM スクリプトのスペースを削減できますが、公開キーを結合するために証明者と挑戦者の間で大量の対話が必要になります。将来的には、このソリューションを改善し、特定の BitVM 機能モジュールに Scripless Script を導入することを試みる予定です。

3.5 許可のないマルチパーティチャレンジ

3.5 許可のないマルチパーティチャレンジ

現在の BitVM チャレンジがデフォルトで許可を必要とする理由は、ビットコインの UTXO が 1 回しか実行できないため、悪意のある検証者が誠実な証明者にチャレンジして契約を「無駄にする」可能性があるためです。 BitVM は現在、2 者間チャレンジ モードに制限されています。悪事を行おうとする証明者は、自身が管理する検証者と同時に契約に異議を申し立てることができ、それによって契約を「無駄」にして邪悪な行為を成功させることができますが、他の検証者はその行為を阻止することができません。したがって、Bitcoin に基づいて、BitVM の既存の 1-of-n 信頼モデルを 1-of-N に拡張できる、パーミッションレスのマルチパーティ OP チャレンジ プロトコルを研究する必要があります。このうち、N は n よりもはるかに大きいです。さらに、異議申し立て者が証明者と共謀したり、「無駄な」契約に悪意を持って異議を申し立てたりする問題を研究し、解決する必要がある。最後に、信頼性の低い BitVM プロトコルを実装します。

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

BitVM をパーミッションレスなマルチパーティ チャレンジ モデルに拡張するには、次の攻撃を解決する必要があります。

将来的には、ビットコインの特性に適し、上記の攻撃問題に対抗できる BitVM パーミッションレス マルチパーティ チャレンジ モデルを検討していきます。

4 結論

BitVM テクノロジーの探求はまだ始まったばかりですが、将来的には、ビットコインの拡大を達成し、ビットコイン エコシステムを繁栄させるために、さらなる最適化の方向性が探求され、実践されるでしょう。

参考文献