/earn
paelapel
·
2 years ago
ZkSync
The general rollup workflow is as follows:
•Users can receive, deposit, and transfer assets to each other.
•Users can withdraw assets under their control to an L1 address.
Rollup operation requires the assistance of an operator, who rolls transactions together, computes a zero-knowledge proof of the correct state transition, and affects the state transition by interacting with the rollup contract. To understand the design, we need to look into how zkSync rollup transactions work.
zkSync operations are divided into rollup transactions (initiated inside rollup by a rollup account) and priority operations (initiated on the mainchain by an Ethereum account).
The zkSync rollup operation lifecycles are as follows:
•A user creates a transaction or a priority operation.
•After processing this request, the operator creates a rollup operation and adds it to the block.
•Once the block is complete, the operator submits it to the zkSync smart contract as a block commitment. Part of the logic of some rollup operations is checked by the smart contract.
•The proof for the block is submitted to the zkSync smart contract as block verification. If the verification succeeds, the new state is considered final.
Furthermore, on zkSync, each L2 block will progress through the following four stages until it is final.
•Pending: The transaction was received by the operator, but it has not been processed yet.
•Processed: The transaction is processed by the operator and is confirmed to be included in the next block.
•Committed: This indicates that the transaction data of this block has been posted on Ethereum. It does not prove that it has been executed in a valid way, but it ensures the availability of the block data.
•Finalized: This indicates that the SNARK validity proof for the transaction has been submitted and verified by the smart contract. After this step, the transaction is considered to be final.
The typical time for a transaction to go from Processed to Finalized is a couple of hours at the current stage.
Please note that for developer convenience, we usually treat the Processed and Committed states as a single stage called Committed since they have no difference from the UX/DexEx standpoints.
2 comments