Rollup Decentralization: Analysis of Aztec's Decentralized Sequencer Solution

Author: 0xhhh, EthStorage

Editor: Faust, "Geek Web3"

Since Rollup became a prominent topic, the decentralization of the Sequencer has always been a focal point for the Ethereum/Celestia community, as well as a significant challenge in Layer 2 development. In this regard, various Rollup solutions have proposed ideas for node decentralization, providing vast imaginative space for this topic.

The author of this article takes the well-known ZKRollup project Aztec as an example, using the two recent proposals named B52 and Fernet put forward by Aztec Labs as a starting point to analyze how ZKR achieves the decentralization of Sequencer nodes for readers.

Proposal B52: Permissionless Sequencer Solution

Proposal B52 aims to achieve the following goals (ideally):

1. A decentralized sequencer network, where L2 nodes elect a proposer for each round.
2. A decentralized prover network with low hardware requirements for prover nodes.
3. The Rollup overall possesses good censorship resistance.
4. The MEV value generated by L2 is obtained by L2 nodes.
5. When L2 blocks are submitted to the DA layer, they can achieve relatively effective finality; irreversible finality must wait for the Validity Proof to be submitted.
6. L2 Tokens can have a good economic model.
7. L2 blocks and transaction data are propagated in the L2 p2p network.
8. L2 inherits the security of L1 (the assumption of the B52 proposal regarding the Rollup structure is that the Proposer is essentially the Sequencer). This solution divides the entire L2 block production process into three time phases:

Block Proposal Window (BPW)

Block Acceptance Window (BAW)

State advances

Among them, the BPW (Block Proposal) phase is the process where multiple Sequencers propose different blocks and compete, and Provers choose a candidate block to vote on.

BAW (Block Acceptance) is the process where Provers provide validity proofs for the blocks and submit them.

Block Proposal Window (BPW) Phase:

BPW can be further divided into Block Proposal, Block Voting, Aggregation three stages.

(Block Proposal Window flowchart) In the Block Proposal (BP) phase, anyone can collect transactions and broadcast their BP content. The BP content will include three parts: txs order hash, prover reward percentage, burn token amount. txs order hash: The Proposer selects the most valuable batch of transactions from the L2 transaction pool (mempool) and orders them, then includes the hash of this batch of transactions in the block they construct.

prover reward percentage: The percentage of block rewards shared with Provers by the Sequencer.

burn token amount: The amount of L2 Native Tokens proposed to be burned by the Proposer, after which they send their proposed BP to the L2 p2p network.

Block Voting Phase: After receiving different BPs proposed by various Proposers in the p2p network, Provers will vote for the BP that allows them to earn the most rewards. However, the composition of the votes is quite special:

Vote = { BlockHash, Index of Pro of Tree }

BlockHash is the hash of the Proposal that the Prover is voting for, while Index of Pro of Tree is the leaf index value of the Pro of Tree that the Prover is participating in constructing (to be explained later).

Aggregation: The Proposer collects the votes from Provers regarding the BP in the L2 p2p network, aggregates them, and includes them in the BP, submitting it to L1 (each BP generally only contains voting records related to itself). At this point, it is important to emphasize the prerequisites for a BP to be selected and included in the Rollup ledger:

Having the highest score:

SCORE (y) = NUMPROVERS (x)^3 * BURNBID (z)^2

NUMPROVERS (x) is the number of Prover votes received by the BP, and BURNBID is the amount of L2 Tokens proposed to be burned by the BP. Since the higher the BURN_BID, the less reward the BP proposer ultimately receives, this value needs to be set appropriately.

At the same time, the BP must be submitted to L1 before the Block Proposal Window ends, and the corresponding validity proof must be uploaded to L1 before the Block Acceptance Window ends.

It should be noted: In the score calculation of the BP, the number of votes carries the greatest weight, followed by the amount of burned tokens. Meanwhile, the B52 proposal allows multiple proposers (which are essentially sequencers) to compete for a valid BP slot.

The B52 proposal only requires the Proposer (sequencer) to specify the amount of burned tokens in their BP (similar to the EIP1559 approach) and does not require prior staking of tokens, which can make the network more permissionless and also benefit the native Token of L2 by creating deflation.

Additionally, the BP does not contain complete transaction data, only the hashes of the transaction sequences, similar to Ethereum's PBS scheme, aimed at preventing MEV from being exploited and front-run by other Proposers.

Block Acceptance Window (BAW) Detailed Explanation: (Block Acceptance Window diagram, labeled as Proof Acceptance) After the Block Proposal Window ends, Provers need to reveal their complete transaction data corresponding to their BP. If the BP voted by the Prover is selected (having the highest score, which can be queried through the L1 contract), they need to construct the Sub Proof Tree corresponding to the Index of Pro of Tree given during voting. Assuming Aztec's block contains 2^13=16384 transactions and there are 2048 Provers, then each Prover constructs a sub proof tree consisting of 2^3=8 transactions. The Prover then broadcasts their constructed sub proof tree to the L2 p2p network. The proposer will then aggregate all the sub proof trees into a single block proof. Next, the Proposer submits the aggregated proof to the L1 Rollup contract, which will verify the correctness of this proof and the corresponding state transition results. It is important to note that if a Prover intentionally fails to submit the proof, they will not only be unable to receive the block reward promised by the Proposer but will also be slashed, as becoming a Prover requires prior staking of Tokens. Therefore, unlike the Proposer (Sequencer), the Prover is not permissionless.

State Advances (State Transition Phase) Detailed Explanation:

After the Block Acceptance Window ends, the Rollup contract will select the block with the highest score to include in the Rollup ledger and distribute the block rewards according to the proportions declared in advance by the Proposer (Sequencer) to both the Proposer and the Prover.

This is the Aztec B52 proposal. However, the author believes that the B52 proposal has some potential issues:

Issue 1: What if the validity proof of a block with the highest score is incomplete? The solution proposed in the proposal is that if the Proposer only provides 50% of the proof, they can only receive 50% of the block reward, ensuring that the Proposer has no incentive to intentionally fail to submit the complete proof. At the same time, the Prover can also submit the proof directly to the contract.

According to the proposal's description, it is acceptable for a block to lack a complete transaction validity proof. This is actually unreasonable: because zkrollups declare the new state of the block valid only when providing the validity proof.

If the aggregated proof submitted to L1 by the proposer is missing the proof for a certain transaction, it is evident that all state transition proofs for transactions occurring after this transaction are invalid (since transactions are executed sequentially and have state dependencies), and we cannot confirm that the new state corresponding to this block is valid.

Therefore, the reasonable approach in this case should be to enter an infinite wait for the Block Acceptance Window until all transaction proofs are submitted.

Issue 2: What if the block with the highest score is an illegal block? (This point is also not explained in the B52 proposal). The BP only contains the hashes of the transaction sequences, so a malicious proposer could intentionally construct problematic transactions, such as double-spending transactions. In this case, it is necessary to add a function in the L1 contract that allows anyone to submit an illegal proof, which is used to prove that the BP with the highest score is an illegal block.

Moreover, such reports should be rewarded; we can reward the nodes that submit illegal proofs with the burn tokens sent by the proposer to the contract.

Interesting Thought: Regarding uncle blocks and excess Prover work: The B52 proposal will actually treat other BPs (that have already submitted complete proofs) appearing in the same round as uncle blocks after the highest and valid BP appears, allocating certain uncle block rewards.

This actually follows the practice of the ETH POW consensus mechanism; to avoid excessive concentration of computing power, a portion of the block rewards needs to be allocated to the proposers (miners) of unadopted blocks to protect the interests of small mining pools/individual miners and prevent computing power from being monopolized by large mining pools. Therefore, adopting the uncle block mechanism that performs well in Ethereum is also a very smart choice.

The significance of the B52 proposal in the decentralization of Rollup: Proposers are decentralized and do not require staking, with a low entry threshold; however, because they need to build the most valuable blocks themselves, as well as collect votes from other Provers and aggregate all proofs, the hardware threshold for Proposers is not as low as described in the proposal (for example, bandwidth may not be very low).

Thus, it will ultimately become a relatively centralized network, similar to MEV-Boost Builders, because the Proposers who can ultimately produce blocks are often also the best at capturing MEV as Block Builders.

At the same time, Provers in the B52 proposal need to stake assets, but since they only need to generate sub-tree proofs, compared to those requiring the complete generation of entire block proofs, the decentralization level of Provers will be better (hardware requirements can be lowered).

Liveness: Overall network liveness is good because L2 has its own p2p network to broadcast transactions and votes/BPs, and both Sequencers and Provers are relatively decentralized. However, we need to address the two issues mentioned above: one is that the block with the highest score must be a legal block, and the second is that we need to wait for the complete block proof to be submitted to L1 before entering a new state. Therefore, a more effective incentive mechanism is needed to prevent the entire Rollup network from malfunctioning (stopping) due to the lack of a certain transaction proof.

Censorship Resistance: If we can ensure that anyone can publish block proposals (BPs) and guarantee that not only Proposers can submit block proofs, then the network will have good censorship resistance.

Finality: The finality of L2 is closely related to the network's liveness, as the ultimate verified finality still needs to wait for the submission of Block Proofs, but in practice, you can also trust that the content of a block corresponding to the highest-scoring BP (as long as it does not contain malicious transactions).

This block will be revealed at the start of the Block Acceptance Window, meaning that as a user, you only need to wait for the duration of a Block Proposal Window for the block containing your submitted transaction to be adopted.

Inheriting L1 Security: As an L2 that updates its state by submitting validity proofs, it can inherit the security of L1.

Proposal Fernet: Introducing VDF to Select Valid Proposers

Overview of the Fernet Proposal: By using VDF during each block production cycle, an estimated score is set for different nodes in the Committee (which is the collection of Sequencer nodes), and the Sequencer proposing the block with the highest final score will become the valid block.

First, how to join the Committee? In fact, it requires staking 16 ETH on L1, and after the staking operation is completed, one must wait for 4 L1 blocks before joining the Sequencer Committee. As for exiting the Sequencer Committee, one needs to call the Unstake function in the L1 contract, and then wait another 3 days to retrieve their staked amount.

Then, what is VDF? Verifiable Delay Function is a mathematical function that satisfies strict serial execution characteristics; it performs a series of computational steps and will consume a predictable amount of time. We denote the value calculated by VDF as Score, which satisfies a uniform normal distribution, so when the Sequencer calculates the VDF Score, they can determine their probability of being selected as a valid Proposer.

The VDF calculation for the Sequencer is as follows:

Score = VDF (privatekey, public inputs)

public inputs = {current block number, randao}

randao is a random number used to prevent the Sequencer from pre-computing their VDF Score for all future block heights.

The entire process of Fernet is mainly divided into 3 phases:

1. Proposal Phase
2. Proving Phase
3. Finalization

Proposal Phase: PROPOSALPHASEL1_BLOCKS = 2 Ethereum blocks (this phase will last for the time of 2 L1 blocks)

At the start of this phase, each Sequencer will use VDF to calculate their corresponding VDF Score at the current block height. If a Sequencer believes their VDF Score is likely to win the block production rights (assuming the Score follows a normal distribution), then they will submit a Proposal to the L1 Rollup contract. The Proposal includes: the hash of the transaction sequence and which previous L2 block it points to.

unproven block: only the Proposal has been submitted to the Rollup contract. Then, the Sequencer needs to send the block contents corresponding to the unproven block and the proof of VDF to the L2 p2p network.

Proving Phase: PROVINGPHASEL1_BLOCKS = 50 L1 blocks (this phase will last for 50 L1 blocks, approximately 10 minutes)

Provers receive all transactions corresponding to the Block Contents from the L2 p2p network and will construct proofs for the blocks with higher VDF Scores. The construction of proofs is also done through parallel collaboration among multiple Provers (similar to the B52 proposal).

Thus, the Sequencer ultimately needs to aggregate the proofs corresponding to multiple different transactions into a single Block Proof (including VDF Proof) and submit it to the L1 Rollup contract. Anyone can submit the Block Contents of an already submitted Block Proof to the Rollup contract.

Finalization: A transaction on L1 needs to be submitted to finalize the block, and a block that can be finalized must meet the following conditions: it has submitted Block Contents and Block Proof, and the previous block it points to must be finalized. In addition to meeting the above conditions, it must also have the highest Score.

(Pipelined block production process, where the proposal phase of the previous block just ends, and the proposal phase of the next block begins without waiting for the proving phase of the previous block to finish)

Pipelined Block Production Mechanism: It is important to note that Fernet adopts a pipelined block production mechanism. When the Proposal phase of the N-th block ends, the Proposal for the N+1-th block begins (similar practices can be seen in public chains like Aptos). However, for the N+1-th block, it must wait for the N-th block to finalize before it can submit the Final Block transaction to L1 and be verified as the Final Block.

Potential Attack Dimensions: If the Sequencer with the highest VDF Score intentionally does not broadcast the Block Contents in the L2 p2p network, it may lead to block reorganization (reorg).

Calculation of the number of L2 blocks for reorg: 1 + PROVINGPHASEL1BLOCKS / PROPOSALPHASEL1BLOCKS = 1 + 50/2 = 26 blocks.

Solution: Introduce an uncle block mechanism to avoid having only one complete candidate block for each L2 slot (block production slot).

The significance of Fernet in decentralization: Sequencers join the Sequencer Committee by staking 16 ETH, which does not set a high entry threshold (but also not low). Provers do not need any staking, but if a Prover fails to generate a Proof, there is no penalty. This is essentially the opposite of the B52 proposal.

Liveness: The overall liveness of the network can be guaranteed because the VDF + uncle block mechanism ensures that there is more than one block producer in each round.

MEV: The consideration of MEV is quite special; this proposal plans to introduce PBS, so once the Sequencer calculates a high-scoring VDF Score, they can directly seek Block Builders to construct a more valuable block.

Censorship Resistance: Fernet will also adopt the same PBS mechanism as Ethereum, so essentially the censorship issues of Fernet are equivalent to the censorship issues of Ethereum's PBS.