每种 ZK Rollup 的 zkEVM 是在诸多性能中有所取舍,实际并没有绝对的优劣之分。
撰文:0x1
以太坊的发展路线越来越倾向于 Modular Blockchain,其本质就是 Layer1 的 data sharding 和 Layer2 的 Rollups 扩容相结合,成为一种模块化架构,从而推动以太坊实现。
ZK Rollup 的核心工作机制是将链上的用户状态压缩存储在一棵 Merkle 树中,并将用户状态的变更转移到链下进行,同时通过 zksnark/zkstark 证明来保证该链下用户状态变更过程的正确性。通俗地理解,ZK Rollup 可以理解为通过 zksnark 或 zkstark 来使用亚线性处理以验证线性数量的语句。比如,1000 条语句需要 10 次验证者检查,10000 条语句需要 11 次验证者检查。所以,呈现出来的结果是,ZK rollup 可以实现以太坊扩容。
ZK Rollup 的大致区块链事务处理过程如下:
众所周知,第一代的 ZK Rollups 是不支持 EVM 的,可编程性和可组合性较差,只能限定在一些特定的场景,比如:Loopring 只能限定在 Payments&Swaps 等场景;Immutable 只能限定在 NFT Minting&Trading&Games 等场景;zksync1.0 其实也不支持 zkEVM。不具有通用性。
后来,头部的那些 ZK Rollups 开始探索,在 ZK Rollup 上研发支持 EVM 字节码的代码执行环境,从而使得以太坊上的智能合约可以从以太坊迁移到 ZK Rollup 上,而无需从头开始编写代码。
EVM 是第一个图灵完备的区块链虚拟机,于 2015 年发布。它是迄今为止最久经考验的区块链虚拟机,也是以太坊非常重要的智能合约基础设施。甚至在谈到其他区块链时,也会将 EVM 兼容与否作为一个评判维度,因为 EVM 兼容的背后代表的不仅仅是智能合约执行环境,也代表着可用的以太坊生态和工具集,更代表着不可忽视的网络效应。所以,ZK Rollups 也没敢忽略这一块儿。
zkEVM 则可以理解为将 EVM 作为智能合约引擎运行在 ZK Rollup 中。zkEVM 的目标是在不失去 Rollup 性能优势的基础上,将以太坊体验完全带入到 L2。
截至目前,zkSync2.0、Polygon Hermez2.0、Scroll 等头部的通用 ZK Rollup 项目都已经先后推出了 zkEVM 测试网,StarkNet 则已经进入到了 Alpha Mainnet 阶段。
当前的 ZK Rollups 的 zkEVM 与 Ethereum 本身并非完全兼容,更遑论“以太坊等效”的终极愿景。所以,不仅以太坊本身的升级规划在迁就 Rollup 友好型,各个 ZK Rollup 项目也一直在解决与以太坊的兼容性问题。
Vitalik 根据与现有 EVM 基础设施的兼容性程度,将 zkEVM 通用 ZK Rollup 分为 4 类:
Type-1 型 zkEVM 力求完全且毫不妥协地与以太坊等效。无需改变以太坊系统的任何部分,无需取代哈希、状态树、事务树、预编译或任何其他共识逻辑。简而言之,Type-1 型的 zkEVM 完全等效于 Ethereum。
Type-1 型 zkEVM 能够像以太坊一样验证以太坊区块,或者至少验证执行层端(包括所有交易执行、智能合约和账户逻辑,不包括信标链共识逻辑)。
Type-1 型 zkEVM 是以太坊最终需要的,也是 Rollups 的最理想选择。一方面,Type-1 型 zkEVM 可以让 Rollups 重用大量的基础设施(例如:Ethereum Execution Clients、Block Explorers、Block Production 等);另一方面,Type-1 型 zkEVM 能使得以太坊 Layer1 本身更具可扩展性,因为在 Type-1 型 zkEVM 上探索的一些对以太坊的修改,也许未来会被引入到 Ethereum 本身。
当然,Type-1 型 zkEVM 也有缺陷。以太坊最初并非围绕 ZK 友好型设计的,因此以太坊协议的许多部分需要大量计算才能进行 ZK 证明。Type-1 型与以太坊一样,无法缓解在这个事情上的低效(在生成证明方面,需要较长时间)。针对这个问题,目前行业里提出的解决方案主要是:通过巧妙的工程大规模并行化证明,或通过 ZK-SNARK ASIC 来实现硬件加速。
目前,主要有两个团队在尝试探索 Type-1 ZK-EVM,一个是Privacy and Scaling Explorations team,一个是Taiko。
Type-2 型 zkEVM 力求完全等效于 EVM,但不完全等效于以太坊。它们与现有的应用程序也完全兼容,但需要对以太坊进行一些小的修改,以使开发更容易并更快地生成证明。
Type-2 型 zkEVM 对区块结构和状态树之类的数据结构有一些修改。由于这些是 EVM 本身无法直接访问的结构,所以在以太坊上运行的应用程序几乎可以直接在 Type-2 型 zkEVM Rollup 上运行。虽然无法按原样直接使用以太坊执行客户端,但通过一些修改仍可以使用它们,并且还可以使用 EVM 调试工具和大多数其他开发工具。
通过删除部分不必要的和 ZK 不友好的以太坊堆栈,Type-2 zkEVM 的证明时间比 Type-1 zkEVM 更快些。这些修改虽然显著提高了证明者的效率,但并没有根本性解决证明时间慢的问题。总而言之,Type-2 的证明时间还是很慢。
Type-3 型 zkEVM 几乎与 EVM 等效,在兼容性方面也有所牺牲,但其 EVM 更易于开发。
Type-3 型 zkEVM 通过删除一些在 zkEVM 中很难实现的功能(比如:预编译),以及在处理合约代码、内存或堆栈方面的调整,总体在等效性方面做出了一些牺牲,实现了更多的验证器时间、并使 EVM 更易于开发。
在兼容性方面有所牺牲,由于有一些应用程序使用了被 Type-3 型 zkEVM 删除的预编译,这些应用程序需要对其中的部分进行重写。
目前,Scroll和Polygon都属于 Type-3。当然,从长远来看,还没有哪个 zkEVM 团队公开表明愿意长期停留在 Type-3。Scroll 和 Polygon Hermez 都在朝着 Type-2 型 zkEVM 的方向发展,虽然还有许多复杂的预编译还没有实现。
Type-4 类实际上属于 zkVM。Type-4 系统通过获取以高级语言(Solidity、Vyper)编写的智能合约源代码,并将其编译为明确设计为 ZK-SNARK 友好的某种语言来工作。
优劣势都很明显。有非常快的验证时间,因为 Type-4 类不对每个 EVM 执行步骤的所有不同部分进行 ZK 证明,而是从更高级别的代码开始,从而降低成本并获得更快验证时间。兼容性较差,合约在 Type-4 系统中的地址与它们在 EVM 中的地址不同;手写的 EVM bytecode 更难使用;很多调试的基础设施不能被继承,因为这些基础设施是运行在 EVM 字节码上。
总而言之,Type-4 属于语言级别等效,与字节码级别等效相比在兼容性方面有较大差距。根据 Vitalik 的观点,目前主要有Zksync属于 Type-4 类,尽管随着时间的推移它可能会增加对 EVM 字节码的兼容性;基于 Nethermind 的 warp 项目正在构建从 Solidity 到 Starkware 的 Cairo 编译器也会把StarkNet变成 Type-4 型。
这些 zkEVM 并没有绝对的优劣之分。它们只是在兼容性与速度之间有所取舍,Type-1 型 zkEVM 与以太坊的兼容性最高,但证明速度较慢;Type-4 型 zkEVM 与以太坊的兼容性较差,但验证速度更快。而且我们会发现,现有的 ZK Rollup 的明星项目,包括 Zksync、StarkNet、Polygon、Scroll 等都属于 Type-4/Type-3 这样的与以太坊兼容性没有那么高的 zkVM/zkEVM 类型。
Vitalik 是希望随着时间的推移,通过 zkEVM 的改进和以太坊本身的改进相结合,最终所有 zkEVM 都成为 Type-1 类。这样的好处在于,未来会有多个 zkEVM,既可以用于 ZK Rollup,也可以用于验证以太坊链本身(未来以太坊会对 ZK-SNARK 更加友好)。
Vitaliki 提出的观点,一般来说很容易达成整个行业的共识,我也非常认可。Type-1 型 zkEVM 的项目在 Ethereum 生态自然是最受欢迎的、也比较匹配 Ethereum L1。但 Type-4 类 zkVM 也未尝不是执行层项目的一个好的技术方案选择。主要有两点考虑:
当然,zkEVM 的兼容性和速度实际上并不是开发者考量基于哪个 ZK Rollup 去做应用的唯一指标。还有许多其他的因素会影响他们的选择,比如:
总而言之,每种 ZK Rollup 的 zkEVM 是在诸多性能中有所取舍,实际并没有绝对的优劣之分。
【免责声明】市场有风险,投资需谨慎。本文不构成投资建议,用户应考虑本文中的任何意见、观点或结论是否符合其特定状况。据此投资,责任自负。