Analyzing Aztec's Decentralized Sequencer Solution

• Forward the Original Title：Decentralizing Rollup: Analyzing Aztec’s Decentralized Sequencer Solution

Introduction: Ever since Rollup became prominent, the decentralization of the Sequencer has always been a focus of the Ethereum/Celestia community, and it is also a difficult mountain to cross in Layer2 development work. In this regard, different Rollup plans have proposed ideas for node decentralization, providing an extremely wide range of imagination for this topic.

The author of this article takes the well-known ZKRollup project Aztec as an example, and uses the two proposals named B52 and Fernet recently proposed by Aztec Labs as the entry point, to analyze for the readers how ZKR realizes the decentralization of the sequencer nodes.

Proposal B52: Permissionless Sequencer Scheme

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

1. Decentralized sequencer network, with L2 nodes electing proposers for each round.

2. Decentralized prover network, with low hardware requirements for prover nodes.

3. Rollup possessing excellent censorship resistance overall.

4. MEV value generated on L2 is obtained by L2 nodes.

5. When L2 blocks are submitted to the DA layer, relatively effective finality can be obtained. Irreversible finality requires completion of the Validity Proof submission.

6. L2 Tokens can have a decent tokenomic model.

7. Both L2 block and transaction data are propagated in the L2’s p2p network.

8. L2 inherits the security of L1.

(B52 proposal assumes the Rollup structure, the Proposer is essentially the Sequencer)

This plan divides the entire L2 block production process into three time stages:

Block Proposal Window (BPW) Block Acceptance Window (BAW) State advances

Among them, the BPW (Block Proposal) stage is the process where multiple Sequencers propose different blocks and compete, and Prover selects a candidate block to vote. BAW (Block Acceptance) is the process in which Prover constructs a Validity Proof for the block and submits it. Block Proposal Window (Block Proposal Phase): BPW can be further subdivided into three stages – Block Proposal, Block Voting, Aggregation.

(Block Proposal Window process diagram)

Block Proposal (BP) stage: anyone in the stage can collect transactions and broadcast their own 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), sorts them, and then places the hash value of these transactions into the block they are building. prover reward percentage: The percentage of block rewards that the Sequencer shares with the Prover. burn token amount: The quantity of L2 Native Tokens that the Proposer proposes to burn, then they send their BP to the L2 p2p network.

Block Voting Stage:

After the Prover receives BPs proposed by different Proposers in the p2p network, they will vote for the BP that allows them to get the most rewards. However, the composition of the vote is special:

Vote={BlockHash, Index of Proof Tree}

BlockHash is the hash of the Proposal that Prover wants to vote for, and Index of Proof Tree is the leaf index value of the Proof Tree that Prover wants to participate in building (will be explained later)

Aggregation: The Proposer collects votes from Provers on the BP in the L2 p2p network, aggregates them and puts them into the BP, and submits them to L1 (each BP generally only contains voting records related to itself).

Here, it is necessary to emphasize the prerequisite for BP to be selected and included in the Rollp ledger:

Having the highest score:

SCORE(y) = NUM_PROVERS (x)^3 * BURN_BID(z)^2`

NUM_PROVERS (x) is the number of Prover votes that this BP has received, and BURN_BID is the number of L2 Tokens proposed to be burned by this BP. Because the higher the BURN_BID, the less rewards the BP proposer will get in the end, so this value should be set appropriately.

At the same time, this BP needs to be submitted to L1 before the end of the Block Proposal Window, and the corresponding validity proof Proof needs to be uploaded to L1 before the end of the Block Acceptance Window.

Note: In the scoring of BP, the number of votes occupies the largest weight, followed by the number of burn tokens. At the same time, the B52 scheme allows multiple proposers (actually sequencers) to compete for a valid BP quota.

The B52 scheme only requires the Proposer (sequencer) to specify the number of burn tokens in their own BP (similar to the EIP1559 method) without having to stake tokens in advance, which can make the network more permissionless (no admission permission), and is also conducive to L2’s native Token deflation.

In addition, the BP does not contain complete transaction data, but only contains the hash of the transaction sequence, which is similar to Ethereum’s PBS scheme, aiming to avoid MEV being peeped and preempted by other Proposers.

Detailed explanation of Block Acceptance Window:

(Schematic diagram of Block Acceptance Window, written as Proof Acceptance in the picture)

After the Block Proposal Window ends, the Prover needs to reveal their complete transaction data corresponding to their BP. If the BP that the Prover votes for 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 Proof Tree given when voting.

Assume that an Aztec block contains 2^13=16384 transaction quantities, and there are 2048 provers, then each prover constructs a sub proof tree composed of 2^3=8 transactions. Then the prover broadcasts its constructed sub proof tree to the L2 p2p network. After receiving it, the proposer will aggregate all sub proof trees into a block proof.

Next, Propsoer will submit the aggregated proof to the L1 Rollup contract, which will verify the correctness of this proof and the corresponding state transition results. It should be noted here that if Prover deliberately does not submit the proof, it will not only fail to receive the block reward dividends promised by Proposer, but will also be slashed, because becoming a Prover requires staking tokens in advance. Therefore, unlike the Proposer (Sequencer), the Prover is not Permissionless.

Detailed explanation of State Advances:

After the Block Acceptance Window ends, the Rollup contract will select the block with the highest score to be included in the Rollup ledger, and the block reward will be sent to the Proposer (Sequencer) and the Prover in the proportion previously declared by the Proposer.

The above is Aztec’s B52 scheme. However, the author of this article believes that the B52 proposal has some potential problems:

Problem one: Suppose the validity proof of a block with the highest score is incomplete. The solution given in the proposal is that if the Proposer only provides 50% of the proof, then he can only get 50% of the block reward, thereby ensuring that the Proposer has no incentive to deliberately not submit a complete proof. At the same time, the Prover can also directly submit the proof to the contract.

According to the description of the proposal, it is acceptable for a block not to have a complete transaction validity proof. This is actually unreasonable because: zkrollup declares the new state corresponding to this block to be valid only when the validity proof is given.

If the aggregate proof that the proposer finally submits to L1 is missing the proof of a certain transaction, it is obvious that the state transition proof of all transactions that occur after this transaction is invalid (because transactions are executed in sequence and have state dependencies), and we cannot confirm that the new state corresponding to this block is valid.

Therefore, at this time, the reasonable way should be to enter the infinite waiting Block Acceptance Window until all transaction proofs are submitted.

Problem 2: Suppose the highest scoring block is an illegal block (this point is not explained in the B52 plan). The BP only contains the hash of the transaction sequence, so a malicious proposer could intentionally construct problematic transactions, such as double-spending transactions. At this time, it is actually necessary to add a function to the L1 contract that allows anyone to submit an illegal proof. This illegal proof is used to prove that the highest scoring BP is an illegal block.

Also, this kind of report should be rewarded. We can give all the burn tokens sent to the contract by the proposer as a reward to the node that submitted the illegal proof.

Interesting thought: About uncle blocks and redundant Prover Work: The B52 plan will actually, after each round of the highest and valid BP appears, treat other BPs (who have submitted complete proofs) in this round as uncle blocks and distribute a certain amount of uncle block rewards.

This actually follows the practice of ETH POW consensus mechanism. To avoid excessive concentration of computing power, it is necessary to allocate a part of the block reward to the proposers of the blocks that are not adopted (miners), to protect the interests of small mining pools/individual miners and to prevent the mining power from being monopolized by large mining pools. Therefore, adopting Ethereum’s well-performed uncle block mechanism is also a very clever choice.

The significance of the B52 proposal in terms of Rollup decentralization: The Proposer is decentralized and does not require a pledge, and the entry barrier is low. However, because it requires building the most valuable block by itself, as well as collecting votes from other Provers and aggregating all Proofs, the hardware threshold of the Proposer is not as low as described in the proposal (for example, the bandwidth may not be very low).

Therefore, it will eventually become a more centralized network, similar to Mev-Boost Builder, because the proposer who can eventually produce the block is often the Block Builder who is best at capturing MEV.

At the same time, the Prover in the B52 scheme needs to pledge assets, but because it only needs to generate sub tree proof, compared to those solutions that need to fully generate the entire block proof, the degree of decentralization of the Prover will be better (hardware requirements can be lowered).

Liveness: The overall network Liveness is good, because L2 has its own p2p network to broadcast transactions and voting/BP, and both Sequencer and Prover are relatively decentralized. But we need to solve the two problems mentioned above, one is that the highest scoring block 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 avoid the entire Rollup network from failing to work normally (stopping) due to the lack of some tx proof.

Censorship Resistance: If we can ensure that anyone can publish block proposals BP, and ensure that not only the Proposer can submit block proof, then the network will have good censorship resistance.

Finality: L2’s finality is closely related to the network’s liveness, because the final verified finality still needs to wait for the submission of Block Proof, but in fact you can also trust the block content corresponding to the highest scoring BP (as long as it does not contain malicious transactions).

This block will be revealed at the beginning of the Block Acceptance Window, which means that as a user, you only need to wait for a Block Proposal Window time, and the block where your transaction is located can be adopted.

Inherit L1 Security: As a L2 that updates the state by submitting validity proof, it can inherit the security of L1.

Fernet Proposal: Introducing VDF for Proposer Selection

Overview of the Fernet Scheme: Utilizing VDF within each block generation cycle, a projected score is assigned to different nodes within the Committee (the collection of Sequencer nodes), and the block proposed by the Sequencer with the highest final score becomes the valid block.

Firstly, how does one join the Committee? Essentially, it requires staking 16 ETH on L1 and then, after the staking process is completed, waiting 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, after which it takes 3 days to retrieve the remaining staked amount.

Next, what is VDF? Verifiable Delay Function is a mathematical function that adheres to strict serial execution characteristics. It executes certain computational steps and consumes a predictable amount of time. We denote the value calculated by VDF as the Score, which follows a uniform normal distribution. Thus, once the Sequencer calculates the VDF Score, they can determine the probability of being selected as a legitimate Proposer.

The VDF calculation for Sequencer is as follows:

Score = VDF( privatekey , public inputs )

public inputs = { current block number , randao }

randao is a random number used to prevent Sequencers from prematurely calculating its VDF Score for all future block heights

The entire process of Fernet is mainly divided into three stages:

1. Proposal Phase 2. Proving Phase 3. Finalization

Proposal Phase: PROPOSAL_PHASE_L1_BLOCKS = 2 Ethereum blocks (This phase will last for 2 L1 block time)

At the beginning of this phase, each Sequencer will calculate its own VDF Score at the current block height. If the Sequencer believes that its VDF Score is likely to win the block production right of this block (assuming the Score satisfies the normal distribution), it will submit a Proposal to the L1 Rollup contract. The Proposal includes: the hash of the transaction sequence, pointing to a previous L2 block.

unproven block: The block that has only submitted the Proposal to the Rollup contract block contents. 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: PROVING_PHASE_L1_BLOCKS= 50 L1 blocks (This phase will last for 50 L1 blocks, about 10 min)

The Prover receives all transactions corresponding to the Block Contents from the L2 p2p network, and builds a Proof for the block with a higher VDF Score. The construction of the Proof also adopts a method of multiple Provers cooperating in parallel (similar to the B52 scheme).

Therefore, the Sequencer needs to finally aggregate the Proofs of multiple different transactions into a Block Proof (including VDF Proof), and submit it to the L1 Rollup contract. Anyone can submit the Block Contents that have already submitted the Block Proof to the Rollup contract.

Finalization: It needs to submit an L1 transaction to Finalize the block, a block that can be finally Finalized needs to meet: submitted Block Contents and Block Proof, the previous block it points to must be Finalized. On this basis, it also needs to have the highest Score.

(The pipeline-style block-out process, as soon as the proposal stage of the previous block ends, the proposal stage of the next block begins, without waiting for the Proving stage of the previous block to end.)

Pipeline block generation mechanism: It is worth noting that Fernet adopts a pipeline block generation mechanism. When the Proposal phase of block N ends, the Proposal for block N+1 begins (similar to what Aptos and other public chains do). However, for block N+1, it needs to wait for block N to finalize before it can submit the Final Block transaction of L1 and be validated to become the Final Block.

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

Calculation of L2 block quantity for reorg: 1+PROVING_PHASE_L1_BLOCKS / PROPOSAL_PHASE_L1_BLOCKS =1+50/2=26 blocks

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

The significance of decentralization in Fernet: Sequencers join the Sequencer Committee by staking 16 ETH, and the entry threshold is not high (but not low either). Provers do not need any staking, but if Provers do not generate Proof, there is no penalty. This is basically opposite to the B52 scheme.

Liveness: The overall network’s Liveness can be guaranteed because VDF + uncle block mechanism can ensure that there is more than one block producer in each round.

MEV: Consideration of MEV is particularly unique. This scheme plans to introduce PBS, so after a Sequencer calculates a high-scoring VDF Score, it can directly approach the Block Builder to construct a more valuable block.

Censorship Resistance: Fernet will also adopt a PBS mechanism consistent with Ethereum, so essentially, Fernet’s censorship resistance issue is equivalent to Ethereum’s PBS censorship resistance issue.

Disclaimer：

1. This article is reprinted from [Geek Web3], Forward the Original Title‘ollup Decentralization: Analysis of Aztec’s Decentralized Sequencer Solution’,All copyrights belong to the original author [xhhh，EthStorage]. If there are objections to this reprint, please contact the Gate Learn team, and they will handle it promptly.
2. Liability Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
3. Translations of the article into other languages are done by the Gate Learn team. Unless mentioned, copying, distributing, or plagiarizing the translated articles is prohibited.