为了解决区块链 Layer 1 网络的扩容问题，Rollup 方案应运而生。结合 ZK 技术，ZK Rollup 成为 Layer 2 赛道的新宠儿。然而，对于大多数人来说，ZK、Rollup 和 EVM 等相关概念可能有一定的理解门槛。因此，本份研报的目标是以简明易懂的语言为你系统梳理 zkEVM Rollup 的一系列概念，深入分析 zkEVM Rollup 技术的演变和发展现状，并对其中的主要生态项目进行详细解读，以此旨在帮助你全面深入了解和判断 zkEVM Rollup 赛道发展趋势。
理解 ZK
ZK（或是 ZKP），全称 Zero-Knowledge Proof，即零知识证明，在密码学中，零知识证明或零知识协议是一种方法，通过该方法，一方（证明者）可以向另一方（验证者）证明一个事实，而无需透露该事实的具体信息，也就是说一方（证明者）无需透露任何该事实的「具体信息」，便能让对方知道这个事实是否正确，因此 ZK 技术能够在隐私保护领域为我们带来诸多想象空间。
当然，ZK 技术除了能够带来隐私保护的好处，在 ZK Rollup 中，ZK 技术更重要是解决「验证难」的问题。「验证」这个过程对于区块链非常重要，Ethereum 中绝大部分的计算过程都是为了满足验证的要求，而 ZK Rollup 能大大整个节点网络投入在验证中的时间。举例，如果一个区块需要很长时间来验证区块生成时是否满足整个网络的规则，那么可以有一个证明者初次验证它并生成有关这个区块计算结果的「证明」，剩下的其他人可以通过快速验证这个「证明」而不是计算量极大的原区块，而达到验证区块的目的。
一个简单的 ZK 协议分为以下几个步骤，生成密钥、证明和验证，接下来我将逐一为你拆解。
生成密钥，证明和验证
在 ZK 中，我们需要首先将待验证的问题转化为数学表达式，进而转化为多项式，并将其表示为算数电路的形式。当程序转换为算术电路时，它被分解为由加法、减法等基本算术运算组成的单个步骤。如一个将作为输出的函数，可以转化为以下电路图，见图 1。
图 1 一个电路图的示例，可以注意到在电路中所有的运算被拆分为最简单的基本运算| 图源 https://zhuanlan.zhihu.com/p/487866576
使用这个电路和一些随机数作为输入，我们可以生成一个证明密钥（pk，proving key）和验证密钥（vk，verification key），用于后续的验证过程，示意图见图 2。
图 2 「公共参数」的生成
我们的证明系统还需要两种类型的输入——私有输入和公开输入，与证明密钥一起生成证明。其中，私有输入（witness）是我们想要隐藏的秘密，而公开输入是可以公开的信息。例如，在等式 X+Y*Z=OUT 中，X 和 OUT 是公开输入，而 Y 和 Z 的值则是我们不想向验证者公开的。虽然根据公开输入可以推出 Y*Z 的值，但是 Y 和 Z 的具体取值仍然无法确定。
图 3 ZK-SNARKs 的证明过程和验证过程
当验证方接收到证明后，使用公开输入、证明和验证密钥来验证该证明，并返回验证结果（即是否验证成功）。
明白了上述流程之后，我们可以将这种技术运用到区块的验证当中，实现一个小小的 ZK-SNARK，见图 3。实现零知识证明的协议和方式有很多，SNARK 是相较比较容易理解的一种，也是现阶段多数项目的选择。在「从 ZK-SNARKs 到 ZK-STARKs」这个段落中我们会谈到 SNARK 的优势和不足。
尝试一个小小的 SNARK
我们以一个记录账户状态的 Merkle Tree 的零知识证明为例来练习。该 Merkle Tree 记录了账户的地址和余额。当有新的交易需要更新 Merkle Tree 时，我们需要执行以下操作：
1) 验证交易的发送方和接收方是否在树的叶子节点上。
2) 验证发送方的签名。
3) 更新发送方和接收方的余额。
4) 更新 Merkle Tree 的根节点（即 Merkle Root），并将其作为最终输出。
在没有零知识证明的情况下，验证者需要重复这些步骤来确保计算的准确性。但是使用零知识证明后，情况就不同了。首先，我们需要确定两种类型的输入：
在该过程中，只有新的交易信息、原 Merkle Root 和更新后的 Merkle Root 是公开输入。
Merkle Tree 本身作为 witness（见证），不需要被验证者读取或处理。
其次，我们需要生成密钥和计算电路。我们将 Merkle Tree 更新、输入输出地址验证等计算过程构建成计算电路，以获得证明密钥和验证密钥。该电路与输入的交易信息无关，也与现有的 Merkle Root 无关，因为 Merkle Tree 的计算方式是固定的。
在生成证明的阶段，我们将前后两个 Merkle Tree 和交易信息作为输入。在验证者阶段，验证者可以不需要获取到 Merkle Tree，也就是不了解账户信息的情况下，确保更新情况的可靠性。该电路类似于一个稳固的黑盒，只要输入正确，就能获得正确的输出。
使用零知识证明，其他验证者可以快速验证 Merkle Tree 的生成过程是可信的，从而减少了网络上重复验证的时间，同时 Merkle Tree 的信息无需向验证者披露。
从 ZK-SNARKs 到 ZK-STARKs
上述讲的证明协议是 ZK-SNARKs。SNARK 代表 succinct non-interactive arguments of knowledge，其中 succinct 指的是这种方式的简洁性，non-interactive 指的是相对于其他证明方式，SNARKs 是非交互性质的证明，即验证者只需使用由证明者生成的 proof 即可获得验证结果。但是，ZK-SNARKs 存在一些问题。在密钥生成阶段，电路和随机数相当于一组初始的公共参数，这个公共参数的生成过程存在不可避免的中心化问题。
ZK-STARKs 在 SNARK 的基础上另辟蹊径，其中的「s」代表可扩展的，其证明生成时间和原始计算的耗时呈拟线性关系，而验证耗时和原始计算呈对数关系，这意味着在大量数据集作为数据的情况下，验证者所需的验证时间被大大缩短。
同时，作为 ZK-SNARKs 的升级版，ZK-STARKs 不仅仅可以提高验证效率（理论效率为 10 倍），而且不依赖椭圆曲线或可信设置，并且不需要生成初始公共参数的过程（字母「T」代表透明性），这消除了对可信设置的中心化需求。一些开发者认为，ZK-STARK 中的哈希函数有助于抵御量子攻击。
然而，ZK-STARKs 的推出时间较晚，目前技术还不够成熟，并且依赖哈希函数，这限制了它的通用性，ZK-SNARKs 仍然是通用的证明算法。基于 STARK 的算法的一些示例包括 Fractal、SuperSonic 等，相关项目方有 StarkWare、Polygon Miden 等。
理解 Rollup
除了 ZK，另一个我们需要了解的概念是 Rollup，Rollup 的意义在于解决一层网络的拥堵问题。
以 Ethereum 为例，它当前存在着交易拥堵的问题。解决这个问题有两种方法：一种是增加区块链本身的交易能力，例如通过分片等技术来扩展区块链的吞吐量。另一种方法是改变区块链的使用方式，即在二层（Layer2，下称 L2）中执行大部分活动，而不是直接在链上执行。在这种情况下，链上往往会部署一个智能合约，它只负责处理存款和取款，并使用各种方法来读取链下数据，以验证链下发生的一切是否符合规则。这相当于在小路旁架设高速公路，即通过 L2 扩容来解决拥堵问题。
当前，L2 扩容的三种主要类型或方案是 state-channels、Plasma 和 Rollup。它们是三种不同的范式，各有优点和缺点。所有 L2 扩展大致都可以归为这三个类别（尽管命名存在部分争议，例如 validium），其中，Rollup 具有自己的优势所在。
Rollup 和数据可用性
相比于其他扩容方案，Rollup 具有一定的优越性，其中一个比较直观的优势是解决了 Plasma 数据可用性的问题（Darren 老师文章「数据可用性」这个章节中曾提到）,这里我也将做一定的补充。
数据在链上这一事实十分重要（注意：将数据「放在 IPFS 上」是行不通的，因为 IPFS 不提供共识层面的验证，无法保证给定数据是否可用，即数据必须存储在区块中）。在 Plasma 以及之前的 Channel 这两种扩容方案中，数据和计算完全放到二层网络中，当二层网络和以太坊进行交互时，二层链上所有交易数据并不包含在内，从状态机的视角来看，也就是没有包含 Plasma 链每一次状态变更的情况。这会导致以太坊如果脱离了 Plasma 等的二层网络，就无法复原之前状态变更的情况，因此以太坊数据可用性非常依赖对 Plasma 数据的保护。
Rollup 的机制
为了保证数据可用性，因此市场选择了 Rollup，那么 Rollup 具体是如何工作的？
图 4 L1 合约中的 State Root | 图源 https://vitalik.ca/general/2021/01/05/rollup.html
在 Rollup 的设计中，主链上有一个 Rollup contract 的合约，其中保存了一个状态根（state root）。可以把这个状态根看作是 Merkle Tree 的 Merkle 根的升级版，它存储了账户余额（即状态的一种）、合约代码等信息，图 4展现了 Rollup contract 中存储的状态根。
L2 节点主要有三个功能：首先确定哪些交易应该优先被打包（通常该类节点或客户端被称为定序器 Sequencer），其次需要对每个打包的数据给出证明，最后提交给 L1 上的 Rollup contract 由该合约进行验证。图 5展现了 L2 中定序器的作用。
图 5 定序，证明和提交 Batch 是 L2 阶段的主要功能 |图源 https://foresightnews.pro/article/detail/20517
具体来说，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 层的计算消耗：
1) Optimistic Rollup 项目，如 Optimism 和 Arbitrum，分别使用 OVM 和 AVM，它们的虚拟环境与 EVM 基本相同，因此可以直接将 L1 层的合约迁移到 L2 上进行部署。然而，在 ZK Rollup 中，将 ZK-SNARK 用于证明通用的 EVM 执行是相当困难的，因为 EVM 并不是按照 ZK 证明计算的数学需求来开发的，所以需要改造某一类的 EVM 客户端，以利用 ZK 技术来验证交易和合约运行。
2) 同时，即使经过相应的转化，ZK 运算仍然需要大量的算力投入，因此在 L2 层的效率上 ZK Rollup 不及 Optimistic Rollup。
3) ZK Rollup 提供了比 Optimistic Rollup 更好的数据压缩功能，因此能够在 L1 上提交更小的数据。
4) 由于 ZK 中的证明验证过程更快捷，且具有更高的批处理密度，在 L1 层的计算消耗上 ZK Rollup 较低。可以理解为 L2 上的节点付出大大减轻了对 L1 节点的要求，从而显著提升了 L1 层的可扩展性。
图 6 两种 rollup 方式的比较 | 图源：https://tokeninsight.medium.com/zksync-vs-starkware-whats-the-difference-between-the-top-two-zk-rollup-66d1a7d08ef3
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。
图 7 一图说明 zkVM | 图源 https://mp.weixin.qq.com/s/i9O0vpHnkHFwVBPjNeqMUQ
现有项目也在考虑逐渐放弃了为特定应用程序做优化，而升级转向支持运行通用合约即 zkEVM Rollup。因此，zkEVM Rollup 虽然作为 ZK Rollup 的下位概念，在大部分情况下，提起 ZK Rollup 时便指 zkEVM rollup。
理解 zkEVM
我们为了理解 zkEVM（也可以认为是 zkVM）,便必须对 EVM 的概念有一个初步的理解，从而才能明白当前 zkEVM 的局限性。
从 EVM 到 zkEVM
还记得 Ethereum 社区经典的表述，EVM 由数千台运行以太坊客户端，相互连接的计算机（节点）共同维护。以太坊协议本身的存在仅仅是为了保持这个独一无二的状态机的连续地、不间断地和不可变地运行。EVM 规定着如何在区块不断更迭的过程中去定义那个「标准」的状态。EVM 的行为更像一个数学函数：给定一个旧的有效状态和一组新的有效交易 T，以太坊状态转换函数产生一个新的有效状态。在这个图灵完备的状态记上可以运行任何代码。
EVM 按照一定的规则执行交易。首先，EVM 将人类可读的编程语言（如 Solidity 和 Move）编译为面向机器的 16 进制的「低级」语言，称为 EVM 字节码（bytecode），最终按照操作码（Opcode）解析为顺序指令列表。
所以 zkEVM 是一个至少在编程语言层面兼容 EVM 的 zkVM。EVM 的设计存在一定的局限性，与本份研报相关的是，EVM 无法与 ZK 相应的协议兼容，需要对原有 EVM 进行一定的改造，这种改造是颇具有挑战性的：
1. EVM 对椭圆曲线的支持有限。
2. EVM 基于 256 位整数运行（就像大多数基于 32～64 位整数运行的普通虚拟机那样），零知识证明则「天然」基于素域运行。
3. 第三，EVM 不同于传统虚拟机,有许多特殊的操作码。
4. 第四，EVM 是基于堆栈的虚拟机而不是更高级别的零知识证明友好型 IR（Intermediate Representation，即中间表示。这是一种计算机程序编译过程中源代码和目标代码之间的中间状态）。
zkEVM 兼容性：三种类型
在 Vitalik 的文章中对于改造程度和 EVM 兼容程度做了四个层面的划分，本文对其做更为明晰的理解。
类型一，高级语言编译等效：最低层级的「兼容」便是将流行的高级语言编译为 ZK-SNARK 友好型语言。此时底层环境和虚拟机特性是完全不同于 EVM 的 zkVM，最为直接的体现是在字节码层面和 EVM 不兼容，开发者无法直接复制、修改 EVM bytecode，且可能 VM 内部脱离以太坊的技术支持，缺乏一定的 ERC 标准，无法与 EVM 保持同步的安全性。
类型二，EVM 等效：zkEVM 和 EVM 在字节码层兼容但在共识层不兼容，其将大部分 EVM opcode 转化为电路。这个类型涵盖现阶段项目范围最广，在 Vitalik 的 Blog 中细分为三种类型，主要在 gas fee（满足 ZK 协议复杂的操作），部分操作码兼容性，哈希函数类型，少量的区块、交易树、状态树结构，证明时间等方面有一定的差异性。这些不同方面的不兼容会导致较高的证明 / 验证开销、较低的效率，或是对开发者合约部署、运行的有限的影响，但是和类型一类型三之间有本质性的区别。由于现阶段处于 zkEVM 项目爆发期，项目迭代快，同时很难具体评估技术细节不同而导致的等效层级不同，因此笔者认为只需要关注项目和项目之间的技术大致差异性，而无需强求类型的限定。
类型三，Ethereum 等效：zkEVM 和 EVM 在共识层兼容，此时 zkEVM 在一定程度上可以完全融入 L1，作为等效的 p2p 节点进行协议通信，zkVM 和 EVM 可以等效。此时 zkEVM 在 L1 层便可以进行多个交易的证明，以加快其他节点区块的验证，这意味着 L1 层自身的扩容，无需围绕 zkEVM 构建 L2。该类 EVM 效率极低，仍处于「研究」领域，且大规模的部署可视作以太坊的升级。类似的存在另一种极端情况，公链运行 zkVM，L1 证明本身数据而抛弃 Ethereum 原有架构，以此减少生成证明时间。
在笔者看来，所谓兼容性，是在有限的 ZK 协议证明能力，网络协议设计难度，网络算力下，运行效率、投入计算量和开发适配性的一个取舍。
运行效率针对链上用户而言，最为直观体现是交易速度，有关 L1 上验证者效率，L2 上证明者效率，zkEVM 硬件加速程度等；
投入计算量体现 L1、L2 层网络的 gas fee；
在而开发适配性则从合约开发者角度，考虑合约兼容程度和基础设施通用性等，和特殊操作码，部分 ERC 协议是否适配等有关。
类型一的 zkVM 完全实现一个 ZK 友好型 VM，在性能方面具有优势，但 DApp 开发者有相当高的迁移成本，同时无法同步以太坊的最新特性和安全性。而在类型二中，往往证明者证明速度（满足电路转化的要求）、计算量和基础设施通用程度（满足以太坊的要求）呈负相关。
当前 ZK 赛道梳理
围绕着上文提到的 zkEVM 不同等效程度的优劣势，ZK 细分赛道也逐渐火热，主要有以下几个方面：
1. ZK 以太坊兼容 / 电路编译：解决的是最为核心的 EVM 兼容性问题，也是赛场的主角，各类其他生态围绕其展开。
2. ZK 公链，如 Manta Network 等，抛弃 Ethereum，建立新的 zkVM，重视 L1 层扩容问题的同时关注数据隐私问题。
3. ZK 跨链桥 / 预言机：ZK 赛道的基础设施，在多条 zkEVM Rollup 的 L2 之间进行资产迁移或是获取链下数据。
4. ZK 硬件加速：ZK 赛道的基础设施，解决生存证明计算量大问题。目前 ZK 硬件加速主要来自 GPU，预计需要到 2023 年年底之后，才能够出现支持 zkEVM 证明的专用硬件（ASIC），以及相对成熟可用的产品。
5. ZK 工具类：根据兼容程度提供不同的开发工具。
6. ZK 应用：与本文关联较小，更多的聚焦在 ZK 隐私性的优势上。
zkEVM Rollup 项目概览
2023 年上半年各类 zkEVM 项目喷井式而出，笔者在关注这些项目的时候主要关注以下方面：
1. 当前项目进展：包括当前项目阶段，以及测试网、主网预计上线时间，是否和发展路线图有一致性。
2. 项目实际交互情况：通过与测试（主）网的交互等，主观感受网络 TPS，单笔交易确认时间等，对网络性能有直观感受。
3. zkEVM 兼容性：这是最为核心的技术点也是最难评判的，即便部分项目开源，在 VM 层面的技术最为硬核，且涉及到较多的 ZK 协议。具体的，需要关注 ZK 协议、VM 安全性、兼容程度等。
4. zkEVM Rollup 架构：相对于 zkEVM，一般项目都会在白皮书等技术文档中公开其 Rollup 架构，且总体差异性较少，但是要关注其整体去中心化程度。
5. 生态运营：项目用户数量、活跃程度、链上应用生态的运营和孵化情况以及开发者社区的维护等软性反应项目运营的情况的指标。
6. 投融资情况。
本文更多的从前四点角度来对项目进行考量，更多地从技术层面关注 zkEVM Rollup 的整体架构。
Scroll
Scroll 团队创立于 2021 年，致力于开发 EVM 等效的 ZK Rollup 用于扩展以太坊，近两年来，Scroll 一直致力于与 Privacy and Scaling Explorations 团队以及其他开源贡献者一起公开构建与字节码兼容的 zkEVM。2 月底 Scroll 宣布其 Alpha 测试网现已在 Goerli 上线，任何用户无需许可都能够参与技术测试，测试网平均出块时间为 3 秒，现已经有 2 千多万笔交易，150 多万的区块和 400 万余的交互地址。同时 Scroll 也于 4 月 11 日开放了网站生态系统界面。
从近期信息披露来看，Scroll 在类型二 EVM 等效的道路上不断向前。近期，Scroll 已经完成了所有 EVM 操作码的兼容开发工作，正在进行审计工作，同时下个目标是兼容 EIP2718 交易。
技术架构上，Scroll 的架构较为传统,因此在这里详细介绍。如图 8，主要分为两个部分：核心部分是 zkEVM，用于证明 EVM 在 L2 执行的正确性；但是要将 zkEVM 变成以太坊上完整的 ZK Rollup，还需要围绕 zkEVM 构建一个完整的 L2 架构。具体的，现有的 Scroll Alpha testnet 由 Scroll Node、Bridge Contract 和 Rollup Contract 组成：
图 8 Scroll rollup 整体架构 | 来源 https://scroll.io/blog/architecture
1. Scroll Node：由 Sequencer、Relayer 和 Coordinator 组成。
a) Sequencer，也就是所谓的定序器，向用户和应用开放 JSON-RPC，读取交易池中的交易并生成 L2 的区块和状态根。现阶段 Scroll 的 Sequencer 节点是中心化的，在之后的升级中会逐渐去中心化。
b) Coordinator 负责在 Roller 和 Scroll Node 之间进行通讯，当有新的区块在 Sequencer 中生成的时候，随机选择池中的 Roller 进行证明生成。
c) Relayer 监测 Ethereum 和 Scroll 链上的 Bridge Contract 和 Rollup Contract。Rollup Contract 保证 L2 数据在 L1 层面的数据可用性，确保在 L1 层可以恢复 L2 区块，一旦 L2 层提交的区块经过 L1 层上 Rollup Contract 的有效性验证，那么该区块在 L2 才达成终局性的不可更改的状态。Bridge Contract 在跨链时负责在双链合约之间通信，双向发送任意消息或是完成跨链时资产质押和提取操作。
图 9 2. Roller Network | 来源 https://scroll.io/blog/architecture
1. Roller Network：Roller 内置 zkEVM，在网络中充当证明者，负责为 ZK Rollup 生成有效性证明，见图 9。
a) Roller 首先将从 Coordinator 接收到的 execution trace（也就是合约具体做了哪些操作，涉及哪些地址）转换为电路的 witnesses。
b) 它为每个 zkEVM 电路生成证明，最后聚合这些来自多个 ZK 电路的证明。
StarkWare
StarkWare 提供了一种基于 STARK 的扩展解决方案，以确保 L2 的安全性、快速性和无缝用户体验。他们支持多种数据可用性模式。StarkNet 是他们的 L2 网络，而 StarkEx 则是面向企业用户的 Rollup 验证服务，DApp 可以构建在 StarkEx 服务之上。然而，目前只能针对特定的 DApp 进行定制化的电路编写，而不是通用的 zkEVM Rollup。StarkEx 支持一系列即插即用的服务，包括 NFT 铸造和交易、衍生品交易等。在生态方面，去中心化期货合约交易平台 DYDX 是 StarkWare 的忠实用户。
StarkNet，严格来讲是 zkVM，它没有针对以太坊操作码做 ZK 电路，而是自己做了一套更加 ZK 友好的汇编语言、AIR（代数中间表示）以及高级语言 Cairo。尽管 StarkNet 本身不兼容 EVM，但仍然可以通过包括 Kakarot（Kakarot 是一个用 Cairo 写的 zkEVM，是一个字节码等效 EVM 的 zkEVM）等其他方式兼容以太坊。根据个人理解，StarkNet 相对来说还是一个中心化的项目，其中一点是其无法随着以太坊的安全性升级而同步，因此需要集中研发人员补足安全性上的短板，并跟随 ETH 开发适配新的协议。
StarkNet 使用的 STARK 作为其证明系统，相对于 SNARK，STARK 具有更多创新。它不需要和 SNARK 那样依赖「可信设置」。并且，它还带有更简单的密码学假设，避免了对椭圆曲线、配对和指数知识假设的需要，纯粹依赖哈希和信息论，因此更能抵御量子攻击。总体而言，STARK 比 SNARK 更安全。在拓展能力方面，STARK 边际效应显著，证明越大，总成本越低。
然而，在架构方面，目前系统中只有一个 Sequencer（定序器），由 StarkWare 控制，并且只有一个 Prover（也就是生成 ZK Proof 的证明者），它不仅为 StarkNet 生成证明，还为运行在他们自己的 StarkEx rollup 上的所有其他应用程序生成证明。
ZK Rollup 的变体：Validiums 和 Volitions
Validium 也是一种 L2 级别扩展解决方案，它使用诸如 ZK Rollup 之类的计算证明来强制执行交易过程的完整性。和 ZK Rollup 不同的是，Validium 不会将交易数据存储在以太坊主网上。牺牲链上数据可用性是一种权衡取舍，它可以带来可扩展性的巨大改进，最直接的点便是 Validiums 每秒可以处理约 9000 笔交易。
但是在笔者眼中 Validium 不能算严格的 ZK Rollup。这个方案和 Plasma 类似，都没有做到 L1 层的数据可用性，因此都不能算作 Rollup。和 Plasma 的区别在于 Plasma 在 L2 层中设置了类似于 OP Rollup 的「七天退出机制」，而 Validium 利用了和 ZK 手段来缩短 L2 层对数据的验证时间且不把数据同步到 L1 中。
Volition 由 StarkWare 率先推出，可让用户轻松地在 ZK Rollup 和 Validium 之间切换。例如一些应用程序，比如去中心化衍生品交易所可能更适合 Validium，同时仍希望与 ZK Rollup 上的应用程序可互操作，那么 Volition 便提供了这种可切换性。
zkSync
与 StarkNet 类似，zkSync 一直坚持选择高级语言等效的 zkVM，并且备受瞩目，拥有相当高的热度和锁仓量。zkSync 1.0（zkSync Lite）于 2020 年 6 月 15 日在以太坊主网上启动，实现了约 300 TPS 的交易吞吐量，但不兼容 EVM。而 zkSync 2.0（zkSync Era）于 2023 年 3 月 24 日启动。
zkSync Era 的目标是通过使用他们自定义的 VM 进行优化，而不是追求 EVM 等效性，从而更快地生成证明。它通过强大的 LLVM 编译器支持 Solidity、Vyper、Yul 和 Zinc（rollup 的内部编程语言），以此来实现大部分智能合约功能。由于采用了自研 VM，zkSync Era 支持原生账号抽象，使得任何账户都可以用任何 Token 支付费用。
此外，通过 zkPorter 协议的应用，结合了 ZK Rollups 和分片技术，网络吞吐量得到了指数级增长，达到 20,000+ TPS（类似于 Volitions 的数据可用性切换）。
总体而言，zkSync 是一个生态丰富的 L2 项目，备受开发者和投资者关注。尽管近期出现了一些 zkSync 上彻底失败的项目案例，但仍然存在一个问题，即开发者是否能在高级语言等效的 zkVM 上获得良好的开发和迁移体验。目前缺乏开发者层面的确切使用报告，如果开发者有良好的体验，那么其他类型的努力贴近 EVM 的 zkVM 又有何意义呢？我们还需要更多时间来观察。
Polygon zkEVM
Polygon 于 3 月 27 日启动 zkEVM Rollup 主网络的 Beta 版，也是以太坊等效的虚拟机，并开源所有 zkEVM 代码。相较于 zkSync，polygon zkEVM 的锁仓量就小很多，但是在生态中也有很多比较有趣且有活力的项目。
在 Rollup 设计方面，Polygon 与 Scroll 不同之处在于使用了效率证明（PoE）模型来激励排序器（Sequencer）和聚合器（Aggregator），以解决去中心化和无许可验证器的一些挑战。在无需许可的排序器 – 聚合器两步模型中，任何排序器都可以提出打包批次的申请，以获得打包费用，但需要支付 L1 层的 Gas 费用并存入一定数量的 Token；同时，聚合器需要设定自己的目标，以最大化保证每次证明生成的利润。此外，Polygon 与 Volition（ZK Rollup 和 Validium）模式还具有深度兼容的数据可用性模型，来为用户提供不同层次的服务。
另外，Polygon 在 ZK 协议方面也投入了相当的工作量，效果也是显著的，在文档中他们总结自己的技术优势，主要包括以下几点：
1) 更加兼容：Polygon 始终坚持采用 EVM 等效的 zkVM，以降低开发者迁移 dApp 的成本。同时，尽管 Polygon Miden 采用了 ZK-STARK 协议，但仍支持运行 Solidity 合约。
2) 更容易的验证：ZK Rollup 经常受到批评的原因是生成有效性证明需要昂贵的专用硬件，厂商运行这些硬件并将成本转嫁给用户。Polygon ZK Rollup（如 Polygon Zero）旨在简化证明方案，使得更低级的设备可以参与其中，例如，在消费级 PC 上进行的 Plonky2 证明生成测试。
3) 更快的证明生成和验证过程：Polygon Zero 可以在 170 毫秒内生成一个 45kb 的证明。
理论技术和现实项目之鸿沟
本份研报主要进行了 ZK 技术的科普，Rollup 机制的介绍，重点强调了数据可用性的重要性，并在 ZK 还是 zkEVM Rollup 的问题上做了一定的界别。此外，在区分 zkVM 和 zkEVM 的基础上，同时还详细梳理了 zkEVM 三种类型的区别以及围绕着不同类型以及相关的 ZK 赛道。最后，结合几名优势项目，对各自的技术框架、现有生态等进行了回顾。
然而，在具体项目方面，选择高级语言等效的项目反而占据市场主流地位，部分 StarkWare 这类中心化较为严重的产品也能博得市场的青睐。即便在理论研究中谈到的第一类 VM 有很强的局限性，但是在有限的市场客户下，「通用性」似乎是一种累赘，我们无法分辨出「高效拓展」突破了哪些问题并实现了超越理论的效果。当然实际上很多人也不关注技术特征，因此这显得不太 Web3，又很 Web3。
Rollup 技术的目的是进一步挖掘区块链的价值，但往往因为迫切成为市场上的「创新性概念」，而产生「开倒车」的现象，回归到中心化。这是当前市场存在的问题。
区块链的价值很容易被看到，谁不希望拥有一个永恒的计算机？但核心问题是，当这台计算机的运行能力远远低于我们身边任何一台服务器，并需要大量资源投入时，即使使用价值远低于我们的投入成本，作为一个「公共产品」，它还能吸引每个人加入使用吗？
当我们已经拥有了相当多国家、社会甚至个人的产品时，在什么情况下，我们愿意忽视高昂的使用成本，追求「永远在线，永远正确」的结果呢？我认为这是当今区块链行业需要思考的问题。Rollup 技术在技术上可以改善这个问题，但还有一大部分问题需要留给浮躁的市场去解决。
（声明：请读者严格遵守所在地法律法规，本文不代表任何投资建议）
