# 以太坊的扩容之路

By [Jackson Oar](https://paragraph.com/@jackson-oar) · 2022-03-18

---

前言
--

作者：Luka（Twitter：0x8e06）

审阅：Jackson（Twitter：0xOar）

无论你是不是区块链技术方面的专家，只要你待在Crypto的世界里够久。以太坊扩容，layer2，Rollup这些词语对于你来说都不会陌生。很多人都对这些概念中的一个或多个有所了解，但是他们之间的关系到底是怎样的？我们为什么需要这些技术？他们想要解决什么样的问题？

如果你想要知道以上问题的答案，那希望这篇文章会对你有所帮助：

本文中的所有内容都是逻辑上的梳理，不会涉及密码学/计算机科学方面的知识，所以相信只要你对以太坊本身熟悉，基本都可以理解。

自从CryotoKitty造成以太坊链上拥堵的那天开始，以太坊开发者们就在不停的探索提高以太坊吞吐量的方案。

### 从原理上可以分为两类

（1）：是对以太坊区块本身进行改造，我们姑且称之为Layer1方案，这里的主要解决方案是分片。

（2）：是改变我们使用以太坊的方式，将交易的执行和处理放在链下，以太坊本身只用来校验其交易有效性，提供安全性。这就是我们经常听到的Layer2。

Layer2的核心思想是将大批实际发生的交易放在链下执行和计算，再将其通过以太坊上极少量的交易进行交易最终有效性的验证。无论是State Channel，Plasma还是Rollup，实际上都遵循了这一原则。

现在谈起Layer2，很多人第一反应都是将其与Optimistic/ZK Rollup挂钩，但在这里我们先简单介绍一下状态通道和Plasma，这有助于我们理解为何Rollup最终胜出，成为当前我们谈论最多的Layer2解决方案：

一：状态通道
------

以下是一个状态通道的最原始结构:

![](https://storage.googleapis.com/papyrus_images/b407c2f461f6ab8a5dc6bdfad5a599aaa42acb6abe2f7be5f2188bde36ebb0b5.png)

状态通道是一种已经存在很久的区块链扩展方案，他最出名的应用是比特币的闪电网络。

### 1：举例说明

相比描述他的原理，一个例子更能够说清楚什么是状态通道：

你很喜欢楼下的一家理发店，每次去理发店的时候Tony老师都会在你的耳边一直让你办卡。

有一天你终于决定了，办卡就办卡吧，反正我以后还会来。于是你向理发店转账一千元办了一张卡。

以后每次去理发，你都不需要再向理发店转账，取而代之的是你的卡里的余额会被扣除，同时每次理发你都和理发店完成了一次实际上的交易。

过了一个月，你要搬家了，可是你卡里的钱还没用完。于是你向理发店申请退卡，理发店的Tony老师退给了你200元。

在这一个月的时间里，你在理发店消费了十几次，但你和理发店实际上只互相转账了两次。

将这个过程放在区块链上，你买卡的过程实际上是将钱存进了某个智能合约，同时开启了一个你与理发店间的状态通道。你退卡的过程关闭了你与理发店之间的“状态通道”。你和理发店之间的互相转账相当于在以太坊主链上的两笔交易。

设想一下你没有办卡，那每次理完头你都需要给理发店转一次帐。

通过这个例子我们发现，通过状态通道，只有第一步和最后一步需要我们在区块链上进行交易，在这些步骤之间，你 和 理发店 可以向对方发送无限数量的签名消息（完成一次消费），指示付款。在这种情况下，以太坊区块链仅用作结算层来处理一次性付款的最终交易，这大大减轻了底层区块链的负担。

2：应用场景

（1）状态通道在某些简单场景如流支付中能够发挥很大的作用，其通过在链下对消息签名的方式对交易数据进行记录，将大量在逻辑上发生了的交易简化成了主链上的两笔交易。 （2）状态通道因为其成本较低，很适合一些微支付的场景，比如用ETH或者BTC买早餐咖啡等。

3：局限性

但同时，状态通道需要资金的发送方和接受方都进入这个通道来，而为了维护状态通道，支持比流支付更复杂的操作，大笔的资金需要被锁定。因此开发者们很快意识到状态通道无法作为可选的扩容方案之一。

二：Plasma
--------

### 1：原理

现在我们都知道了状态通道的局限性，而为了解决这个问题。——Plasma应运而生 其解决了将资产发送给任意目标人的问题，同时也能够确保TPS的提升。 事实上在开发者们研究Layer2解决方案的开始很长一段时间里，Plasma一度被认为就是那 “一个”。

要理解Plasma，首先要明白它并不是一种实际的技术，它更像是一种设计思想或者技术架构。

Plasma通常是一条链，它可以拥有与主链不同的共识机制，也可以拥有自己的矿工。但最重要的是Plasma链上会有一个叫做“Operator”的角色定期的根据子链上的状态转换，生成一棵默克尔树，并将这棵默克尔树的树根哈希值提交给主链做验证和记录。关于为什么默克尔树和其树根哈希值能够用作状态转换的验证，我们会在同样使用了这一应用的Rollup中讲到。

通过这样的方式，无论在两次提交期间，子链上发生了多少笔交易，子链只需要将交易执行造成的状态信息提交到主链上即可。

以下是使用Plasma机制的简单示意图：

![](https://storage.googleapis.com/papyrus_images/3a258e592001730be7381f94fae4ed01f5a536b92f8e74ffbcb488dbb7775bae.png)

用户想要进入Plasma链需要在以太坊主链上做资产的映射，而当其需要将Plasma链上的资产转移或主链上时，需要经历一段时间的挑战期来供其他人使用「 欺诈证明 」机制来确认资产转移的有效性。

「 欺诈证明 」意味着任何人在这段挑战期（通常是7天或者更久）内，都可以通过默克尔树校验的方式来提交证明用户资产的退出是不合法的。

### 2：问题

但这带来两个问题： （1）想要验证这个提款的正确性需要有节点保存Layer2上的交易和状态信息，因为Plasma只会提交其状态转移的结果，而想要提交欺诈证明必须有Layer2上的信息，这将大大提升 验证者 这一角色的成本。

（2）是所谓的 「 数据不可用」，他的意思是Plasma不会将其链上发生的交易数据发给主链进行存储，主链的节点无法获取到这些交易数据，无法通过主链本身的安全性为其做验证。当然有些解决方案会把这些数据提交到中心化存储或者IPFS上，但这对主链来说没有任何意义，因为用户使用Layer2的基础是信任主链本身的安全性。

三：Rollup
--------

我们可以看到Plasma一个很重要的问题是他的 “数据不可用”，主链只会收到Operator提交的状态转移结果，其只能期待有人存储了链下的的交易和状态信息，通过欺诈证明机制来确保子链的提交真实性，它在这个过程中只承担了确认者的角色，其安全级别是较差的。

### 1：具体理解“数据不可用”

以太坊将其链上发生的所有数据都公开，所有人都可以查询。但Plasma不会提交这些交易数据到主链上，而只提交执行结果，因此其效率上的提升是很高的，但是这样做的代价是Plasma无法建立和以太坊主链同一级别的信任。

Rollup实际上可以算是原始主链处理方式和Plasma方式的折中，其会将数据提交给主链，但他会最大限度通过聪明的编码方式压缩这些数据，同时基于Rollup本身的特性适当删除和缩减一部分数据，只要保证最终的提交能够供任何人验证即可。

交易数据上链后，任何人都可以根据这个数据来校验Rollup提交的结果是否正确。因此，Rollup的安全性要比Plasma高。

总结一下，Rollup的核心优势是所谓的“数据可用性”，它会将数据提交给主链，这大大加强了安全性。

那么究竟Rollup是如何实现的呢？

### 2：原理

（1）State Root

首先Rollup在主链上拥有一个(或者一系列相互关联的)合约：

![](https://storage.googleapis.com/papyrus_images/5b4cfd3e81efd0fb0ad355f98cdb35d13125fe07a19e13000212d86ff9d5a016.png)

这个合约用来维护Rollup层中的状态记录，这个状态记录实际上是一棵默克尔树的根节点存储的哈希值，这个哈希值被称为state root。

而这颗默克尔树的叶子节点是Rollup中的账户状态信息。如果你不知道什么是默克尔树，以下是一个简单的例子：

![](https://storage.googleapis.com/papyrus_images/479eac20a5615450ee5d7591595fa961ed42fc7c1576e6153ecd74d3361b2729.png)

可以看到这是一颗二叉树，在二叉树的叶子节点上记录着当前rollup层账户的状态信息。

对于每两个状态信息(例如State 1/State 2)，我们可以根据某种哈希公式计算出一个唯一的哈希值(eg: Hash(1,2) )来作为这两个叶子节点的父亲节点，依次一层一层往上类推，最终得到一个哈希值存储在根节点中：

你不需要知道怎样计算哈希值，你只需要记住几件事情。

1 任意一个叶子结点的改变都会导致根节点的值变化（任何一个状态的变化都会导致Root hash发生变化） 2 如果两棵树的根哈希值相同，那说明他们的叶子结点存储的信息完全一致（因此只需要对比两个根节点哈希值就可以确认底层状态信息的一致性） 3 根据根节点的哈希值和指向某一个状态信息的路径，我们可以确认某一个状态信息存在于这颗哈希树中。

（2）Batch

通过 state root 我们可以得出一个账户状态的key-value map：

其中key是账户地址，value则包含余额/Nonce/合约代码/存储（对于合约账户）等状态信息

![](https://storage.googleapis.com/papyrus_images/d1bbcba65bac3b5d08ffef6da58b1568e8c6c64b0d3a799d599b8e7ff0e858fd.png)

当rollup上发生交易的时候，很显然的，这些账户的状态会发生改变，由此产生新的state root。

虽然这样可以非常准确和及时的反馈Rollup上最新的状态变化，但是如果每发生一笔交易就在主链更新一次state root，产生的成本反而会比将这些交易在Layer1上执行更高。

所以为了解决这个问题，rollup中产生的交易将被按批次打包汇总，同时根据这批交易全部执行完成后的状态，会产生一个新的state root。无论是谁将交易打包提交给主链上的智能合约，他都需要计算这个新的state root，并将其和上一个state root以及交易数据一并提交。

![](https://storage.googleapis.com/papyrus_images/ccb9b9cfe41ea44e1e97edd39baba06d32fbd58fc2356f84a397de2904a9511c.png)

这一部分的打包被称为一个”batch”，提交者将batch提交给Rollup contract之后，主链会去验证新的state root是否正确，如果通过验证，则将state root更新为最新提交的state root，并最终完成一次rollup内的状态转移确认。

（3）Rollup的实质 以下是一个简化版本的Optimstic Rollup流程，可以看到和Plasma的最大的区别其实在于新增了交易数据的提交。

![](https://storage.googleapis.com/papyrus_images/a74ab05db4186bd8c289cac2a8a4e8b0a9badf8779c900c53fb8fe85e3d8a7e8.png)

所以，Rollup的实质是将一大笔实际产生的交易汇总成一笔主链上的交易，这些交易由Rollup链来执行和计算，但会将数据提交给主链，同时由主链扮演一个“最高法院法官”的角色最终确认这些交易。由此我们利用了主链的共识和安全性，同时提升了实际上的交易效率，降低了交易成本。

### 3：疑惑

看完以上的描述你可能会有一些问题，别担心，我们会一步一步进行推演和解释。

（1）如果提交全量交易数据，还是很难扩容吧？前文说的数据压缩是解决这个问题的嘛？怎么做的？

这两种技术方案能够做到扩容，核心都是交易的压缩和打包。这是因为以太坊的区块 gas limit 是有上限的, 压缩后的交易越小，一次能提交给主链的交易就越多。那么如何做到这一点呢？

以下是Vitalik在其文章中描述的一种压缩模式，作为例子帮我们理解

以太坊主链上一笔简单的交易（比如发送 ETH）通常消耗约 110 字节。然而，在 Rollup 上发送 ETH 可以缩减到约 12 字节。

![](https://storage.googleapis.com/papyrus_images/99bc8de244c56a78a966c846b0e404d95d5ad2584c4073b70c98a67157eceacd.png)

达到这样的压缩效果，一方面是采用了更简单高级编码，而目前 Ethereum 的 RLP 在每个值的长度上都浪费了 1 字节。另一方面，还有一些巧妙的压缩技巧：

Nonce：在 rollup 中可以完全省略 nonce

Gasprice：我们可以允许用户使用固定范围的 gasprices 进行支付，例如 2 的 16 次幂等

Gas：我们同样也可以将 gas 设置为 2 的多次幂。另外，我们也可以在 batch 层面设置 gas 限制。

To：可以通过默克尔树上的索引来标识地址

Value：我们可以用科学计数法存储 value。在大多数情况下，转账仅需 1 ～ 3 有效位。

Signature：我们可以使用 BLS 聚合签名，将多个签名整合为一个

这些压缩技巧是 rollup 扩容的关键，如果我们不对交易数据进行压缩，rollup 或许只能在主链的基础上的有大约 10 倍的提升效率，但有了这些压缩技巧，我们才能做到50倍 100倍甚至更高的压缩效率。

与此同时，为了节省gas，这些被压缩过的交易数据会被放入calldata参数中存储。著名的EIP-4488，提出calldata中每一字节数据gas消耗降低，就是为了进一步优化一笔主链交易能够承载的roll层交易数据量。对于具体的压缩效果，我们会在下面对于两种不同的ZK-Rollup进行对比时展示简单的数据。

（2）怎么来验证提交的可供验证的信息是正确的？ 既然最终的状态转换确认（也代表着交易的确认）由state root的更新决定，但是目前看起来Rollup上的提交者可以随意提交他想要的交易数据和state root，那么怎么来验证他提交的这些信息是正确的呢？

对于这一问题，大体上有两种解决方案，而根据解决方案的不同，rollup也被分成了两类：

### 4：Optimistic Rollup

正和它的名字一样，这种解决方案选择乐观的相信提交者提交的batch是正确的，除非有人通过一个欺诈证明来证明提交者是其实是一个坏蛋，他提交了一个错误的batch。 （1）以下是一个欺诈证明构建的简单例子（再次感谢Vitalik）： 提交一个欺诈证明来证明某个提交的batch是错误的，需要下图的绿色部分包括的信息：

提交者提交的batch

上一个state root代表的默克尔树（实际上代表了真实的账户状态信息）的一部分，根据这一部分能够构建完整的默克尔树

![](https://storage.googleapis.com/papyrus_images/83c8e3bacffb7a4a6d6a3fff9b215730a00ac8379b12e84ba37a94286751733e.png)

基于第二部分构建的默克尔树，我们模拟执行batch中提交的交易，从而得到了新的账户状态，得到新的默克尔树，得到新的state root。 将上一步得到的state root和batch中的state root进行比对从而验证batch中的是否正确

（2）验证过程 我们从逻辑上梳理了Optimstic确保state root真实性的过程，实际上，为了确保能够威慑提交者不作恶，提交者往往需要质押资金，当他的提交被验证为错误时，一部分质押资金将会被扣除作为惩罚。同时，提交了相应欺诈证明的验证者在某些解决方案中会得到被扣除的资金，以此来激励监测和提交欺诈证明的行为。

如果我们将OR和Plasma进行比对，我们会发现一些相似性，例如他们都使用了欺诈证明机制，需要有一个验证者的角色来监测OR给主链的提交。但由于OR同时向主链提交了交易数据，所以OR上的验证者不需要在自己去保存记录OR上的交易，作为对比，再将前文的简单架构图放在这里以供读者对比：

![](https://storage.googleapis.com/papyrus_images/a74ab05db4186bd8c289cac2a8a4e8b0a9badf8779c900c53fb8fe85e3d8a7e8.png)

5：ZK-Rollup

（1）Zk-rollup的核心

另一类解决方案是ZK Rollup，与OR（Optimistic Rollup）不同，ZK Rollup做了这样的根本假设：

不相信提交者能主动提交正确的batch，或者说类似法律学中的“有罪推定”。提交者在提交batch时除了交易数据以及post/previous state root 之外，还要携带一个ZK-SNARK证明。

ZK-SNARK本质上是一个“有效性证明”，他可以直接用来被验证所提交的batch是正确的。这个证明被提交到Rollup合约之后，任何人都可以使用它来验证Rollup层中特定批次的交易，而，这意味着rollup不再需要在提交后再等待7-14天来做验证。

（2）有效性证明和欺诈证明的区别

那么如何通俗的理解ZK-Rollup这样的“有效性证明”和Plasma/Optimsitic Rollup使用的“欺诈性证明”之间的区别呢？

首先这三种方案都需要有人来做Layer2上交易的排序，执行和打包，我们姑且称这个角色为“执行者”。

Plasma的执行者只会提交执行结果，秉承着其他人爱信不信的原则，你如果不信任我就需要发起挑战，而发起挑战需要你自己保存底层的交易数据。

OR也是一样，但是执行者在提交的同时会把交易数据也放上来，同样是爱信不信，你如果不信就自己根据这个交易数据去验证就完了。

但ZK不一样，ZK说我不想等你好几天让你来挑战我，那多浪费时间啊，我赶着确认我的交易呢。于是ZK直接在提交的时候生成一个证明，把这个证明也放上去，在提交的同时完成验证。

与此同时，Plasma/OR都需要通过质押的方式来确保执行者作恶是有损失的，而ZK不用，因为它不需要别人相信它，每次提交他都会自证清白。

除了这方面的区别外，另一个有意义的地方在于，ZK-SNARK可以让我们在不提交全部交易数据的情况下证明这批交易的有效性，这对于Rollup来说是很重要的，在下面我们会解释这一点。 （3）ZK-Rollup的实现逻辑

首先ZK-Rollup本质上还是一种Rollup解决方案，因此其仍然需要做以下两件事情：

打包压缩一个批次的交易数据 生成新的state root

唯一不同的是验证方式，ZK-Rollup不会等待验证者发起欺诈证明流程，而是直接生成一个ZK-SNARK 证明并添加到Batch里提交给主链rollup合约。

![](https://storage.googleapis.com/papyrus_images/27e5480039ef8c8878112486384f40b06f462f818e7e3d2828158a424f8e75ba.png)

如图示，提交的内容相比OR来说 增加了一个ZK-Proof，同时验证人这一角色被隐去了。

提交到rollup合约之后任何人都可以进行验证，验证成功后主链rollup合约会将State root更新为提交的最新数据。

（4）如何生成一个ZK-SNARK 有效性证明？

A 什么是ZK-SNARK？

ZK-SNARK的全称是“Zero-Knowledge Succinct Non-Interactive Argument of Knowledge.” 简洁非交互零知识证明。我会尽量解释其中每一部分的意思：

Succint（简明）：与实际证明的数据量相比，这种方法生成的证明要小很多。

例如我们要证明一系列交易确实存在并发生，所生成的证明数据量必须要小于这些交易本身的数据量。

Non-interactive (无交互): 在证明构建完成后，证明者只需要向验证者发一次简单的消息，而且通常情况下允许任何人无需许可的验证。

这对于ZK-Rollup或者区块链上的ZK应用是很重要的，因为有一些ZK证明需要证明人和验证人之间多次交互(猜颜色问题是一个典型的例子)，放在链上则意味着要发起多笔交易，这在成本上是不可容忍的。

Arguments：可以抵抗计算能力有限的证明者的攻击

这一部分意味着生成证明使用的加密算法复杂度在现有的算力条件下，无法以可接受的时间和经济成本被暴力破解。

of Knowledge：在不知晓要证明的是什么的情况下 不可能构建一个证明

这对于ZK-Rollup来说也是很重要的，因为我们不能允许有人能够根据非交易数据创建一个ZK Proof 提交给主链合约。

最后，也是最重要的”Zero-Knowledge“：

零知识意味着在证明人向验证者证明某个论断（Statement）时，不透露任何有用的或和所证明的实体本身有关的任何信息。

B 一个最简单的零知识证明例子是这样的

Alice想向Bob证明知道某个保险箱的密码，密码是打开保险箱的唯一方式，但她不想告诉Bob保险箱的密码，怎么办呢？

正好Bob知道保险箱里有一副Bob前女友写给他的情书，上面有Bob和前女友共同的指纹。

于是Alice背着Bob打开了保险箱，拿出了这封情书给了Bob。

由此证明了Alice知道保险箱的密码，同时Alice并没有告诉Bob密码是什么，成功！

C 如何为ZK-Rollup生成一个ZK-SNARK证明！

简要的说，生成一个ZK-SNARK证明分为以下几步：

确定问题在逻辑上的验证规则（例如检查balance，nonce是否符合要求等） 将逻辑上的验证规则转化为门电路Circle问题 将门电路Circle问题转化为R1CS(rank-1 constraint system，一阶约束系统)形式 将R1CS转化为QAP （Quadratic Arithmetic Program)

经过以上转换，我们就可以根据逻辑上的验证规则得到一组可通过固定验证方法验证的ZK-SNARK证明。具体的转换过程可以看这篇文章：

[https://mp.weixin.qq.com/s/M1ZAXPSPqO8KpE3VyExwTw](https://mp.weixin.qq.com/s/M1ZAXPSPqO8KpE3VyExwTw)

如果你觉得这一部分的复杂程度超过了之前的每一部分，你是对的。同样觉得复杂的还有目前的ZK-Rollup解决方案提供商，这也是为什么目前ZK-Rollup研发进度和实际应用要比Optimstic Rollup慢的原因之一。如果你不是数学/密码学专家，或者不是Matter Labs的开发者，你只需要知道以下几件事情：

生成一个ZK-SNARK证明比验证一棵默克尔树需要花费的算力和时间成本都要高很多 并不是随便一种语言，编译环境，虚拟机，指令集都能够无缝支持完成以上提到的过程，需要做额外的适配。

对于第一点，这是各大ZK解决方案提供商目前在努力的方向。首先是时间成本，如果生成一个可用的ZK-Proof需要一个小时，那么间接的用户提款的时间也会变长。而计算成本包括两部分，一部分是生成的ZK-Proof的数据量，另一部分是验证这个Proof所需要花费的算力。这两部分越大，在以太坊上需要消耗的Gas就越多，进而影响到ZK-Rollup的优化表现。

对于第二点，这是当前限制ZK-Rollup发展的一大原因。在EVM设计之初，开发者们完全没有想到之后会用到ZK技术。因此为EVM操作生成可用的零知识证明是几乎不可能的，由此催生了ZK-EVM的需求。

D 为什么兼容EVM对于ZK来说如此困难？

![](https://storage.googleapis.com/papyrus_images/bd6cee2284c4d70f19b4b6c4ba7b38bb3f4867fb23fcf0ee8f609c925ee22faf.png)

打开DeFillama，你会发现TVL排名前几的Layer2解决方案清一色的都是OR，这是因为这些OR解决方案都已经有了自己的网络，这些网络都做到了EVM兼容，开发者可以无缝的将以太坊上的智能合约移植到他们的网络上，用户也可以在其网络上做到swap，抵押，提供流动性等操作。

而ZK-Rollup目前还很难做到这一点，现有的很多解决方案只能够支持简单的支付和swap场景。

为什么如此呢，首先我们要明确一点，在 Layer 1 上，已部署智能合约的字节码都存储在以太坊 storage（存储项）内。然后交易将在点对点网络中传播，对于每一笔交易，每个全节点需要加载对应的字节码并在 EVM 上执行以获得相同的状态（交易将作为输入数据）。

而在 Layer 2 上，智能合约的字节码虽然同样存储在存储项内，用户的操作方式也相同。但是其交易将在链下发送至一个中心化的 zkEVM 节点，同时，zkEVM 不单需要执行字节码，还必须生成一个Proof来表明交易达成后状态已正确更新。最后，Layer 1 合约才能验证该证明并更新状态，而这时layer2上不需要重新执行交易。

也就是说在zk-Rollup上执行交易是完全不同的逻辑和路径，与此同时zkEVM还有在执行交易的同时适配生成zk电路证明，而现有的EVM生成ZK-SNARK证明有以下几个问题：

对ZK-SNARK所需要的部分椭圆曲线运算不支持 和传统虚拟机相比，EVM有许多独特的操作码，这些操作码对电路设计来说很困难 EVM 基于 256 位整数运行（就像大多数基于 32～64 位整数运行的普通虚拟机那样），零知识证明则 “天然” 基于素域运行。

这些也只是在EVM中生成ZK Proof的部分问题，而OR虽然同样需要构建虚拟机来执行EVM操作，但由于其只需要在执行交易的基础上在完成交易打包等功能即可，所以构建起来要简单的多。对于ZK-Rollup，除了在兼容EVM的同时生成ZK-Proof存在难度之外，在Layer1上验证这个证明也并不容易。

如果你想了解更多关于ZK-EVM难度的更多信息，可以看这篇文章：[https://hackmd.io/@yezhang/S1\_KMMbGt](https://hackmd.io/@yezhang/S1_KMMbGt)

看完以上内容，不可否认的是zk-Rollup的实现有很高的技术难度，那为什么我们不直接使用更“简单的”的Optimistic Rollup技术呢？

现在让我们对这两种Rollup技术做一个简单的对比。

### 6：Optimstic VS ZK

(1)效率优化（TPS/交易费用）

以下是特定以太坊环境下，目前市场上几种不同方案的费用和TPS对比： 来源：[https://w3hitchhiker.mirror.xyz/7dwD76ZZIlR7ep731K6y9vTTuXGHOojxWSnkXKzqPzI](https://w3hitchhiker.mirror.xyz/7dwD76ZZIlR7ep731K6y9vTTuXGHOojxWSnkXKzqPzI)

![](https://storage.googleapis.com/papyrus_images/e1ae06fb91c977697dfc30c400d544806d0b34b98566972ca6b4e30926a41fe9.png)

感谢@W3.Hitchhiker 团队的贡献！ 图上我们可以看到ZK方案要比OR方案的效率更高，为什么呢？

对于一个Rollup方案来说，最重要的是在一笔以太坊交易中能够携带多少Layer2上交易的数据，而这和两个参数有关：

Rollup压缩的一笔交易的Gas消耗 以太坊区块的max gas limit

其中Rollup可以解决的是第一点，虽然ZK-Rollup证明的存储和验证需要消耗一定的存储空间和gas(一个可信的数据是在500K 左右)。但是由于在交易压缩上做的更好，而交易数据的存储消耗是Gas消耗的绝大部分，所以ZK-Rollup要比OR效率优化表现更好。

另外提一句，你可能注意到表中ZKPort的TPS和交易成本优化最好，这主要由于其使用的Validium本质上是一种将欺诈证明替换为ZK Proof的 Plasma 方案，它不会提交交易数据，其效率完全是由Plasma链的处理效率决定的，但是安全性上同样面临着数据不可用的问题。

上面的计算假设gas price为30 Gwei，而我们都知道以太坊活动大幅上升时，gas price会达到什么样的水平。届时Rollup尤其是ZK方案的成本优化效果会更加明显。

(2)时间成本

我们之前说到过，因为欺诈证明机制，在Optimtisc Rollup上提款需要7-14天的提交期以供其他人来证伪潜在的作恶行为。

当然我们可以通过一些独立于Rollup机制本身的行为来减少提款期，类似Boba Network等Optimstic Rollup解决方案提出的流动性池机制。

让我们假设这样一个场景：

Alice是OR用户，在L2上拥有5ETH的资产。

在L1上又一个流动性池B，转为ALice这样的OR用户提供流动性。

现在Alice想从OR上取回所有资产，现在他和B做了一笔交易：

Alice可以从Bob这里直接拿走5ETH，同时支付一定的手续费

7天后Alice的资产被解锁，这时Alice拿走的5ETH回到池子里。

这对于流动性池来说有一定的风险，因此他可以通过监测OR合约，获取不诚实提交的罚金来对冲风险，同时收取的手续费也是降低风险的储备。

但是这种方式不适用于NFT，因为NFT不可分割，而且流动性池无法简单的复制一个NFT给用户。

而ZK-Rollup并不存在这一问题，提交者在提交时必须自证清白，提供可供验证的ZK-SNARK证明，目前的ZK-SNARK证明生成时间已经可以达到几分钟。用户只需要等待下一个batch提交并被验证即可。

时间成本是OR的硬伤，也是ZK-Rollup的显著优势之一。

(3)可适配性

Optimsitic和ZK 都面临着需要兼容适配复杂EVM合约调用操作的问题，但显然Optimstic实现起来更容易。

包括Arbiturm，Optimsim在内的OR解决方案都拥有EVM兼容的虚拟机，允许其能够处理在以太坊主链上发生的所有事务。一些OG级别的DeFi协议如Uniswap/Synthetix/Curve等也都已经在OR 网络上部署。

而构造兼容EVM的ZK-SNARK证明难度很大，以至于目前为止都没有能够公开使用的ZK-Rollup解决方案。不过我们在最近有一些好消息，zkSync 2.0公共测试网在二月底正式上线，这也是以太坊测试网上首个兼容 EVM 的 ZK Rollup。或许ZK Rollup的正式大规模实际使用要比我们想象的要快一些。

(4)安全性

这个问题的答案是显而易见的，OR 的安全性来自于经济学。为了能够良好的运转，OR必须设计合理的激励机制驱使一批主链上的验证人随时监测提交者，并准备提交欺诈证明。而对于提交者，其也需要通过质押等方式确保节点作恶会付出相应的代价。

而ZK的安全性来自于数学或者密码学，正如区块链中建立信任的一大基础：代码不会作恶一样。数学和密码学提供的保障要远比乐观的相信人性不会作恶来的稳。

当然，当前的Rollup机制本身也存在一定的安全问题，虽然rollup将数据提交到主链解决了数据可用性问题。但是我们还没有讨论过到底谁来负责交易的处理，排序，压缩，打包和提交。当前一些主流解决方案，如 Arbitrum、Optimism 和 StarkNet，使用一个叫sequencer的角色， 是它们自己运行的单个节点。这种方式带来的结果是高度的中心化。

我们知道去中心化是一切安全的前提，这种sequencer模式好处在于效率高，在rollup还在摸索阶段时可以进行快速的迭代，这些解决方案也声明了要在未来逐步进行sequencer的去中心化过程。例如使用PoS或dPoS方式进行sequencer节点的选举等，像Metis这样新的解决方案已经进行了一些探索。

(5)总结

让我们根据一个表格来具像化上面的讨论：

![](https://storage.googleapis.com/papyrus_images/ec3ccaaab3c5e6c541be9c87f1208f4e950bc8c42909d8b10b182aa40dd58ec0.png)

总体而言，OR在现阶段是更成熟的解决方案，事实上也是如此，目前Optimstic和Arbiturm的产品已经可供以太坊开发人员使用。但是由于使用欺诈证明机制，其提款时间和安全性目前来看值得商榷，同时其成本优化相比ZK也略逊一筹。

而ZK Rollup的弱点基本都属于技术问题，随着大量优秀的开发人员投入到相关研究，包括Vitalik在内的大多数人都认同ZK Rollup在未来会是更优秀的扩容方案。

### 7：Rollup是完美的吗？

经过以上对于三类Layer2方案的阐述，相信你已经对他们有了一定的认知。事实上文章撰写的顺序也是开发者们对于Layer2扩容方案研究的顺序，往往是发现某一种解决方案存在的问题之后，另一种更好的解决方案被提出用来解决相关问题。不仅在加密研究领域如此，这一流程可以被推及到所有工程类的问题上：

提出想法，测试，迭代，优化，直到找到最可行的解决方案。

现在看上去Rollup就是我们想找的那个答案，他解决了普适性的问题，解决了数据可用性的问题，同时在安全性和效率上看起来也不错。那么，它是完美无缺的那一个吗？

答案是否定的，任何方案都不能做到完美无缺，Rollup同样存在着许多问题，即使是看上去更好的ZK-rollup，也无法避免它们。

(1)效率优化存在天花板：

当我们说到rollup和plasma的主要区别时，我们谈到为了保证数据可用性。rollup需要将交易数据提交给主链，这是rollup方案战胜plasma的主要原因。

但我们要看到另一方面，交易上链意味着rollup仍会收到以太坊主链容量的限制: 简单算一笔账： 当前以太坊区块 max gas limit：12.5M gas 每字节存储在链上的数据成本：16 gas 每个块的最大字节数：~781,000 bytes (12500000/16) Rollup进行 一次ETH 转账所需的数据量：12 bytes（可见上节gas成本） 每个区块能承载的交易：~65,000（781,000 bytes/ 12 bytes） 以太坊的平均出块时间：13 秒 TPS：~5000（65,000 tx/13 s）

在这里我们做了很多的假设，例如我们假设所有交易都是简单的ETH转账。而实际的交易会包含很多的复杂合约调用，消耗的gas要更高。而且对于ZK-Rollup 我们还需要算上验证ZK-Proof的成本（一半在500K gas左右) 。

即使如此Rollup所能达到的TPS也只有5000左右，我们也在上面看到使用Plasma机制带来的直接效率优化要比Rollup高很多。

以太坊基金会也很清楚这个问题，目前它们主推的方案是分片+rollup，这将使得rollup带来的TPS提升再上一个数量级。

(2)流动性的割裂：

在当前多链格局的影响下，本身的流动性割裂情况已经日趋严重。

而由于目前多种技术方案，多家解决方案提供上的存在，未来的rollup网络的数量只会不断增长，由此带来了更严重的流动性割裂情况。

![](https://storage.googleapis.com/papyrus_images/bd6cee2284c4d70f19b4b6c4ba7b38bb3f4867fb23fcf0ee8f609c925ee22faf.png)

当前以太坊及其layer2网络TVL一览

好消息是跨链通信可以解决这一问题，代表性的事件是Synthetix已经在着手将其在以太坊主链和Optimism上的债务池进行合并。如果这一过程顺利且丝滑的完成，相信会对主链和子链上的流动性合并趋势有一定的推进。

毕竟合成资产项目的债务池模型远比目前更常见的流动性池模型复杂，可以预见Uniswap等主流DeFi项目延续这一进程。

(3)通信难题和技术障碍带来的可组合性降低：

上一个问题中我们谈到了通信问题使得流动性发生了割裂，这一现象同样适用于主链dapp和子链dapp之间的交互，在以太坊上构建的每个新协议都像乐高积木一样，其他协议可以轻松地在其上构建，这也是DeFi 发展迅速的原因之一。

如果无法解决通信问题，那么子链上的dapp需要重新建立自己的生态，这就造成了更大的资源浪费。不仅是子链和主链之间，子链和子链之间也需要构建通信机制。

Again，一些优秀的开发者也正在解决这方面的问题，让我们希望他们能够简化这些操作和流程。毕竟Layer1本身的操作已经够繁琐了，如果再加上layer2的复杂度，这将使Web3世界的门槛更高。

(4)中心化风险

我们在上文提到当前各类Rollup解决方案中，负责执行，排序，压缩和打包交易的sequencer目前都是一个较为中心化的角色。Rollup若想进一步的提升安全性，必须要着手解决当然的中心化问题。

三：总结
----

全文写完已经超过一万字，远远超出了我的预期。以太坊的扩容本身是一个很宏大，很复杂的主题。而本文中只涉及到了Layer2解决方案的一部分。Layer1的扩容解决方案（分片），以及其他Layer2方案如Side Chain，Validium 等都没有提及。事实上以太坊的扩容并不是某一个单一方案能够一劳永逸解决的。很多解决方案提供商也都在多条路径上进行着探索，像Polygon这样的公司更是投资了一大批不同类型的Layer2方案。

同时文中很多东西限于篇幅原因还有待挖掘，比如Layer2和Layer1之间的提交需要的通信支持是怎么样的。欺诈证明/有效性证明在Layer1上都是如何具体实现的，各家ZK/OR实现方案之间的具体区别等。理解这些事情对于想要深入了解Layer2尤其是Rollup扩容的研究者来说都是相当重要的。文章中的某些概念为了便于理解和梳理，我们做了比较笼统的概括，例如OR/ZK在交易数据压缩方面解决方案有很大的不同等，文中使用的vitalik的例子更偏向ZK的解决方案。在写作的过程当中我们也参考了一些优秀的Layer2内容，在文中和文末我们都做了标记，我们也希望有更多更优秀的内容能够出现，帮助大家进一步建立相关的认知。

最后，单就我们介绍的Rollup两种方案来看，Optimstic Rollup目前已经占据市场先机，上线可用产品的同时逐步吸引主流Dapp融入生态，不可否认相关开发者的伟大贡献。但是从长远来看ZK Rollup + 分片是我们更应该期待的未来。

参考： [1.An](http://1.An) Incomplete Guide to Rollups （Vitalik） [https://vitalik.ca/general/2021/01/05/rollup.html](https://vitalik.ca/general/2021/01/05/rollup.html)

2.W3hitchhiker 团队对四种Layer2解决方案的成本对比 [https://w3hitchhiker.mirror.xyz/7dwD76ZZIlR7ep731K6y9vTTuXGHOojxWSnkXKzqPzI](https://w3hitchhiker.mirror.xyz/7dwD76ZZIlR7ep731K6y9vTTuXGHOojxWSnkXKzqPzI)

1.  Scorll Tech 对于zkEVM实现的解读 [https://hackmd.io/@yezhang/S1\_KMMbGt](https://hackmd.io/@yezhang/S1_KMMbGt)

---

*Originally published on [Jackson Oar](https://paragraph.com/@jackson-oar/5QWAwCmMAQ3EWRbCfbVr)*