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 test version of the Polygon zkEVM mainnet was officially launched, and Vitalik completed the first transaction on it.

This article is the first in a series about Polygon zkEVM, briefly explaining the overall architecture and transaction execution process of Polygon zkEVM, and analyzing how Polygon zkEVM achieves computational scalability while inheriting the security of Ethereum.

In the next two articles, we will also provide detailed introductions to the zkEVM Bridge and the design details of zkEVM, as well as the roadmap for the upcoming decentralized Sequencer of Polygon zkEVM.

1. Rollup for Computational Scalability on Ethereum

First, we need to clarify the general working principle of Rollup. The emergence of Rollup aims to achieve computational scalability for Ethereum, specifically by outsourcing the execution of transactions to Rollup, and storing the transactions and the post-execution state in Ethereum's contracts. Due to different technical routes, two types of Rollup have evolved:

Optimistic Rollup
Assumes that the Rollup transactions sent to Ethereum and the corresponding Rollup states are correct. Anyone can challenge the Rollup state that is still in the challenge period by providing a Fraud Proof.

Zero-knowledge Rollup
ZK provides a validity proof for the Rollup transactions sent to Ethereum and the corresponding Rollup states (verified by contracts on Ethereum to prove that the state after executing the Rollup corresponds to the correct transaction).

Refer to the official Ethereum definition:
https://ethereum.org/en/developers/docs/scaling/#rollups
The biggest difference between Zero-knowledge Rollup and Optimistic Rollup is the different methods of verifying state validity, which leads to different times to achieve Finality;
Optimistic Rollup optimistically assumes that the transactions and states submitted to Ethereum are correct, so there is a 7-day challenge period (the time to achieve Finality is 7 days). During this period, anyone who finds that the state corresponding to a transaction on Ethereum is incorrect can challenge it by submitting the correct state.
The time to achieve Finality for Zero-knowledge Rollup (zk-Rollup) depends on the time taken to submit the validity proof for the transaction to Ethereum and verify it. Currently, the Finality time is mostly around 1 hour (considering Gas cost issues).

2. Polygon zkEVM Execution Process

Next, let's look at how Polygon zkEVM works through a simple transaction confirmation process, providing a concrete understanding of the overall protocol. The entire process can be mainly divided into three steps:

1. The Sequencer packages multiple user transactions into a Batch and submits it to the L1 contract;
2. The Prover generates a validity proof for each transaction and aggregates the validity proofs of multiple transactions into one validity proof;
3. The Aggregator submits the aggregated validity proof of multiple transactions to the L1 contract.
   
4. The Sequencer packages user transactions into a Batch and submits it to the L1 contract.

1) Users send transactions to the Sequencer, which processes them locally in the order they are received (FRFS). Once the Sequencer successfully executes the transactions locally, if the user believes the Sequencer is honest, they can consider the transaction to have achieved Finality at this point. It is important to note that most Sequencer's internal Mempools (transaction pools) are currently private, so the MEV that can be obtained is relatively small.
2) The Sequencer will package multiple transactions into a Batch (currently, a Batch only contains one transaction) and after collecting multiple Batches, it will send them together to the L1 transaction Calldata through the SequenceBatch() function of PolygonZKEvm.sol on L1.

(Note that submitting multiple Batches at once is to minimize L1 Gas consumption)

3) When PolygonZkEvm.sol receives the Batches provided by the Sequencer, it will sequentially calculate the hash of each Batch in the contract, then record the hash of the previous Batch in the subsequent Batch, thus obtaining the Batch structure shown in the figure below.

4) The order of transactions within each Batch is also determined, so once the order of the Batches is confirmed, we consider that the order of all transactions included in the Batch submitted to the L1 Polygon zkEVM contract is also determined.

The above actual process is also the work that L1 needs to complete as the Rollup DA layer (at this point, no state verification or advancement work has been completed).

2. The Aggregator Generates Validity Proof for Multiple Batch Transactions

1) When the Aggregator detects that a new Batch has been successfully submitted to the L1 PolygonZKEVM.sol contract, it will synchronize these Batches to its node and then send these transactions to the zkProver.
2) After the zkProver receives these transactions, it will generate a Validity Proof for each transaction and then aggregate the Validity Proofs of the transactions contained in multiple Batches into one validity proof (Validity Proof).

3) The zkProver sends the aggregated Validity Proof of multiple transactions to the Aggregator.

3. The Aggregator Submits the Aggregated Proof to the L1 Contract

The Aggregator will submit this validity proof (Validity Proof) along with the corresponding post-execution states of these Batches to the L1 Polygon zkEvm.sol contract by calling the following method:

The contract will then execute 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 batch will have truly achieved Finality (corresponding to the end of the 7-day challenge period for OP).

3. The Role of Ethereum in Polygon-zkEVM

In the above text, we have understood the overall process of Polygon zkEVM. We can review what work Ethereum has done for Rollup:

In the first step, the Sequencer collects Rollup transactions, packages them into Batches, and submits them to the L1 contract. L1 not only provides DA layer functionality but also completes part of the transaction ordering function; when you submit a transaction to the Sequencer, the transaction is not truly ordered because the Sequencer has the power to change the order of transactions at will. However, once the transactions are included in a Batch and submitted to the L1 contract, no one has the right to modify the order of those transactions.

In the second step, the Aggregator brings the Validity Proof to the L1 contract to achieve a new state. The Aggregator acts similarly to a Proposer, while the contract acts like a Validator; the Aggregator provides a Validity Proof to prove that a new state is correct and informs the Validator which transaction Batches the Validity Proof involves and where they exist in L1.

Then, the Validator extracts the corresponding Batches from the contract, and by combining them with the Validity Proof, can verify the legality of the state transition. If the verification is successful, the contract will also update to the new state corresponding to the Validity Proof.

4. Structuring Smart Contract Rollup from a Modular Perspective

From a modular perspective, Polygon zkEVM belongs to the Smart Contract Rollup type. We can attempt to deconstruct its various modules. From the diagram provided by Delphi, we can also see that Polygon zkEVM, as the Consensus Layer of Smart Contract Rollup, has the DA Layer and Settlement Layer actually coupled within the PolygonZkEVM.sol contract, making it difficult to distinguish. However, we will 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 capital flow mechanism between Rollup and L1, specifically the official bridge of Polygon-zkEVM (which will be detailed in the next article).

Consensus Layer: Includes transaction ordering and how to determine the next valid state (fork choice). The Sequencer completes the transaction ordering when calling the SequenceBatch() in the L1 contract, and the Aggregator completes the confirmation of the next valid state when calling TrustedVerifyBatches() in the L1 contract.

Execution Layer: Executes transactions and obtains the new world state. This is the process when users submit transactions to the Sequencer, and the Sequencer executes them to obtain the new state (which is why we often say Rollup is computational scalability, as L1 outsources the process of executing transactions to obtain the new state to Rollup, while the Sequencer delegates zkProver to help generate Validity Proof through the Aggregator).

5. Why Polygon-zkEVM Inherits the Security of L1

From the overall process introduced above, it can be seen that the Sequencer performs work similar to that of Ethereum Proposers, proposing a batch of transactions as valid transactions and providing the new state after executing this batch of transactions. The verification logic of the L1 contract is equivalent to all L1 Validators executing it in their Ethereum clients, effectively making all Ethereum validators act as Rollup validators. Therefore, we believe that Polygon zkEVM inherits the security of Ethereum.

From another perspective, since all Rollup transactions and states are stored on Ethereum, even if the Polygon zkEVM team were to run away, anyone would still have the ability to 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 Sequencers and Aggregators profitable to maintain continuous work?

First, users need to pay transaction fees for their transactions on Rollup, which are denominated in ETH and paid using Bridged ETH.

The Sequencer needs to pay the cost of uploading these Batches containing Rollup transactions to the L1 transaction Calldata (the cost of calling SequenceBatch(batches())), and at the same time, needs to pay a certain amount of Matic to the L1 contract when uploading the Batch, which will be used to pay the Aggregator for providing Validity Proof for these Batches later.

The Aggregator, while calling TrustedVerifyBatches to provide Validity Proof for Batches that have not yet achieved Finality in the L1 contract, can also withdraw the MATIC tokens that the Sequencer has paid in advance in the contract as a reward for providing Validity Proof.

The Sequencer's income = Gas fees for all Rollup transactions - L1 network Gas fees for uploading Batches to L1 - Fees paid to Aggregator for proof (denominated in MATIC).

The Aggregator's income = MATIC rewards paid by the Sequencer - Gas fees for submitting Validity Proof to L1 - Hardware costs incurred for generating Validity Proof.

To adjust the proof fees paid to the Aggregator, and to avoid the Sequencer going on strike due to lack of profit, the following mechanism is provided to adjust the proof fees paid by the Sequencer to the Aggregator.

The contract contains a method to adjust the proof fees for providing proof for Batches:

function _updateBatchFee(uint64 newLastVerifiedBatch) internal

This will change a variable in the contract named BatchFee, which determines the amount of MATIC tokens the Sequencer pays for each Batch.

The adjustment mechanism is as follows:

The contract maintains a variable called VeryBatchTimeTarget, which represents the expected time for each Batch to be verified after being submitted to L1 by the Sequencer.

The contract will record all Batches that have not been verified after exceeding VeryBatchTimeTarget, and the total number of these Batches will be referred to as DiffBatches.

Thus, when there are late Batches, the following formula will be used to adjust BatchFee:

MultiplierBatchFee is a number limited to the range of 1000~1024, which can be changed by the contract administrator through the function setMultiplierBatchFee():

Function setMultiplierBatchFee(uint16 newMultiplierBatchFee) public onlyAdmin

It is important to note that the use of MultiplierBatchFee and 10^3 is to achieve adjustment precision to three decimal places.


Similarly, if Batches are early, the corresponding batchFee adjustment mechanism will also be triggered: DiffBatches represents the number of Batches that have been verified early.

Summary

In this article, we have outlined the core mechanisms of Polygon zkEVM and analyzed its feasibility in achieving computational scalability for Ethereum. With an overall outline in place, we will delve deeper into the internal protocol in the upcoming articles, sequentially analyzing the design details of the zkEVM Bridge, the decentralization roadmap of the Sequencer, the implementation of zkProver, and the design principles of zkEVM.