Glaze & Fundamental Labs 对 ZK 的研报

[Whisker17]

零知识证明（ZK） 为什么重要

[Whisker17]

当我们看 ZK 隐私项目时，以下几点较为重要：

• ZK 只是技术，我们要专注产品力和团队

• ZK 是个复杂的技术，会拖慢开发进度

• ZK 有利于 DAO 治理和身份认证

• ZK 是机构上链的必备技术

[Whisker17]

ZKEVM 有三个阶段：

• 共识级

• 字节码级

• 语言级

[Whisker17]

生态潜在方向

• 充分利用高 TPS 和低手续费的应用程序

• Layer2 之间的通信协议/应用程序

• 聚合流动性

• 开发工具/框架

• 基于云的开发工具

• 具有独特功能的跨 Layer2 Layer1 应用程序

• 不同的 ZKVM

• ZK 桥

• 在其他链上应用 ZK

• 拥有递归功能的 Layer2

• ZK 在 DAO 和社区治理中的应用

• 商业化 ZK 算法

• 芯片和云计算

[Whisker17]

SNARK

• 简洁性（Succinct）：验证所需要的计算资源远远小于重新跑一遍需要证明的程序。

• 非交互性（Non-interactive）：证明者和验证者不需要每一轮都沟通。他们只需要在一开始完成可信初始化（Trust Setup）：其他验证者也可以在可信初始化之后加入验证。

• Argument：如果证明者有着无比强大的算力，那么他可以生成假证明。如果这种情况发生，主流的公私钥加密模式也不再安全。

• 知识（Knowledge）：证明者需要知道一些其他人不知道的秘密，才能生成证明。

[Whisker17]

• ZK-SNARK 最大的问题在于它需要可信初始化（Truest Setup）。
• 可信初始化会生成参考字符串（Reference String）。如果 RS 被泄露，那么任何人都可以生成虚假证明。
• 此外，如何设计多人参与的可信初始化也很具有挑战性。RS 还只能被用于指定的程序。对于其他的程序，我们需要另外的可信初始化。因此 ZK-SNARK 不可能用于通用计算。
• 另外一点，RS 不能升级。如果我们升级了程序，可信初始化要重新运行。

[Whisker17]

解决可信初始化的两种思路

1. Transparent Setup：可信初始化生成公共参考字符串（Common Reference String）。CRS 是公开的，不需要保密。Fractal，Halo，ZK-STARK，SuperSonic 都是采取了这一条路线。这一条路线的问题是生成的证明占用太多的存储，来到了 kB 的量级。对于区块链来说，存储是非常昂贵的。
2. Universal Setup：可信初始化生成了结构化参考字符串（Structure Reference String），但它需要保密。SRS 让可信初始化可以用于不同的程序，这让通用计算的证明可能实现。Marlink，SuperSonic-RSA 和 Plonk 都采用了这条路线。

[Whisker17]

算法介绍

• Groth16：Zcash 一开始使用了这种算法。它是零知识证明中的跑分对照组，因为它具有证明快，生成的证明小的特点。它的缺点是需要可信初始化，并且一次可信初始化只能针对一个程序。它拥有最完善的工具链。

• Sonic：支持 Universal Setup. SRS 的大小和程序大小成线性关系。生成的证明是固定大小，但是验证需要消耗很多的计算资源。Sonic 让通用计算的零知识证明变为可能。

• Fractal：支持递归（Recursion）。生成的证明占用较多空间。

• Halo： 支持递归，但并不满足简洁性（Succinct）因为证明时间是非线性的。Halo2 是目前主流使用的证明系统。

• SuperSonic：第一个实际的，可以应用的 Transparent ZK-SNARK。

• Marlin：程序可以升级。性能处于 Sonic 和 Groth16 之间。

• Plonk：程序可以升级；参与者按照顺序加入可信初始化。这让进行有很多人参与的可信初始化不那么复杂；Plonk 使用 Kate commitments 而不是多项式承诺（ZK-SNARK 的第一步是将计算问题转化为多项式问题）。许多现代化的零知识证明系统都构建与 Plonk 之上。Plonk 有着非常优秀的工具链。

[Whisker17]

[Whisker17]

Benchmark

• 介绍

[Whisker17]

• Benchmarking Zero-Knowledge proofs with isekai | by Guillaume Drevon | Sikoba Network | Medium

[Whisker17]

• Zero-Knowledge Proofs: STARKs vs SNARKs | ConsenSys

[Whisker17]

• Community Proposal: A Benchmarking Framework for (Zero-Knowledge) Proof Systems (zkproof.org)

[Whisker17]

• Comparison of Different zk-SNARKs

[Whisker17]

算法优劣的指标

• 一笔交易和十笔交易的证明时间

• 一笔交易和十笔交易的验证时间

• 一笔交易和十笔交易打包后的证明大小

• 可信初始化

• 参考字符串长度

• CRS 支持

• SRS 支持

• 递归证明支持

• 能否抵抗量子计算机

• 安全性基于任何密码学假设

[Whisker17]

• Rollup 依赖于 ZK 的两大特性：简洁（Succinct）和递归（Recursion）。
• 简明的特性有助于验证者节省大量的计算资源。 验证者不需要重新运行整个程序。
• 递归特性有助于节省存储空间。 通过递归，区块链可以保持一个固定的大小。这也有利于去中心化，因为这样的区块链节点在什么样的硬件上都可以跑起来。

[Whisker17]

Rollup 机制

• 哈希树的状态根存储在 Rollup 合约中。Rollup 智能合约从 Layer2 提交的信息中更新状态根。

[Whisker17]

• 依赖于零知识证明的简洁性，完备性，合理性，ZKRU 得以安全地提升 TPS。
• 完备性和合理性是证明系统的必备特性。
  • 完备性 Completeness：如果证明是有效的，验证方一定会相信证明方的断言。真的假不了；
  • 合理性 Soundness：虚假断言不可能生成有效的证明。假的真不了。

[Whisker17]

• ZKRU 整体来说优于 Optimistic Rollup（OPRU）。OPRU 的 TPS 略差，并且需要更长的提款周期，因为它依赖于欺诈证明（Fraud Proof）。
• OPRU 并没有坐以待毙，他们尝试将 ZK 融入自家的解决方案来提升 TPS，解决原生提款周期过长的问题。例如，他们将 ZK 应用于状态变化，这样就可以缩短欺诈证明所需要的时间了。

[Whisker17]

角色

在 Rollup 的体系中，一共有三个角色：

• 用户：用户在 Layer2 提交交易。他们从 Layer1 充值资产至 Layer2

• Rollup 节点：Rollup 节点负责维护 Layer2 网络的正常运行。它们需要生成证明，执行交易，打包交易，参与欺诈证明

• Layer1: Layer1 保证了 Layere2 的安全性，并负责共识的达成。大部分 Layer1 目前都是以太坊。

[Whisker17]

状态验证

• 欺诈证明（Fraud Proofs）：允许白名单执行者监控链上交易，并指出错误状态。
  • 仅在退出验证（Exits Only）：退出网络时，状态会被验证。中间状态并不会被验证。
  • 互动证明（INT）：需要多笔交易来解决纠纷。
  • 一轮（1R）：只需要一轮证明来解决状态纠纷。
• 零知识证明（ZK proofs ）：使用 ZK-STARKs/ZK-SNARKs 来证明状态的正确性。

[Whisker17]

数据可用性

• 链上（On chain）：构建证明需要的所有数据都在链上。

• 外部数据委员会（External DAC）： 构建证明需要的所有数据都不在链上。数据委员会负责保护和提供数据。

• 外部（External）： 构建证明需要的所有数据都不在链上。

[Whisker17]

升级（Upgradability）

• 是（Yes）： 可以随时升级，不需要任何公告。

• 21 天延迟或无延迟（21 day or no delay）： 有 21 天的延迟，除非安全委员会多签通过了立即升级。

[Whisker17]

故障序列（Sequencer Failure）

• L1 交易（Transact using L1）：用户可以在 L1 提交一笔交易来强制 L2 打包自己的交易。

• 强制交易/L1 退出（Force trade/ exit to L1）：用户可以在 L1 提交请求来强制 L2 打包自己的提款请求，但这意味着用户需要找在系统之外找到交易对手方。

• 强制 L1 退出（Force exit to L1）：用户可以在 L1 提交请求来强制 L2 打包自己的提款请求。

• 构建区块（Propose blocks(ZK)）：用户需要自行运行节点来构建区块。这个区块包含了用户想要打包的交易。这要求用户自行计算 ZK 证明。这对算力有很大要求。

• L1 退出（Exit to L1）：用户只能在 L1 提交提款请求。

[Whisker17]

验证失败（Validation Failure）

• 逃生舱（Escape hatch(MP)）：用户可以在无需信任的情况下拿回押金。用户需要提交资金的哈系树证明。押金将会以上一次状态中的平均价格退出。

• 构建区块（Propose blocks）：用户需要自行运行节点来构建区块。

[Whisker17]

[Whisker17]

ZKRU 对比 OPRU

• 优点

  • 降低用户手续费

  • 优于 OPRU 的性能， 手续费，提款周期

  • 区块可以并行运算，有利于去中心化

  • 更高的 TPS

  • 更短的提款周期，优于欺诈证明

• 缺点

  • 计算证明需要大量的资源

  • ZKRU 的可信初始化较为中心化

  • 量子计算可能会损害安全性

  • 安全假设包含不可验证的信任

[Whisker17]

ZKEVM

-ZKEVM 是 ZKRU 的下一个里程碑。ZKEVM 可以划分为三个等级：

• 共识级：ZKEVM 和主网上的 EVM 等价。生成的状态根是通用的。以太坊在未来计划实现主网上的 ZKEVM。

• 字节码级：ZK 证明系统在这个阶段非常重要，需要对 EVM 友好。字节码级的 ZKEVM 生成的状态根与 EVM 的状态跟格式不一样，因为 ZKEVM 采用不一样的密码学算法。EVM 使用的那些对于 ZK 证明系统不友好。Scroll 和 Hermez 采用这个解决方案。

• 语言级：在这个级别，并没有真正的 ZKEVM。一个转译器将 Solidity 编写的智能合约或者字节码转译成自定义虚拟机可以执行的格式。zkSync 和 Starkware 都是采用这个解决方案。这个方案的缺陷是，并不能兼容 EVM 的所有功能。

[Whisker17]

生态介绍

[Whisker17]

Polygon

• Miden：实验性质的 ZKRU 通用计算平台，TPS 1k+ ，15 min 提款，5 秒产出 1 个块，隐私交易。

• Nightfall：Nightfall 是一个 ORU，集成了 ZK 来实现隐私交易。一笔交易需要 9k Gas，110 TPS，为安永会计师事务所设计。

• Hermez：EVM 兼容的 ZKRU，2k TPS。目前网络已经上线，几乎没有交易量（数据来自区块浏览器）。

• Zero：通用 ZKRU 计算平台，支持递归。只需要 0.17s 就可以生成证明。证明大小 45 kB。一个账户只占用 5 bits。

[Whisker17]

zkSync

zkSync 2.0 测试网在 2022/2 上线，兼容 EVM。Matter Labs 将大部分 OPCODE 电路化实现在不修改证明系统的前提下，实现 EVM 兼容。目前 zkSync 2.0 并不支持 ADDMOD，SMOD，MULMOD，EXP，CREATE2 和 KECCAK256。在这种解决方案下，Solidity 成为了一等公民。

zkSync 2.0 的 Gas Price 是根据以太坊主网 Gas Price 和 ZK 证明成本动态变化的。受以太坊主网 Gas Price 影响的原因是 zkSync 会将数据打包存储到以太坊主网。

为了进一步降低手续费，提高 TPS，zkSync 计划发布 ZKPorter。用户可以选择将他们的账户数据存储在 ZKPorter 上来降低手续费。如果一个账户数据存储在 ZKPorter 上，则它所有的交易都将由 ZKPorter 确保数据可用性，交易不再能提交到以太坊主网上。

[Whisker17]

Starkware

• Starkware 有两个产品：StarkEx，StarkNet。
• StarkEx
  • StarkEx 是一款 SaaS 产品，为项目方提供 ZKRU 解决方案。目前客户包含 dYdX，DeverseFi，Immutable，Sorare。
• StarkNet
  • StarkNet 是更加开放的 ZKRU 相比于 StarkEx，任何人都在可以在上面部署合约。StarkNet 目前不兼容 EVM。StarkNet 使用 Cairo 来编写智能合约。

Starkware 也在推进 ZKEVM。他们用了和 zkSync 不一样的解决方案。他们使用 Warp 来将 Solidity 编写的智能合约转译成 Cairo。这个解决方案并不如 zkSync 的解决方案，对 Solidity 的兼容性较差。

[Whisker17]

保护隐私分为三个阶段：

• 交易隐私：用户可以隐藏他们的交易。

• 通用计算隐私：目前以太坊上的所有计算过程都是公开的。任何人都可以看到输入，输出，和状态转换。通用计算隐私将隐藏这些计算过程。

• 函数隐私：有时调用函数的名称会泄露信息。例如，mint() 往往意味着铸造代币。函数隐私将隐藏函数的调用记录。