除了 ZK，另一个我们需要了解的概念是 Rollup，Rollup 的意义在于解决一层网络的拥
堵问题。
以 Ethereum 为例，它当前存在着交易拥堵的问题。解决这个问题有两种方法：一种是
增加区块链本身的交易能力，例如通过分片等技术来扩展区块链的吞吐量，详见菠菜菠
菜老师的研报《以太坊新分片方案 Danksharding 及 EIP-4844 万字研报：全新公链叙
事已来？白话解读「区块链不可能三角」的变革性解决方案 – Web3Caff Research》。
另一种方法是改变区块链的使用方式，即在二层（Layer2，以下称之为 L2）中执行大部
分活动，而不是直接在链上执行。在这种情况下，链上往往会部署一个智能合约，它只
负责处理存款和取款，并使用各种方法来读取链下数据，以验证链下发生的一切是否符
合规则。这相当于在小路旁架设高速公路，即通过 L2 扩容来解决拥堵问题。
当前，L2 扩容的三种主要类型或方案是 state-channels、Plasma 和 Rollup。它们是三
种不同的范式，各有优点和缺点。所有 L2 扩展大致都可以归为这三个类别（尽管命名
存在部分争议，例如 validium），详见 Darren 老师的研报《以太坊 Layer 2 赛道万字
研报：全景式拆解其扩容方案、技术原理、生态应用与未来挑战 – Web3Caff
Research》。其中，Rollup 具有自己的优势所在。
Rollup 和数据可用性
相比于其他扩容方案，Rollup 具有一定的优越性，其中一个比较直观的优势是解决了
Plasma 数据可用性的问题（Darren 老师文章 “ 数据可用性” 这个章节中曾提到 Rollup
能够取代 Plasma 的一大优势点就在于 Rollup 能够将交易数据也提交到以太坊主链，同
时保证这些数据的可用性）, 这里我也将做一定的补充。
数据在链上这一事实十分重要（注意：将数据 “放在 IPFS 上” 是行不通的，因为 IPFS 不
提供共识层面的验证，无法保证给定数据是否可用，即数据必须存储在区块中）。在
Plasma 以及之前的 Channel 这两种扩容方案中，数据和计算完全放到二层网络中，当
二层网络和以太坊进行交互时，二层链上所有交易数据并不包含在内，从状态机的视角
来看，也就是没有包含 Plasma 链每一次状态变更的情况。这会导致以太坊如果脱离了
Plasma 等的二层网络，就无法复原之前状态变更的情况，因此以太坊数据可用性非常
依赖对 Plasma 数据的保护。
Rollup 的机制
为了保证数据可用性，因此市场选择了 Rollup，那么 Rollup 具体是如何工作的？
在 Rollup 的设计中，主链上有一个 Rollup contract 的合约，其中保存了一个状态根
（state root）。可以把这个状态根看作是 Merkle Tree 的 Merkle 根的升级版，它存储
了账户余额（即状态的一种）、合约代码等信息，图 4 便展现了 Rollup contract 中存
储的状态根。
L2 节点主要有三个功能：首先确定哪些交易应该优先被打包（通常该类节点或客户端
被称为定序器 Sequencer），其次需要对每个打包的数据给出证明，最后提交给 L1 上
的 Rollup contract 由该合约进行验证。图 5 展现了 L2 中定序器的作用。
具体来说，L2 可以将一批数据（batch）传递给 L1，这些数据可以是高度压缩的交易集
合或合约运行后的状态变化情况，同时还包括 L1 合约中存储的状态根（state root）以
及经过 L2 处理数据后得到的新的后状态根（post-state root）。合约根据这些数据来验
证后状态根的正确性。一旦验证通过，该批数据就会在 L1 层确认，完成了从 L2 到 L1
的上链过程。
后状态根（post-state root）是根据原始数据计算得出的，为了确保提交的数据中的新
后状态根是正确的，最直接的方法是让 L1 重新计算一次。然而，这样做无疑会给 L1 带
来巨大的压力。为了解决这个关键问题，存在两种完全不同的优化方案，即 Optimistic
Rollup 和 ZK Rollup。
ZK Rollup 和 Optimistic Rollup
ZK Rollup 使用诸如 ZK-SNARKs 或 ZK-STARKs 等加密协议证明，通过这些证明来验证
执行该批次后状态根（post-state root）的正确性。不论 L2 的计算量有多大，ZK
Rollup 能够快速在 L1 上链上进行验证。
另一种证明方式是 Optimistic Rollup，它使用欺诈证明。这里有个形象的比喻，这就好
比妈妈不经常检查儿子的作业，但只要有一次作业没有完成，就会严厉惩罚。在这种机
制下，Rollup 合约跟踪状态根的完整历史和每个批次的哈希值。如果有人发现某个批次
的后状态根不正确，他们可以发布一个证明，证明该批次计算不正确。其他节点一起验
证该证明，并恢复该批次及其后续的所有批次。
下表（图 6）总结了 Optimistic Rollup 和 ZK Rollup 的优劣势对比。在这里需要注意的
是，ZK Rollup 在 TPS 方面表现出色，并且在退款周期方面具有显著优势。然而，它的
劣势在于 EVM 兼容性和 L2 层的计算消耗：
- Optimistic Rollup 项目，如 Optimism 和 Arbitrum，分别使用 OVM 和 AVM，它
们的虚拟环境与 EVM 基本相同，因此可以直接将 L1 层的合约迁移到 L2 上进行部
署。然而，在 ZK Rollup 中，将 ZK-SNARK 用于证明通用的 EVM 执行是相当困难
的，因为 EVM 并不是按照 ZK 证明计算的数学需求来开发的，所以需要改造某一
类的 EVM 客户端，以利用 ZK 技术来验证交易和合约运行。
- 同时，即使经过相应的转化，ZK 运算仍然需要大量的算力投入，因此在 L2 层的效
率上 ZK Rollup 不及 Optimistic Rollup。
- ZK Rollup 提供了比 Optimistic Rollup 更好的数据压缩功能，因此能够在 L1 上提
交更小的数据。
- 由于 ZK 中的证明验证过程更快捷，且具有更高的批处理密度，在 L1 层的计算消
耗上 ZK Rollup 较低。可以理解为 L2 上的节点付出大大减轻了对 L1 节点的要求，
从而显著提升了 L1 层的可扩展性。
ZK Rollup 还是 zkEVM Rollup？
虽然 ZK Rollup 看起来很有吸引力，但在实际部署中存在诸多困难。目前，ZK Rollup
仍然具有相当大的局限性，而 Optimistic Rollup 仍然是主流方案。大多数已实现的 ZK
Rollup 也都是为某些特定应用程序定制的。
如何理解定制化的 ZK Rollup？开发者为不同 DApp 构建专用电路（“ASIC”），如
Loopring、StarkEx rollup 和 zkSync 1.0，它们支持特定类型的支付、Token 交换或者是
NFT 铸造，然而，它们的电路设计需要高度的技术知识，这导致了开发者体验的不佳。
以特定类型的支付数据为例子，节点将交易数据提交给定序器，由定序器打包成 batch
交给提验证（proof）的节点作为公开的输入，证明过程和虚拟机上的合约执行过程无
关，ZK 只是负责将某个特定的执行结果的 rollup 计算、压缩过程进行进行证明。
而 zkEVM Rollup 又代表了将虚拟机运行结果 Rollup 的能力。当在 L2 层运行通用的智
能合约，需要证明合约运行前后状态转换的有效性时，便需要有一个虚拟环境能够支撑
ZK 算法的运行。因此，运行合约，输出最终状态，证明合约执行过程的有效性，并将
交易记录，账户记录，状态变化记录数据一同 rollup 提交，这便是 zkEVM 的意义。而
L1 层只需要快速验证证明，开销较小，无需再次运行合约，图 7 生动的说明了 zkVM
的作用。需要注意的是，zkEVM 其实是运行在 L2 层的类 EVM 虚拟机器，因此更为精
确的说法是 Zero Knowledge Virtual Machine，zkVM，只不过大家强调其兼容以太
坊而称之为 zkEVM。
现有项目也在考虑逐渐放弃了为特定应用程序做优化，而升级转向支持运行通用合约即
zkEVM Rollup。因此，zkEVM Rollup虽然作为 ZK Rollup的下位概念，在大部分情况
下，提起 ZK Rollup时便指 zkEVM rollup。
好的，今天就分享到这里了，感兴趣的朋友请关注我们！
微信1：victeam005
微信2：shijie20170405
Telegream：https://t.me/VICOINDAOCHAT