注：原文来自@@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证明；
4）zk-SNARK证明分别relay给L2的Validators和L1 主链生成 Commit Hash；
5）Validator负责验证zk-SNARK证明的正确性，无误后提交给L1智能合约生成Verify Hash；
6）L1上的zkSync智能合约校验Commit Hash 和Verify Hash的匹配性；
7）成功匹配后生成Verified Transaction交易最终上链；
8）若匹配失败，原来的Commit Hash作废，由Sequencer重新提交batch再走一遍流程。
这里需要强调下，zkSync采用了“二阶段提交（2PC）”，通过前后Commit Hash 和Verify Hash两个阶段的Hash校验最终确定合法交易批次。 这样做一方面可以确保系统运转流程中的数据一致性安全，我个人理解，也是一种让Sequencer和Validator两个系统组件互相约束的去中心化思想显现，值得点赞。
zkSync的Workflow主要有Relay、Sequencer、zkPorter、Validator四大角色，协调工作中会存在诸多“不稳定因素”。 可概括为节点职能稳定性，节点协作稳定性，及算法和底层协议复杂性等。任一环节出现差错，都可能导致出块延迟。常见的 Arbitrum Sequencer技术故障就是典型，zkSync面临的挑战只会更多。
至于算法复杂性，这是zkSync链的天命所归，需要生态开发者们铆足劲去克服。而节点智能和协作的稳定性，我觉得未来去中心化阶段到来后，会得到有效改善。逻辑也简单：
1）多分布式节点，可避免单点故障带来的网络不稳定，系统鲁棒性使然；
2）分布式通证激励机制可给开发者维护节点稳定提供源动力。
换个角度思考，Verifing时间长在生态初期并非问题，可以有效提升链的安全性，避免系统中若干节点作恶。 总之，若厘清zkSync的整个运营流程，进一步了解下layer 2的技术复杂性和其中为安全性所设计的“特殊”机制，能巩固对L2技术赛道的信心。 欢迎大家转发分享，随时DM我，一起深入交流学习zkSync。
微信扫一扫 
