Flash Depth Data Forum

Forum

Search Extension

Polygon zkEVM's overall architecture and trade execution process

2023-03-29 18:23

Read this article in 225 Minutes

This paper briefly describes the overall architecture of Polygon zkEVM and transaction execution process, and analyzes how Polygon zkEVM implements computing capacity expansion and inherits the security of Ethereum.

The original title: "zkEVM series (1) | Polygon zkEVM overall architecture and trade execution process"

0xhhh, Binary DAO

On March 27, Polygon zkEVM mainnet Beta went live, and Vitalik made its first transaction on it.

This article, the first in a series of Polygon zkEVM articles, provides a brief overview of Polygon zkEVM's overall architecture and transaction execution process, as well as an analysis of how Polygon zkEVM implements computing expansion while inherits Ethereum's security.

In the meantime, the next two articles will introduce the zkEVM Bridge and design details of Polygon zkEVM, as well as the roadmap of Polygon zkEVM's subsequent decentralized Sequencer.

Rollup To implement computing expansion for Ethereum

First, we need to understand roughly how Rollup works. Rollup was created to expand computing capacity in Ethereum by outsourcing the execution of trades to Rollup, and then storing trades and the post-execution State in Ethereum contracts. Two types of Rollup have evolved due to different technical routes:

Optimistic Rollup

Optimistic that the Rollup Transaction sent to Ethereum and the corresponding Rollup State are correct, anyone can provide proof of Fraud (Fraud Challenge the Rollup State that is still in challenge.

Zero-knowledge Rollup

ZK provides a proof of validity for the Rollup transaction sent to Ethereum and the corresponding Rollup status (verified by the contract on Ethereum to prove that the status of the Rollup transaction is correct after it executes the corresponding transaction). .

Refer to the official Ethereum definition

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

Optimistic Rollup is optimistic that the trades and states submitted to Ethereum are correct, so there is a challenge period of 7 days (7 days to reach Finality). Anyone who finds that the corresponding state of a transaction on Ethereum is incorrect can challenge it by submitting the correct state.

The time of Finality reached by Zero-knowledge Rollup(zk-Rollup) depends on the time it takes for the Validity Proof of the transaction to be submitted to Ethereum and verified. Currently, Finality is likely to be around 1 hour (because Gas costs need to be taken into account).

Ii. Polygon zkEVM Execution Flow

Let's take a look at how Polygon zkEVM works in a simple transaction confirmation process to get a concrete understanding of the overall protocol, which can be broken down into three steps:

1. Sequencer packaged multiple user transactions into batches and submitted them to the contract of L1.

2. Prover generates Validity Proof for each transaction and aggregates the validity proof of multiple transactions into one validity proof;

3. Aggregator submitted the Validity Proof of multiple transactions into L1 contracts.

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

1) The user sends the transaction to Sequencer, and Sequencer will process the transaction in local order according to the speed of receiving the transaction (FRFS). After Sequencer successfully executes the transaction on local, if the user believes that Sequencer is honest, Then he can consider the Finality of the transaction at this time. It should be noted here that at present most mempools (trading pools) in Sequencer are private, so few MEVs can be obtained temporarily.

2) Sequencer will pack multiple transactions into a Batch (currently only one transaction is included in a Batch) and then use on L1 after collecting multiple Batches. The SequenceBatch() function of PolygonZKEvm.sol Batches multiple batches to the transaction Calldata of L1.

(Please note that Batches are submitted in order to minimize L1 Gas consumption.)

3) When PolygonZkEvm.sol After receiving the Batches provided by Sequencer, they will then hash each Batch in the contract in sequence and record the hash of the previous Batch in the latter Batch, thus giving us the Batch structure shown below.

4) The order of transactions in each Batch is also determined, so after the order of the Batch is determined, we believe that the order of all transactions included in the Polygon zkEVM contract submitted by the Batch to L1 has been determined.

The actual process above is what L1 needs to do to act as the Rollup DA layer (no status checking or advancement is done at this time).

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

1) When Aggregator detects that new Batch has been successfully submitted in L1 PolyonZKEVM.sol contract, it will synchronize the Batch to its own node and then send these transactions to zkProver.

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

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

3. Aggregator submits the contract of aggregation proof to L1.

Aggregator will submit the Validity Proof together with the corresponding Batch execution status to L1. Polygon zkEvm.sol Within the contract, by calling the following methods:

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

When this step is successfully executed within the L1 contract, all the transactions contained in this batch are truly Finality (the end of the 7 day challenge period corresponding to the OP).

Three, The role Ethereum plays in Polygon-zkEVM

Having looked at the overall flow of Polygon zkEVM above, let's review what Ethereum is doing for Rollup:

In the first step, Sequencer collected the transactions of Rollup, packaged them into batches and submitted them to the contracts of L1. L1 not only provides the functions of DA layer, but also completes part of transaction ranking function. When you submit a trade to Sequencer, it is not really ordered because Sequencer has the power to change the order of the trade at will, but when the trade is included in the Batch and submitted to the L1 contract, no one has the right to change the order of the trade.

In the second step,Aggregator puts the Validity Proof on the L1 contract to achieve a new state. Aggregator is a Proposer and the contract is a Validator. Aggregator provides a Validity Proof to prove that a new state is correct, and tells Validator which transaction Batch is involved in the Validity Proof I provide, and where they all exist in L1.

Then, the Validator extracts the corresponding Batch from the contract and combines it with the Validity Proof to verify the Validity of the state transition. If the verification is successful, the contract will be updated to the new state of the corresponding Validity Proof.

Four, from the perspective of modular structure Smart Contract Rollup

If Polygon zkEVM is a Smart Contract Rollup type from a modularity point of view, we can try to deconstruct its modules. From the diagram Delphi gave us, We can also see that Polygon ZkEVM is actually the Consensus Layer for Smart Contrat Rollup, In fact, DA Layer and Settlement Layer are coupled in PolygonZkEVM.sol contract and cannot be well distinguished. But we tried to deconstruct the modules:

Data Availability Layer: where Rollup transactions are stored. For Polygon-zkEVM , when Sequencer calls SequenceBatch() Method, which actually involves submitting transaction data to the DA layer.

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

Consensus Layer: contains transaction sequencing and how to determine the next legal state (bifurcation selection). Sequencer invokes SequenceBatch() in L1 contract; When the Aggregator called TustedVerifyBatches in the L1 contract, then they did the ordering. Is done confirming the next legal state.

Execution Layer: When the user submits the trade to Sequencer and gets the new state after it has executed (so Rollup is often said to be computational expansion, because L1 outsources the process of executing the trade to get the new state to Rollup. Meanwhile, Sequencer commissioned zkProver to help generate Validity Proof through Aggregator.

5. Why does Polygon-zkEVM inherit the security of L1

In terms of the overall process introduced above, Sequencer has actually done a similar work to Proposer by proposing a number of valid transactions and presenting the new status after these transactions are executed. The validation logic of the L1 contract means that all of the L1 validators are executed in their own Ethereum client. In fact, all of the Ethereum validators act as the validators of Rollup. Therefore, we believe that Polygon zkEVM inherits Ethereum's security.

On the other hand, since all of Rollup's transactions and state are stored on Ethereum, even if Polygon zkEVM's team goes away, anyone will still be able to recover the entire Rollup network using the data stored on Ethereum.

Vi. Incentive mechanism of Polygon zkEVM

Rollup incentive mechanism mainly refers to how to make Sequencer and Aggregator profitable so as to maintain continuous work.

First, the user pays his own transaction commission on the Rollup. This part is charged by the dged ETH, called the Bridged ETH.

Sequencer needs to pay the cost of uploading batches containing Rollup transactions to Calldata of L1 transactions (cost of calling SequenceBatch()), At the same time, some Matic should be paid to L1 contract when Batch is uploaded, which is used to pay the cost of the Aggregator to provide Validity Proof for these Batches later.

Aggregator trusted VerifyBatches When providing Validity Proof for the Batches of products in the L1 contract that are not yet Finality batches, we can also take out Sequencer to pay MATIC Token in the contract in advance as the reward for providing Validity Proof.

The income of Sequencer. Rollup Gas charges for all transactions -- Batches of Gas charges used to upload to L1 network -- certified charges paid to Aggregator (MATIC pricing).

The income of Aggregator = the MATIC remuneration paid by Sequencer. - Gas cost for submitting Validity Proof to L1 - Hardware cost for generating Validity Proof.

To adjust the certification fees paid to Aggregator, and to avoid a strike by Sequencer on the grounds of unprofitability, the following mechanism is provided to adjust the certification fees paid by Sequencer to Aggregator.

A method exists in the contract to adjust the cost of certifying the Batch:

function _updateBatchFee(uint64 newLastVerifiedBatch) internal

It changes a variable in the contract called BatchFee, which determines how many MATIC tokens Sequencer pays for each Batch.

The change mechanism is as follows:

VeryBatchTimeTarget is maintained in the contract. Verybatchtimetarget , represents the expected state of validation within this time after each Batch is submitted to L1 by Sequencer.

All Batches that exceed VeryBatchTimeTarget and haven't been verified will be recorded in the contract, and the total number of Batches will be marked as DiffBatches.

Then the BatchFee will be adjusted using the following formula when Batches are overdue.

MultiplierBatchFee Is a number limited in the range of 1000~1024, which can be obtained by the function setMultiplierBatchFee() Changed by the Contract Administrator:

Function setMultiplier BatchFee (uint16newMultiplierBatchFee) public onlyAdmin

Notice MultiplierBatchFee And 10^3 is to achieve adjusted precision after 3 decimal points.

Similarly, if Batches are advanced, the Batches will trigger batchFee adjustment :DiffBatches indicates the number of batches in the advanced verification state.

summarize

In this article, we take a look at Polygon zkEVM's core mechanics and examine its feasibility for Ethereum computing expansion. After having an overall outline, we will go deep into the interior of the protocol in the following articles and analyze the design details of zkEVM Bridge, the decentralization route of Sequencer, the implementation of zkProver and the design principle of zkEVM in turn.