zkEVM Series (2): Polygon zkEVM More Technical Details About Sequence and Bridge

Author: 0xhhh, EthStorage (Twitter: @hhh69251498)

In the first article about Polygon zkEVM (zkEVM Series (1) | Overall Architecture and Transaction Execution Process of Polygon zkEVM), we summarized the overall framework of Polygon zkEVM and the transaction execution process, while also analyzing how Polygon zkEVM achieves computational scalability while inheriting the security of L1. In this article, we will build on the framework established in the previous article and delve into more technical details about Sequencer and Bridge in Polygon zkEVM, while also exploring the different characteristics of potential decentralized Sequencer architectures in the future.

1. In-depth Analysis of zkEVM Bridge

In the previous article, we introduced Polygon zkEVM, but we actually missed a very important part, which is the native bridge of Polygon zkEVM. (Note: In this article, L2 specifically refers to Rollup, and L1 specifically refers to Ethereum.)

1. Cross-chain Data State Management

Polygon zkEVM maintains an Exit Tree for both L1 and L2, named L1 Exit Merkle Tree and L2 Exit Merkle Tree, respectively. However, to better manage these two trees, Polygon zkEVM cleverly combines them, as shown in the figure below:

This means that the L1 Exit Tree Root is used as the left leaf node of the Global Exit Tree, while the L2 Exit Tree Root is used as the right leaf node of the Global Exit Tree. However, it is important to note that the L1 Tree Root and L2 Tree Root are Sparse Merkle Trees (SMT), while the Global Exit Tree is a Binary Merkle Tree.

The basic information of the L1/L2 Exit Tree leaf nodes is as follows:

2. Cross-chain Process

In the contract design of Polygon zkEVM, efforts are made to decouple the Bridge and Consensus contracts as much as possible. Currently, the contracts deployed on L1 are mainly divided into three, as shown in the figure below:

It is important to note that they are not in an inheritance relationship; they are independent contracts. PolygonZkEVMBridge and PolygonZkEVM will both call PolygonZkEVMGlobalExitRoot to update or verify the Global Exit Tree Root.

1) L1 → L2 Cross-chain Process

The L1 → L2 cross-chain process corresponds to the three steps marked in orange in the figure above:

Corresponding to the structure of globalExitRoot in the BatchData in the following code:

PolygonZkEVMBridge Contract on L2

https://testnet-zkevm.polygonscan.com/tx/0x2a742f2f8a7b8635a76cc70b4574bebb1a81b2c0c1a618188773a1f8f2283bb8

https://testnetzkevm.polygonscan.com/address/0x39e780d8800f7396e8b7530a8925b14025aedc77#code

2) L2 → L1 Cross-chain Process

Users call the Bridge() function in the Bridge contract (PolygonZkEVMBridge.sol) deployed on L2 to send an L2-Bridge-Tx, which will update and add a new node in the L2 Exit Tree, and then sequentially update the L2 Exit Tree Root and Global Exit Tree Root.

Next, the Sequencer will place this L2-Bridge-Tx into a Batch and send it to the consensus and DA contract (PolygonZkEVM.sol) on L1.

Then, when the Aggregator calls trustedVerifyBatches() to submit the validity proof to L1, it will also upload the L2 Exit Root as input, which is the NewLocalExitRoot in the following function. It represents that there is a new BridgeToL1 transaction in L2, but these transactions cannot be withdrawn on L1 yet and need to wait for the new NewLocalExitRoot to be successfully verified.

The incoming New Local ExitRoot will also be part of the verification circuit, inputting the verification logic to determine whether these new BridgeToL1 transactions that occurred in L2 caused the L2 Exit Tree Root to change to the currently submitted New Local ExitRoot.

If this Validity Proof verification passes, then the Global Exit RootManager on L1 will update the L2 Exit Tree Root and Global Exit Tree Root: globalExitRootManager.updateExitRoot(newLocalExitRoot);

At this point, users can call the ClaimAsset() function in the Bridge contract (PolygonZkEVMBridge.sol) deployed on L1 and provide the corresponding Merkle Path to withdraw, thus perfectly completing the cross-chain transaction.

2. How Polygon zkEVM Resists Censorship

In the previous article, we introduced Trusted Sequencer, which is a Single Sequencer operated by the official. Basically, transactions on the L2 network are submitted to this Trusted Sequencer, and users can obtain timely Sequencer Finality.

In fact, users can also submit transactions directly to the L1 contract without going through the Trusted Sequencer, thus ensuring that the entire network still possesses a certain degree of censorship resistance.

1. Execution Process

1) Users call the Force Batch function in the L1 contract, through which they can send the L2 transactions they want to execute directly to the L1 contract.

2) The contract will package these Transactions into a Batch and record them in a Force Batches Mapping in the contract.

3) The Trusted Sequencer listens for new Force Batches in the Force Batches and will synchronize them to the local node, and then include this Force Batch in the next submission of Batches to L1.

4) However, there is also a special case: if the Trusted Sequencer goes down or deliberately does not submit a certain user's submitted Force Batch, then after five days, the user can call the SequenceForceBatches() function in the L1 contract to let this Force Batch enter the Sequenced Batches in the L1 contract, which means that the transaction order of this Force Batch in the Rollup has been finalized by the L1 contract, and even the Trusted Sequencer cannot change the transaction order of this Force Batch anymore. (In fact, all Rollups have such features to provide censorship resistance, such as Arbitrum's Sequence Inbox and Inbox).

However, it is recommended that users avoid submitting Rollup transactions through the Force Batch method as much as possible, because by doing so, when you call Force Batch to submit your transaction to L1, you will expose your transaction content, and at this point, the transaction order has not been confirmed yet (you need to wait for the Sequence to synchronize the Force Batch and submit it to L1 again through Sequence Batch() for the transaction order to be truly confirmed), and you will no longer be able to cancel your transaction, which puts you at a high risk of being front-run.

This does not seem to truly resist censorship, as the Force Batch method carries the risk of being front-run. Will users really use this feature?

2. The True State of Sequencer

From the above, we can see that the Sequencer will synchronize the transactions in the Force Batch from L1 to the local node for execution, so the true state of the Sequencer is shown in the figure below:

Bn represents the result obtained after the user directly submits the transaction to the Sequencer for execution;

FBn represents the result obtained after the Sequencer synchronizes and executes the transactions in the Force Batch.

https://zkevm.polygon.technology/

3. Three Different Finalities in L2 Network

Next, we will review the overall architecture of Polygon to lay the groundwork for the upcoming decentralized Sequencer discussion. We need to pay attention to the fact that:

For Sequencer and Aggregator, their states are synchronized from the L1 contract through the Synchronizer, and they do not communicate directly with each other.

1) Three Types of Finality

Therefore, we can consider that the entire network currently has three different degrees of Finality, which we name Sequencer Finality, DA Finality, and Verified Finality.

a. The first type, Sequencer Finality, is referred to as Soft Finality in some articles, but I think calling it Sequencer Finality is more appropriate because this Finality is actually the state commitment given by the Single Sequencer.

After the Sequencer receives the user transaction, it executes and provides the state, which is the least secure state; however, in the current scenario of the official Single Sequencer, it can provide an extreme user experience while ensuring security. In the current single Sequencer Rollup network, users can basically experience the joy of instant confirmation. However, the biggest risk of the Single Sequencer is its downtime, which can lead to the entire L2 network being paralyzed. However, since the DA layer is located on Ethereum, it can still partially restore the state of the L2 network before the downtime; however, the L2 transactions that could not be sent to L1 in time will not be recoverable.

b. The second type, DA Finality, indicates that these transactions have been submitted to the L1 DA layer contract, and at this point, the transaction order has also been determined.

The Trusted Sequencer has called Sequence Batch to send transactions to L1, and in this case, the transactions have been included in the DA layer; in Polygon's design, due to the single Trusted Sequencer, it can ensure that the transactions uploaded to the L1 contract for DA are all valid transactions. We can consider that when a transaction is uploaded to the L1 contract by the Trusted Sequencer, it has already been acknowledged by the Rollup network, and subsequently, the Aggregator will provide Validity Proof to ensure that this transaction cannot be reverted (unless L1 is reorganized).

c. The third type, Verified Finality, refers to transactions that have been verified through Validity Proof, representing true Finality; in some articles, it is also called Hard Finality.

When the Validity Proof provided by the Aggregator for a batch of transactions uploaded to the DA layer is verified by the contract, we consider that these transactions can no longer be reverted (unless L1 is reorganized). We mentioned in the previous article that the time from submitting transactions to the DA layer to the verification of the validity proof is currently 30 minutes, and the Aggregator can also obtain sufficient Matic rewards by providing Validity Proof.

2) Trade-offs in Aggregator Synchronizing State

Assuming that providing Validity Proof is profitable, for the Aggregator, the best way to synchronize transactions is not to synchronize in the L1 DA layer contract but to establish an RPC link directly with the Trusted Sequencer to obtain the latest transactions directly from the Trusted Sequencer. This way, generating Validity Proof will be faster, giving it a competitive advantage over other Aggregators that obtain transactions from the DA contract, because providing Validity Proof is first-come, first-served. For a batch of transactions, only one aggregated validity proof is needed, and the first Aggregator to submit the Validity Proof can take the corresponding Matic rewards, while other Aggregators generating Validity Proof will not receive any rewards.

However, in practice, Polygon also has a Trusted Aggregator, which performs the work of generating and submitting Validity Proof. https://zkevm.polygon.technology/

4. The Future of Sequencer

Next, we continue to think about decentralized Sequencers. The first question is why we need decentralized Sequencers? Because we hope that Rollups can scale Ethereum's computational capacity while inheriting Ethereum's security and decentralization. The current Single Sequencer solution clearly fails to achieve the goal of inheriting Ethereum's level of decentralization. Before further outlining the future of decentralized Sequencers, let’s first review the work of Sequencers. Taking Polygon zkEVM as an example, the current Trusted Sequencer processes transactions following FCFS (First-Come, First-Served), with the first transaction being processed first, and the parallel Mempool is also private, protecting users' transactions from MEV as much as possible.

After collecting a certain amount of transactions, they will be packaged into Batches and uploaded to the corresponding DA location in the L1 contract. In the first article, we also mentioned that the transaction order in the Batches uploaded by the Sequencer has actually been determined by including the hash of the previous Batch in the subsequent Batch. Therefore, we consider the work of the Sequencer to be similar to that of an L1 Proposer, proposing a batch of transactions and confirming the order of transactions.

Since we started discussing decentralized Sequencers from Polygon zkEVM, we will first introduce the Proof Of Efficiency (PoE) scheme for decentralized Sequencers in Polygon zkEVM.

1. Proof-Of-Efficiency
1) Scheme Description
In the design of PoE, anyone can become a Sequencer and submit Rollup Blocks to L1. The transaction order in the Rollup network depends on the order in which transactions are submitted to the L1 Rollup DA contract. (In Polygon zkEVM, a Batch is equivalent to a Block.) As shown in the figure below, users can choose which Sequencer to send their transactions to, or even become a Sequencer themselves. These Sequencers will package these transactions into a Batch after receiving enough transactions and then submit them to L1.

These Sequencers need to consider profit issues:

Sequencer Cost = L1 gas cost + generate zkProof fee

Sequencer Revenue = L2 gas fee

So Sequencers need to consider how many transactions to package into a Batch to submit to L1 to be profitable. However, Sequencers also need to consider another issue: timeliness. If a Sequencer's transaction submission speed is too slow, its users may switch to other Sequencers that provide faster confirmations.

2) Feasibility of the Scheme

The core reason this scheme can operate is that Polygon's DA part does not make any state commitments, only determining the transaction order; state commitments (the Sequencer commits to the new world state corresponding to the transaction execution, but this state has not been verified by Validity Proof or Fraud Proof) are only given when submitting Validity Proof, which is the core reason this scheme can be executed.

In fact, like Arbitrum, there is no state commitment when submitting transactions to the DA contract, but Optimism carries state commitments when submitting transactions to the DA layer. Therefore, theoretically, Arbitrum can also use PoE to achieve decentralized Sequencers, but Optimism cannot.

3) Why can't carrying state commitments use PoE? Because when multiple Sequencers almost simultaneously submit Batches to L1, no Sequencer can guarantee the final transaction order of L2 transactions on the DA contract. Therefore, if carrying state commitments, it is highly likely that the entire Batch will fail to pass Validity Proof or Fraud Proof verification.

4) How to Handle Invalid Transactions?

Invalid transactions refer to transactions with a low account nonce or insufficient balance to pay gas fees. When these transactions are on L1 (Geth), they will not be included in the block because if a block contains an invalid transaction, the entire block becomes invalid, and Validators will not vote for such blocks, nor will Proposers propose such blocks.

In the current Single Sequencer case, the L2 network can identify such invalid blocks and avoid including such transactions in the L1 DA contract, which can prevent wasting L1 block space.

However, after adopting PoE, Sequencers actually lose the ability to identify such invalid transactions. Therefore, during the state change process of validating transactions on L1, this situation also needs to be taken into account, and Sequencers submitting invalid transactions will not receive user fees.

5) Public Mempool?

After adopting PoE, if there is a Public Mempool among these decentralized Sequencers, it will lead to a situation where a user's transaction is submitted multiple times by different Sequencers. Of course, only the first submitted transaction is valid, and only this transaction can ultimately receive the user's fee.

6) Why Sequencers Cannot Predict Execution Results

In this Permissionless Sequencer model, a Sequencer cannot provide timely Sequencer Finality to users because the predicted final on-chain transaction order may deviate from the actual transaction order. This deviation occurs because multiple Sequencers may submit transaction Batches to the L1 DA contract almost simultaneously, making it difficult to guarantee that the actual order of these transaction Batches matches the predicted order.

Therefore, when Sequencers synchronize their own states, they will also synchronize the latest submitted transaction Batches from the L1 DA contract and execute them to obtain the latest state, rather than synchronizing the state from other Sequencers.

7) L2 MEV Flowing to L1

Since anyone can become a Sequencer to submit transactions to the Rollup network, and the transactions submitted in the Batch are essentially the same as ordinary transactions on L1, they will still go through the entire MEV Boost process, which means that the MEV of the L2 network will flow into the MEV Boost module.

8) Design of Aggregator

In the design of PoE, Aggregators are also Permissionless. However, since Validity Proof only requires one correct transaction, it means that only the first Aggregator to submit the correct Validity Proof for the transaction can receive rewards. Therefore, as an Aggregator, you need to weigh the range of the Validity Proof submitted, the submission time, and the relationship between the Matic rewards that can be obtained by submitting Validity Proof to find the most competitive strategy.

It seems that using this free market competition strategy can achieve the fastest generation speed for the corresponding Validity Proof of transactions.

https://ethresear.ch/t/proof-of-efficiency-a-new-consensus-mechanism-for-zk-rollups/119888 )

8) Summary

PoE can bring a completely Permissionless network, and the entire network may not have the risk of downtime. However, the L1 DA contract may contain invalid transactions (such as transactions with the same nonce), and MEV will be captured by the L1 network, providing only DA Finality and Verified Finality.

2. Based Rollup

Based Rollup aims to delegate the work of the Single Sequencer in the Rollup network to Ethereum's proposer. It will require each Proposer to include a valid Rollup block in the proposed L1 block.

Therefore, the L1 network's Block Builder needs to run a full node of the Rollup to accept L2 transactions and construct the maximum value Rollup Block.

The advantage of this scheme is that it maximally inherits the security and decentralization of L1, but it will also lead to only providing Sequencer Finality and Verified Finality, and the MEV of L2 will also flow to L1, while also requiring modifications to the Ethereum client code, which may affect the security of L1.

3. Shared Sequencing

Shared Rollup, compared to Based Rollup, delegates the construction and submission of Rollup Blocks to a committee of Shared Sequencers.

3.1. The specific process is as follows:

a. Different Rollup users can directly send Rollup transactions to the network where Shared Sequencers are located.
b. Shared Sequencers will run a BFT consensus internally, selecting a Sequencer Leader in each round to sort transactions and construct the corresponding Rollup Block.
c. Then, these Rollup Blocks will be submitted to the corresponding DA contracts of different Rollup networks on L1.
d. Different Rollup networks will then synchronize the latest transactions in the network through the L1 DA contract and enter their own processes to verify Validity Proof or Fraud Proof.

3.2. Potential Impact of Shared Sequencer Architecture

1) Multiple Rollup networks share a Shared Sequencer Committee.
2) From the perspective of a single Rollup, it simply delegates the work of the officially operated Single Sequencer to this Shared Sequencer Committee.
3) In each round, a Sequencer Leader will be selected from the Shared Sequencer Committee, responsible for constructing the Rollup Blocks for the Rollup networks connected to this Shared Sequencer network and sequentially submitting these Rollup Blocks to the corresponding DA contracts on Ethereum.

a. For example, if A needs to cross-chain USDC from Arbitrum to Optimism, the normal process would be to first Lock on Arbitrum, wait for the Lock to succeed, and then submit its Lock Proof (e.g., Merkle Tree Path + Tree Root) on Optimism to Mint the corresponding USDC asset.
b. When a user submits such a transaction to Shared Sequencers, the Sequencer Leader selected in each round can actually execute the Arbitrum Lock operation and the Optimism Mint operation in the same Rollup Block at the same time, which can greatly enhance the user experience.
c. However, it still cannot achieve the same user experience as within a single Rollup network; for example, when Minting, you still need to provide your Lock Proof.
d. Therefore, we can consider that the Rollups connected to this Shared Sequencer network form a system that is close to complete synchronization.
e. What is the significance of a system that is close to complete synchronization?
f. It can provide atomic cross-chain services because the Sequencer Leader selected in each round has the power to order all Rollup transactions, so it is capable of constructing atomic cross-chain transactions.

4) From the perspective of cross-chain MEV

Since the Sequencer Leader in each round has the power to order all Rollup Blocks, it can theoretically capture all cross-chain MEV. It seems that Shared Sequencer will also need to introduce or directly connect to MEV Boost architecture because, currently, the block intervals of various Rollup networks are much faster than Ethereum's block intervals. For example, Optimism has a block every 2 seconds, while Arbitrum can produce a block as fast as every 0.25 seconds. Therefore, the computational load for the Sequencer Leader to construct Rollup Blocks in each round is not small, and it seems that once the ecosystem matures, there will be corresponding MEV architectures to assist in constructing the maximum value Rollup Blocks.

5) From the perspective of Decentralization and Liveness of Shared Sequencers

Since the Shared Sequencer Committee will use BFT consensus to select a Sequencer Leader in each round to propose all Rollup Blocks, both Decentralization and Liveness will be significantly stronger than the current Single Sequencer solution.

6) From the ecological perspective

a. Different Rollups have better reasons for coexistence because users can easily transfer assets across various Rollup networks, and it can better achieve load balancing of the Ethereum ecosystem.
b. For different projects constructing Shared Sequencers, it may become a life-and-death competition because, from the user's perspective and the current Single Sequencer perspective of various Rollups, it seems that there will be a winner-takes-all situation in the Shared Sequencer race.

7) From the perspective of Finality

Since it is essentially still a Single Sequencer, both Sequencer Finality and Verified Finality remain the same as before.

3.3. Potential Risks

Because Rollups may not be homogenous, for example, cross-chain transactions between Arbitrum and Polygon zkEVM, this means that the Verified Finality of transactions corresponding to cross-chain transactions on Arbitrum and Polygon zkEVM may not be consistent. For instance, if a mint transaction on Polygon zkEVM has already obtained Verified Finality (submitted Validity Proof), but at this time, the Lock transaction on Arbitrum has only obtained DA Finality (waiting for a 7-day challenge period), if I successfully revert my transaction on Arbitrum at this time, it means that I have effectively minted many cross-chain assets on Polygon zkEVM at no cost.

3.4. Summary

Advantages:

a. MEV can be captured by the Rollup network, and additional cross-chain MEV can also be obtained;
b. Users have a better cross-Rollup experience, and it can transform the competitive relationship between Rollups into a symbiotic relationship, where each Rollup can provide its unique value and then combine with other Rollup networks to offer various customized services to users;
c. Compared to Single Sequencer, the degree of decentralization of the network has been significantly enhanced, and the stability of the network has greatly improved. When a Sequencer Leader fails to produce a block, a new Sequencer Leader will be promptly rotated in to produce the block;
d. The three types of Finality in the network remain consistent with the original Single Sequencer.

Disadvantages: It is essentially still a Single Sequencer model and introduces new attack vectors.

5. Conclusion

In this article, we detailed the bridge of Polygon zkEVM and more technical details about Sequencer. In the next article, which will also be the final article, we will continue to dissect the technical details of zkEVM. Stay tuned.