作者：Shew&Noah，仙壤GodRealmX

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

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

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

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

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

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

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

MIPS虛擬機與內(nèi)存MerkleTree

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

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

1. Ethereum上的智能合約無法自動獲得欺詐證明需要的輸入?yún)?shù)；

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

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

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

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

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

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

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

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

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

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

交互式欺詐證明

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

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

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

1.FDG先定位到需要上鏈執(zhí)行的MIPS操作碼及此時的VM狀態(tài)信息；

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

ZK化欺詐證明

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

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

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

3.鏈上實現(xiàn)特定VM來重放指令是較為復雜的，開發(fā)難度極高

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

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