I saw many friends complaining, so I wrote it down in detail today.
#zkSync's "downtime" is actually "unstable block generation", mainly due to the unstable verification time of transactions submitted by the Sequencer, but this problem is not obvious to user interaction. If users perceive "downtime", it may be due to transaction failure caused by compatibility issues between some DApps and the underlying chain.
#The operation process of zkSync includes:
The user sends batch transactions to the Sequencer through relay forwarding;
The Sequencer is responsible for sorting transactions and aggregating and packaging them into Merkle trees.
zkPorter generates zk-SNARK proof from Merkle tree;
The zk-SNARK proof is relayed to L2 Validators and L1 main chain to generate Commit Hash;
Validator is responsible for verifying the correctness of the zk-SNARK proof and submitting it to the L1 smart contract to generate the Verify Hash.
The zkSync smart contract on L1 verifies the matching of Commit Hash and Verify Hash;
After successful matching, a Verified Transaction is generated and finally uploaded to the chain;
If the match fails, the original Commit Hash is invalidated, and the Sequencer resubmits the batch and goes through the process again.
The way to speak is:
First, users want to perform some operations on the zkSync network, such as sending some assets. They send these operations through a relay in the form of a batch of transactions, like a to-do list. You can think of it as you order food at a restaurant, and these orders (transactions) need to be processed.
This to-do list (batch of transactions) is sent to a sequencer called "Sequencer". This sequencer is like a chef in a restaurant. They process these orders in order, organize these transactions in a certain order, and then package them into a data structure called a Merkle tree. This is like a chef preparing all the dishes and arranging them together for serving.
Then, the Merkle tree is sent to the zkPorter. The zkPorter is like a super checker. They use a special technology called zk-SNARKs to check the Merkle tree. Their job is to generate a proof that the Merkle tree (that is, the batch of transactions) is correct and there is no problem.
This zk-SNARK proof will be sent to the validators of Layer 2 (L2) and Layer 1 (main chain). They will generate something called Commit Hash respectively. You can think of this Commit Hash as a special label that proves that this proof (and the corresponding transaction) has been checked.
The job of the L2 verifier is to check the correctness of the zk-SNARK proof. If everything is correct, they will submit the proof to the smart contract of Layer 1, and the smart contract will generate something called Verify Hash. This Verify Hash can be regarded as a confirmation tag, proving that the transaction has been finally confirmed.
On Layer 1, there is a special smart contract called zkSync smart contract. The job of this contract is to check if the Commit Hash and Verify Hash match. It is like checking if the mailing label and the delivery label of a package are consistent.
If the two hashes match, then the transaction is confirmed and added to the chain, just like you get your dish at a restaurant, and the transaction is complete.
If the two hashes do not match, it means that something went wrong somewhere. In this case, the original Commit Hash will be discarded, just like discarding an incorrect order. Then, the sequencer will resubmit a batch of transactions, and the whole process will go through again until all problems are resolved and all transactions are processed correctly.
zkSync adopts "two-phase commit (2PC)", which finally determines the legal transaction batch through hash verification in the two stages of Commit Hash and Verify Hash, thus ensuring the consistency and security of data in the system operation process.
The workflow of zkSync mainly involves four roles: Relay, Sequencer, zkPorter, and Validator. There are many unstable factors in this coordination process, including 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. So rather than calling it a downtime, it is better to say that it is due to the long workflow and unstable block generation.
