Detailed explanation of the overall architecture and transaction execution process of Polygon ZkEVM

Author: 0xhhh（Twitter: @hhh69251498 ），Binary DAO
Editor: Red One
On March 27, the Polygon zkEVM mainnet test version was officially launched, and Vitalik completed the first transaction on it.
This article is the first in a series of articles on Polygon zkEVM. It briefly explains the overall architecture and transaction execution process of Polygon zkEVM, and analyzes how Polygon zkEVM achieves computing expansion while inheriting the security of Ethereum.
At the same time, the design details of Polygon zkEVM’s zkEVM Bridge and zkEVM, as well as the roadmap of Polygon zkEVM’s subsequent decentralized sequencer, will be introduced in detail in the next two articles.
 
1. Rollup to achieve computing expansion for Ethereum
First, we need to understand the general working principle of Rollup. Rollup was created to expand the computing capacity of Ethereum. The specific implementation method is to outsource the execution of transactions to Rollup, and then store the transactions and the state after the transaction execution in the Ethereum contract. Due to different technical routes, two types of Rollup have evolved:
Optimistic Rollup optimistically believes that the Rollup transaction (Rollup Transaction) and the corresponding Rollup state (Rollup State) sent to Ethereum are correct, and anyone can challenge (Challenge) the Rollup State that is still in the challenge period by providing a fraud proof (Fraud Proof).
Zero-knowledge RollupZK will provide a validity proof for the Rollup transaction and the corresponding Rollup state sent to Ethereum (verified by the contract on Ethereum to prove that the state of the Rollup after executing the corresponding transaction is correct).
Refer to the official definition of Ethereum: https://ethereum.org/en/developers/docs/scaling#rollupsThe biggest difference between Zero-knowledge Rollup and Optimistic Rollup is that the different ways of verifying the validity of the state lead to different times for reaching Finality; Optimistic Rollup optimistically believes that the transactions and states submitted to Ethereum are correct, so there is a 7-day challenge period (the time to reach Finality is 7 days), during which anyone who finds that the corresponding state of the transaction on Ethereum is incorrect can challenge it by submitting the correct state. The time it takes for Zero-knowledge Rollup (zk-Rollup) to reach Finality depends on: the time it takes for the validity proof (Validity Proof) corresponding to the transaction to be submitted to Ethereum and verified. At present, the Finality of about 1 hour is mostly possible (because the Gas cost issue needs to be considered).
2. Polygon zkEVM Execution Process
Next, let’s take a look at how Polygon zkEVM works with a simple transaction confirmation process, so as to have a specific understanding of the overall protocol. Its entire process can be divided into three main steps:
1. Sequencer packages multiple user transactions into a batch and submits it to the L1 contract; 2. Prover generates a validity proof for each transaction and aggregates the validity proofs of multiple transactions into one validity proof; 3. Aggregator submits the validity proof of multiple transactions aggregated into the L1 contract. 1. Sequencer packages user transactions into a batch and submits it to the L1 contract
1) The user sends the transaction to the Sequencer, and the Sequencer will process it locally in the order in which the transactions are received (FRFS). When the Sequencer successfully executes the transaction locally, if the user believes that the Sequencer is honest, then he can think that the transaction has reached Finality at this time. It should be noted here that the Mempool (transaction pool) inside most Sequencers is private, so the MEV that can be obtained for the time being is relatively small.      2) The Sequencer will pack multiple transactions into a Batch (currently a Batch contains only one transaction) and then after collecting multiple Batches, the SequenceBatch() function of PolygonZKEvm.sol on L1 will send multiple Batches together to the transaction Calldata of L1.
(Note that submitting multiple Batches at one time is to minimize L1 Gas consumption)
3) When PolygonZkEvm.sol receives the Batches provided by Sequencer, it will calculate the hash of each Batch in the contract in turn, and then record the hash of the previous Batch in the next Batch, so we get the Batch structure shown in the figure below.
4) The order of transactions in each Batch is also determined, so when the order of the Batch is determined, we believe that the order of all transactions included in the Batch and submitted to the Polygon zkEVM contract on L1 is determined.
The above actual process is also the work that L1 needs to complete as the Rollup DA layer (no status verification or advancement work is completed at this time).
2. Aggregator generates Validity Proof for multiple batch transactions
1) When the Aggregator detects that a new batch has been successfully submitted in the PolyonZKEVM.sol contract of L1, it will synchronize these batches to its own node and then send these transactions to zkProver. 2) After receiving these transactions, zkProver will generate a Validity Proof for each transaction in parallel, and then aggregate the Validity Proofs of transactions contained in multiple batches into one Validity Proof. 3) zkProver sends the Validity Proofs of multiple transactions aggregated to the Aggregator.
 
3. Aggregator submits aggregation proof to L1 contract
Aggregator will submit this validity proof and the corresponding status of these batches after execution to the Polygon zkEvm.sol contract of L1, and call the following method: The contract will then perform the following operations to verify whether the state transition is correct. When this step is successfully executed in the L1 contract, all transactions contained in this part of the batch will truly reach Finality (corresponding to the end of the OP's 7-day challenge period).
 
3. Ethereum’s role in Polygon-zkEVM
We have learned about the overall process of Polygon zkEVM above. Let's review what Ethereum does for Rollup: In the first step, Sequencer collects Rollup transactions and packages them into Batch, and then submits them to the L1 contract. L1 not only provides the functions of the DA layer, but also completes some transaction sorting functions; when you submit transactions to Sequencer, the transactions are not really sequenced, because Sequencer has the power to change the order of transactions at will, but when the transactions are included in the Batch and submitted to the L1 contract, no one has the right to modify the transaction order.
In the second step, Aggregator brings the Validity Proof to the L1 contract to achieve a new state. Aggregator plays a role similar to Proposer, and the contract plays a role similar to Validator. Aggregator provides a Validity Proof to prove that a new state is correct, and tells Validator which transaction batches are involved in the Validity Proof I provided, and where they are stored in L1.
Then the Validator extracts the corresponding Batch from the contract and combines it with the Validity Proof to verify the legitimacy of the state transition. If the verification is successful, the contract will actually be updated to the new state corresponding to the Validity Proof.
4. Structuring Smart Contract Rollup from a modular perspective
From the perspective of modularization, Polygon zkEVM belongs to the Smart Contract Rollup type. We can try to deconstruct its modules. From the diagram given by Delphi, we can also see that Polygon ZkEVM is actually the Consensus Layer of Smart Contract Rollup. The DA Layer and Settlement Layer are actually coupled in the PolygonZkEVM.sol contract and cannot be distinguished well. But we try to deconstruct each module:
Data Availability Layer: The place where Rollup transactions are stored. For Polygon-zkEVM, when the Sequencer calls the SequenceBatch() method, it actually includes submitting transaction data to the DA layer.
Settlement Layer: Specifically refers to the fund flow mechanism between Rollup and L1, specifically refers to the official bridge of Polygon-zkEVM (which will be introduced in detail in the next article).
Consensus Layer: Contains transaction sorting and how to determine the next legal state (fork selection). When Sequencer calls SequenceBatch() in the L1 contract, it completes the transaction sorting work. When Aggregator calls TustedVerifyBatches() in the L1 contract, it completes the work of confirming the next legal state.
Execution Layer: Execute transactions and obtain a new world state. When a user submits a transaction to the Sequencer, the Sequencer obtains a new state after execution (so we often say that Rollup is computing expansion, because L1 outsources the process of executing transactions to obtain a new state to Rollup, and the Sequencer will entrust zkProver to help generate Validity Proof through the Aggregator.
5. Why Polygon-zkEVM inherits the security of L1
From the overall process described above, the Sequencer actually does a similar job to the Ethereum Proposer, proposing a batch of transactions as valid transactions and giving the new status of these transactions after execution; and the verification logic of the L1 contract is equivalent to all L1 validators being executed in their own Ethereum clients. In fact, all Ethereum validators act as Rollup validators, so we believe that Polygon zkEVM inherits the security of Ethereum.
From another perspective, because all transactions and status of Rollup are stored on Ethereum, even if the Polygon zkEVM team runs away, anyone can still restore the entire Rollup network based on the data stored on Ethereum.
6. Polygon zkEVM Incentive Mechanism
The Rollup incentive mechanism mainly refers to how to make Sequencer and Aggregator profitable so as to maintain continuous work? First of all, users need to pay their own transaction fees on Rollup. This part of the fee is denominated in ETH and paid with Bridged ETH.
The Sequencer needs to pay the cost of uploading the Batches containing the Rollup transactions to the Calldata of the L1 transaction (the cost of calling SequenceBatch(batches()), and at the same time, it needs to pay a certain amount of Matic to the L1 contract when uploading the Batch, which will be used to pay the cost of the Aggregator to provide Validity Proof for these Batches.
When the Aggregator calls trusted VerifyBatches to provide Validity Proof for the Batches in the L1 contract that have not yet been Finalized, it can also withdraw the MATIC tokens paid in advance by the Sequencer in the contract as a reward for providing Validity Proof.
Sequencer’s income = Gas fees of all Rollup transactions - L1 network Gas fees spent on uploading Batches to L1 - Proof fees paid to Aggregator (denominated in MATIC).
Aggregator’s income = MATIC reward paid by Sequencer - Gas fee submitted to Validity Proof to L1 - Hardware fee spent on generating Validity Proof.
Adjust the proof fee paid to the Aggregator. In order to avoid the Sequencer from going on strike due to unprofitability, the following mechanism is provided to adjust the proof fee paid by the Sequencer to the Aggregator.
There is a method in the contract to adjust the cost of providing proof for Batch:
function _updateBatchFee(uint64 newLastVerifiedBatch) internal
It changes a variable in the contract called BatchFee, which determines the number of MATIC tokens that the Sequencer pays for each Batch.
The change mechanism is as follows:
The contract maintains a variable VeryBatchTimeTarget, which represents the expected verification status within this time after each Batch is submitted to L1 by the Sequencer.
The contract will record all the Batches that have not been verified after VeryBatchTimeTarget, and the total number of these Batches will be recorded as DiffBatches.
So when Batches are late, the BatchFee will be adjusted using the following formula:
MultiplierBatchFee is a number limited to the range of 1000~1024, and can be changed by the contract administrator through the function setMultiplierBatchFee():
Function setMultiplier BatchFee (uint16newMultiplierBatchFee) public onlyAdmin
It should be noted that MultiplierBatchFee and 10^3 are used here to achieve the adjustment accuracy after 3 decimal points. Similarly, if the batches are advanced, the corresponding batchFee adjustment mechanism will be triggered: DiffBatches indicates the number of batches with advanced verification status. Summary
In this article, we have sorted out the core mechanisms of Polygon zkEVM and analyzed its feasibility in achieving Ethereum computing expansion. With an overall outline, in the following articles we will go deep into the protocol, analyze the design details of zkEVM Bridge and the decentralized route of Sequencer, the implementation of zkProver and the design principles of zkEVM.