BitVMの知識：不正防止とZK不正防止実装のアイデア

By Shew &; Noah, Fairy Loam GodRealmX

周知の通り、不正の証明はブロックチェーン分野で広く使われている技術的ソリューションであり、イーサリアムコミュニティで最初に生まれ、現在に至っている。ArbitrumやOptimismなどのイーサネットレイヤー2が有名です。2023年にビットコインエコシステムが台頭した後、Robin LinusはBitVMと呼ばれるスキームを提案しました。これは、詐欺の証明をコアアイデアとして使用し、Taprootなどの確立されたビットコイン技術に基づいて、ビットコインレイヤー2、つまりブリッジに新しいセキュリティモデルを提供します。

BitVMには、論理ゲート回路をプリミティブとする初期のBitVM0から、ZK不正証明とGroth16検証回路を中核とする後期のBitVM2まで、いくつかの理論的バージョンがあり、BitVM関連技術の実装経路は進化を続けてきました。成熟する傾向にあり、多くの実務家の注目を集めている。Bitlayer、Citrea、BOB、Fiamma、Goat Networkはすべて、BitVMを技術的なルーツの1つとしており、どの異なるバージョンの実装に基づいているかに基づいています。

市場にBitVMの体系的な説明が少ないことから、BitVMの知識を普及させることを目的とした一連の記事を開始しました。BitVMとFraud Proofの根深い関係を考慮し、この記事ではFraud ProofとZK Fraud Proofを主なトピックとし、、できるだけわかりやすい言葉で説明します。

Optimismの不正証明ソリューションを素材として、そのMIPS VMベースのインタラクティブな不正証明ソリューションと、ZK不正証明の背後にある主なアイデアを分解します。

(Optimism).インタラクティブな不正証明のためのメカニズム原理）

OutputRoot and StateRoot

楽観主義は、そのようなものです。よく知られたOptimistic Rollupプロジェクトで、そのインフラはシーケンサー（主要モジュールにはop-node、op-geth、op-batcher、op-proposerが含まれる）とイーサチェーン上のスマートコントラクトで構成されている。

シーケンサーによって取引データのバッチが処理されると、このDAデータがイーサに送信されます。DAデータがイーサに送信される。Optimism ノードクライアントを実行する能力さえあれば、シーケンサーによってアップロードされたデータをローカルにダウンロードすることができ、その後、これらのトランザクションをローカルで実行して、Optimism の現在の状態セットハッシュを計算することができます（各アカウントの現在の残高などのデータを含みますが、これに限定されません）。

シーケンサーが間違った状態セットハッシュをイーサにアップロードした場合、ローカルで計算された状態セットハッシュが異なることになります。するとローカルで計算された状態セットハッシュは異なるものになり、不正証明システムを通じてそれに異議を唱えることができます。

「ステートセット」という用語について言えば、EVMブロックチェーンは多くの場合、World State Trieと呼ばれる、ステートセットを記録するためのメルクルツリー形式のデータ構造を使用しています。トランザクションが実行され、特定のアカウントの状態が変化すると、World State Trieも変化し、最終的なハッシュも変化する。イーサネットは、World State Trieの最終ハッシュをStateRootと呼び、状態セットの変更を表します。

次の図は、イーサのstateRootの構成を表しています。 イーサのさまざまなアカウントの残高、スマートコントラクトのアカウントに関連付けられたコードのハッシュなどが、World State Trieに集約され、そこからstateRootが計算されることがわかります。

オプティミズムのアカウントシステムとそのデータ構造は、イーサとほぼ一致しています。状態セットの変更を反映するためにStateRootフィールドも使用しています。OPシーケンサーは、StateRootと他の2つのフィールドから計算されるOutputRootというキーフィールドを定期的にEtherにアップロードします。

元に戻ります。OPのノード・クライアントを実行し、StateRootと現在のOutputRootをローカルで計算するとき、計算した結果がOPのシーケンサーがアップロードした結果と一致しないことがわかれば、不正証明を開始することができます。では、その仕組みはどのようになっているのだろうか。以下では、MIPS VMの状態検証と対話型不正証明について順番に紹介していく。

MIPS VMとメモリ・メルクル・ツリー

先に述べたように、OPシーケンサーから提出されたOutputRootに問題があるとします。

間違ったOutputRootをチェーン上にアップロードするようOPシーケンサーに挑戦したい場合、チェーンとの一連のやり取りを完了しなければならず、その後、関連するスマートコントラクトがOPシーケンサーが間違ったOutputRootをアップロードしたかどうかを判断します。strong>OutputRootの正しさをスマートコントラクトでオンチェーン検証する場合、これを行う最も簡単な方法は、イーサオンチェーンをOPノードクライアントから実装することです。同じ入力パラメータで同じプロシージャを実行し、計算が一貫しているかどうかをチェックします。 この方式はフォールト・プルーフ・プログラムと呼ばれ、オフチェーンで実装するのは簡単ですが、イーサチェーンで実行するのは非常に困難です。

1. イーサ上のスマートコントラクトは、不正を証明するために必要な入力パラメータを自動的に取得することができません。限られた、過度の複雑さの計算タスクをサポートしていない、我々は完全にチェーン上のOPノードクライアントを実装することはできません

最初の問題は、オンチェーンスマートコントラクトにオフチェーンデータを読み取らせることと等価であり、これは予言マシンと同様のソリューションによって解決することができます。OPはPreimageOracleコントラクトをイーサチェーンに展開しています。不正の証明関連のコントラクトはPreimageOracle内で使用できます。内の必要なデータを読み取ります。

理論的には、誰でも好きなだけ契約書にデータをアップロードできますが、OPの不正防止システムには、データが必要なものかどうかを識別する方法があります。

2つ目の問題については、OP 開発チームはSでMIPS 仮想マシンを書きました。不正証明システムが使用するのに十分な、OPノード・クライアントの機能の一部を実装しています。MIPSは一般的なCPU命令セット・アーキテクチャであり、OPシーケンサーのコードはGolang/Rustのような高水準言語で書かれているため、Golang/Rustで書かれたプログラムをMIPSプログラムとしてコンパイルし、イーサネット・チェーン上のMIPS VMを通して処理することができます。

OPの開発チームは、不正の証明に必要な最も単純化されたプログラム群を書くためにGolangを使用しました。これは、トランザクションを実行し、ブロックを生成し、OutputRootを実行するOPノードのモジュールと本質的に同じ機能です。しかし、この簡略化されたプロセスはまだ「完全に実行可能」ではない。

つまり、各OPブロックには多数のトランザクションが含まれ、それが処理されるとOutputRootになり、どのOutputRootがどのブロックの高さで間違っているかはわかりますが、そのブロックからチェーン上でトランザクションを実行しても、対応するOutputRootが間違っていることを証明することはできません。対応するOutputRootに誤りがあることを証明するために、そのブロックに含まれるすべてのトランザクションをチェーン上に置いて実行するのは現実的ではない。

さらに、各トランザクションは実行プロセスにおいて一連のMIPSオペコードを含み、計算オーバーヘッドとガス消費量が大きすぎるため、オンチェーンコントラクトによって実装されたMIPS VMでそれらすべてを実行することはできません。オーバーヘッドとガス消費量が大きすぎるからです。

(MIPS命令セット)works)

この目的のために、Optimismチームは、OPのトランザクション処理フローの深い粒度を提供することを目的としたインタラクティブ不正証明システムを設計しました。OutputRootの全計算フローから、OPシーケンサーのMIPS仮想マシンにおいて、どのMIPSオペコードがエラーで処理されるかが観察される。エラーが決定された場合、シーケンサーによって提供されたOutputRootは無効であると結論づけることができます。

そこで問題が明らかになります。OPシーケンサーによるトランザクション・パック・ブロックの処理は、膨大な数のMIPSオペコードの整然とした処理に分解することができ、各MIPSオペコードの実行後にVMの状態ハッシュが変化します。メルクルツリーに要約することができます。

対話型不正証明プロセスでは、OPシーケンサーがどのMIPSオペコードを実行した後にVMの状態ハッシュがおかしくなったかを判断し、次に、チェーン内のその時点のMIPS VMの状態を再現し、オペコードを実行し、その後の状態ハッシュがシーケンサーによって提出された結果と一致しているかどうかを観察することが重要です。シーケンサーによって提出された結果と一致するかどうかを観察します。 チェーン上で実行されるMIPSオペコードは1つだけなので、複雑さは高くなく、計算処理はイーサネットチェーン上で行うことができます。しかし、これを行うには、メモリデータの一部など、MIPS VMの状態情報をチェーンにアップロードする必要があります。

コード実装レベルでは。イーサチェーン上の不正証明に関連するスマートコントラクトは、以下の関数を通過しますステップ
。最終的なMIPSオペコード実行フローを完了する:

上記の関数のパラメータにある_stateDataと_proofは、MIPS VMのレジスタ状態など、1つのMIPSオペコードを実行するための依存データ項目を表しています、メモリー状態のハッシュなどです。回路図は次のとおりです:

私たちはを使用することができます。code>_stateDataと_proof入力をこれらのMIPS VMの環境パラメータに与え、その連鎖上で単一のMIPS命令を実行して、権威ある結果を得る。連鎖から得られた権威ある結果がシーケンサーによって提出された結果と矛盾する場合、シーケンサーは悪を行っていると言われます。

我々は一般的に_stateDataのハッシュを_stateDataと呼ぶ。memRootは、_stateDataのいくつかのフィールドの中で最も微妙な設計です。周知のように、プログラムは実行中に大量のメモリを占有し、CPUはいくつかのメモリ・アドレスのデータと相互作用する。そのため、VM.Step関数を通して連鎖的にMIPSオペコードを実行するとき、MIPS VMのメモリアドレスのいくつかにデータを提供する必要があります。

OPは32ビットアーキテクチャのMIPS VMを使用しており、そのメモリには合計で2の27乗個のアドレスが含まれています。これは、最下層に2の27乗個のリーフを持つ、28レベルの分岐したメルクルツリーとして編成することができ、各リーフはVMのメモリアドレスの1つにデータを記録します。データ。次の図は、MIPS VMのメモリデータを記録するMerkleツリーの構造を示している。

私たちは、step関数の_proofフィールドを介してイーサチェーンにアップロードされる、メモリアドレス内のコンテンツの一部を提供する必要があります。インメモリ・メルクルツリーに基づくメルクル証明もここにアップロードされ、あなた/シーケンサーが提供したデータがインメモリ・メルクルツリーに確かに存在し、空から作り出されたものではないことを証明します。

インタラクティブな不正の証明

上記では、VM状態の検証でMIPSオペコードの連鎖実行を完了させることで、2つ目の問題をすでに解決していますが挑戦者とシーケンサーは、どのように論争の的になっているMIPSオペコード命令の場所を特定すべきでしょうか？

皆さんの多くは、多かれ少なかれ、ネット上で対話型不正証明の簡単な説明を読んだことがあり、その二律背反的な考えについて何か耳にしたことがあると思います。OPチームは、挑戦者と防御者という2つの役割があるFault Dispute Game (FDG)として知られる一連のプロトコルを開発しました。

シーケンサーによってチェーンに提出されたOutputRootに問題が見つかった場合、私たちはFDGのチャレンジャーとして行動することができ、シーケンサーはディフェンダーとして行動します。チェーン上で処理される必要がある前述のMIPSオペコードを簡単に見つけるために、FDGプロトコルは、参加者全員がローカルにメルクルツリーを構築することを要求する。ゲームツリーと呼ばれるツリーは次のような構造をしている:

GameTreeは実際には非常に複雑で、第1レベルのツリーと第2レベルのサブツリーからなる階層的な入れ子関係を持っていることがわかります。

先に説明したように、シーケンサーによって生成された各ブロックはOutputRootを含み、GameTreeの第1レベルツリーのリーフノードは異なるブロックのOutputRootです。どのブロックが係争中のOutputRootを持っているかを決定する。

問題のあるブロックを特定した後、GameTreeの2番目のレベルに潜ります。ツリーの2番目のレベルもMerkleツリーです。あるオペコードを処理した後のVMの状態ハッシュは異なる振る舞いをします。

その後、両当事者は何度かチェーン上で対話し、最終的に争われている場所を特定します。そして最終的にチェイン上で実行される必要がある1つのMIPSオペコードを特定します。

この時点で、私たちは以下のプロセスを完了しました。対話型不正プルーフィングの全プロセスが完了したことになります。要約すると、対話型不正証明は2つのコアメカニズムで構成されています。

1.FDGはまず、実行のためにアップロードされる必要があるMIPSオペコードと、その時点でのVM状態情報を検索します。最終結果を得る。

ZK化された不正の証明

上記の伝統的な不正の証明は非常に複雑であることがわかります。不正の証明は非常に複雑で、FDGプロセス内で複数ラウンドの相互作用が必要であり、その後、1つの命令をチェーン上で再生する必要があります。

1.イーサチェーン上で複数ラウンドのインタラクションをトリガーする必要があり、ほぼ数十回のインタラクションを必要とし、大量のガスコストが発生します。

3.命令を再生するためにチェーン上に特定のVMを実装することは、より複雑であり、開発が非常に困難である

これらの問題を解決するために、O<公式楽観主義はZK不正証明というコンセプトを考え出しました。その核心は、チャレンジャーがチャレンジを行う際、チェーン上で再生する必要があると思われるトランザクションを指定し、RollupシーケンサーがチャレンジされたトランザクションのZKプルーフを与え、それがイーサ上のスマートコントラクトによって検証され、検証がパスした場合、そのトランザクションはエラーなく処理されたとみなされ、Rollupノードは不正を行わなかったというものである。

上図のChallengerがチャレンジャー、Defenderがディフェンダーです。チャレンジャー、ディフェンダーがOPシーケンサーです。通常、OPシーケンサーは受信トランザクションに基づいてブロックを生成し、異なるブロックの状態をイーサにコミットします。上の画像のBonsaiは、実際にはZKプルーフ生成ツールです。

対話型不正証明に対するZK不正証明の最大の利点は、複数ラウンドのやりとりをZK証明生成とオンチェーン検証の1ラウンドに減らすことで、多くの時間とガスを節約できることです。また、ZKロールアップと比較して、ZK不正証明に基づくOPロールアップは、ブロックがアウトするたびに証明を生成する必要がなく、チャレンジされたときに一時的にZK証明を生成するだけなので、ロールアップ・ノードの計算コストも削減できます。

ZK-enabled Fraud Proofのアイデアは、BitVM2でも使われています。のアイデアはBitVM2でも使われています。BitlayerやGoat Network、ZKM、FiamaなどのBitVM2を採用するプロジェクト関係者は、ビットコインスクリプトを通じてZK Proofの検証プロセスを実装し、チェーン上に必要なプロセスのサイズを大幅に簡素化しています。スペースの都合上、この記事では詳細には触れませんが、実装経路を深く理解するにはBitVM2に関する記事をお待ちいただければと思いますので、ご期待ください！