zkVM和zkEVM学习笔记

一、关于 zkp 和 zk-SNARK, zk-STARK

零知识证明在不透漏知识的具体内容的情况下，就可以实现证明参与者是否真正掌握了该知识。

零知识证明在节省冗余计算、压缩链上空间和保护用户隐私的方面有重要的应用价值。零知识证明的实现方法有很多，比如 zk-SNARK, zk-STARK, PLONK, Bulletproofs 等。

zk-SNARK 是 Zero-Knowledge Succinct Non-Interactive Argument of Knowledge 的缩写，意思是简洁非交互零知识证明。简洁代表了用这种方法生成的证明比实际证明的数据量小，非交互的意思是在证明构建完成之后，证明者仅需发送一条简单的信息给验证者，并且一般情况下，没有授权的任何人都可以进行验证。这减少了链上交互的次数，节省了证明的开销。论据 (Argument) 代表着在当前计算能力的情况下，生成证明所采用的加密算法的复杂性是不能以可接受的时间和经济代价强行破解的。知识 (of Knowledge) 代表着在不掌握该知识不知道要证明什么的情况下不可能构造出该证明。零知识代表着在证明过程中不透露与证明实体有关的任何有用信息。

zk-STARK 是 Zero-Knowledge Scalable Transparent Arguments of Knowledge 的缩写，意思是可扩展透明零知识证明。与 zk-SNARK 不同，STARK 通过允许开发人员将计算和存储转移到链下来提高可扩展性，在计算速度和大小方面更具可扩展性。透明的意思是它消除了初始的可信任方来初始设置 zk 证明系统，而是转为使用可公开验证的随机性来创建无需信任的可验证计算系统。并且 zk-STARK 是抗量子的，可以防止量子计算机的攻击。

二、Rollup 扩容方案和 zk-Rollup 的原理简述

Rollup 扩容方案在 Plasma 方案的基础之上，进而将经过巧妙压缩过后的数据提交到主链上，这样，任何人都能通过这些数据验证 Rollup 提交的结果是否正确，它实现了数据可用性，加强了安全性。

Rollup 在主链上有一系列合约，维护 Rollup 中的状态记录，通过用保存 Rollup 层账户信息的 Merkle Trie 的根节点的哈希值，来保证任意叶子节点的值改变都会影响最后默克尔树根的哈希值，从而确认了底层状态信息的一致性。

通过记录交易执行结束之后的世界状态的状态根，我们可以得到一个账户状态的键值表。在 Rollup 上发生交易之时，键值表会发生改变，产生新的状态根。Rollup 上的交易会被分批打包汇总，并提交新的 state root.提交者在向 Rollup 合约提交一个新的批次的时候，主链会验证新状态根是否正确，若正确，则完成状态转移。

下图是简化版的 Optimistic Rollup 的图解。

Optimistic Rollup 默认提交者提交的 batch 是正确的，如果任何人发现某个 batch 的后状态根不正确，他可以向区块链发布一个证明，证明该 batch 计算错误。合约会对证明进行验证，并且对该 batch 及其之后的 batches 进行回滚。这样为了防止回滚，资金需要在 Optimistic Rollup 锁定 7 天来确保验证结果是正确的。

Zk Rollup 默认提交者提交的 batch 是错误的，提交者需要额外提交一个 Zk-SNARK 证明来自证提交的 batch 是有效的。可以在不提交全部交易数据的情况下证明数据的有效性，可以减少向主链提交的数据量。

下图是简化版的 Zk Rollup 的图解。增加了 ZK Proof，减少了验证人。

下表是 Vitalik 文章中对于两种不同 Rollup 的对比。

下表是四大 Rollup 方案的开销对比。

为 Zk Rollup 生成一个 zk-SNARK 证明相当困难。需要单独的指令集来完成这一点。

三、zkVM 和 zkEVM 的简述和前景

3.1 zkVM

zkVM 是一种虚拟机，通过零知识证明，可以确保可信特征的安全性，即，输入原来的状态和程序将输出新的状态。

下图简要地解释了什么是 zkVM.

zkVM 实现了易用性、通用性、简洁性和递归性。开发者无需掌握零知识开发，可以实现图灵完备、不用重复生成整个虚拟机的电路、对虚拟机的验证可以通过虚拟机来进行。

zkVM 同样有计算架构特殊和一些需要优化电路的性能问题。

主流的 zkVM 分三类，分为主流 (WASM, RISC-V)、EVM (EVM bytecode)、ZK-Optimized ( 全新指令集, 针对零知识证明所优化, 比如 Cairo 和 zkSync)，下图为三者的对比图：

zkVM 是一个很好的方向，它可以将 EVM 的垂直优化转化为 EVM 的横向扩展，从而摆脱 EVM 的局限。

3.2 zkEVM

zkEVM 在 Vitalik 的新作里已经写的很完备了，本文尝试做一个翻译和综述。

Polygon、ZKSync 和 Scroll 和 Privacy and Scaling Explorations 团队、Nicolas Liochon 的团队以及 Cairo 的 alpha 编译器都在最近发布了公告。本文将尝试描述 EVM 等价的不同类型的分类和每种类型的好处和成本。

下图为不同类型的概览：

类型 1（完全等效于以太坊）

类型 1 力图与以太坊完全等效，哈希、状态树、事物树、预编译、其他公式逻辑都不变。

优点：完美兼容

目标是与执行层端做到一样的验证方法。

一型 ZK-EVM 是 Rollup 的理想选择，因为以太坊执行客户端可以原样生成和处理 Rollup batch,区块浏览器和区块产生的过程都能复用。

缺点：证明时间

以太坊起初并没有以 ZK 友好为中心，所以很多以太坊协议的部件都要大量计算以进行 ZK 验证。类型 1 的目的是准确地拷贝以太坊，所以不能减轻这种低效。目前以太坊的区块证明需要数个小时才能产生。

谁在建造它？

隐私和扩展探索团队 ZK -EVM 正在构建 1 类 ZK-EVM。

类型 2（完全等效于 EVM）

类型 2 ZK-EVM 力求完全等同于 EVM，但不完全等同于以太坊。也就是说，它们“从内部”看起来与以太坊完全一样，但它们在外部存在一些差异，特别是在块结构和状态树等数据结构上。

目标是与现有应用程序完全兼容，但对以太坊进行一些小的修改，以使开发更容易并更快地生成证明。

优点：VM 级别的完美等价

类型 2 ZK-EVM 对保存诸如以太坊状态之类的数据结构进行更改。需要对以太坊执行客户端做微调使用 Type 2 ZK-EVM rollup。例外在于：对于验证历史以太坊区块的 Merkle 证明以验证有关历史交易、收据或状态的声明的应用程序出现了一种不兼容（例如，桥有时会这样做）。用不同的哈希函数替换 Keccak 的 ZK-EVM 会破坏这些证明。

缺点：改进但仍然很费证明时间

类型 2 删除了依赖于不必要的复杂和 ZK 不友好密码学的部分以太坊堆栈。例如改变以太坊的 Keccak 和基于 RLP 的 Merkle Patricia 树，可能还会改变区块和收据结构。

这减少了证明时间但必须按原样证明 EVM 的缓慢性以及 EVM 固有的所有低效率和 ZK 不友好性仍然存在。比如 MLOAD 可以读取任何 32 个字节，这可能是一个块或者两个连续的块。这造成了内存管理的问题。

谁在建造它？

Scroll 的 ZK-EVM 项目正朝着 Type 2 ZK-EVM 方向发展，Polygon Hermez 也是如此。也就是说，这两个项目都还没有完成。特别是，许多更复杂的预编译还没有实现。因此，目前这两个项目都被更好地考虑为 Type 3。

2.5 型（EVM 等效，gas 成本除外）

显着改善最坏情况证明者时间的一种方法是大大增加 EVM 中很难进行 ZK 证明的特定操作的 gas 成本。这可能涉及预编译、KECCAK 操作码，以及调用合约或访问内存或存储或恢复的可能特定模式。更改 gas 成本可能会降低开发人员工具的兼容性并破坏一些应用程序。

类型 3（几乎等效于 EVM）

3 类 ZK-EVM 几乎与 EVM 等效，但在精确等效性方面做出了一些牺牲，以进一步缩短验证器时间并使 EVM 更易于开发。

优势：更容易构建，更快的验证时间

类型 3 ZK-EVM 可能会删除一些在 ZK-EVM 实现中极难实现的功能，例如预编译。此外，Type 3 ZK-EVM 有时在处理合约代码、内存或堆栈方面也存在细微差别。

缺点：不兼容较多

使用 Type 3 ZK-EVM 删除的预编译的或者对其他删除功能有依赖的应用程序需要重写。

谁在建造它？

Scroll 和 Polygon 在其当前形式中都是 Type 3，尽管它们有望随着时间的推移提高兼容性。Polygon 使用了一些不同的内部逻辑来完成它。Type 3 只是一个过渡阶段，直到完成添加预编译的复杂工作并且项目可以移动到 Type 2.5。

类型 4（高级语言等效）

Type 4 系统通过获取以高级语言（例如 Solidity、Vyper 或两者都可以编译的中间语言）编写的智能合约源代码并将其编译为明确设计为 ZK-SNARK 友好的某种语言来工作.

优势：非常快的验证时间

如果没有 ZK 证明每个 EVM 的各个步骤，并且从高级语言代码开始，你就可以节省大量的开销。

缺点：不兼容较多

合约的地址因为 CREATE2 合约地址取决于确切的字节码而地址不同。手写的 EVM 字节码更难使用。很多调试基础设施不能被继承，因为这样的基础设施运行在 EVM 字节码上。

谁在建造它？

ZKSync 是一个 Type 4 系统，尽管随着时间的推移它可能会增加对 EVM 字节码的兼容性。Nethermind 的 Warp 项目正在构建一个从 Solidity 到 Starkware 的 Cairo 的编译器，这将把 StarkNet 变成事实上的 Type 4 系统。

3.3 zkEVM 的未来

编号较小的类型与现有基础架构的兼容性更高，但速度较慢，编号较高的类型与现有基础架构的兼容性较差，但速度更快。最理想的状况是一切都成为类型 1，要实现这样的未来，还需要相当长的时间。与此同时，我们将在扩展以太坊和基于以太坊的 ZK-rollup 的不同路径中看到许多创新。

四、zkEVM 的各项目基本面分析

4.1 Scroll

Scroll 在 7 月 19 日开启了 Scroll Pre-Alpha 测试网，融资情况：4 月 21 日，以太坊扩容网络 Scroll 完成 3000 万美元 A 轮融资，本轮融资由 Polychain Capital 领投，Bain Capital Crypto、Robot Ventures 和 Geometry DAO 等参投。此外，来自以太坊基金会的 Ying Tong 和 Carlos Aria、以及 Anthony Sassal、Ryan Adams 和 Santiago Santos 等以太坊社区成员也加入了此轮融资。

4.2 Polygon

Polygon 用户量 Unique 7 Days：845k，Unique 30 Days：2.26M，可以预见旧有用户转化到 Hermez 网络的转化率一旦提升，用户量基础巨大。现有市值：72 亿美元。Hermez 将提升 Polygon 网络的竞争力，并且提供与 ETH 网络等价的安全性。

4.3 zkSync

用户数：345596

融资情况：其开发公司 Matter Labs 获得了 5000 万美元的 B 轮融资。由 a16z Crypto 领投，其他投资方包括 Placeholder、Dragonfly 和 1kx 等，以及 Blockchain.com、Crypto.com、Consensys、ByBit、OKEx、Alchemy、Covalent 等战略合作伙伴，另外，还有来自 AAVE、Paraswap、Lido、Futureswap、Gnosis、Rarible、Aragon、Liquity、Celer Network、Connext、Perpetual Protocol、Euler、Opium 等 70 多个项目的创始人或高管参投。

TVL：$66.65 M

生态项目：Zigzag 是一个非托管的订单簿交换平台，是 zkSync 先行者之一。Yearn Finance 和 Taker Protocol 采用 zkSync 提供 DeFi 借贷服务。

4.4 StarkNet

用户数：23,557

融资情况：StarkWare 以 80 亿美元估值完成 1 亿美元 D 轮融资，Greenoaks Capital、Coatue、Tiger Global 和其他参与者领投，所筹资金将用于产品和业务开发、工程设计和周边生态系统的发展。

TVL:$1.09M

生态项目：StarkWare 生态中大部分原生项目处于早期阶段。

相关文章

https://vitalik.eth.limo/general/2022/08/04/zkevm.html https://www.ethereum.cn/an-incomplete-guide-to-rollups https://mirror.xyz/0x22034f804960B9B34353d6A7595cC4E83ac0daBe/vVgKwJ0L5A0lm-ysPNipUddrXK_64NcXE_WkkRP_DT8 https://threadreaderapp.com/thread/1538166119785111552.html https://ecn.mirror.xyz/rGHawBLJ0lJiRnwYd12W_gX6hzTOaWlPBKuwcq8_LuE https://mp.weixin.qq.com/s/808jMXvIUqB973aVHrAzGQ https://mp.weixin.qq.com/s/S9ajxMU4vfdomoCAXnvhpg https://web3caff.com/zh/archives/7573 https://www.panewslab.com/zh/articledetails/31jem01m37xk.html