作者：Shew&Noah，仙壤GodRealmX

眾所周知，欺詐證明是一種在Blockchain領域中被廣泛應用的技術方案，其最早發源于Ethereum社區，并被Arbitrum和Optimism等知名EthereumLayer2所采用。2023年Bitcoin生態興起后，RobinLinus提出了名為BitVM的方案，以欺詐證明為核心思想，在Taproot等Bitcoin既有技術的基礎上，為Bitcoin二層或橋提供了新的安全模型。

BitVM曾先后推出過多個理論版本，從最早的以邏輯門電路為基元的BitVM0，到后來以ZKFraudProof和Groth16驗證電路為核心的BitVM2，與BitVM相關的技術實現路徑在不斷的演化并趨于成熟，吸引了許多從業人員的關注。大家所聽聞的Bitlayer、Citrea、BOB、Fiamma和Goat Network等項目均以BitVM為技術根基之一，在此基礎上進行了不同版本的實現。

鑒于市面上系統解釋BitVM的資料比較稀少且晦澀難懂，我們推出了以BitVM知識科普為目的的系列文章。考慮到BitVM與欺詐證明之間根深蒂固的關系，本篇文章將以欺詐證明和ZKFraudProof為主要話題，以盡可能易懂的語言為大家展開解讀。

我們將以Optimism的欺詐證明方案為素材，為大家解析其基于MIPS虛擬機和交互式欺詐證明的方案，以及ZK化欺詐證明的主要思路。

如果定序器把錯誤的狀態集hash上傳到了Ethereum上，那么你在本地算出的狀態集hash會與之不同，此時你可以通過欺詐證明系統發起質疑，系統會根據判決結果對定序器采取限制或懲罰亦或不處罰。

提到“狀態集”一詞，EVM系Blockchain常用到MerkleTree式的數據結構來記錄狀態集，名為WorldStateTrie。一筆交易被執行后，某些賬戶的狀態會變化，WorldStateTrie便會發生變化，其最終hash也會變更。Ethereum將WorldStateTrie的最終hash稱為StateRoot，用其表現狀態集的變化。

下圖展示了EthereumstateRoot的構成，我們可以看到Ethereum內不同賬戶的余額，智能合約賬戶關聯的代碼hash等數據都會被匯總到WorldStateTrie中，并依此計算出stateRoot。

MIPS虛擬機與內存MerkleTree

前面我們提到，假設我發現OP定序器提交的OutputRoot有問題，就可以發起“挑戰”，挑戰流程需要在鏈上完成一系列交互動作，交互完成后，相關智能合約會斷定OP定序器是否上傳了錯誤的OutputRoot。

如果要在鏈上用智能合約驗證OutputRoot的正確性，最簡單的方法是在Ethereum鏈上實現出OP節點客戶端，采用與OP定序器相同的輸入參數，執行相同的程序，查驗計算結果是否一致。這個方案被稱為FaultProofProgram，其在鏈下很容易實現，但想要在Ethereum鏈上運行卻十分困難。因為存在兩個問題：

1. Ethereum上的智能合約無法自動獲得欺詐證明需要的輸入參數；

2. Ethereum每個區塊的GasLimit有限，不支持復雜度過高的計算任務，我們無法在鏈上完全實現OP節點客戶端

第一個問題等價于讓鏈上智能合約讀取鏈下數據，可以通過類似預言機的方案來解決。OP在Ethereum鏈上專門部署了PreimageOracle合約，欺詐證明相關合約可以在PreimageOracle內讀取所需的數據。

理論上任何人都可以向該合約隨意上傳數據，但OP的欺詐證明系統有辦法鑒別數據是否為其所需，具體過程在此不展開論述，因為對本文的核心話題而言不重要。

對于第二個問題，OP開發團隊用Solidity編寫了一個MIPS虛擬機，實現了OP節點客戶端中的部分功能，足夠欺詐證明系統所用。MIPS是一種常見的CPU指令集架構，而OP定序器的代碼是用Golang/Rust等高級語言編寫的，我們可以將Golang/Rust寫的程序編譯為MIPS程序，然后通過Ethereum鏈上的MIPS虛擬機進行處理。

OP的開發團隊使用Golang編寫了欺詐證明所需的最簡化程序，與OP節點中執行交易、生成區塊及OutputRoot的模塊功能基本一致。不過這套精簡化的程序仍無法“完整執行”。

也就是說，每個OP區塊中包含很多筆交易，這批交易處理完后，會得到一個OutputRoot。雖然你知道是哪個區塊高度下的OutputRoot有錯誤，但你如果要把該區塊中包含的交易全都放到鏈上去跑，證明對應的OutputRoot有錯，是不現實的。

此外，每筆交易的執行流程中，又涉及到一連串MIPS操作碼的有序處理，你不可能把這一串操作碼都放到鏈上合約實現的MIPS虛擬機中去跑，因為涉及的計算開銷和Gas消耗量太大。

Ethereum鏈上與欺詐證明相關的智能合約，會通過以下名為Step的函數完成最后的MIPS操作碼執行流程：

_stateData和_proof輸入這些MIPS虛擬機的環境參數，在鏈上運行單條MIPS指令，獲得權威結果。如果鏈上得出的權威結果與定序器提交的結果不一致，則說明定序器做惡。

step函數中的_proof字段來上傳到Ethereum鏈上。這里還要上傳基于內存Merkle樹的默克爾證明，證明你/定序器提供的數據的確存在于內存Merkle樹中，而非憑空編造的。

交互式欺詐證明

在上文中，我們已經解決了第二個問題，完成了MIPS操作碼的鏈上執行與虛擬機狀態驗證，但挑戰者與定序器該如何定位到那條有爭議的MIPS操作碼指令？

相信很多人在網上多多少少閱讀過交互式欺詐證明的簡單解釋，對于其二分法的思路有所聽聞。OP團隊開發了一套被稱為FaultDisputeGame(FDG)的協議，在FDG中，包含兩個角色：挑戰者和防御者。

假如我們發現定序器提交到鏈上的OutputRoot有問題，那么我們就可以作為FDG中的挑戰者，而定序器會作為防御者。為了便于定位到前文提及的需要鏈上處理的MIPS操作碼，FDG協議要求參與者都要在本地構建一顆Merkle樹，稱為GameTree，其具體結構如下:

1.FDG先定位到需要上鏈執行的MIPS操作碼及此時的VM狀態信息；

2.在Ethereum鏈上實現的MIPS虛擬機里執行該操作碼，獲得最終結果。

ZK化欺詐證明

我們可以看到上述傳統欺詐證明的交互極為復雜，需要在FDG流程里進行多輪交互，然后將單條指令在鏈上重放。但這種方案存在幾個難點：

1.多輪交互需要在Ethereum鏈上觸發，差不多需要幾十次交互，會產生大量gas成本；

2.交互式欺詐證明的過程較長，一旦交互啟動，Rollup就無法正常執行交易；

3.鏈上實現特定VM來重放指令是較為復雜的，開發難度極高

為了解決這些問題，Optimism官方提出了ZKFraudProof的概念。核心在于當挑戰者進行挑戰時，指定其認為需要在鏈上重放的一筆交易，Rollup定序器給出被挑戰交易的ZK證明，由Ethereum上的智能合約進行驗證，如驗證通過，則可認為該交易的處理流程沒錯誤，Rollup節點沒做惡。

ZK化欺詐證明的思路也被BitVM2所采用。采用BitVM2的項目方如Bitlayer和GoatNetwork及ZKM、Fiama等，通過Bitcoin腳本來實現ZKProof驗證程序，并對需要上鏈的程序尺寸進行了極大程度的精簡化。限于篇幅，本文不展開贅述，大家可等待我們之后關于BitVM2的文章來深入理解其實現路徑，敬請期待！