The operation mechanism of zkSync is sorted out, it does not "downtime" frequently

I saw a friend complaining that @zkSync is always down. In fact, calling it "downtime" is a bit of an exaggeration. To be precise, it is "unstable block generation".

Essentially, 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 problem caused by the compatibility between some DApps and the bottom layer of the chain. After all, developing DApps on zkSync itself is very challenging.

It takes about 30min-1 hour for me to observe the status change from Commit to Verified from the official browser, while the user-side interactive DApp is hardly affected by this.

This article focuses on the underlying logic of popular science zkSync technology, and brings you a clear understanding of zkSync.

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

1. User sends batch transactions to the Sequencer through relay forwarding;

2. Sequencer is responsible for sorting transactions, aggregating and packaging batches into a Merkle tree;

3. zkPorter generates zk-SNARK certificates from the Merkle tree; zk-SNARK certificates are respectively relayed to L2 Validators and L1 main chain to generate Commit Hash; Validators are responsible for verification

4. The correctness of the zk-SNARK proof is submitted to the L1 smart contract to generate a Verify Hash;

5. The zkSync smart contract on L1 verifies the matching of Commit Hash and Verify Hash;

6. After successful matching, a Verified Transaction is generated and the transaction is finally uploaded to the chain;

7. 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 in 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 restrains the two system components, Sequencer and Validator, and is worthy of praise.

zkSync's Workflow 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:

Multiple distributed nodes can avoid network instability caused by a single point of failure, and the system is robust; the distributed token incentive mechanism can provide developers with a source of motivation to maintain node stability.

Thinking from another angle, 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 strengthen your confidence in the L2 technical track.