Layer2的核心目标是提升区块链处理速度，原因是无法在一层中同时满足安全性、处理速度、去中心化，详情可见之前的一篇文章不可能三角。

L2有3种模式 state channel/ plasma/rollup(个人虽然不喜欢用英文，但这3个词基本成为了特定名词) ,state channel/ plasma因为各自的缺陷没有成为主角，所以本文我们只介绍rollup机制即可，其他模式有兴趣可以自行查阅。

Rollup

Rollup 的核心思路是在L1上保存能够验证交易过程的凭证，而将交易过程(计算过程)还有状态存储运行在L2中。

何为交易过程的凭证，我们知道交易执行的过程就是由1个状态转移到另外1个状态的过程，如果L1知道了一组交易前的状态和一组交易后的状态还有这一组交易，自然可以验证这组交易对应的状态转移是否正确。

如上图所示，发布者将交易前状态树的根hash 交易后状态树的根hash以及交易发布到L1上，L1智能合约确认交易前状态树根hash是否和存储的根hash一致。交易前的根hash一致说明起始状态正确，那么本次交易过程是否正确如何验证呢？最安全的做法肯定是我们每次都在L1上重新执行L2的交易树，进行状态转移，但这样L2失去了意义，还是会面临不可能三角中处理速度的问题。

如何去验证状态转移是否正确也引出了2种不同的Layer2 Rollup机制。

第一种是欺诈证明，即默认相信存入的状态是正确的，等待其他参与者提出欺诈证明挑战，每一次L2发布到L1时的节点都要缴纳一定的保障金，当欺诈被证明后 回滚到前一状态，发布者保证金会被全部扣除，部分给到挑战者，部分直接销毁。如何证明欺诈，根据和L1交互程度的不同，分为交互式欺诈证明和非交互式欺诈证明，下面会详细解释。

第二种是零知识证明，每次存入状态都需要给出证明，证明会在L1进行验证，如果验证根hash值是正确的，代表发布者的发布无误，这里的证明用到了零知识证明相关研究。

刚刚上面说到欺诈证明本着默认相信的原则。当没有挑战的时候，流程较为简单, 即将状态树的根hash 交易信息存入L1中。核心在于有挑战者发起挑战时，如何证明交易前状态树的根hash经过这一组交易可以变为新的状态根hash。这里有2种思路。

1.非交互式欺诈证明，即在L1上将这组交易重新执行一遍，看看执行过后的状态树 根hash值和传入的根是否一致即可。

2.交互式欺诈证明，由挑战者和发布者在L2上进行多轮挑战，最终挑战者锁定具体哪条指令具有欺诈性，由L1进行裁决。L1只需要执行存在争议的最小指令即可。

非交互式欺诈证明

我们将以Optimism为例说明交互式欺诈

欺诈证明过程解析

非交换式欺诈，欺诈证明实现较为简单，将L2中执行的交易在L1中再完整执行一次，以确定状态根的hash是否一致来判断欺诈行为。

如上图所示，发布者发布信息到L1上，携带交易信息和新旧整体根hash, L1中的智能合约收到后会默认变更state为新的根hash，这时挑战者提出挑战，挑战者需要提供符合旧根hash的merkle状态树，L1智能合约通过旧的状态树执行完整的交易流程得到根hash和发布者提供的新根hash比较，不相等则说明有欺诈行为。

重新执行就会遇到一个问题，区块相关的属性会因为执行环境不同而发生变化。

如上图所示block.timestamp会获取当前区块的时间戳，但由于合约执行的环境不同得到的时间戳大概率是不一样的。我们看看Optimism是如何设计OVM来解决这一问题的。

OVM

为了解决在L2和L1运行智能合约时所处环境不一致的问题，Optimism使用了虚拟化技术（实际上就是使用封装方法屏蔽）的方式，让智能合约直接获取一些状态变为经过OVM封装后调用。

上面的那个例子，将不能直接调用block.timestamp，改为调用ovm封装的1个方法ovm_getTimestamp(非真实 随意命名)

contract OVM_ENV {
  uint timestamp;  //L1重新执行前调用该方法设置正确的L2 timestamp即可  
  funtion ovm_setTimestamp(t:uint) {      
        timestamp=t;     
   } 
  
  funtion ovm_getTimestamp() returns(uint) {
       return timestamp;
  }
}

交互式欺诈证明

我们将以Arbitrum为例说明交互式欺诈

Arbitrum欺诈证明过程解析

其实之前智能合约一文开头讲过智能合约执行的过程就是推进状态变化的过程我们再次回顾状态机的概念

如图所示，无论上L1上的状态树还是L2上的状态树，都是由一系列的交易(智能合约的执行也是一次交易的调用)，推动状态转换的，而由于智能合约，交易又可以拆分为更小的步骤指令。所以就变成了下面的样子

我们的问题转化为证明状态树从状态A 经过N个指令变成了状态B，那么这个证明过程是否是可分解的呢？我们用分治的方式不难想到二分法，将1个大问题拆两个子问题，问题就变为证明状态A 经过前N/2个指令变成状态X和状态X经过后N/2个指令变成状态B。逐步二分最终定位到存在问题的指令，交由L1执行验证即可。

让我们完整描述整个运行过程，假设Ｘ是发布者 发布从状态A经过N条指令转移到状态B Y是挑战者。

Y向Ｘ提出挑战，要求给出经过 N/2条指令处的状态，Ｘ给出状态后，Y会自行验证是否正确。如果验证正确，则代表前N/2指令执行无问题，问题在后N/2，如果验证错误，则代表前Ｎ/2条指令执行就有问题。Y继续向Ｘ询问存在问题的指令区间N/2处状态，循环往复，直至找到有问题的指令(这里不是指令有问题，是执行指令前的状态无法通过执行指令得到执行指令后的状态)。

在实际应用中Arbitrum不是使用二分的方式，而是使用了K分，即每次将N个指令分为N/K组去寻找欺诈指令，效率更高。

AVM

Arbitrum 设计 AVM和EVM不同的核心点在于：AVM不仅仅要支持EVM完全兼容的执行逻辑，还要支持交互式欺诈证明的证明逻辑。

证明过程中，要保证当前程序计数器中指令的正确性。这时采取了类似区块链的做法，PC(当前的程序计数器位置)不仅存储操作码，而且存储PC+1处的hash值，这样就可以在指令执行过程中验证验证每个指令是否正确。

交互式欺诈证明vs非交互式欺诈证明

交互式欺诈证明 非交互式欺诈证明

EVM兼容性 无法做到完全兼容由于OVM使用虚拟化技术解决L1和L2运行环境不一致的问题，那么必然就会导致一部分在L1运行的智能合约代码到OVM运行时需要进行修改 可以完全兼容

处理成本 存在欺诈行为时由于非交互式欺诈证明需要在L1完全重新执行所有交易，所以会耗费大量gas费用。 存在欺诈行为时交互式欺诈证明只需要在L1执行有争议的1条指令，所以gas费用很少。

复杂合约的支持 由于合约需要在L1上重新执行，合约复杂度不能超过L1对合约复杂度的限制 可以支持更复杂的合约。

由上述对比来看交互式欺诈证明除了实现难度较高外，主要特性都优于非交互式欺诈证明。具有代表性非交互式欺诈证明使用者Optimism也准备切换到交互式欺诈证明。可以预见未来交互式欺诈证明将会是欺诈证明的主流。

欺诈证明大都存在1个问题较长的提款周期，这是因为需要足够多的时间，让挑战者提出挑战。受益于密码学的较新研究成果，zk-rollup将解决这一问题。

ZK-Rollup

零知识证明的含义

零知识即在参与者解出问题结果但不告知验证者结果的情况下，让验证者相信参与者解出的问题结果是正确的。我们举2个比较有名的例子。

著名的阿里巴巴

很久很久以前，有一个藏着财宝的山洞，阿里巴巴因为知道开启山洞石门的咒语，而被强盗抓住。如果说出咒语，失去利用价值也是一死；如果坚持不说，强盗也会杀死他。
两难的阿里巴巴却想了一个好办法，他让强盗随机下指令：“你们只需离我一箭之遥，用弓箭指着我，你们举起右手我就念咒语打开石门，举起左手我就念咒语关上石门，如果我做不到或伺机逃跑，你们就用弓箭射死我。”
重复多次后，强盗始终无法获知咒语，却可以相信阿里巴巴拥有咒语的事实，阿里巴巴也保住了性命。

数独问题

有一组9*9的数独，A已经解出答案，A在不透露答案的前提下想让B相信A已经成功解出。

解决方法是：让B随机挑选1行或1列，A将这一行或一列取出打乱展示给B，包含了1～9，重复多次B就会相信A得出正确答案。

ZK-SNARK是如何解决问题的

目前ZK机制较为成熟的是zk-SNARK 所以后面指的zk算法都以zk-SNARK为例。

ZK-SNARK工作流程分为2步:

1.通过将问题转换为电路再转化为多项式，即从真实的零知识证明问题转化为数学的零知识证明问题

2.验证这个多项式零知识证明 随机给出1些检查点都可以得出符合条件的解，则验证成功。

关于zk证明我们后面会单独再来一篇文章来介绍，因为zk证明不仅仅会运用在以太坊扩容，更多会运用在隐私保护领域，比如较为热门的DID。

zk-rollup

我们以starkware为例介绍zk-rollup的机制，starkware流程图如下图所示。

图片来源于:https://docs.starkware.co/

当发布者发布交易到L1上时，需要将交易以及L2上状态打包交给一个证明生成服务，证明生成服务经过大量运算，生成这次发布的证明。证明服务将证明发送给L1的验证服务。同时发布者将状态根hash值提交到L1，L1中接收到根hash值会询问L1上的验证服务，验证服务根据证明验证根hash值是否正确，如果正确L1会将状态根切换成新的hash值。

在这个过程中本来验证状态树的根hash是需要前一次完整状态树执行这次发布的所有交易得到新的交易树，从而计算新的根hash值，最终根据发布者提供的根hash值和新的hash值进行比较判断发布是否合法。由于引入了zk证明，我们不需要知道具体的状态和交易就可以判断hash值是否正确。这就是zk证明在以太坊扩容的应用。

zk-rollup vs 欺诈证明

zk-rollup 欺诈证明

等待周期 很快，因为证明和新的根hash同时传入L1所以可以立马验证结果 需要等待一周，等待挑战者发起挑战

每次发布固定gas费用 较高 执行验证计算需要较多计算量 较低 写入状态树根hash值即可

发布中每笔交易的增量gas费用 低 不影响状态变更的信息不需要写入L1 较高 发起挑战后需要在L1上执行指令，正常情况下需要存入发布的所有信息

技术复杂性 较高 用到了零知识证明 较低

ZK证明的发展

SNARK(零知识简明非交互式知识证明) 和STARK(零知识可扩展透明证明)对比

SNARK STARK

安全性 需要启动参数 可信设置 如果启动参数被泄露 将面临毁灭性打击 无需启动参数

抗量子性 不具备抗量子性 抗量子性

验证成本 生成证明较小，验证成本较小，gas花费较小 (这里的小是相对概念，相比STARK) 生成证明较大，验证成本较高，gas花费较大

相比SNARK而言，STARK发展还处于早期，但就安全性和抗量子性较好的表现，有望在接下来取得更大的发展。

本文我们介绍主要介绍了rollups这种主流layer2技术，rollups中根据何时去验证L2提交的状态是正确的时机分为了欺诈证明和zk rollups ，欺诈证明又根据挑战者是否需要和发布者交互分为了非交互式欺诈证明和交互式欺诈证明，经过对比发现无论是运行成本还是EVM兼容性，交互式欺诈证明都处于优势。而zk这一密码学较新的研究成果给我们带来了新的方向zk rollups得以更快地验证发布者的发布。并且zk还为隐私保护等其他方向带来了新的可能。

更多web3相关文章 可关注公众号 "web3探索者"