よく知られているように、詐欺証明はブロックチェーン空間で広く使用されている技術ソリューションです。これらはEthereumコミュニティで生まれ、ArbitrumやOptimismなどの有名なEthereum Layer 2ソリューションに採用されました。2023年にビットコインエコシステムが台頭した後、Robin LinusはTaprootなどの既存のビットコイン技術に基づいたBitVMという解決策を提案し、詐欺証明を中心に据え、Bitcoin Layer 2やブリッジ向けの新しいセキュリティモデルを提供しています。

BitVMは、最初のBitVM0から論理ゲート回路を原始として使用したもの、後のバージョンであるBitVM2など、ZK詐欺証明とGroth16検証回路に焦点を当てたものなど、いくつかの理論的なバージョンを発表しています。BitVMに関連する技術的な実装経路は進化し、成熟しており、多くの業界のプロフェッショナルの注目を集めています。Bitlayer、Citrea、BOB、Fiamma、Goat Networkなどのプロジェクトは、すべて異なるバージョンをこの基盤に基づいて実装しており、BitVMをコアテクノロジーの1つとして使用しています。

BitVMに関する公に利用可能な説明の希少性と複雑さを考慮して、BitVM知識を普及させることを目的とした一連の記事を発表しました。BitVMと詐欺証明の深い関連性を考慮すると、この記事では詐欺証明とZK詐欺証明に焦点を当て、これらの概念を簡単でわかりやすい言葉で説明します。

(最適主義のインタラクティブな詐欺証明メカニズムの原則)

OutputRootとStateRoot

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

シーケンサーがトランザクションデータのバッチを処理した後、このDAデータはEthereumに送信されます。Optimismノードクライアントを実行できる限り、シーケンサーによってアップロードされたデータをローカルマシンにダウンロードすることができます。その後、これらのトランザクションをローカルで実行し、Optimismの現在のステートセットハッシュ（各アカウントの現在の残高などを含む）を計算できます。

シーケンサが誤ったステートセットハッシュをEthereumにアップロードした場合、ローカルで計算したステートセットハッシュは異なる可能性があります。この場合、詐欺証明システムを通じてチャレンジを行うことができます。判断に基づいて、シーケンサに制限や罰則を科すか、何もしないかがシステムによって決定されます。

「ステートセット」という用語を言及する際、EVMベースのブロックチェーンは一般的にMerkle Treeに似たデータ構造を使用してステートセットを記録し、World State Trieと呼ばれます。取引が実行されると、特定のアカウントの状態が変化し、World State Trieも変化し、その最終ハッシュが変更されます。EthereumはWorld State Trieの最終ハッシュをStateRootと呼び、ステートセットの変更を表します。

次の図は、EthereumのstateRootの構造を示しています。私たちが見ているように、異なるアカウントの残高、スマートコントラクトアカウントに関連付けられたコードハッシュ、およびその他のデータがすべてWorld State Trieに集約され、stateRootが計算されます。

Optimismのアカウントシステムとデータ構造は一般的にEthereumと一致しており、StateRootフィールドを使用して状態セットの変更を表します。OPシーケンサは定期的にOutputRootと呼ばれるキーフィールドをEthereumにアップロードし、これはStateRootと他の2つのフィールドに基づいて計算されます。

最初の質問に戻ると、OPノードクライアントを実行し、StateRootと現在のOutputRootをローカルで計算すると、OPシーケンサーがアップロードした結果と一致しないことがわかった場合、詐欺証明を開始できます。では、これの具体的なメカニズムは何でしょうか？以下では、MIPS仮想マシンの状態検証と対話型詐欺証明を順次紹介します。

MIPS仮想マシンとメモリMerkle木

前述のように、OPシーケンサーによって提出されたOutputRootが正しくないことがわかったとします。そして、“チャレンジ”を開始したい場合を想定してください。チャレンジプロセスでは、一連のオンチェーンでのやり取りを完了する必要があり、その後関連するスマートコントラクトがOPシーケンサーが正しくないOutputRootをアップロードしたかどうかを判断します。

スマートコントラクトを使用してチェーン上のOutputRootの正確性を検証するには、最も簡単な方法は、OPシーケンサーと同じ入力パラメータを使用して、Ethereumチェーン上にOPノードクライアントを実装し、同じプログラムを実行し、計算された結果が一致するかどうかを確認することです。このアプローチはFault Proof Programと呼ばれます。これは、オフチェーンで実装することは比較的簡単ですが、Ethereumチェーン上で実行することは2つの問題があるため非常に難しいです。

1. Ethereum上のスマートコントラクトは、詐欺証明に必要な入力パラメータを自動的に取得することはできません。

2. Ethereum’s block gas limit is limited, and it does not support highly complex computational tasks. Thus, we cannot fully implement the OP node client on-chain.

最初の問題は、オンチェーンのスマートコントラクトにオフチェーンのデータを読み込むことを要求することに等しいため、オラクルに類似した解決策を使用して解決できます。 OPは、Ethereumチェーン上にPreimageOracleコントラクトを展開しており、詐欺証明に関連する契約は、この契約から必要なデータを読み取ることができます。理論的には、誰でもこの契約にデータをアップロードできますが、OPの詐欺証明システムには、データが必要かどうかを検証する方法があります。ただし、このプロセスについては詳しく説明しませんが、これはこの記事の主要なトピックには関係ありません。

第2の問題に関して、OP開発チームは、詐欺証明システムに十分なOPノードクライアントの機能の一部を実装するために、SolidityでMIPS仮想マシンを作成しました。 MIPSは一般的なCPU命令セットアーキテクチャであり、OPシーケンサーのコードはGolang/Rustのような高水準言語で記述されています。Golang/RustプログラムをMIPSプログラムにコンパイルし、それらをEthereumチェーン上のMIPS仮想マシンを介して処理できます。

OP開発チームは、詐欺証明のためにGolangで簡略化されたプログラムを記述しました。これは基本的に、トランザクションを実行し、ブロックを生成し、OutputRootを生成するOPノード内のモジュールを模倣しています。ただし、この簡略化されたプログラムでも「完全に実行する」ことはできません。つまり、各OPブロックには多くのトランザクションが含まれています。このバッチのトランザクションを処理した後、OutputRootが生成されます。特定のブロック高のOutputRootが間違っていることはわかっていますが、その対応するOutputRootが誤っていることを証明するために、そのブロック内のすべてのトランザクションをオンチェーンで実行することは現実的ではありません。さらに、各トランザクションの実行中に、一連のMIPSオペコードが順次処理されます。これらのオペコードの全シリーズを、オンチェーンの契約で実装されたMIPS仮想マシンで実行することは現実的ではなく、計算上のオーバーヘッドやガス消費が大きすぎるでしょう。

(MIPS命令セットの動作原理)

これを解決するために、Optimismチームは、OPのトランザクション処理フローを深く分析することを目的としたインタラクティブな詐欺証明システムを設計しました。OutputRootの計算プロセス全体を観察することで、システムは、OPシーケンサーのMIPS仮想マシンがエラーを起こしたMIPSオペコードを特定します。エラーが確認されれば、シーケンサーによって提供されたOutputRootが無効であると結論付けることができます。

したがって、問題は明確になります: OPシーケンサーがトランザクションをブロックにパッケージ化するプロセスは、多数のMIPSオペコードの順次処理に分解できます。各MIPSオペコードが実行されるたびに、仮想マシンの状態ハッシュが変化します。これらのレコードはMerkleツリーに集約できます。

インタラクティブな詐欺証明プロセスでは、OPシーケンサの仮想マシン状態ハッシュが正しくなくなったMIPSオペコードの後に決定し、その後、MIPS仮想マシンの状態を再現し、オンチェーンで実行し、オペコードを実行し、その結果の状態ハッシュがシーケンサによって提出されたものと一致するかどうかを観察します。オンチェーンで実行されるMIPSオペコードは1つだけなので、複雑さは低く、計算プロセスはEthereumチェーン上で完了できます。ただし、これを実現するには、MIPS仮想マシンの状態情報（部分的なメモリデータなど）をチェーンにアップロードする必要があります。

コードの実装に関して、詐欺証明に関連するイーサリアムチェーン上のスマートコントラクトは、Stepという関数を通じて最終的なMIPSオペコードの実行プロセスを完了します。

上記の関数内のパラメータ_stateDataと_proofは、MIPS仮想マシンのレジスタ状態、メモリ状態ハッシュなど、単一のMIPSオペコードの実行に必要な依存データ項目を表します。次の図に示す通りです。

_stateDataと_proofを介してこれらのMIPS仮想マシン環境パラメータを入力し、オンチェーンで単一のMIPS命令を実行し、権威ある結果を得ることができます。オンチェーンで得られた権威ある結果がシーケンサが提出した結果と異なる場合、シーケンサが悪意を持っていることを示しています。

通常、_stateDataのハッシュをstatehashと呼びますが、これはMIPS仮想マシンの状態のハッシュとしておおよそ理解することができます。_stateDataのいくつかのフィールドの中で、memRootは最も独創的な設計です。プログラムの実行中には大量のメモリが使用され、CPUは特定のメモリアドレスのデータとやり取りします。したがって、VM.Step関数を介してMIPSオペコードをチェーン上で実行する際には、MIPS仮想マシンから特定のメモリアドレスのデータを提供する必要があります。

OPは、MIPS仮想マシン用に32ビットアーキテクチャを使用し、そのメモリには2^27のアドレスが含まれており、28段階のバイナリMerkle Treeに整理することができます。最も低いレベルの葉ノードの数は2^27で、それぞれの葉は仮想マシンの特定のメモリアドレスからのデータを記録しています。葉のデータから計算されるハッシュはmemRootです。以下の図は、MIPS仮想マシンのメモリデータを記録するMerkleツリーの構造を示しています。

特定のメモリアドレスからコンテンツを提供する必要があり、このコンテンツはステップ関数の_proofフィールドを介してEthereumチェーンにアップロードされます。さらに、提供されたデータがメモリMerkleツリーに実際に存在することを証明するために、メモリMerkleツリーに基づいたMerkleプルーフをアップロードする必要があります。データが捏造されたものではなく、提供者（またはシーケンサー）が実際にメモリMerkleツリーに存在することを証明するためにアップロードする必要があります。

インタラクティブ詐欺証明

前のセクションでは、MIPSオペコードと仮想マシンの状態の実行を完了することで、2番目の問題に対処しました。しかし、チャレンジャーとシーケンサーは、具体的な争われているMIPSオペコード命令をどのように特定できるのでしょうか？

多くの人々は、オンラインでインタラクティブな詐欺証明の簡単な説明を読んだり、その背後にある二分探索アプローチについて聞いたことがあるかもしれません。 OPチームは、Fault Dispute Game（FDG）と呼ばれるプロトコルを開発しました。 FDGプロトコルには、チャレンジャーとディフェンダーの2つの役割が含まれています。

OutputRootがシーケンサーによって提出されたものと異なることが判明した場合、FDGにおいて私たちはチャレンジャーとして行動し、シーケンサーはディフェンダーとして行動することができます。オンチェーンで処理する必要があるMIPSオペコードを特定するために、FDGプロトコルでは、参加者にGameTreeと呼ばれるMerkleツリーをローカルに構築することが求められます。その具体的な構造は次の通りです。

GameTreeは、階層的な入れ子構造を持ち、第1レベルのツリーと第2レベルのサブツリーから構成されていることがわかります。言い換えると、第1レベルのツリーの葉ノードにはサブツリーが含まれています。

前述のように、シーケンサによって生成される各ブロックにはOutputRootが含まれ、GameTreeの第1レベルツリーの葉ノードは異なるブロックのOutputRootを表します。チャレンジャーとディフェンダーは、OutputRootで形成されるMerkleツリー内で相互作用する必要があり、どのブロックのOutputRootが争いの的であるかを決定する必要があります。

紛争のあるブロックが特定されると、私たちはGameTreeの第2レベルに入ります。第2レベルの木もMerkle木であり、その葉ノードは前述のMIPS仮想マシンの状態ハッシュです。詐欺証明のシナリオでは、チャレンジャーとディフェンダーは、ローカルに構築したGameTreeの葉ノードに不一致があります。特定のオペコードを処理した後の状態ハッシュは異なります。

複数回のチェーン上での相互作用の後、当事者は最終的に正確な争われているオペコードを特定し、チェーン上で実行する必要がある特定のMIPSオペコードを決定します。

この時点で、インタラクティブな詐欺証明の全プロセスが完了しました。要約すると、インタラクティブな詐欺証明の2つの中核的なメカニズムは次のとおりです。

1. FDG（Fault Dispute Game）は、ブロックチェーン上で実行する必要があるMIPSオペコードと、その時点でのVMステート情報を最初に特定します；

2. イーサリアムチェーン上で実装されたMIPS仮想マシンは、オペコードを実行し、最終結果を生成します。

ZK詐欺証明

ZK詐欺証明。従来の詐欺証明手法は非常に複雑な相互作用を必要とし、FDGプロセスで複数のラウンドの相互作用が必要であり、チェーン上で個々の命令を再生する必要があります。しかし、この解決策にはいくつかの課題があります。

イーサリアムチェーン上で複数のラウンドのインタラクションをトリガーする必要があり、著しいガスコストが発生する数十のインタラクションが発生します。2.インタラクティブな詐欺証明プロセスは時間がかかり、一度インタラクションが開始されると、Rollupは通常のトランザクションを処理することができません。3.チェーン上に特定のVMを実装して、指示を再生することは非常に複雑で、開発の難易度が高いです。

これらの問題に対処するために、OptimismはZK Fraud Proofという概念を導入しました。その中心的な考え方は、チャレンジャーがチャレンジを提起する際に、オンチェーンで再生が必要と信じている取引を指定することです。ロールアップ・シーケンサーは、挑戦された取引のためにZK証明を提供し、その後、イーサリアムチェーン上のスマートコントラクトによって検証されます。検証が成功した場合、取引の処理にエラーがなかったと結論付けられ、ロールアップノードには非がないとされます。

図では、チャレンジャー refers to the party that raises the challenge, and the ディフェンダー通常の状況では、OPシーケンサーは受信したトランザクションに基づいてブロックを生成し、異なるブロックの状態のコミットメントをEthereumに提出します。これらの状態のコミットメントは、単純にブロックのハッシュ値と見なすことができます。Challengerはブロックハッシュに基づいて異議を申し立てることができます。異議を受け入れた後、Defenderはブロック生成の結果が正しいことを証明するZK証明を生成します。図中では、OPシーケンサーです。盆栽実際には、ZK証明生成ツールです。対話型詐欺証明と比較して、ZK詐欺証明の最大の利点は、複数の対話ラウンドを単一のZK証明生成ラウンドとオンチェーン検証に置き換えることです。これにより、時間が大幅に節約され、ガスコストが削減されます。さらに、ZK Rollupsとは異なり、ZK詐欺証明に基づくOP Rollupsは、ブロックが生成されるたびに証明を生成する必要がありません。それどころか、チャレンジされたときに一時的にZK証明を生成するだけで済み、Rollupノードの計算コストも削減されます。

ZK詐欺証明のコンセプトは、BitVM2でも採用されています。BitVM2を使用するプロジェクト、例えばBitlayer、Goat Network、ZKM、およびFiamaは、ビットコインスクリプトを介してZK Proof検証プログラムを実装し、オンチェーンに持ち込む必要があるプログラムのサイズを大幅に簡素化しています。スペースの制約のため、この記事ではこのトピックについて詳しく説明しません。BitVM2に関する私たちの次回の記事をお楽しみにして、その実装経路についてより深く理解してください。

免責事項:

1. この記事は[から転載されていますGodRealmX], 著作権は元の著者にあります[シュー＆ノア]、もし転載に異議がある場合は、お問い合わせください。Gate Learnチームは、関連手続きに従ってできるだけ早く対応します。

2. 免責事項：この記事で表現されている意見は、著者個人の意見を表しており、投資アドバイスを構成するものではありません。

3. 他の言語版の記事は、Gate Learnチームによって翻訳されており、言及されていませんGate.io、翻訳された記事を転載、配布、あるいは盗用することはできません。