BitVM背景知识：欺诈证明与ZK Fraud Proof的实现思路

作者：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的文章来深入理解其实现路径，敬请期待！