著者: lynndell, mutourend; 出典: Bitlayer Research Group
1 はじめに
ビットコインは分散型の、安全で信頼できるデジタル資産です。しかし、決済やその他のアプリケーションのためのスケーラブルなネットワークになることを妨げる重大な制限があります。ビットコインのスケーリングは、設立当初から懸念されていました。ビットコインのUTXOモデルは、各トランザクションを個別のイベントとして扱い、その結果、複雑で状態に依存する計算を実行する能力を欠くステートレスシステムになる。その結果、ビットコインは単純なスクリプトやマルチシグネチャトランザクションを実行できる一方で、ステートフルなブロックチェーンプラットフォームで一般的な複雑で動的な契約上のやり取りを促進するのに苦労している。この問題は、ビットコイン上で構築できる分散型アプリケーション（dApps）や複雑な金融商品の範囲を大幅に制限する一方、ステートフルモデルプラットフォームは、機能豊富なスマートコントラクトを展開・実行するためのより多様な環境を提供します。
ビットコインのスケーリングにおいて、主なテクノロジーはステートチャネル、サイドチェーン、クライアントサイドの検証です。このうち、ステートチャンネルは安全で多様な決済ソリューションを提供しますが、任意に複雑な計算を検証する能力に限界があります。この制限により、複雑な条件付きロジックやインタラクションを必要とする様々なシナリオでの使用は制限される。サイドチェーンは、幅広いアプリケーションをサポートし、ビットコインの能力を超える多様性を提供する一方で、セキュリティは低い。このセキュリティの違いは、サイドチェーンがビットコインのコンセンサスメカニズムよりもはるかに堅牢性に劣る別のコンセンサスメカニズムを使用しているという事実に起因する。ビットコインのUTXOモデルを使用したクライアントサイドの検証は、より複雑なトランザクションを扱うことができるが、ビットコインとの双方向チェックサム制約がないため、ビットコインよりもセキュリティが低くなる。クライアント検証プロトコルのオフチェーン設計は、サーバーやクラウドインフラに依存するため、中央集権化や危殆化したサーバーによる検閲の可能性がある。また、クライアント側検証のオフチェーン設計は、ブロックチェーンインフラにさらなる複雑さをもたらし、スケーラビリティの問題につながる可能性があります。
2023年12月、ZeroSyncプロジェクトの責任者であるRobin Linus氏は、BitVM: Compute Anything On Bitcoin" ホワイトペーパーは、ビットコインを改善するための考えを呼び起こした。Bitcoinのプログラマビリティを向上させるという考えを呼び起こした。BitVMは、BitcoinスクリプトとTaprootをフル活用して、楽観的なロールアップを実装します。コミットメント）に基づき、ビットコインの2つのUTXO間の接続を確立し、ステートフルなビットコインスクリプトを可能にします。Taprootアドレスに大規模なプログラムをコミットし、オペレータと検証者はチェーン上に小さなフットプリントを生成する多くのオフチェーンインタラクションを実行する。当事者が協力すれば、チェーン上に足跡を残すことなく、任意に複雑でステートフルなオフチェーン計算を行うことができる。当事者が協力しない場合は、紛争が発生した場合にオンチェーンでの実行が必要となる。このように、BitVMはビットコインの潜在的なユースケースを大幅に広げ、通貨としてだけでなく、さまざまな分散型アプリケーションや複雑な計算タスクの検証プラットフォームとしても使用できるようにします。
しかし、BitVMテクノロジーはビットコインのスケーリングにとって非常に有利ではあるものの、まだ初期段階にあり、効率性やセキュリティの面でいくつかの問題が残っています。例えば、(1)チャレンジとレスポンスは複数のやり取りを必要とするため、高額な手数料と長いチャレンジサイクルが発生する、(2)Lamportのワンタイムシグネチャデータは長く、データ長を短縮する必要がある、(3)ハッシュ関数の複雑さは高く、コストを削減するためにはビットコインに優しいハッシュ関数が必要である、(4)既存のBitVMコントラクトは巨大であり、ビットコインのブロック容量は限られている。(5)既存のBitVMはパーミッションモデルを採用しており、連合メンバーのみがチャレンジを開始でき、それは2つのパーティのみに制限されている。信頼前提をさらに減らすべきである。この目的のために、本稿ではBitVMの効率とセキュリティをさらに改善するための最適化のアイデアを提案する。
2.BitVMの原理
BitVMはビットコインのオフチェーンコントラクトとして位置づけられ、ビットコインのコントラクト機能を促進することに専念しています。現在のビットコインスクリプトは完全にステートレスであるため、ビットコインスクリプトは各スクリプトの後に実行環境がリセットされた状態で実行されます。スクリプト1とスクリプト2を同じx値にするネイティブな方法はなく、ビットコインスクリプトもネイティブにはサポートしていません。ただし、Lamportのワンタイムシグネチャを使用することで、既存のオペコードを使用してビットコインスクリプトをステートフルにすることは可能です。BitVMプログラムの計算はオフチェーンで行われ、結果の検証はオンチェーンで行われる。現在のビットコインブロックには1MBの制限があり、検証計算が複雑すぎる場合は、より複雑な計算をサポートするためにチャレンジ・レスポンス・モードを採用するOP技術の助けを借りて検証することができます。
オプティミスティック・ロールアップ（Optimistic Rollup）やMATT提案（Merkelise All The Things）と同様に、BitVMシステムはプルーフ・オブ・フラウド（proof-of-fraud）とチャレンジ・レスポンス（challenge-response）プロトコルをベースにしていますが、ビットコインのコンセンサスルールを変更する必要はありません。Taprootツリーに基づいています。
検証者は逐語的にコミットしますが、チェーン上のすべての計算を検証するのはコストがかかりすぎます。そこで検証者は、証明者の誤った主張に対して簡潔に反論するために、一連の手の込んだ挑戦を行う。こうして、ビットコイン上の普遍的な計算検証を可能にする。
BitVMの主な構成要素は次のとおりです：
Circuit Commitment（回路コミットメント）：証明者と検証者は、プログラムを大規模なバイナリ回路にコンパイルします。証明者は回路をTaprootアドレスにコミットし、そのアドレスの下にある各リーフスクリプトが回路の各論理ゲートに対応する。コアはビットコミットメントに基づき、回路コミットメントの実装から論理ゲートコミットメントを実装する。
挑戦と応答： 挑戦と応答のゲームを実装するために、証明者と検証者は一連のトランザクションに事前に署名します。理想的には、この相互作用はオフチェーンで行われ、証明者が協力しない場合にはオンチェーンでも実行できる。
曖昧性ペナルティ：もしプロヴァーが不正な発言をした場合、ベリファイアはチャレンジ成功後にプロヴァーの預金を取り上げることができ、プロヴァーの不正な行動を阻止することができる。
3.BitVMの最適化
3.1 ZKに基づくOPインタラクション数の削減
現在、2つの主要なロールアップがあります：ZKロールアップとOPロールアップです。ZK RollupsはZK Proofに依存しており、ZK Proofは正しい実行を証明する暗号であり、その安全性は計算複雑性の仮定に依存している。OP RollupsはFraud Proofに依存しており、Fraud Proofは提出された状態がすべて正しいと仮定し、チャレンジ期間を通常7日間とし、その安全性は、不正な状態を検出してFraud Proofを提出できる正直者がシステム内に少なくとも1人存在することを仮定している。BitVMチャレンジ手順の最大ステップ数を2^{32}と仮定すると、2^{32}*4バイトのメモリが必要で、これは約17GBになります。最悪のケースでは、チャレンジとレスポンスの約40ラウンド、約半年、合計約150KBのスクリプトが必要です。
ゼロ知識証明を使用して、BitVMのチャレンジ数を減らし、BitVMの効率を改善することを検討してください。ゼロ知識証明の理論によると、データDataがアルゴリズムFを満たす場合、証明は検証アルゴリズムVerifyを満たす、つまり検証アルゴリズムはTrueを出力します。データDataがアルゴリズムFを満たさない場合、証明も検証アルゴリズムVerifyを満たさない、つまり検証アルゴリズムはFalseを出力します。BitVMシステムでは、挑戦者が証明当事者の提出したデータを認識しない場合、挑戦が開始されます。
アルゴリズムFについては、2^n回かかると仮定して、バイセクション分割を使用すると、エラーポイントを見つけることができます。しかし、ゼロ知識証明による検証アルゴリズムVerifyの複雑さは固定であり、PROOFの証明と検証アルゴリズムVerifyの全過程がオープンされ、出力が偽であることが判明する。ゼロ知識証明の利点は、検証アルゴリズムVerifyをオープンするのに必要な計算複雑さが、元のアルゴリズムFをオープンする二分法に比べてはるかに低いことである。したがって、ゼロ知識証明の助けを借りて、BitVMが元のアルゴリズムFではなく、検証アルゴリズムVerifyにチャレンジすることを可能にし、チャレンジラウンドの数を減らし、チャレンジサイクルを短縮します。
最後に、ゼロ知識証明の有効性と不正証明は異なるセキュリティ仮定に依存していますが、この2つを組み合わせることができ、ZK不正証明はオンデマンドZK証明を実現するために構築することができます。個々の状態遷移ごとにZK証明を生成する必要がなくなった完全なZKロールアップとは異なり、オンデマンドモデルは、個々の状態遷移ごとにのみZK証明を生成することを可能にします。デマンド・モデルにより、ZKプルーフは課題がある場合にのみ必要となり、ロールアップ全体の設計は楽観的なままである。したがって、生成された状態は、誰かがその状態にチャレンジするまで、デフォルトで有効である。しかし、参加者がチャレンジを開始した場合、チャレンジされたブロック内のすべてのトランザクションの正しさについてZK Proofを生成する必要がある。将来的には、常にZK Proofを生成する計算コストを回避するために、1つの係争中の命令についてZK Fraud Proofを生成することが検討される可能性がある。
3.2ビットコインに優しいワンタイムシグネチャ
コンセンサスルールに従ったビットコインネットワークのトランザクションは有効なトランザクションですが、コンセンサスルールに加えて、標準性ルールが導入されました。ビットコインノードはブロードキャストされた標準的なトランザクションのみを転送し、有効だが非標準的なトランザクションをパッケージ化する唯一の方法は、マイナーと直接行うことです。
コンセンサスルールによると、レガシー（つまり非セグウィット）トランザクションの最大サイズは1MBで、ブロック全体を占めることになっている。しかし、レガシートランザクションの標準的な上限は100kBです。コンセンサスルールによると、Segwitトランザクションの最大サイズはウェイトの上限である4MBです。BitVMの基本コンポーネントであるLamportワンタイムシグネチャは、署名と公開鍵の長さを短くすることで、トランザクションデータを減らすことができ、その結果、手数料を削減することができます。Lamportワンタイムシグネチャ方式では、ハッシュ関数（例えば、一方向順序関数f）を使用する必要があります。したがって、署名と公開鍵の長さを短くするために、同様の機能を持つ署名方式を見つける必要がある。Lamportワンタイムシグネチャと比較すると、Winternitzワンタイムシグネチャは署名と公開鍵の長さを大幅に削減できるが、署名と検証の計算量が増える。
Winternitzワンタイムシグネチャ方式では、特別な関数Pを用いてvビットのメッセージを長さnのベクトルsにマッピングする。Lamport一回署名方式は、d=1の特別な場合のWinternitz一回署名方式である。Winternitz一回署名方式では、n,d,vの関係は、n≈v/log2(d+1)を満たす。d=15の場合、n≈(v/4)+1となり、n個の要素を含むWinternitz署名の場合、Lamport一回署名方式の公開鍵長、署名長の4倍となる。しかし、署名チェックの複雑さは4倍になる。d=15,v=160,f=ripemd160(x)を用いてBitVMにWinternitzワンタイムシグネチャを実装すると、ビットコミットメントサイズが50%削減され、BitVMのトランザクション手数料が少なくとも50%削減される。将来的には、既存のWinternitzビットコインスクリプト実装の最適化とともに、ビットコインスクリプトで表現されるよりコンパクトなワンタイムシグネチャスキームを調査することができる。
3.3ビットコインに適したハッシュ関数
コンセンサスルールによると、P2TRスクリプトの最大サイズは10kBで、P2TRスクリプト証人の最大サイズはSegwitトランザクションの最大サイズと同じ4MBです。
現在のビットコインネットワークはまだOP_CATをサポートしておらず、メルクルパスの検証のために文字列をスプライスすることはできません。そのため、最適なスクリプトサイズとスクリプトウィットネスサイズを持つ既存のビットコインスクリプトを使用して、ビットコインに適したハッシュ関数を実装し、メルクル包含証明検証機能をサポートする必要があります。
BLAKE3は、BLAKE2ハッシュ関数の最適化バージョンであり、Baoツリーパターンを導入しています。BLAKE3ハッシュ関数は、入力を1024バイトの連続したチャンクにスライスします。チャンクが1つしかない場合、そのチャンクはルートノードとなり、ツリー内の唯一のノードとなる。これらのチャンクをバイナリツリーのリーフノードとして並べ、各チャンクを個別に圧縮します。
Merkle包含証明シナリオの検証にBitVMを使用する場合、ハッシュ演算への入力は2つの256ビットハッシュをつなぎ合わせたもの、つまりハッシュ演算への入力は64バイトとなります。BLAKE3ハッシュ関数を使用する場合、これらの64バイトは単一のチャンク内に割り当てることができ、BLAKE3ハッシュ演算全体は単一のチャンクに圧縮関数を1回適用するだけでよい。
u32値に基づくXOR、モジュロ加算、ビット右シフトなどの基本演算は現在BitVMで行われており、ビットコインスクリプトで実装されたBLAKE3ハッシュ関数を簡単に組み立てることができます。BLAKE3に必要なu32加算、u32ビット単位のXOR、u32ビット単位の回転は、u32ワードを表現するためにスタック内の4つの別々のバイトを使用して実装されています。現在のBLAKE3ハッシュ関数ビットコインスクリプトの合計は約100kBで、BitVMのTOYバージョンを構築するために使用するには十分すぎるほどです。
さらに、このBLAKE3コードを分割する機能により、VerifierとProverは、Challenge-Responseゲームでの実行を完全に実行するのではなく、2つに分割することで、必要なオンチェーンデータ量を大幅に削減することができます。最後に、Keccak-256、Grøstlなどのハッシュ関数がビットコインスクリプトを使用して実装され、そこから最もビットコインに適したハッシュ関数が選択され、他の新しいビットコインに適したハッシュ関数が探索される。
3.4スクリプトレススクリプトBitVM
スクリプトレススクリプトは、シュナー署名を使用してスマートコントラクトをオフチェーンで実行する方法です。スクリプトレススクリプトのコンセプトはMimblewimbleから生まれ、カーネルを除いて永続的なデータを保存しません。スクリプトレス・スクリプトはMimblewimbleから生まれたもので、カーネルとその署名以外は永続的なデータを保存しません。
スクリプトレススクリプトの利点は、機能性、プライバシー、効率性です。
機能性：スクリプトレススクリプトは、スマートコントラクトの範囲と複雑性を高めます。ビットコインのスクリプト機能は、ネットワークで有効化されたOP_CODESの数によって制限されますが、スクリプトレススクリプトは、スマートコントラクトの仕様と実行をチェーンから外し、デザインコントラクトの参加者だけの話し合いに移行するため、新しいOPコードを有効にするためにビットコインネットワークのフォークを待つ必要がなくなります。
プライバシー：スマートコントラクトの仕様と実行をオフチェーンに移すことで、プライバシーが向上します。オンチェーンでは、契約の多くの詳細がネットワーク全体で共有され、これらの詳細には参加者の数やアドレス、送金額などが含まれます。スマートコントラクトをオフチェーンに移行することで、ネットワークは参加者が契約の条件が満たされ、問題の取引が有効であることに同意したことだけを知ることができる。
効率性：スクリプトレススクリプトは、チェーン上で検証され保存されるデータ量を最小限に抑えます。スマートコントラクトをオフチェーンに移行することで、ノード全体のオーバーヘッドが削減され、ユーザーの取引手数料も削減されます。
スクリプトレススクリプトは、明示的なスマートコントラクトの実行を回避する、Bitcoin上の暗号プロトコルを設計するアプローチです。核となる考え方は、機能を実装するためにスクリプトを使用するのではなく、希望する機能を実装するために暗号アルゴリズムを使用することです。アダプタ署名とマルチ署名は、スクリプトレススクリプトのオリジナルの構成要素です。スクリプトレススクリプトを使用することで、通常のトランザクションよりも小さなトランザクションが可能になり、トランザクション手数料が削減されます。
スクリプトレススクリプトを使用すると、BitVMスキームのようにハッシュ値とハッシュのオリジナルイメージを提供する必要がなくなるだけでなく、BitVM回路の論理ゲートコミットメントを実装する必要もなくなるため、BitVMスクリプトのスペースを節約し、BitVMの効率を向上させるために、シュナー・マルチシグネチャとアダプター・シグネチャを使用できます。既存のスクリプトレス・スクリプト方式は、BitVMのスクリプト空間を縮小することができますが、公開鍵を組み合わせるために、証明者と挑戦者の間で多くの対話が必要です。このスキームは、特定のBitVM機能モジュール内にスクリプトレススクリプトを導入する試みとともに、将来的に改善される予定である。
3.5パーミッションレス・マルチパーティチャレンジ
現在のBitVMチャレンジは、デフォルトでパーミッションが必要です。なぜなら、ビットコインのUTXOは一度しか実行できないため、悪意のある検証者が正直な証明者にチャレンジすることで契約を「無駄に」することができるからです。現在、BitVMは2パーティ・チャレンジ・モードに制限されている。悪質な行為を行おうとするプロヴァーは、同時に彼の支配下にある検証者にコントラクトを「浪費」するよう挑むことができ、悪質な行為を成功させるが、他の検証者はその行為を止めることができない。したがって、Bitcoinの上に、既存のBitVMの1-of-n信頼モデルを1-of-N（Nはnよりはるかに大きい）に拡張することができる、許可なしのマルチパーティOPチャレンジプロトコルを研究する必要がある。さらに、プロヴァーと結託したり、悪意を持って契約に挑戦したりする挑戦者による契約の「浪費」の問題に対する解決策を研究する必要がある。契約の「浪費」の問題。最終的な目標は、より信頼性の低いBitVMプロトコルを実現することです。
許可なしのマルチパーティチャレンジは、許可リストなしで誰でも参加できるようにします。これは、ユーザーが信頼できる第三者の関与なしにL2からコインを引き出すことができることを意味します。さらに、OPチャレンジプロトコルに参加したいユーザーは誰でも、無効な引き出しに挑戦し、削除することができます。
BitVMをパーミッションレスのマルチパーティチャレンジモデルに拡張するには、以下の攻撃に対処する必要があります：
ウィッチ攻撃：攻撃者が複数のIDを偽造して争いのあるチャレンジに参加したとしても、1人の正直な参加者が争いに勝つことができます。正しい結果を守るための正直な参加者のコストが、攻撃者に対する攻撃者の数に線形に関係しているとすると、多数の攻撃者が参加する場合、論争に勝利するための正直な参加者のコストは非現実的になり、魔女攻撃の影響を受けやすくなります。論文
-
- 『パーミッションレス・レフェリード・トーナメント』
- では、1人の誠実な参加者が紛争に勝つためのコストが、対戦相手の数に対して線形ではなく対数的に成長する、ゲームを変える紛争解決アルゴリズムが提案されています。
遅延攻撃：悪意のある当事者（または当事者のグループ）は、L1での正しい結果の確認（例えば、L1への資産の引き出し）を阻止または遅延させ、正直な証明者にL1の手数料を使わせる戦略に従う。この問題は、挑戦者が事前に誓約する必要があることを要求することで軽減できる。もし挑戦者が遅延攻撃を行った場合、挑戦者は誓約を失う。しかし、攻撃者が遅延攻撃を追求するために、ある制限の範囲内で誓約を犠牲にすることを厭わないのであれば、遅延攻撃の影響を軽減する対処戦略があるはずである。論文 BoLD.Bounded Liquidity Delay in a Rollup Challenge Protocolは、攻撃者がどれだけの誓約を失っても、最悪のケースの攻撃はある上限値の遅延しかもたらさないようなアルゴリズムを提案しています。
将来的には、上記の攻撃問題に耐性のあるBitVM許可なしマルチパーティチャレンジモデルが、ビットコインの特徴に適用されるように調査される予定です。
4.結論
BitVM技術の探求は始まったばかりであり、将来的には、ビットコインの拡大とビットコインエコシステムの繁栄を達成するために、より多くの最適化の方向性が探求され、実践されるでしょう。
参考文献
BitVM: Compute Anything on Bitcoin
BitVM: Off-chain Bitcoin Contracts
BitVM: Compute Anything on Bitcoin
BitVMに関するRobin Linus
[bitcoin-dev] BitVM: Compute Anything on Bitcoin
The Odd Couple: ZK and Optimistic Rollups on a
ビットコインのトランザクションとスクリプトの制限は？BIP-342: タップルートスクリプトの検証
https://twitter.com/robin_linus/status/1765337186222686347
応用暗号学の大学院コース暗号技術
BLAKE3: 1つの関数、どこでも高速
[bitcoin-dev] Bitcoin ScriptでBlake3を実装する
https://github.com/BlockstreamResearch/scriptless-scripts
スクリプトレス入門
スクリプトレススクリプトを使用するBitVM
ロールアップの遅延攻撃に対するソリューション
DAVEの紹介。
ロールアップの遅延攻撃
ロールアップの遅延攻撃
DAVEを紹介します。span style="font-size: 18px;">ロールアップに対する遅延攻撃の解決策 - Arbitrum Research
多人数参加型インタラクティブ計算ゲーム。マルチプレイヤーインタラクティブ計算ゲームノート
BoLD: Bounded Liquidity Delay in a Rollup.チャレンジプロトコル
無許可審判トーナメント
JinseFinance
Cheng Yuan
Sanya