zk-Sync 2.0 是目前在开发 zk-EVM 的众多项目之一（其他项目包括 StarkNet、Polygon Hermez 和 Scroll）。zk-Sync 1.0 要求用户重新构建其代码库的大部分内容，以便从 EVM迁移到 zk-Sync。与 zk-Sync v1.0 不同，在 zk-Sync 2.0 中，程序员可以在几乎没有变化的情况下部署其应用程序。

实际上，并非所有的 zk-EVM 都是等效的。它们在可组合性（与原始 EVM 合约的接近程度）和高性能（zk-Rollups 的运行速度）之间存在着明显的权衡[6]。在这种权衡中，zk-Sync 选择了高性能，从而牺牲了可组合性。

在 Vitalik看来，目前主要有四种不同类型的 zk-EVM，这四种类型如下图所示：

zk-EVMs 的类型，改编自：https://vitalik.ca/general/2022/08/04/zkevm.html

正如 Vitalik所述，在目前的状态下，zk-Sync 2.0 是第4类zk-EVM。与 EVM 不同，zk-Sync 2.0 能够使用自己的编译器编译，可以使用 Solidity 和高级语言编写智能合约。由于 zk-Sync 可以完全控制其编译器的设计，因此他们能够积极优化速度和吞吐量。但这样做的代价是，一些 DApps 和 EVM 调试工具链可能与 zk-Sync 2.0 不兼容。从本质上看，zk-Sync 与 Ethereum 有相同的“汽车外壳”，但换了一个引擎[5]。

事实上，在 zk-Sync 开发者文档中，Matter Labs 声称，虽然智能合约 "读取 "操作可以在不改变代码的情况下集成，但智能合约的 "写入 "操作需要 "附加代码"，因为 "Layer1 和 Layer2 之间存在根本差异" [6] 。实际上，这略有误导。与其说是由于 Layer1 和 Layer2 之间的 "根本差异"，不如说是由于 Matter Labs 所追求的第4种Rollups。因为 zk-Sync 本质上是使用不同的编译器和字节码，基于第4种的 Rollups 意味着智能合约有不同的地址，但依赖于字节码分析的调试器基础设施可能无法在 zk-Sync 2.0 上运行[7]。

在未来，zk-Sync 可能会加入更多对 EVM 字节码的本地支持，允许系统慢慢过渡到支持更广泛的 "边缘情况 "，也就是指第3类的 Rollups。但是，对于 zk-Sync 的第3类和第4类的 zk-Rollup 来说，与 Polygon Hermez 和 Scroll Labs 的第2类的 Rollups（基本上是以速度换取更广泛的兼容性）相比，必须有两个重要的前提条件才能成功。首先，只有一小部分不重要的项目与 zk-Sync 的自定义编译器不兼容。其次，与第2类zk-EVM 相比，zk-Sync 的执行速度需要有质的区别。

不幸的是，我个人认为这种情况不太可能发生。任何先进的开发生态系统都依赖于成熟 "框架 "的基础设施，包括便捷性、模块化、调试和测试工具。如果像 Vitalik 假设的那样，由于字节码的不同，大部分 EVM 原生调试工具将无法移植到 zk-Sync，那么 zk-Sync 将不得不开发自己的测试和调试工具套件。与 Polygon Hermez 和 Scroll 等可组合性更强的第2类zk-EVM 相比，这是会增加额外的开销，最终可能会影响 zk-Sync 作为 Layer2 解决方案的采纳进度。

点个【 在看 】，你最好看