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