The first part of the zkEVM series: the overall architecture and transaction execution process of Polygon zkEVM

Author: 0xhhh, Ethstorage（Twitter:@hhh69251498 ）

Editor:Red One

On March 27th, the beta version of the Polygon zkEVM mainnet was officially launched, and Vitalik completed its first transaction on it.

This article is the first in a series of articles on Polygon zkEVM, which briefly describes the overall architecture and transaction execution process of Polygon zkEVM, and analyzes how Polygon zkEVM achieves computational scaling while inheriting the security of Ethereum.

In the next two articles, we will also detail the design details of Polygon zkEVM’s zkEVM Bridge and zkEVM, as well as the roadmap for Polygon zkEVM’s next decentralized Sequencer.

First, Rollup is to achieve computational scaling for Ethereum

First, we need to be clear about how Rollups work. The emergence of Rollup is to scale the computation of Ethereum, the specific implementation method is to outsource the execution of transactions to Rollup, and then store the transaction and the state (State) after transaction execution in the Ethereum contract.

Optimistic Rollup

Optimistically, the Rollup Transaction and the corresponding Rollup State sent to Ethereum are correct, and anyone can challenge a Rollup State that is still in the challenge period by providing a Fraud Proof.

Zero-knowledge Rollup

ZK will provide a validity proof for the rollup transaction sent to Ethereum and the corresponding rollup state (verified by the contract on Ethereum to prove that the rollup is in the correct state after the execution of the corresponding transaction).

Refer to the official definition of Ethereum:

The biggest difference between Zero-knowledge Rollup and Optimistic Rollup is that the time to reach finality is different due to the different ways of verifying the validity of the state.

Optimistic Rollup is optimistic that the transactions and statuses 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 a transaction on Ethereum is incorrect can challenge by submitting the correct status.

The time it takes for a Zero-knowledge Rollup (zk-Rollup) to reach finality depends on the time it takes for the Validity Proof of the transaction to be submitted to Ethereum and verified. At present, it may be around 1 hour for finality (because of the need to consider the cost of gas).

Second, Polygon zkEVM execution process

Let’s take a look at how Polygon zkEVM works with a simple transaction confirmation process, so as to have a concrete understanding of the overall protocol, and its whole process can be divided into three main steps:

1. Sequencer packages multiple user transactions into batches and submits them to the L1 contract.

2. Prover generates a Validity Proof for each transaction and aggregates the validity proofs of multiple transactions into a single Proof of Validity.

3. Aggregator submits Validity Proof of aggregator aggregated multiple transactions into the L1 contract.

1 Sequencer packages user transactions into batches and submits them to the L1 contract.

1. The user sends the transaction to Sequencer, and Sequencer will process the transaction locally in the order of receipt (FRFS), when Sequencer executes the transaction locally, if the user believes that Sequencer is honest, then he can consider the transaction to have reached finality. It is important to note here that most of the Mempools within Sequencer are currently private, so there are relatively few MEVs that can be obtained for the time being.

2. Sequencer will pack multiple transactions into a batch (currently only one transaction in a batch) and then send multiple batches together to the transaction Calldata of L1 via the SequenceBatch() function of PolygonZKEvm.sol on L1.

(It should be noted that multiple batches are submitted at once in order to reduce the gas consumption of L1 as much as possible.)

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 in the following figure.

4) The order of transactions in each batch is also determined, so when the order of the batch is determined, we consider the order of all transactions that are included in the batch to be submitted to the L1 Polygon zkEVM contract have been determined.

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

**2. Aggregator generates Validity Proof for multiple batches of transactions

1. When the Aggregator listens to the successful submission of new batches in the PolyonZKEVM.sol contract on L1, it synchronizes these batches to its node and sends these transactions to zkProver.

2. After receiving these transactions, zkProver will generate a Validity Proof for each transaction, and then aggregate the Validity Proof of the transactions contained in multiple batches into a Validity Proof.

3. zkProver sends the Validity Proof of aggregating multiple transactions to Aggregator.

3. Aggregator submits the contract for aggregate proofs to L1

Aggregator will submit this Validity Proof to the Polygon zkEvm.sol contract on L1 along with the corresponding state of the batch execution by calling the following method:

The following actions are then performed within the contract to verify that the state transition is correct.

When this step is successfully executed in the L1 contract, all transactions included in this part of the batch will truly reach Finality (corresponding to the end of the 7-day challenge period of OP).

3. Ethereum’s role in Polygon-zkEVM

Now that we’ve looked at the overall process of Polygon zkEVM, let’s review what Ethereum has done for Rollup:

In the first step, Sequencer collects the rollup transactions and packages them into batches, which are then submitted to the L1 contract. L1 not only provides the functionality of the DA layer, but also actually completes some of the transaction ordering functions, when you submit a transaction to Sequencer, the transaction is not really ordered, because Sequencer has the power to change the order of transactions at will, but when the transaction is included in the Batch and submitted to the L1 contract, no one has the right to change the order of transactions.

In the second step, Aggregator brings the Validity Proof to the L1 contract to reach the new state, the Aggregator is a Proposer-like role, and the contract is similar to the Validator role, and the Aggregator provides a Validity Proof to prove that the new state is correct and tells the Validator the Validity I provide What transaction batches are involved in Proof, and where are they 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, and if the verification is successful, the contract will actually be updated to the new state of the corresponding Validity Proof.

Fourth, structure the Smart Contract Rollup from the perspective of modularity

If from the perspective of modularity, Polygon zkEVM belongs to the Smart Contract Rollup type, we can try to deconstruct its modules, and from the diagram given by Delphi, we can also see that Polygon ZkEVM is actually the Consensus Layer, DA Layer and Settlement of Smart Contrat Rollup Layers are actually coupled to the PolygonZkEVM.sol contract, which is not well distinguished. But let’s try to deconstruct the modules:

Data Availability Layer: Where rollup transactions are stored, and in the case of Polygon-zkEVM, when Sequencer calls the SequenceBatch() method, it actually includes the submission of transaction data to the DA layer.

Settlement Layer: Specifically refers to the mechanism of money flow between Rollup and L1, specifically the official bridge of Polygon-zkEVM (more on this in the next article).

Consensus Layer: Contains the ordering of transactions and how to determine the next valid state (fork selection), Sequencer completes the ordering of transactions when it calls SequenceBatch() in the L1 contract, and confirms the next legal state when Aggregator calls TustedVerifyBatches() in the L1 contract.

Execution Layer: The process by which a transaction is executed and a new world state is obtained, when the user submits a transaction to Sequencer, and the new state is obtained after the Sequencer is executed ( That’s why we tend to say that Rollups are computational scaling, because L1 outsources the process of executing transactions to get a new state to Rollups, and Sequencer delegates zkProver to help generate Validity Proof through Aggregator.

5. Why Polygon-zkEVM inherits the security of L1

Judging from the overall process described above, Sequencer actually does something similar to Ethereum Proposer, proposing that a batch of transactions are valid transactions, and giving the new state of this batch of transactions after execution, and the verification logic of the L1 contract is equivalent to all L1 validators will be executed in their own Ethereum clients, in fact, all Ethereum validators act as validators of Rollup, so we think Polygon zkEVM Inherited the security of Ethereum.

On the other hand, because all transactions and state of Rollups are stored on Ethereum, even if the Polygon zkEVM team runs away, anyone will still have the ability to recover the entire Rollup network based on the data stored on Ethereum.

6. Polygon zkEVM incentive mechanism

Rollup incentives are primarily about how to make Sequencer and Aggregator profitable and thus keep the work going?

First of all, users need to pay their own transaction fees on Rollup, which are denominated in ETH and paid in Bridged ETH.

Sequencer will need to pay the cost of uploading the Batch containing the Rollup transaction to the Calldata of the L1 transaction (the cost of calling SequenceBatch(batches()), and the Matic will need to pay a certain amount of Matic to the L1 contract at the same time as the batch is uploaded, which will later pay the cost of Aggregator providing Validity Proof for these Batches.

While Aggregator calls trusted VerifyBatches to provide Validity Proof for Batches in the L1 contract that have not yet been finality, Sequencer can also take out the MATIC tokens paid in advance by Sequencer in the contract as a reward for providing Validity Proof.

Sequencer’s revenue = gas fees for all transactions in the rollup - L1 network gas fees spent uploading Batches to L1 - attestation fees paid to Aggregator (MATIC denomination).

Aggregator’s Revenue = MATIC Rewards Paid by Sequencer - Gas Fees Submitted to Validity Proof to L1 - Hardware Fees Spent Generating Validity Proofs.

Adjust the attestation fee paid to the Aggregator, and in order to prevent Sequencer from being unprofitable to strike, the following mechanism is provided to adjust the attestation fee paid by Sequencer to the Aggregator.

There is a method in the contract that adjusts the cost of providing proofs for batches:

function _updateBatchFee(uint64 newLastVerifiedBatch) internal

It changes a variable in the contract called BatchFee, which determines the amount of MATIC tokens that Sequencer pays for each batch.

The mechanism of change is as follows:

The contract maintains a variable VeryBatchTimeTarget that represents the expected state of each batch to be validated within that time after being committed to L1 by Sequencer.

The contract will record all the batches that have not been validated after exceeding the VeryBatchTimeTarget, and the total number of these batches will be recorded as DiffBatches.

Therefore, when a Batches is late, the BatchFee will be adjusted with the following formula:

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

FunctionsetMultiplier BatchFee(uint16newMultiplierBatchFee) public onlyAdmin

It should be noted that the use of MultiplierBatchFee and 10^3 here is to achieve the adjustment accuracy after 3 decimal points.

Similarly, if the batches are in advance, the corresponding batchFee adjustment mechanism will be triggered: DiffBatches indicates the number of batches in the early verification state.

Summary

In this article, we sort out the core mechanism of Polygon zkEVM and analyze its feasibility of achieving Ethereum computational scaling. With an overall outline, in the following articles we will dive into the interior of the protocol, analyzing the design details of the zkEVM Bridge, the decentralization route of Sequencer, the implementation of zkProver, and the design principles of zkEVM.

——To be continued——