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 next two articles will introduce in detail the design details of Polygon zkEVM’s zkEVM Bridge and zkEVM, as well as Polygon zkEVM’s next decentralized Sequencer roadmap.
1. Rollup is used to expand computing capacity for Ethereum
First, 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 transactions to Rollup, and then store the transaction and the state after transaction execution in the Ethereum contract. Due to different technical routes, it evolved There are two types of Rollup:
Optimistic Rollup
Optimistically believe that the Rollup Transaction and the corresponding Rollup State sent to Ethereum are correct, and anyone can commit fraud by providing Fraud Proof challenges the Rollup State which is still in the challenge period.
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 Rollup The status after executing the corresponding transaction is correct).
Refer to the official definition of Ethereum:
https://ethereum.org/en/developers/docs/scaling/#rollups
Zero-knowledge The biggest difference between Rollup and Optimistic Rollup is that the time to reach Finality is different due to different ways of verifying the validity of the state;
Optimistic Rollup optimistically believes that the transactions and states submitted to Ethereum are correct. Therefore, there is a 7-day challenge period (the time to reach Finality is 7 days). During this period, anyone who finds that the corresponding status of the transaction on Ethereum is incorrect can challenge it by submitting the correct status.
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. Currently, Finality is probably around 1 hour (because Gas cost needs to be taken into consideration).
2. Polygon zkEVM execution process
Next, we use a simple transaction confirmation process to see how Polygon zkEVM works, so as to have a specific understanding of the overall protocol. The entire process can be mainly divided into three steps:
- Sequencer packages multiple user transactions into Batch and submits them to the L1 contract;
- Prover generates a validity proof for each transaction and aggregates the validity proofs of multiple transactions into one validity proof;
- Aggregator submits the Validity Proof that aggregates multiple transactions to the L1 contract.
- Sequencer packages user transactions into Batch and submits them to the L1 contract
-
The user sends the transaction to the Sequencer, and the Sequencer will process the transactions locally in the order of speed (FRFS). When the Sequencer successfully executes the transaction locally, if the user believes that the Sequencer is honest, then he can consider the transaction at this time Finality has been achieved. It should be noted here that most of the Mempools (transaction pools) within Sequencer are currently private, so the MEV available for the time being is relatively small.
-
Sequencer will pack multiple transactions into a Batch (currently, a Batch only contains one transaction). Then after collecting multiple Batches, the SequenceBatch() function of PolygonZKEvm.sol on L1 will Batches are sent together to the transaction Calldata of L1.
(It should be noted that multiple Batches are submitted at one time in order to reduce L1’s Gas consumption as much as possible) -
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 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 submitted to the Polygon zkEVM contract of L1 has been determined.
The above actual process is also the work that needs to be completed by L1 acting as the Rollup DA layer (no status inspection or advancement work has been completed at this time).
- Aggregator generates Validity Proof for transactions of multiple batches
- When the Aggregator detects that new batches have 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.
- After zkProver receives these transactions, it will generate Validity Proof for each transaction in parallel, and then aggregate the Validity Proofs of the transactions contained in multiple batches into one Validity Proof.
- zkProver sends the Validity Proof that aggregates multiple transactions to the Aggregator.
- Aggregator submits the aggregation proof to the L1 contract
Aggregator will submit this validity proof (Validity Proof) and the corresponding status after execution of these batches to the Polygon zkEvm.sol contract of L1, by calling the following method:
The following operations will be performed within the contract to verify whether the state transition is correct.
When this step is successfully executed in the L1 contract, all transactions included in this 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
Above we have understood the overall process of Polygon zkEVM, we can review what Ethereum has done for Rollup:
In the first step, the Sequencer collects the Rollup transactions, packages them into Batch, and submits them to the L1 contract. L1 not only provides the functions of the DA layer, but also actually completes part of the transaction sequencing function; when you submit the transaction to the Sequencer, the transaction is not actually 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 sequence.
In the second step, the Aggregator mentions the Validity Proof to the L1 contract to achieve a new state. The Aggregator plays a role similar to the Proposer, and the contract plays a role similar to the Validator. The Aggregator provides a Validity Proof to prove that a new state is correct, and Tell the Validator which transaction batches the Validity Proof I provide involves, and where in L1 they are stored.
Then the Validator extracts the corresponding Batch from the contract and combines it with the Validity Proof to verify the legality 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. Structure Smart Contract Rollup from a modular perspective
From a modular perspective, Polygon zkEVM belongs to the Smart Contract Rollup type. We can try to deconstruct its various modules. From the diagram given by Delphi, we can also see that Polygon ZkEVM actually serves as the Consensus Layer of Smart Contract Rollup. , 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: 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 introduced in detail in the next article).
Consensus Layer: Contains transaction sorting and how to determine the next legal state (fork selection). The Sequencer completes the transaction sorting work when it calls SequenceBatch() in the L1 contract. When the Aggregator calls TustedVerifyBatches() in the L1 contract ), the work of confirming the next legal status is completed.
Execution Layer: Execute a transaction and obtain a new world state. When the user submits a transaction to the Sequencer, and the Sequencer completes the execution, the process of obtaining the new state (so we often say that Rollup is a computational expansion, because L1 obtains the execution transaction The process of the new state is outsourced to Rollup, and Sequencer will entrust zkProver through Aggregator to help generate Validity Proof.
5. Why is it said that Polygon-zkEVM inherits the security of L1?
Judging from the overall process introduced above, Sequencer actually does work similar to Ethereum Proposer, proposing a batch of transactions as valid transactions, and giving the new status after the execution of this batch of transactions; and the verification logic of the L1 contract, It is equivalent to all L1 Validators being executed in their own Ethereum client. 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 states of Rollup are stored on Ethereum, even if the Polygon zkEVM team runs away, anyone will still be able to restore the entire Rollup network relying 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, users need to pay their own transaction fees on Rollup. This part of the fee is denominated in ETH and is paid with 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 SequenceBatch(batches())). At the same time, it needs to pay a certain Matic to the L1 contract while uploading the Batch for later payment. Aggregator provides the cost of Validity Proof for these Batches.
While the Aggregator calls trusted VerifyBatches to provide Validity Proof for the Batches in the L1 contract that have not been finalized, it can also withdraw the MATIC tokens paid by the Sequencer in advance in the contract as a reward for providing Validity Proof.
Sequencer's income = Gas fee for all transactions in Rollup - L1 network Gas fee for uploading Batches to L1 - Attestation fee paid to Aggregator (MATIC pricing).
Aggregator's income = MATIC remuneration paid by Sequencer - Gas fee submitted to Validity Proof to L1 - Hardware fee spent on Validity Proof generation.
Adjust the certification fee paid to the Aggregator. At the same time, in order to avoid the Sequencer from going out due to unprofitability, the following mechanism is provided to adjust the certification 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 will change a variable in the contract called BatchFee, and this variable determines the number of MATIC tokens paid by the Sequencer for each Batch.
The change mechanism is as follows:
The contract maintains a variable VeryBatchTimeTarget, which represents that each Batch is expected to be verified within this time after it is submitted to L1 by the Sequencer.
The contract will record all Batches that have not been verified after exceeding VeryBatchTimeTarget, and record the total number of these Batches as DiffBatches.
So when some 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 MultiplierBatchFee and 10^3 are used here to achieve adjustment accuracy of 3 decimal points.
In the same way, if Batches are advanced, the corresponding batchFee adjustment mechanism will be triggered: DiffBatches represents the number of Batches that are verified in advance.
Summarize
In this article, we sort out the core mechanism of Polygon zkEVM and analyze its feasibility to achieve Ethereum computing expansion. After having an overall outline, in the next article we will go deep into the protocol and analyze the design details of zkEVM Bridge and the decentralization route of Sequencer, the implementation of zkProver and the design principle of zkEVM.