Matter Labs 阐述推迟上线 zkSync 2.0 的原因以及后续的测试网和主网规划。

　　原文标题：《Matter Labs：为什么我们未能在 8 月上线 zkSync 2.0？》

　　撰文：Matter Labs

　　编译：链捕手

　　2021 年 3 月 27 日，我们宣布了 zkSync 1.x 和 2.0 的计划。

　　我们成功地将 zkSync 1.x 升级部署到主网，但未能满足我们对 8 月发布 zkSync 2.0 的预测。在这篇文章中，我们将讨论延迟、逐步推出测试网以及公平启动主网。

　　早在 3 月份，我们就完成了 zkSync 2.0 的设计，并估算了构建所需的时间。由于 gas 费用一直居高不下，我们的设计优先考虑安全性和时间，在效率、优化和与以太坊的兼容性方面进行了一些权衡——由于线路的基本限制，使线路环境适应 EVM 并不简单。

　　然而，有一个关键决定没有优先考虑主网上线时间：选择 LLVM。虽然从头开始实现自定义编译器会更快，但从长远来看，除了 LLVM 之外别无选择。LLVM 由从事工业级产品（LLVM 是 macOS 和 iOS 不可或缺的一部分）的工程师构建，是生产工业级产品的最先进的编译器框架，迫使我们考虑调试器、链接器、汇编器、反汇编器和二进制实用程序，即使我们只是想快速发布一个编译器。通过利用 LLVM，我们的编译器具有所有经典优化、超过 20,000 个回归测试和 3,000 个集成 / 可执行测试、低维护负担、

　　5 月份，虽然我们的节点和 VM 已准备就绪，但与我们的架构和 LLVM 存在一些无法预料的不兼容性，我们需要额外的时间来集成到框架中。我们不想打开一个缺少三个核心组件之一的测试网，但即使有初始开销，我们仍然坚持我们从一开始就采用 LLVM 的决定。Matter Labs 绝不会在安全性或代码质量方面妥协。遵循最佳工业级实践是缓慢的，但替代方案是使用技术债务进行编程。债务总有一天要还的。

　　构建 zkSync 2.0 是一个紧张的研发过程：

• 　　对 snark 友好的 EVM 和相同地址空间中不同的每个帐户数据可用性策略以前从未做过；

• 　　它需要同时解决编译器、zkEVM 和节点的需求。

　　由于实现与研究高度相关，很多时候我们找到了一个更好的解决方案，导致更低的成本、更好的兼容性或更方便的接口：

• 　　我们进行了几次迭代以提高编译器的效率，这为我们提供了如何使我们的 VM 更高效的想法（更多详细信息在技术见解帖子中）；

• 　　我们的 API 和 SDK 与 Web3 API 和 ethers 非常相似，因此我们决定通过额外的 zkSync L2 特定功能来支持两者；

• 　　我们找到了一种方法来取消交易执行跟踪长度的限制，从而实现任意大的交易。 (责任编辑：admin)