为何zkSync总是“宕机”？梳理zkSync运行机制

　　本质上是，Sequencer 提交的交易，最终 Verified 的时间不稳定，但用户在交互端感知并不明显，因为 zkSync 的 Verify 设计就存在确认滞后性。

　　作者：@tmel0211 / 来源：推特

　　看有朋友吐槽 @zkSync 总是宕机，其实称「宕机」略微言过其辞了，准确说是「出块不稳定」。

　　本质上是，Sequencer 提交的交易，最终 Verified 的时间不稳定，但用户在交互端感知并不明显，因为 zkSync 的 Verify 设计就存在确认滞后性。

　　未来去中心化阶段不稳定性会得到缓解。我画了个 workflow 和大家探讨下。

　　之所以有用户感知「宕机」，可能是某些 DApp 和链底层兼容性导致的交易失败问题，毕竟在 zkSync 上开发 DApp 本身挑战就很大。

　　我从官方浏览器观察 Commit 到 Verified 的 Status 改变大致需要 30min-1 小时左右，而用户端交互 DApp 几乎不受此影响。

　　此文重点在科普 zkSync 的技术底层逻辑，带大家清晰地认识 zkSync。

　　如 workflow 所示，zkSync 运行分以下步骤：

　　1、User 通过 relay 转发向 Sequencer 排序器发送批量交易；

　　2、Sequencer 负责对交易进行排序、聚合打包 batch 成 Merkle 树；

　　3、zkPorter 将 Merkle 树生成 zk-SNARK 证明；zk-SNARK 证明分别 relay 给 L2 的 Validators 和 L1 主链生成 Commit Hash；Validator 负责验证

　　4、zk-SNARK 证明的正确性，无误后提交给 L1 智能合约生成 Verify Hash；

　　5、L1 上的 zkSync 智能合约校验 Commit Hash 和 Verify Hash 的匹配性；

　　6、成功匹配后生成 Verified Transaction 交易最终上链；

　　7、若匹配失败，原来的 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 技术赛道的信心。

　　来源：https://twitter.com/tmel0211/status/1668107719256190977

　　作者：@tmel0211

　　zkSync