Why is zkSync always "downtime"? An article discussing zkSync Workflow

Question

A friend complained that zkSync is always down. In fact, calling it "downtime" is a bit of an exaggeration. To be precise, it means "unstable block generation". In essence, the final Verified time of the transaction submitted by Sequencer is unstable, but the user's perception is not obvious at the interactive end, because zkSync's Verify design has a confirmation lag. The instability in the future decentralization stage will be alleviated. I drew a workflow to discuss with you.

The reason why users perceive "downtime" may be the transaction failure caused by some DApps and the underlying compatibility of the chain. After all, developing DApps on zkSync itself is a great challenge. It takes about 30 minutes-1 hour for me to observe the status change from Commit to Verified from the official browser, and the user-side interactive DApp is hardly affected by this. This article focuses on the underlying logic of popular science zkSync technology, to bring you a clear understanding of zkSync.

As shown in the workflow, zkSync runs in the following steps:

User sends batch transactions to the Sequencer sorter through relay forwarding;
Sequencer is responsible for sorting transactions, aggregating and packaging batches into Merkle trees;
zkPorter generates a zk-SNARK proof from the Merkle tree;
zk-SNARK proves that relay generates Commit Hash to L2 Validators and L1 main chain respectively
The Validator is responsible for verifying the correctness of the zk-SNARK proof, and submitting it to the L1 smart contract to generate a Verify Hash after it is correct; 6) The zkSync smart contract on L1 verifies the matching of the Commit Hash and Verify Hash; 7) Generates a Verified after successful matching The Transaction transaction is finally uploaded to the chain; 8) If the matching fails, the original Commit Hash will be invalidated, and the Sequencer will resubmit the batch and go through the process again.

It needs to be emphasized here that zkSync adopts "two-phase commit (2PC)", and finally determines the legal transaction batch through the Hash verification of the two stages of Commit Hash and Verify Hash. On the one hand, this can ensure the data consistency and safety in the system operation process. In my personal understanding, it is also a manifestation of the idea of decentralization that restricts the two system components, Sequencer and Validator, and is worthy of praise.

The Workflow of zkSync mainly has four roles: Relay, Sequencer, zkPorter, and Validator. There will be many "unstable factors" in the coordination work. It can be summarized as the stability of node functions, the stability of node cooperation, and the complexity of algorithms and underlying protocols. Any error in any link may cause block delay. Common Arbitrum Sequencer technical failures are typical, and zkSync will only face more challenges.

As for the complexity of the algorithm, this is the destiny of the zkSync chain, and ecological developers need to work hard to overcome it. As for the stability of node intelligence and collaboration, I think that after the coming of the decentralization stage in the future, it will be effectively improved. The logic is also simple:

Multi-distributed nodes can avoid network instability caused by single point of failure, which is due to the robustness of the system;
The distributed token incentive mechanism can provide developers with a source of motivation to maintain node stability.

Thinking from another perspective, the long time of Verifing is not a problem in the early stage of the ecology. 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, and further understand the technical complexity of layer 2 and the "special" mechanism designed for security, you can consolidate your confidence in the L2 technical track. Everyone is welcome to forward and share, DM me at any time, and let's have an in-depth exchange and study of zkSync.

View Original