Analyzing Aztec Labs’ B52 proposal How does ZK-Rollup achieve decentralization of sequencer nodes?
Analyzing Aztec Labs' B52 proposal ZK-Rollup's decentralization of sequencer nodes.
Author: 0xhhh, EthStorage
Editor: Faust, “Geek Web3”
Introduction: Since Rollup became popular, the decentralization of the sequencer has always been the focus of attention in the Ethereum/Celestia community and a difficult hurdle in Layer2 development. Different Rollup solutions have proposed ideas about decentralizing nodes, providing vast space for imagination on this topic.
In this article, the author takes the well-known ZKRollup project Aztec as an example, and uses two proposals recently proposed by Aztec Labs named B52 and Fernet as the starting point to explain how ZKR achieves decentralization of sequencer nodes for readers.
Proposal B52: Permissionless Sequencer Solution
Proposal B52 intends to achieve the following goals (ideally):
- Evolution of the decentralized stablecoin landscape What are the ne...
- LianGuaiWeb3.0 Daily | Zuckerberg Meta remains fully committed to t...
- In-depth analysis of RSS3 The bridge between Web3 and AI
1. Decentralized sequencer network, with L2 nodes electing the proposer for each round
2. Decentralized prover network with low hardware requirements for prover nodes
3. Rollup has good resistance to censorship
4. L2 nodes obtain the MEV value generated by L2
5. When L2 blocks are submitted to the DA layer, they can achieve relatively effective finality. Irreversible finality requires the completion of Validity Proof submission
6. L2 Tokens can have a good economic model
7. L2 blocks and transaction data are propagated in the L2’s p2p network
8. L2 inherits the security of L1
This proposal divides the entire L2 block generation process into three time stages:
- Block Proposal Window (BPW)
- Block Acceptance Window (BAW)
- State advances
Among them, the Block Proposal Window (BPW) stage is the process where multiple sequencers propose different blocks and compete, and the Prover selects a candidate block to vote on.
The Block Acceptance Window (BAW) is the process where the Prover constructs a Validity Proof for the block and submits it.
Block Proposal Window stage:
BPW can be further divided into three stages: Block Proposal, Block Voting, Aggregation.
In the Block Proposal (BP) stage, 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 a batch of transactions with the highest value from L2’s transaction pool (mempool), sorts them, and puts the hash values of these transactions into the block they construct.
prover reward percentage: The percentage of block rewards that the Sequencer shares with the Prover.
burn token amount: The amount of L2 Native Tokens that the Proposer proposes to burn, and then sends their proposed BP to the L2 p2p network.
Block Voting phase:
When the Prover receives BPs proposed by different Proposers in the p2p network, it votes for the BP that can provide the highest reward. However, the composition of the vote is special:
Vote={BlockHash, Index of Proof Tree}
The BlockHash is the hash of the Proposal that the Prover wants to vote for, and the Index of Proof Tree is the index value of the leaf that the Prover wants to participate in constructing (this will be explained later).
Aggregation: The Proposer collects the votes of the Provers on the BP in the L2 p2p network, aggregates them, and puts them in the BP, which is then submitted to L1 (each BP generally only contains voting records related to itself).
Here, it is important to emphasize the prerequisites for a BP to be selected and included in the Rollup ledger:
Has the highest score:
SCORE(y) = NUM_PROVERS (x)^3 * BURN_BID(z)^2`
NUM_PROVERS (x) is the number of Prover votes that the BP receives, and BURN_BID 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 will receive, this value needs to be set properly.
At the same time, the BP needs to be submitted to L1 before the Block Proposal Window ends, and the corresponding validity proof Proof needs to be uploaded to L1 before the Block Acceptance Window ends.
It should be noted that in the calculation of the BP score, the weight of the number of votes is the highest, followed by the number of burned 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 amount of burn tokens in their BP (similar to EIP1559), without the need to stake tokens in advance. This can make the network more permissionless and also benefit the deflation of L2’s native tokens.
In addition, the BP does not contain complete transaction data, only the hash of the transaction sequence, similar to the Ethereum PBS scheme, aiming to prevent MEV from being observed and front-run by other Proposers.
Detailed explanation of the Block Acceptance Window phase:
After the Block Proposal Window ends, the Provers need to reveal the complete transaction data corresponding to their BP (Block Proposal). If a BP voted by a Prover is selected (with 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 at the time of voting.
Assuming that Aztec’s block contains 2^13 = 16384 transactions and there are 2048 Provers, each Prover constructs a sub proof tree consisting of 2^3 = 8 transactions. Then the Provers broadcast the sub proof trees they constructed to the L2 P2P network. After receiving them, the Proposer aggregates all the sub proof trees into a block proof.
Then the Proposer submits the aggregated proof to the Rollup contract on L1, and the contract verifies the correctness of this proof and the corresponding state transition results. It should be noted that if a Prover intentionally does not submit the proof, not only will they not receive the block rewards promised by the Proposer, but they will also be slashed because becoming a Prover requires pre-staking tokens. Therefore, unlike the Proposer (Sequencer), the Prover is not permissionless.
Explanation of State Advances:
After the Block Acceptance Window ends, the Rollup contract selects the block with the highest score to be included in the Rollup ledger and distributes the block rewards to the Proposer and Provers according to the proportions declared by the Proposer (Sequencer) in advance.
These are the details of Aztec’s B52 scheme. However, the author of this article believes that there are some potential issues with the B52 proposal:
Issue 1: If the validity proof of the highest-scoring block is incomplete. The proposed solution is that if the Proposer only provides 50% of the proof, then they will only receive 50% of the block rewards, ensuring that the Proposer has no incentive to intentionally not submit the complete proof. Provers can also directly submit the proof to the contract.
According to the description in the proposal, it is acceptable for a block to have an incomplete validity proof. This is actually unreasonable because zkRollup declares the new state corresponding to this block as valid only when the validity proof is provided.
If the aggregated proof submitted by the Proposer to L1 is missing the proof of a certain transaction, it is obvious that the state transition proofs of all transactions that occur after this transaction are invalid (because transactions are executed sequentially and have state dependencies), and we cannot confirm that the new state corresponding to this block is valid.
Therefore, in this case, a reasonable approach would be to enter an infinite waiting Block Acceptance Window until all transaction proofs are submitted.
Issue 2: If the highest-scoring block is an invalid block (this is not explained in the B52 proposal). The BP only contains the hash of the transaction sequence, so a malicious proposer can intentionally construct problematic transactions, such as double-spending transactions. In this case, it is actually necessary to add a function to the L1 contract that allows anyone to submit an illegal proof, which can prove that the highest-scoring BP is an invalid block.
And this kind of reporting should be rewarded. We can reward the proposer who sends the burn token to the contract with the illegal proof submitted by the reporter node.
Interesting thoughts: Regarding uncle blocks and redundant Prover Work: The B52 scheme will actually take the other BPs (who have already submitted complete proofs) that appear in this round as uncle blocks and allocate a certain uncle block reward.
This actually follows the practice of the ETH POW consensus mechanism. In order to avoid excessive concentration of computing power, a portion of the block rewards needs to be allocated to the proposers (miners) whose blocks have not been adopted, in order 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 has performed well in Ethereum is also a very smart choice.
The significance of the B52 proposal in decentralization of Rollup: The proposer is decentralized and does not require collateral, with a low admission threshold; however, because they need to build the most valuable blocks themselves, collect votes from other Provers, and aggregate all proofs, the hardware threshold for the proposer is not as low as described in the proposal (for example, the bandwidth may not be very low).
Therefore, in the end, it will still become a relatively centralized network, similar to Mev-Boost Builder, because the proposers who can ultimately produce blocks are often the most skilled Block Builders at capturing MEV.
At the same time, Provers in the B52 scheme need to collateralize assets, but because they only need to generate sub tree proofs, compared to schemes that need to generate complete block proofs, the decentralization degree of Provers will be better (hardware requirements can be lowered).
Activity Liveness: The overall network liveness is good because L2 has its own p2p network to broadcast transactions and votes/BPs, and both the Sequencer and Prover are relatively decentralized. However, we need to solve the two problems mentioned above: one is that the highest-scoring block must be a valid block, and the other is that we need to wait for the complete block proof to be submitted to L1 before entering a new state. Therefore, we need a more effective incentive mechanism to prevent the entire Rollup network from being unable to function properly (shut down) due to the absence of a certain part of the tx proof.
Censorship Resistance: If we can ensure that anyone can propose a block BP and that it is not only the proposer who can submit block proofs, 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 requires waiting for the submission of block proofs, but in practice, you can also trust 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 during the Block Acceptance Window, which means that as a user, you only need to wait for a Block Proposal Window, and the block containing your submitted transaction can be adopted.
Inheritance of L1 security: As an L2 that updates states by submitting validity proofs, it can inherit the security of L1.
Proposal Fernet: Introducing VDF to Select a Legitimate Proposer
Fernet Proposal Overview: Using VDF, a predicted score is assigned to different nodes in the Committee (which is a collection of Sequencer nodes) during each block generation cycle. The block proposed by the Sequencer with the highest score becomes the valid block.
Firstly, how to join the Committee? In reality, it requires staking 16 ETH on L1 and after the staking operation is completed, wait for 4 L1 blocks before joining the Sequencer Committee. To exit the Sequencer Committee, the Unstake function in the L1 contract needs to be called, and then it takes 3 days to retrieve the remaining staked amount.
So, what is VDF? Verifiable Delay Function is a math function that satisfies strict serial execution properties. It performs some computational steps and consumes a predictable amount of time. The value computed by VDF is called the Score, which follows a uniform normal distribution. Therefore, when the Sequencer calculates the VDF Score, they can determine the probability of being selected as a legitimate Proposer.
The VDF calculation for the Sequencer is as follows:
Score = VDF(private key, public inputs)
public inputs = {current block number, randao}
Randao is a random number used to prevent the Sequencer from calculating their VDF Score for all future block heights in advance.
The entire Fernet process consists of 3 stages:
1. Proposal Phase 2. Proving Phase 3. Finalization
Proposal Phase: PROPOSAL_PHASE_L1_BLOCKS = 2 Ethereum blocks (this phase lasts for 2 L1 blocks)
During this phase, each Sequencer calculates their VDF Score for the current block height using VDF. If a Sequencer believes that their VDF Score has a high chance of winning the block generation right for this round (assuming the Score follows a normal distribution), they will submit a Proposal to the L1 Rollup contract. The Proposal includes the hash of the transaction sequence and a reference to a previous L2 block.
Unproven block: A block that has only submitted a Proposal to the Rollup contract, without submitting the block contents. Then, the Sequencer needs to send the block contents of the unproven block and the proof of VDF to the L2 p2p network.
Proving Phase: PROVING_PHASE_L1_BLOCKS = 50 L1 blocks (this phase lasts for approximately 10 minutes)
The Prover receives all the transactions corresponding to the Block Contents from the L2 p2p network and constructs a Proof for the blocks with higher VDF Scores. The construction of the Proof also involves multiple Provers working in parallel (similar to the B52 scheme).
Therefore, the Sequencer needs to aggregate the Proofs corresponding to different transactions into a Block Proof (including the VDF Proof) and submit it to the L1 Rollup contract. Anyone can submit the Block Contents that have already been submitted with a Block Proof to the Rollup contract.
Finalization: A transaction on L1 needs to be submitted to Finalize a block. A block can only be Finalized if it meets the following conditions: it has submitted Block Contents and Block Proof, and it references a previously Finalized block. Additionally, it must have the highest Score.
Block production pipeline mechanism: It should be noted that Fernet adopts a block production pipeline mechanism. When the Proposal phase of Block N ends, the Proposal phase of Block N+1 begins (Aptos and other public chains also have similar practices). However, for Block N+1, it needs to wait for Block N to be Finalized before it can submit the Final Block transaction of L1 and be verified to become the Final Block.
Potential attack dimension: If the Sequencer with the highest VDF Score intentionally does not broadcast the Block Contents in L2 p2p, it may lead to block reorganization (reorg).
Calculation of the number of L2 blocks in a reorg: 1+PROVING_PHASE_L1_BLOCKS / PROPOSAL_PHASE_L1_BLOCKS = 1+50/2=26 blocks
Solution: Introduce the uncle block mechanism to avoid having only one complete candidate block in each L2 slot (block production time slot).
The significance of Fernet in decentralization: The Sequencer joins the Sequencer Committee by staking 16 ETH, and the admission threshold is not high (but not low either). The Prover does not need to stake any assets, but there is no punishment if the Prover does not generate a proof. This is fundamentally different from the B52 scheme.
Active Liveness: The overall network’s Liveness can be guaranteed because the VDF+uncle block mechanism ensures that there is more than one block producer in each round.
MEV: Consideration for MEV is the most special. This scheme plans to introduce PBS so that after the Sequencer calculates a high-scoring VDF Score, it can directly find the Block Builder to construct a more valuable block.
Censorship Resistance: Fernet will also adopt the same PBS mechanism as Ethereum, so essentially, the censorship resistance problem of Fernet is equivalent to the censorship resistance problem of Ethereum PBS.
