I saw some friends complaining that @zkSync is always down. Actually, calling it "downtime" is a bit of an exaggeration. To be more precise, it is "unstable block generation". In essence, the final Verification time of the transaction submitted by the Sequencer is unstable, but the user does not perceive it obviously on the interactive end because the Verification design of zkSync has a confirmation lag. In the future, the instability will also be alleviated in the decentralized stage. I drew a technical flow chart to discuss with you. 🧵
The reason why some users perceive "downtime" may be due to the transaction failure caused by the compatibility of some DApps and the underlying chain. After all, developing DApps on zkSync itself is very challenging. I observed from the official browser that it takes about 30 minutes to 1 hour for the Status to change from Commit to Verified. In the early days, for the system security of the L2 chain, it is normal to have such a time interval. This article focuses on popularizing the underlying technical logic of zkSync.
As shown in the workflow, zkSync runs in the following steps:
1) User sends batch transactions to Sequencer through relay forwarding;
2) Sequencer is responsible for sorting transactions and aggregating and packaging them into Merkle trees;
3) zkPorter generates zk-SNARK proof from Merkle tree;
4) The zk-SNARK proof is relayed to L2 Validators and L1 main chain to generate Commit Hash;
5) Validator is responsible for verifying the correctness of the zk-SNARK proof, and submitting it to the L1 smart contract to generate Verify Hash if it is correct;
6) The zkSync smart contract on L1 verifies the matching of Commit Hash and Verify Hash;
7) After successful matching, a Verified Transaction is generated and finally uploaded to the blockchain;
8) If the match fails, the original Commit Hash is invalidated, and the Sequencer resubmits the batch to go through the process again.
It should be emphasized here that zkSync adopts "two-phase commit (2PC)", which finally determines the legal transaction batch through the hash verification of the two phases of Commit Hash and Verify Hash. This can ensure the data consistency and security in the system operation process. In my opinion, it is also a manifestation of the decentralized idea of letting the two system components of Sequencer and Validator constrain each other, which is worth praising.
The workflow of zkSync mainly consists of four roles: Relay, Sequencer, zkPorter, and Validator. There are many "unstable factors" in the coordination work. They can be summarized as the stability of node functions, the stability of node collaboration, and the complexity of algorithms and underlying protocols. Errors in any link may lead to block delays. The common Arbitrum Sequencer technical failure is a typical example, and zkSync will face more challenges.
As for algorithm complexity, this is the destiny of the zkSync chain, and it requires the ecosystem developers to work hard to overcome it. As for the stability of node intelligence and collaboration, I think it will be effectively improved after the decentralization stage arrives in the future. The logic is also simple:
1) Multiple distributed nodes can avoid network instability caused by single point failures, which is due to the robustness of the system;
2) The distributed token incentive mechanism can provide developers with the driving force to maintain node stability.
Thinking from another perspective, the long time of Verification is not a problem in the early stage of the ecosystem. It can effectively improve the security of the chain and prevent some nodes in the system from doing evil. In short, if you clarify the entire operation process of zkSync, further understand the technical complexity of layer 2 and the "special" mechanism designed for security, you can consolidate your confidence in the L2 technology track. Welcome everyone to forward and share, DM me at any time, and have in-depth exchanges and learning about zkSync together.