通告|zkSync2.0开发者更新

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 之后，我们不得不考虑调试器、连接器、汇编器、反汇编器和二进制实用程序。由于使用了 LLVM，我们的编译器拥有所有经典优化，经过 2 万多次回归测试和 3000 次集成/可执行测试，维护需求低，而且支持开发者使用任何可翻译成 LLVM IR 的编程语言编写智能合约。

5 月，虽然我们的节点和虚拟机已经准备就续，但是我们的架构和 LLVM 出现了不兼容问题，这是超出我们意料之外的情况。因此，我们需要花费额外的时间将它们整合到框架中。我们不想在三大核心组件之一缺失的情况下启动测试网。但是，尽管这会产生前期成本，我们仍坚持从一开始就采用 LLVM 的决定。Matter Labs 永远不会牺牲安全性和代码质量。遵循最佳工业级实践虽然会拖慢进程，但是采用替代方案会留下技术上的不足。过去欠下的债迟早是要偿还的。

构建 zkSync 2.0 是一个紧锣密鼓的研发过程：

我们需要完成之前没有做过的事：开发 SNARK 友好型 EVM，在相同的地址空间中采用另一种按账户区分的数据可用性策略。
同时还要解决编译器、zkEVM 和节点的需求。

由于实现与研究是紧密关联的，我们在解决问题的过程中经常会发现更好的解决方案，进一步降低成本，提高兼容性，提供更便捷的接口：

我们进行了一些迭代来提高编译器的效率。在这一过程中，我们产生了一些关于如何提高虚拟机效率的想法（预知详情，参见《构建 zkSync 2.0 的挑战》）；
我们的 API 和 SDK 与 Web3 API 和 ethers 非常相似。因此，我们决定引入额外的 zkSync L2 特定功能，让我们的 API 和 SDK 能够开箱即用；
我们已经找到了一种方法来取消对交易执行追踪长度的限制，从而打破交易大小的上限！

由于 6、7、8 月的 gas 价格平均为 20 gwei，我们感到时间压力有所减轻，而且我们不想在明知有改进空间的情况下追赶进度。在所有改进都整合完毕之前，我们不会上线任何版本，尽可能避免任何破环性升级。相比我们在 3 月官宣的版本，我们目前正在开发的版本功能更多、成本更低、兼容性更好而且更加便捷。

但是，我们想要开诚布公地告诉大家：8 月上线是个颇具野心的目标。现在，我们很清楚，即使我们放弃了在效率和以太坊兼容性上的改进，也不可能在不影响质量的情况下进行交付。这就是处于技术创新前沿的研发的本质：任何预测都是基于无数未知进行的猜测。