TLの;博士

はじめに:

この記事では、BitVMのホワイトペーパーを解釈し、BitVMのアプローチを説明します。これはオフチェーンで公開および保存され、コミットメントのみがブロックチェーンに保存されます。

転送された元の記事タイトル:BitVMの簡略化された解釈:BTCブロックチェーン上の不正の証拠を検証する方法(EVMまたはその他のVMオペコードの実行)

まえがき:現在、ビットコインレイヤー2はトレンドになっており、数十のプロジェクトが「ビットコインレイヤー2」として自己識別されています。これらの多くは「ロールアップ」であると主張し、BitVMホワイトペーパーで提案されたアプローチを利用して、BitVMをビットコインエコシステムの重要な部分として位置付けていると述べています。

しかし、BitVMに関する既存の文献のほとんどは、その原理を平易な言葉で説明していません。 この記事では、8ページのBitVMホワイトペーパーを読み、Taproot、MASTツリー、ビットコインスクリプトに関連するリソースを参照した後、簡単な要約を提供します。 理解を助けるために、読者がレイヤー2についてある程度の知識を持ち、「不正の証拠」の基本的な考え方を理解できることを前提に、BitVMホワイトペーパーにある表現からいくつかの表現を変更しました。

BitVMの予備的なコンセプトは、オンチェーンでデータを使用する必要がなく、最初はオフチェーンでデータを公開・保存し、ブロックチェーン上にはコミットメントのみを保存するというものです。 異議申し立てや不正防止の場合、必要なデータのみがオンチェーンに持ち込まれ、ブロックチェーン上のコミットメントとの関連性が実証されます。 その後、BTCメインネットは、オンチェーンデータに問題がないか、データプロデューサー(トランザクションを処理するノード)が悪意のある活動に関与していないかを検証します。 このアプローチは、オッカムの剃刀の原則である「エンティティは不必要に増殖すべきではない」に準拠しています(オフチェーンにできる場合は、オフチェーンにしてください)。

本文:BitVMに基づくいわゆるBTCブロックチェーン詐欺防止検証スキーム、平たく言えば:

1.まず、コンピュータ/プロセッサは、多数の論理ゲート回路で構成される入出力システムです。 BitVMの中心的なアイデアの1つは、ビットコインスクリプトを使用して論理ゲート回路の入出力効果をシミュレートすることです。 論理ゲート回路をシミュレートできる限り、理論的にはチューリングマシンを達成し、計算可能なすべてのタスクを完了することができます。 つまり、十分なリソースとマンパワーがあれば、エンジニアのチームを集めて、最初に基本的なビットコインスクリプトコードを使用して論理ゲート回路をシミュレートし、次に大量の論理ゲート回路を使用してEVMまたはWASMの機能を実装することができます。

(このスクリーンショットは教育ゲーム「Turing Complete」のもので、コアコンテンツは、特にNANDゲートなどの論理ゲート回路を使用して、完全なCPUプロセッサを構築することです。

BitVMのアプローチを、レッドストーン回路を使って「Minecraft」でM1プロセッサを構築することになぞらえる人もいます。 あるいは、ニューヨークのエンパイアステートビルをレゴブロックで建設するようなものです。

(誰かが「Minecraft」で「プロセッサ」を1年かけて作ったと言われています。

1. では、なぜビットコインスクリプトを使用してEVMまたはWASMをシミュレートするのでしょうか? それは非常に面倒ではありませんか? その理由は、ほとんどのビットコインレイヤー2ソリューションは、SolidityやMoveなどの高水準言語をサポートすることを選択することが多いのに対し、現在ビットコインブロックチェーン上で直接実行できる唯一の言語はビットコインスクリプトであるためです。 この言語は原始的で、多数の一意のオペコードで構成されており、チューリング完全ではありません。

(ビットコインスクリプトコードの例)

ビットコインレイヤー2が、アービトラムなどのイーサリアムのレイヤー2ソリューションのように、レイヤー1で不正防止を検証することを目指している場合、BTCのセキュリティを大幅に継承するために、BTCブロックチェーン上の「係争中のトランザクション」または「係争中のオペコード」を直接検証する必要があります。 これは、レイヤー2で使用されるSolidity言語/ EVMオペコードをビットコインブロックチェーン上で再実行する必要があることを意味します。 課題は要約すると、次のようになります。

ビットコインのネイティブだが初歩的なプログラミング言語であるビットコインスクリプトを使用して、EVMまたは他の仮想マシンの効果を実現します。

したがって、コンパイル原理の観点から見ると、BitVMアプローチはEVM/WASM/JavaScriptのオペコードをビットコインスクリプトのオペコードに変換し、論理ゲート回路を「EVMオペコード> ビットコインスクリプトオペコード」間の中間表現(IR)として機能させます。

(BitVMホワイトペーパーでは、ビットコインブロックチェーン上で特定の「係争中の命令」を実行するための一般的なアプローチについて説明しています)

とにかく、シミュレートされる究極の効果は、もともとEVM / WASMでしか処理できなかった命令をビットコインブロックチェーン上で直接処理することです。 このソリューションは実現可能ですが、すべてのEVM/WASMオペコードを表現するための中間形式として多数の論理ゲート回路を使用する方法が困難になります。 さらに、論理ゲート回路の組み合わせを使用して、非常に複雑なトランザクション処理フローを直接表現すると、膨大な作業負荷になる可能性があります。

1. BitVMのホワイトペーパーで言及されているもう1つのコアコンセプトである、Arbitrumが使用しているものと非常によく似た「Interactive Fraud Proofs」について説明しましょう。

インタラクティブな不正防止には、アサートと呼ばれる用語が含まれます。 通常、レイヤー 2 の提案者 (多くの場合、シーケンサーによって操作されます) は、レイヤー 1 でアサートを発行し、特定のトランザクション データと状態遷移の結果が有効でエラーがないことを宣言します。

提案者が提出したアサートに問題がある(関連データが正しくない)と誰かが考える場合、紛争が発生します。 この時点で、提案者と挑戦者はラウンド単位で情報を交換し、係争中のデータに対してバイナリ検索法を使用して、非常にきめ細かな操作指示とそれに関連するデータセグメントを迅速に見つけます。

この係争中の操作命令(OPコード)については、入力パラメータとともにレイヤー1で直接実行し、出力結果を検証する必要があります(レイヤー1ノードは、計算した出力結果を提案者によって以前に公開された出力結果と比較します)。 Arbitrumでは、これは「シングルステップ詐欺証明」として知られています。 (Arbitrumのインタラクティブな不正防止プロトコルでは、バイナリ検索を使用して、問題のある命令とその実行結果を迅速に特定し、シングルステップの不正証明が最終検証のためにレイヤー1に送信されます)。

これをフォローアップします。

1. このプロセスはインタラクティブで、両者が交代で行います。 一方の当事者はロールアップ ブロックに含まれる履歴データをセグメント化し、もう一方の当事者はどのデータ セグメントに問題があるかを指摘します。 これは、バイナリ法(実際には、範囲を徐々に絞り込むプロセス、N / K)に似ています。

2. その後、どのトランザクションと結果に問題があるかをさらに特定し、そのトランザクション内で異議を唱えられている特定のマシン命令にさらに絞り込むことができます。

3. ChallengeManagerコントラクトは、元のデータを細分化して生成された「データセグメント」が有効かどうかのみをチェックします。

4. チャレンジャーとチャレンジドがチャレンジ対象のマシン命令を見つけると、チャレンジャー oneStepProveExecution()は、このマシンインストラクションの実行結果に問題があることを示すために、シングルステップの不正証明を送信します。

(Arbitrumのインタラクティブな不正防止プロトコルでは、提案者が公開したデータから、問題のある命令とその実行結果を迅速に見つけるために、バイナリ検索を使用するプロセスが含まれます。 係争中のデータまたはオペコードを特定した後、最終検証のためにシングルステップの不正証明がレイヤー 1 に送信されます。

参照：

元ArbitrumテクニカルアンバサダーがArbitrumのコンポーネント構造を解説(パート1)

(Arbitrumのインタラクティブな不正防止フローチャート、説明は比較的大雑把です)

この時点で、シングルステップの不正防止の概念は非常に単純になります:レイヤー2で発生するトランザクション命令の大部分は、BTCブロックチェーン上で再検証する必要はありません。 ただし、特定の係争中のデータ セグメント/オペコードにチャレンジされた場合は、レイヤ 1 で再生する必要があります。

検証の結果、提案者が以前に公開したデータに問題があることが示された場合、提案者のステーキングされた資産は削減されます。 チャレンジャーに過失があることが判明した場合、チャレンジャーの賭け資産は削減されます。 また、課題にタイムリーに対応できないプルーバーも斬られる可能性があります。

Arbitrumはイーサリアムのコントラクトを通じて前述の効果を実装しますが、BitVMはビットコインスクリプトを使用してタイムロック、マルチシグ、およびその他の機能を実装することで同様の機能を実現することを目指しています。

4.「Interactive Fraud Proofs」と「Single-step Fraud Proofs」について説明した後、MASTツリーとマークルプルーフについてお話しします。 以前、BitVMソリューションでは、レイヤー2でオフチェーンで処理される膨大な量のトランザクションデータと論理ゲート回路が直接オンチェーンに配置されないことを述べました。 必要なときに、最小限のデータ/論理ゲート回路のみがオンチェーンに配置されます。 しかし、もともとオフチェーンであり、現在はオンチェーンに置く必要があるこのデータが捏造されていないことを証明する方法が必要です。 ここで、暗号学におけるコミットメントの概念が登場し、マークルプルーフはそのようなコミットメントの1つの形式です。

まず、MASTツリーについて話しましょう。 MASTの正式名称はMerkelized Abstract Syntax Treesで、AST(Abstract Syntax Trees)をコンパイラ原理の領域からマークルツリーに変換したものです。 では、ASTとは何でしょうか? 簡単に言うと、複雑なコマンドを字句解析によって一連の基本的な操作単位に分解するツリー状のデータ構造です。

(ASTツリーの例としては、「x=2, y=x*3」のような単純な計算を、基礎となる操作コードとデータに分解することが挙げられます。 )

MASTツリーは、マークルプルーフをサポートするASTツリーにマークル化を適用した結果です。 マークルツリーの利点の1つは、データを効率的に「圧縮」できることです。 例えば、マークルツリーのデータセグメントを必要に応じてBTCブロックチェーン上に公開し、そのデータセグメントがマークルツリー上に本当に存在し、恣意的に選択されていないことを信頼できるものにする場合、どうすればよいでしょうか?

マークルツリーのルートを事前にブロックチェーンに記録するだけです。 将来的には、ルートに対応するマークルツリーにデータが存在することを証明するマークルプルーフを提示するだけで十分です。

(Merkle Proof/BranchとRootの関係)

したがって、完全なMASTツリーをBTCブロックチェーンに保存する必要はありません。コミットメントとして事前にルートを開示するだけで十分です。 必要に応じて、データセグメント+マークルプルーフ/ブランチを提示することで十分です。 これにより、オンチェーンのデータ量を大幅に削減しながら、オンチェーンデータがMASTツリー上に本当に存在するようになります。 さらに、すべてのデータではなく、データセグメントのごく一部+マークルプルーフのみをBTCブロックチェーン上で開示することで、プライバシー保護を大幅に強化することができます。

参照:データ源泉徴収と不正防止:Plasmaがスマートコントラクトをサポートしない理由

(MASTツリーの例)

BitVMのソリューションでは、すべての論理ゲート回路はビットコインスクリプトを使用して表現され、巨大なMASTツリーに編成されています。 このツリーの一番下の葉は、図のコンテンツとして示されており、ビットコインスクリプトで実装された論理ゲート回路に対応しています。 レイヤー2の提案者は、BTCブロックチェーン上でMASTツリーのルートを頻繁に公開し、各MASTツリーは、そのすべての入力パラメータ/操作コード/論理ゲート回路を含むトランザクションに関連付けられています。 これは、ArbitrumのProposerがイーサリアムブロックチェーン上でロールアップブロックを公開しているのと似ています。

紛争が発生すると、チャレンジャーはBTCブロックチェーン上でどのルートに挑戦したいかを宣言し、提案者にルートに対応する特定のデータセグメントを明らかにするように依頼します。 その後、提案者はマークルプルーフを提示し、係争中の論理ゲート回路がチャレンジャーと共同で配置されるまで、MASTツリーのデータの小さなセグメントをオンチェーンで継続的に開示します。 その後、スラッシュを実行できます。

(出典:https://medium.com/crypto-garage/deep-dive-into-bitvm-computing-paradigm-to-express-turing-complete-bitcoin-contracts-1c6cb05edfca)

1. ここまでは、BitVM ソリューションの最も重要な側面をほぼカバーしてきました。 まだ曖昧な部分もあるかもしれませんが、BitVMの本質や要点は理解できると思われます。 ホワイトペーパーで言及されている「ビット値コミットメント」については、提案者がチャレンジを受けてロジックゲート回路をオンチェーンで検証することを余儀なくされたときに、論理ゲートの入力値に0と1の両方を割り当てることを防ぎ、曖昧さと混乱を生じさせるように設計されています。

要約すると、BitVMスキームは、ビットコインスクリプトを使用して論理ゲート回路を表現し、次にこれらの回路を使用してEVM /他のVMのオペコードを表現し、次に特定のトランザクション命令の処理フローを表現し、最後にこれらをマークルツリー/MASTツリーに編成します。 このようなツリーで表されるトランザクション処理フローが非常に複雑な場合、1億リーフを簡単に超える可能性があるため、コミットメントによって占められるブロックスペースと不正証明の影響を受ける範囲を最小限に抑えることが重要です。

シングルステップの不正防止には、ごく少量のデータとロジックゲートスクリプトをオンチェーンでしか必要としませんが、マークルツリー全体は、誰かが異議を唱えた場合にいつでもオンチェーンでアクセスできるように、オフチェーンに長期間保存する必要があります。 レイヤー2の各トランザクションは大きなマークルツリーを生成し、ノードに対する計算とストレージの負荷が想像できます。 ほとんどの人はノードを実行したくないかもしれません(ただし、そのような履歴データは段階的に廃止される可能性があり、B^2ネットワークは特にFilecoinに似たzk-storageプルーフを導入して、ストレージノードが履歴データを長期的に保存するようにインセンティブを与えています)。

ただし、不正証明に基づく楽観的なロールアップは、信頼モデルが 1/N であるため、それほど多くのノードを必要としません。つまり、N ノードのうちの 1 つが誠実で、重要な瞬間に不正証明を開始できる限り、レイヤー 2 ネットワークは安全です。

それにもかかわらず、BitVM に基づくレイヤー 2 ソリューションの設計には、次のような多くの課題があります。

1)理論的には、データをさらに圧縮するために、レイヤ1でオペコードを直接検証する必要はありません。 オペコードの処理フローをさらに圧縮してzk-proofにすることで、挑戦者はzk-proofの検証ステップに異議を唱えることができます。 これにより、オンチェーンのデータ量を大幅に削減することができます。 ただし、具体的な開発の詳細は非常に複雑になる可能性があります。

2)提案者とチャレンジャーは、オフチェーンでインタラクションを繰り返し生成する必要があります。 プロトコルをどのように設計するか、および処理フローでコミットメントとチャレンジプロセスをさらに最適化するには、多くの知的努力が必要です。

免責事項：

1. この記事は[Geek Web3]から転載したものですが、原題は「BitVMのミニマリスト解釈:BTCチェーンで不正防止を検証する方法(EVMまたは他のVMの操作コードを実行する)」で、著作権は原作者[Faust & Misty Moon]に帰属します。
   . この転載に異議がある場合は、 Gate Learn チームに連絡していただければ、迅速に対応いたします。
2. 免責事項:この記事で表明された見解や意見は、著者のものであり、投資アドバイスを構成するものではありません。
3. 記事の他言語への翻訳は、Gate Learnチームによって行われます。 特に明記されていない限り、翻訳された記事を複製、配布、盗用することは禁止されています。