Explain in detail the overall architecture and transaction execution process of Polygon zkEVM

This article is machine translated
Show original

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, in the next two articles, we will introduce the design details of Polygon zkEVM’s zkEVM Bridge and zkEVM, as well as the roadmap of Polygon zkEVM’s next decentralized Sequencer.

1. Rollup in order to achieve computing expansion for Ethereum


First of all, we need to clarify the general working principle of Rollup. The emergence of Rollup is to achieve computing expansion for Ethereum. The specific implementation method is to outsource the execution of the transaction to Rollup, and then store the transaction and the state (State) after the transaction execution in the Ethereum contract. Due to the different technical routes, it has evolved into There are two types of Rollup:


Optimistic Rollup
It is optimistic that the Rollup transaction (Rollup Transaction) and the corresponding Rollup state (Rollup State) sent to Ethereum are correct, and anyone can challenge the Rollup State that is still in the challenge period by providing fraud proof (Fraud Proof) Challenge).


Zero-knowledge Rollup
ZK will provide a validity certificate for the Rollup transaction sent to Ethereum and the corresponding Rollup state (verified by the contract on Ethereum to prove that the state of the Rollup execution corresponding to the transaction is correct).


Refer to the official definition of Ethereum:
https://ethereum.org/en/developers/docs/scaling/#rollups
The biggest difference between Zero-knowledge Rollup and Optimistic Rollup is that the time to reach Finality is different due to different methods of verifying the validity of the state;
Optimistic Rollup optimistically believes that the transaction and status submitted to Ethereum are correct, so there is a 7-day challenge period (the time to achieve Finality is 7 days), during which anyone finds that the corresponding status of the transaction on Ethereum is incorrect. Challenge by submitting the correct status.
The time for Zero-knowledge Rollup(zk- Rollup ) to reach Finality depends on: the time it takes for the Validity Proof corresponding to the transaction to be submitted to Ethereum and passed the verification. At present, the finality may be around 1 hour (because the gas cost needs to be considered).


2. Polygon zkEVM execution process


Next, let's take a simple transaction confirmation process to see how Polygon zkEVM works, 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 (Validity Proof) for each transaction, and aggregates the validity proofs of multiple transactions into one validity proof;
3. The Aggregator submits the validity proof (Validity Proof) that aggregates multiple transactions to the L1 contract.
image
1. Sequencer packages user transactions into batches and submits them to the L1 contract


1) The user sends the transaction to the Sequencer, and the Sequencer will process the transaction locally in the order of receipt (FRFS). When the Sequencer successfully executes the transaction locally, if the user believes that the Sequencer is honest, then he can consider this time The deal has reached Finality. It should be noted here that currently most of the Mempools (transaction pools) inside Sequencer are private, so there are relatively few MEVs that can be obtained temporarily.
2) Sequencer will pack multiple transactions into a Batch (currently a Batch only contains one transaction) and then after collecting multiple Batches, send multiple Batches together through the SequenceBatch function of SOL on L1 L1 transaction Calldata.
image

(It should be noted that the purpose of submitting multiple Batches at one time here is to reduce the Gas consumption of L1 as much as possible)

3) When SOL receives the Batches provided by the 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 latter batch, so we get the following figure Batch structure.

image

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 contained in the Polygon zkEVM contract submitted to L1 by the Batch is determined.

image

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


2. Aggregator generates Validity Proof for multiple Batch transactions


1) When the Aggregator detects that new batches have been successfully submitted in the SOL contract of L1, it will synchronize these batches to its own node, and then send these transactions to zkProver.
2) After zkProver receives these transactions, it will generate Validity Proof for each transaction in parallel, and then aggregate the Validity Proofs of transactions contained in multiple batches into one Validity Proof.
image
3) zkProver sends the Validity Proof that aggregates multiple transactions to the Aggregator.

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


Aggregator will submit this validity proof (Validity Proof) and the corresponding states after the execution of these batches to the Polygon SOL contract of L1, by calling the following method:
image
The following operations will be performed in the contract to verify whether the state transition is correct.
image
image
When this step is successfully executed in the L1 contract, all transactions included in this part of the batch will truly achieve Finality (corresponding to the end of the OP’s 7-day challenge period).

3. The role of Ethereum in Polygon-zkEVM


We have learned about the overall process of Polygon zkEVM above, and we can review what Ethereum has done for Rollup :

In the first step, the Sequencer collects the Rollup transactions and packages them into a Batch, which is then submitted to the L1 contract. L1 not only provides the function of the DA layer, but actually completes a part of the transaction sorting function; when you submit the transaction to the Sequencer, the transaction is not really sequenced, because the Sequencer has the power to change the order of the transaction at will. But after the transaction is included in the Batch and submitted to the L1 contract, no one has the right to modify the transaction order.

In the second step, the Aggregator mentions the Validity Proof to the L1 contract to achieve a new state. The Aggregator acts like a Proposer, and the contract acts like a Validator. Aggregator provides a Validity Proof to prove that a new state is correct, and Tell the 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.
image

4. Structure Smart Contract Rollup from a modular perspective


From a modular point of view, Polygon zkEVM belongs to the type of Smart Contract Rollup , we can try to deconstruct its various modules, from the figure given by Delphi, we can also see that Polygon ZkEVM is actually the Consensus Layer of Smart Contract Rollup, DA Layer and Settlement Layer are actually coupled in the SOL contract, and cannot be distinguished very well. But we try to deconstruct each module:

Data Availability Layer (Data Availability Layer): the place where Rollup transactions are stored. For Polygon-zkEVM, when 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 (will be introduced in detail in the next article).

Consensus Layer: Including transaction ordering and how to determine the next legal state (fork selection), the transaction ordering work is completed when the Sequencer calls the SequenceBatch in the L1 contract, and it is completed when the Aggregator calls the TustedVerifyBatches in the L1 contract In order to confirm the work of the next legal state.

Execution Layer (Execution Layer): Execute the transaction and get the new world state, when the user submits the transaction to the Sequencer, and the process of getting the new state after the Sequencer executes (so we often say that Rollup is computing expansion, because L1 gets the execution transaction The process of the new state is outsourced to Rollup, and Sequencer will entrust zkProver to help generate Validity Proof through Aggregator.
image

5. Why Polygon-zkEVM inherits the security of L1


From the overall process described above, in fact, Sequencer has done a job similar to Ethereum Proposer, proposing a batch of transactions as valid transactions, and giving a new state after the execution of these transactions; and the verification logic of the L1 contract, It is equivalent to that all L1 Validators will be executed in their own Ethereum client. In fact, all Ethereum validators act as Rollup validators. Therefore, we believe that Polygon zkEVM inherits the security of Ethereum.

From another point of view, because all transactions and states of Rollup are stored on Ethereum, even if the Polygon zkEVM team Rug Pull away, anyone still has the ability to rely on the data stored on Ethereum to restore the entire Rollup network.


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?
image
First of all, users need to pay their own transaction fees on Rollup, which are denominated in ETH and paid in Bridged ETH.

The Sequencer needs to pay the cost of uploading the Batch containing the Rollup transaction to the Calldata of the L1 transaction (the cost of calling the SequenceBatch (batches), and at the same time need to pay a certain amount of Matic to the L1 contract while uploading the Batch, which is used to pay the Aggregator later. These Batches provide the cost of Validity Proof.

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

Sequencer's income = Gas fee for all Rollup transactions - L1 network Gas fee for uploading Batches to L1 - Proof fee paid to Aggregator (Matic denomination).

Aggregator's income = Matic remuneration paid by Sequencer - Gas fee submitted to Validity Proof to L1 - Hardware fee for Validity Proof generation.

Adjust the proof fee paid to Aggregator, and in order to avoid Sequencer’s unprofitable strike, the following mechanism is provided to adjust the proof fee paid by Sequencer to Aggregator.

There is such 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 amount of Matic tokens Sequencer pays for each batch.

The change mechanism is as follows:

Such a variable VeryBatchTimeTarget is maintained in the contract, which represents that each Batch is expected to be verified within this time after being submitted to L1 by the Sequencer.

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

So when Batches are late, 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 setMultiplier 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.
image
image
Similarly, if the Batches are ahead of schedule, the corresponding batchFee adjustment mechanism will be triggered: DiffBatches indicates the number of Batches that have been verified in advance.


image
image
Summarize


In this article, we sort out the core mechanism of Polygon zkEVM, and analyze its feasibility to realize the expansion of Ethereum computing. After having an overall outline, in the following articles we will go deep into the interior of the protocol, and analyze the design details of zkEVM Bridge, the decentralization route of Sequencer, the implementation of zkProver, and the design principles of zkEVM in turn.

Source
Disclaimer: The content above is only the author's opinion which does not represent any position of Followin, and is not intended as, and shall not be understood or construed as, investment advice from Followin.
Like
Add to Favorites
Comments