「ZK-Rollup」可能是今年最热门的网络流行语。随着 zkSync2.0 版本「baby alpha」主网的推出，这种兴奋情绪已经达到了顶峰。但在所有这些流行语背后，「ZK-Rollup」真正指的是什么？zkSync 会在哪里发挥作用呢？在本文中，我将努力深入研究 ZK-Rollup 的原理和实践，解释作为一个项目的 zkSync v2.0 的关键技术特征，并探索这一期待已久的技术的潜在未来影响。
为什么我们需要 ZK-Rollup？以太坊很棒，但在目前的状态下，该网络从根本上来说是一种规模不经济。随着网络活动的增加，gas 价格昂贵得令人望而却步。随着以太坊在过去几年中越来越受欢迎，其目前有限的可扩展性已成为该网络的致命弱点。
这就是「Rollup」发挥作用的地方——以太坊的 Rollup 本质上是一个「插件」，为以太坊提供了额外的可扩展性，从而解决了其固有的规模不经济问题。这个想法的背后逻辑是比较简单的。假设你有 5 件物品需要从 A 点搬运到 B 点。「常规」方式是依次搬运第 1 件、第 2 件等。但这显然是缓慢和繁琐的。「Rollup」本质上是将所有 5 件物品「打包」到一个包中，这样你就可以只搬运 1 次而不是 5 次。
但有两点需要注意：
我们如何确保 Rollup 能够「适合」所有内容?
我们如何确保 Rollup 没有被欺骗?
ZK-Rollup 是一种主要的 Rollup 技术 ( 另一种是 Optimistic Rollup)，它利用「零知识证明」来解决这两个问题。为了解决这些问题，ZK-Rollup 将一定数量的交易捆绑在一起，在 L2 上进行计算，并向 L1 上的验证者提交状态更改和「有效性证明」，以表明计算是完整的。这种「有效性证明」是以「零知识证明」的形式进行的，这是一种数学方法，告诉别人你知道某件事，而不告诉他们你知道什么。
零知识证明的一个简单例子是代码自动评分程序 ( 用于 CS 作业 )。自动评分程序是一个「验证者」，它为我们提供一堆随机生成的测试用例，而我们是一个「证明者」，必须能够通过所有的测试用例，以证明自己有正确的代码。一直以来，我们都不会直接与自动评分程序共享代码。刚刚我们就进行了一个「零知识证明」，证明我们知道一些事情，而不用说出知道什么。
代码自动评分程序——零知识证明的简单示例。资料来源：Gradescope。
上面的代码自动评分程序使用「交互式零知识证明」，自动评分程序和代码提供者直接「交互」。相比之下，大多数 ZK-Rollup 使用数学上更复杂的非交互式证明 ( 如 zk-SNARK)，这与交互式证明相比节省了时间和空间。虽然 zk-SNARK 的技术细节超出了本文的范围，但是测试用例传递的基本原则是相同的。
ZK-Rollup 的圣杯是零知识以太坊虚拟机 (zkEVM)，允许开发人员在不修改的情况下将任何以太坊智能合约移植到 ZK-Rollup 链上。但这很难。因为每个「问题」都需要不同的「测试用例」集，开发一个可以解决每个想象得到的测试用例的「证明算法」是零知识证明和 ZK-Rollup 的技术瓶颈。
正如 Vitalik Buterin 所说：
总的来说，我个人的观点是，在短期内，Optimistic Rollup 可能会在通用 EVM 计算中胜出，而 ZK-Rollup 可能会在简单的支付、交换和其他特定于应用程序的用例中胜出，但从中长期来看，随着 zk-SNARK 技术的改进，ZK-Rollup 将在所有用例中胜出。
因此，从历史上看，ZK-Rollup 只是针对特定应用程序的用例建立的技术，其中「测试用例」的定义明确且范围有限。然而，一些项目正在迅速朝着「山上城堡」的方向发展——一种与 EVM 兼容的通用 ZK-Rollup 算法。
zkSync v2.0 是目前开发 zkEVM 的众多项目中的一个 ( 其他项目包括 StarkNet、Polygon Hermez 和 Scroll)。zkSync v1.0 它要求用户重新构建大部分代码库以从 EVM 移植到 zkSync，在 zkSync v2.0 中，程序员可以在几乎不做任何更改的情况下部署他们的应用程序。
在实践中，并非所有 zkEVM 都是一样的。在可组合性 ( 它与原始 EVM 合约的接近程度 ) 和性能 (ZK-Rollup 的运行速度 ) 之间存在明显的权衡。在这种权衡中，zkSync 选择完全优化性能，从而牺牲了组合性。
在 Vitalik Buterin 看来，zkEVM 有四种不同的类型，归纳如下表：
zkEVM 的类型
注释和改编自 https://vitalik.ca/general/2022/08/04/zkevm.html
正如 Vitalik 所言，zkSync v2.0 目前的状态是 Type 4 zkEVM，它能够使用自己的编译器编译 Solidity 和高级语言编写的合约，这与 EVM 不同。因为 zkSync 可以完全控制编译器的设计，所以他们能够积极地优化速度和吞吐量。这样做的代价是，一些 dApp 和 EVM 调试工具链可能与 zkSync v2.0 不兼容。本质上，zkSync 是与以太坊相同的汽车外壳，但更换了引擎。
事实上，在其开发人员文档中，Matter Labs 声称，虽然智能合约的「读」操作可以在不改变任何代码的情况下集成，但智能合约的「写」操作需要「额外的代码」，因为「L1 和 L2 之间有根本差异」。实际上，这有点误导人。这与其说是由于 L1 和 L2 之间的「根本差异」，不如说是由于 Matter Labs 决定追求的 ZK-Rollup 的类型——Type 4 Rollup。因为 zkSync 基本上是使用不同编译器和字节码的 Type 4 Rollup，这意味着智能合约有不同的地址，依赖字节码分析的调试器基础设施可能无法在 zk-Sync v2.0 上工作。
未来，zkSync 可能会添加更多对 EVM 字节码的本地支持，允许系统慢慢过渡到支持更广泛的「边缘情况」的 Type 3 Rollup。但 zkSync 的 Type 4 或 Type 3 ZK-Rollup 要想与 Polygon Hermez 和 Scroll Labs 的 Type 2 Rollup 更成功，就必须满足两个重要的先决条件。首先，只有一小部分不重要的项目与 zkSync 的自定义编译器不兼容。其次，与 Type 2 zkEVM 相比，zkSync 的执行速度存在质的差异。
但是，任何高级的开发生态系统都依赖于成熟的「脚手架」基础设施，包括方便的、模块化的、调试和测试工具。如果正如 Vitalik 所假设的那样，由于字节码的差异，大部分 EVM 本地调试工具将无法移植到 zkSync，那么 zkSync 将不得不开发自己的测试和调试工具套件。与更可组合的 Type 2 zkEVM 竞争对手 ( 如 Polygon Hermez 和 Scroll) 相比，这是额外的开销，可能最终会阻碍 zkSync 作为 L2 解决方案的采用速度。
在 zkEVM 的竞争中有许多竞争对手，可以说，我们看到一个功能齐全的 zkEVM 只是一个时间问题。但接下来呢？ZK-Rollup 的长期优势来自于使用该解决方案的项目。
目前，DeFi、GameFi 和移动应用程序是 ZK-Rollup 基础设施的主要受益者。DeFi 和 GameFi 从根本上来说都是规模经济，因为它们在有很多人使用它们的环境中蓬勃发展。像移动钱包这样的移动应用程序也给大众消费者打开了闸门。因此，在这些情况下使用 ZK-Rollup 非常有意义。
但这绝不是 ZK-Rollup 用途的极限。现在这仅仅是一个开始。ZK-Rollup 之于以太坊，就像 5G 之于互联网。正如 5G 可以实现物联网应用和系统的新世界一样，ZK-Rollup 也可能打开「区块链物联网」的闸门，允许我们物理世界的数字设备——冰箱、手表、红绿灯等——与以太坊上的智能合约集成。
反对物联网的最大论点之一是，它将允许大型科技公司越界进入我们的日常生活。但是有了「区块链物联网」，我们就可以享受物联网带来的便利，而不用担心我们的智能设备在一个集中的数据库中被泄露。我们可以拥有便利和隐私，而不是方便或隐私。这就是 ZK-Rollup 向我们承诺的世界