看到很多朋友吐槽，今天就来详细写下
#zkSync 的“宕机”其实是“出块不稳定”，主要由于Sequencer提交的交易的验证时间不稳定，但这个问题对用户交互并不明显。如果用户感知到“宕机”，可能是由于某些DApp和链底层的兼容性问题导致的交易失败。
#zkSync 的运行流程包括：
用户通过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网络上进行一些操作，比如发送一些资产。他们通过一个中继器（relay）发送这些操作，形式是一批交易，像是一个待办事项列表。你可以想象成你在餐厅点单，这些订单（交易）需要被处理。
这个待办事项列表（批量交易）被送到了一个名叫"Sequencer"的排序器。这个排序器就像是餐厅的厨师，他们按照顺序处理这些订单，把这些交易按照一定的顺序组织起来，然后打包成一个叫做Merkle树的数据结构。这就像是厨师把所有的菜品都做好，然后安排在一起准备出餐。
然后，这个Merkle树被送到了zkPorter。这个zkPorter就像是一个超级检验员，他们用一种特殊的技术，叫做zk-SNARKs，来检查这个Merkle树。他们的工作就是产生一种证明，这种证明可以证明这个Merkle树（也就是那批交易）是正确的，没有问题。
这个zk-SNARK证明会被发送给Layer 2（L2）的验证者（Validators）和Layer 1（主链）。他们会分别生成一个叫做Commit Hash的东西。你可以把这个Commit Hash想象成一个特殊的标签，可以证明这个证明（和对应的交易）已经被检查过了。
L2的验证者的工作就是检查这个zk-SNARK证明的正确性。如果一切都正确，他们就会提交这个证明给Layer 1的智能合约，智能合约会生成一个叫做Verify Hash的东西。这个Verify Hash可以被看作是一个确认标签，证明这个交易已经被最终确认了。
在Layer 1上，有一个特殊的智能合约，叫做zkSync智能合约。这个合约的工作就是检查Commit Hash和Verify Hash是否匹配。就像是检查一个包裹的邮寄标签和收货标签是否一致。
如果这两个hash匹配，那么这个交易就会被确认，然后被添加到链上，就像是你在餐厅得到你的菜一样，这个交易就算完成了。
如果这两个hash不匹配，那就意味着在某个地方出了问题。在这种情况下，原来的Commit Hash就会被废弃，就像是废弃一个错误的订单一样。然后，排序器（Sequencer）会重新提交一批交易，然后整个流程会再走一遍，直到所有的问题都被解决，所有的交易都被正确地处理。
zkSync采用了“二阶段提交（2PC）”，通过前后Commit Hash 和Verify Hash两个阶段的Hash校验最终确定合法交易批次，这样可以确保系统运转流程中的数据一致性安全。
zkSync的工作流程主要涉及Relay、Sequencer、zkPorter、Validator四大角色。在这个协调过程中会存在许多不稳定因素，包括节点职能稳定性，节点协作稳定性，以及算法和底层协议复杂性等。任何环节出现错误都可能导致出块延迟。所以与其叫宕机，不如说是由于工作流程较长，出块不稳定。