看有朋友吐槽 @zkSync 总是宕机，其实称「宕机」略微言过其辞了，准确说是「出块不稳定」。
本质上是，Sequencer提交的交易，最终 Verified 的时间不稳定，但用户在交互端感知并不明显，因为 zkSync的Verify设计就存在确认滞后性。
未来去中心化阶段不稳定性会得到缓解。我画了个 workflow 和大家探讨下。
之所以有用户感知「宕机」，可能是某些 DApp 和链底层兼容性导致的交易失败问题，毕竟在 zkSync 上开发 DApp 本身挑战就很大。
我从官方浏览器观察 Commit 到 Verified 的 Status 改变大致需要 30min-1 小时左右，而用户端交互 DApp 几乎不受此影响。
此文重点在科普 zkSync 的技术底层逻辑，带大家清晰地认识 zkSync。
如 workflow 所示，zkSync 运行分以下步骤：
- User 通过 relay 转发向 Sequencer 排序器发送批量交易；
- Sequencer 负责对交易进行排序、聚合打包 batch 成 Merkle 树；
- zkPorter 将 Merkle 树生成 zk-SNARK 证明；
- zk-SNARK 证明分别 relay 给 L2 的 Validators 和 L1 主链生成 Commit Hash；
- Validator 负责验证 zk-SNARK 证明的正确性，无误后提交给 L1 智能合约生成 Verify Hash；
- L1 上的 zkSync 智能合约校验 Commit Hash 和 Verify Hash 的匹配性；
- 成功匹配后生成 Verified Transaction 交易最终上链；
- 若匹配失败，原来的 Commit Hash 作废，由 Sequencer 重新提交 batch 再走一遍流程。
这里需要强调下，zkSync 采用了「二阶段提交（2PC）」，通过前后 Commit Hash 和 Verify Hash 两个阶段的 Hash 校验最终确定合法交易批次。
这样做一方面可以确保系统运转流程中的数据一致性安全，我个人理解，也是一种让 Sequencer 和 Validator 两个系统组件互相约束的去中心化思想显现，值得点赞。
zkSync 的 Workflow 主要有 Relay、Sequencer、zkPorter、Validator 四大角色，协调工作中会存在诸多「不稳定因素」。
可概括为节点职能稳定性，节点协作稳定性，及算法和底层协议复杂性等。任一环节出现差错，都可能导致出块延迟。常见的 Arbitrum Sequencer 技术故障就是典型，zkSync 面临的挑战只会更多。
至于算法复杂性，这是 zkSync 链的天命所归，需要生态开发者们铆足劲去克服。而节点智能和协作的稳定性，我觉得未来去中心化阶段到来后，会得到有效改善。逻辑也简单：
- 多分布式节点，可避免单点故障带来的网络不稳定，系统鲁棒性使然；
- 分布式通证激励机制可给开发者维护节点稳定提供源动力。
换个角度思考，Verifing 时间长在生态初期并非问题，可以有效提升链的安全性，避免系统中若干节点作恶。
总之，若厘清 zkSync 的整个运营流程，进一步了解下 layer 2 的技术复杂性和其中为安全性所设计的「特殊」机制，能巩固对 L2 技术赛道的信心。
（声明：请读者严格遵守所在地法律法规，本文不代表任何投资建议）
