BitVM 2：ビットコイン上のライセンスフリー認証

BTCスタディ、Robin Linus氏による

BitVMの初期バージョンは、参加者が2人に限定されるように設計されていました。その後の研究では、並列インスタンスと冗長インスタンスを組み合わせて、1-of-nの正直な仮定に基づく複数パーティ参加を導入しました。これらのコントラクトの主な制限は、すべてのバリデータをコンパイル時に定義しなければならないことである。さらに、起動時のオーバヘッドは検証の数とともに増加する。これは、契約を破棄するために、常に限られた数の参加者だけを買収する必要があることを意味する。

BitVM2は大胆な変形であり、誰でも検証者になれる。これでもまだ、正直な参加者の1/nの仮定を持つ1回限りのデバイスが必要ですが、実行時に、誰でも、初期化グループのメンバーである必要なく（そして、それらのn人の参加者の1人である必要なく）、無効なアサーションに異議を唱えることができます。これにより、これまでのスキームの制約が克服され、信頼の前提が最適化される。さらに、試行の最大ラウンド数を2ラウンドに減らすことで、全体的な設計を単純化している。

ブリッジ契約(bridge)は依然として、事前に定義されたオペレータのセットと、m人のオペレータのうち少なくとも1人が正直であることを追加的に要求する。しかし、すべてのオペレーターが不誠実な場合でも、あなたのお金を盗むことはできず、せいぜい燃やされるだけである。

はじめに

与えられたプログラムfについて、我々はある主張を検証したい：あるxを入力するとyが出力される、すなわちf(x) = yである。そして、xは証明であり、yは有効性のあるSNARK証明の出力状態です。

SNARK検証器のような例では、ビットコインスクリプトで表現するには次数が大きすぎます。Groth16バリデータを実装するには、最大20MBのスクリプトが必要になるかもしれません。しかし、許容されるスクリプトサイズの上限は、ビットコインのブロックサイズの上限である4 MBであり、そのサイズに圧縮しても、まだ大きすぎる可能性があります。

Naive Solution

"Lamport Signature "は、手続きf(x)=yを複数のステップに分割する方法を提供します。例えば、ステップ：n=42.

このようにして、f sの計算は、複数のブロックにわたって実行される43のトランザクションの連続シーケンスにスライスすることができる。各トランザクションは、前のトランザクションの出力状態を入力状態とする。もし証明者が状態z_iのいずれかについて曖昧であれば、誰もが不正の証拠として相反するLamport署名を使用することができる。

これは確かに、証明者に挑戦する信頼性のない方法である。しかし、この解決策の重大な限界は、依然として証明者が全計算を実行する必要があるため、チェーン上のフットプリントが大きいことです。加えて、やはりLamport署名のため、状態を切り替えるオーバーヘッドが発生する。

バランスの取れた解決策

重い作業の一部を、証明者側から検証者の不正の証拠に移すことで、オンチェーンフットプリントを大幅に削減することができます。

検証者はどのような誤った主張でも反証することができます。起動フェーズでは、計算f1, f2, f3, f43の任意のセグメントを反証する43のスクリプトを含むTaptreeを定義する。たった一つのアサーション

保持することはできません、誰でも対応するスクリプトから費やすことができます。これにより、最悪の場合の計算を、検証者が実行する1つのステップf_i に減らすことができます。このステップでも、かなりの大きさのスクリプト実装が必要になる場合があります。理論的には、スクリプトをブロックに詰め込むことができれば、さほど問題にはならない。実際には、いくつかの具体的なf 実装のために、証明者のための約束されたボリュームと検証者のためのスクリプトボリュームとの最適なバランスを見つけようとします。

要するに、これは、証明者が不正確な主張をする限り、誰でも証明者の出力を破壊できるようにする。そうでなければ、誰も計算の一部を反証できなければ、スクリプトがタイムアウトするまでに、正直な証明者はその出力を使うことができる。最大でも2ラウンドかかる。

このメカニズムは、ブリッジング・コントラクトのライセンスフリーの検証のための基本的な構成要素として使用することができる。

楽観的な解決策

以下のプロトコルは、上記の設計におけるオールハッピーパス（そして、うまくいけば最もよく使われるパス）を強化するもので、最悪の場合、さらに2ラウンドのやりとりが必要になります：

1.証明者は状態yを出力することを約束します

2.これが正しくない場合、誰でもチャレンジのラウンドを開くことができます

3.証明者は次のことを約束します。中間結果 z1,z2,......z42

4.不正確な場合、誰でも主張f _iを証明または反証できる

無免許ブリッジ契約設計

制限: 手数料

上記の設計では、証明者は手数料を盗むことができます。この場合、プロヴァーが保護された資金を失うことを除けば、資金リザーブは安全なままです。

攻撃シナリオは以下の通り：

• Prover is malicious

• Prover uses its own KickOff_Tx (does not have a valid PegOut_Tx)

• ProverプローバーはチャレンジャーがChallenge_TXを実行するのを待ち、チャレンジを実行したプローバーに支払う

• プローバーはチャレンジを実行せず、単に応答を停止する

次の修正された図がこの問題を解決する。さらに2つのn-of-n事前署名トランザクションが必要です。

制限: 正直なオペレーター

この設計では、オペレーターが少なくとも正直であると考えられることが必要です。現実には、活動的な障害は、資金を盗むための誘拐攻撃と組み合わせることができます（例えば、身代金の50％を支払わない限り、資金のロックを解除しない）。