Introduction: Since Rollup became popular, the decentralization of Sequencer has always been the focus of the Ethereum/Celestia community, and it is also an insurmountable mountain in Layer2 research and development. In this regard, different Rollup schemes have proposed ideas about node decentralization, providing an extremely broad imagination space 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 proposed by Aztec Labs recently as the starting point to analyze how ZKR realizes the decentralization of sequencer nodes for readers.
Proposal B52: Permissionless sequencer scheme
Proposal B52 intends to achieve the following (ideally):
Decentralized sequencer network, L2 nodes themselves elect each round of proposers
Decentralized prover network, low hardware requirements for prover nodes
Rollup has good resistance to censorship as a whole.
The MEV value generated by L2 is acquired by L2 nodes
When the L2 block is submitted to the DA layer, a more effective finality can be obtained, and the irreversible finality has to wait for the ValidityProof (validity proof) to be submitted
L2 Token can have a good economic model
Both L2 blocks and transaction data are propagated in the L2 p2p network
L2 inherits the security of L1
This scheme divides the entire L2 block production process into three time stages:
Block Proposal Window(BPW)
BlockAcceptance Window(BAW)
State advances
Among them, the BPW (block proposal) stage is a process in which multiple sequencers Seuqnecer propose different blocks and compete, and Prover selects a candidate block to give a vote.
BAW (Block Acceptance) is the process in which Prover constructs a Validity Proof for a block and submits it.
Block Proposal Window (block proposal stage):
BPW can be subdivided into three stages: Block Proposal, Block Voting, Aggregation.
Anyone in the Block Proposal (BP) phase can collect transactions and broadcast their own BP content. BP content will contain three parts: txs order hash, prover reward percentage, burn token amount
txs order hash: Proposer selects and sorts the most valuable batch of transactions from the L2 transaction pool (mempool), and then puts the hash value of this batch of transactions into the block it builds.
prover reward percentage: The block reward percentage shared by Sequencer to Prover
burn token amount: The number of L2 Native Token proposed by the Proposer to be destroyed, and then it sends the proposed BP to the L2 p2p network
Block Voting stage:
After Prover receives BP proposed by different Proposers in the p2p network, he will vote for the BP that can get him the most reward. However, the composition of the vote is very special:
Vote={BlockHash, Index of Proof Tree}
BlockHash is the hash of the Proposal that Prover will vote on, and Index of Proof Tree is the leaf index value of the Proof Tree that Prover will participate in building (explained later)
Aggregation aggregation: Proposer collects the votes of Provers for BP in the L2 p2p network, aggregates them and puts them into BP, and submits them to L1 (each BP generally only contains voting records related to itself).
Here, it is necessary to emphasize the prerequisites for BP to be selected and included in the Rollp ledger:
Have the highest score:
SCORE(y) = NUM_PROVERS (x)^3 * BURN_BID(z)^2
NUM_PROVERS (x) is the number of Prover votes obtained by the BP, and BURN_BID is the number of L2 Tokens proposed to be destroyed by the BP. Since the higher the BURN_BID is, the less reward the BP proposer will get in the end, so this value should be set properly.
At the same time, the BP needs to be submitted to L1 before the end of the Block Proposal Window, and the corresponding proof of validity must be uploaded to L1 before the end of the Block Acceptance Window.
Note: In the calculation of BP scores, the number of votes accounts for the largest proportion, followed by the number of burn tokens. At the same time, the B52 scheme allows multiple proposers (actually sequencers) to compete for an effective BP quota
The B52 scheme only requires the Proposer (sequencer) to specify the number of burn tokens in its own BP (similar to the method of EIP1559) without stake tokens in advance, which can make the network more permissionless (no access permission), and is also beneficial to L2 Native Token produces deflation.
In addition, BP does not contain complete transaction data, but only the hash of the transaction sequence. The reason is similar to the Ethereum PBS scheme, which aims to prevent MEV from being spied on by other Proposers.
After the Block Proposal Window ends, Prover needs to reveal the complete transaction data corresponding to their BP. If the BP voted by the Prover is selected (the highest score can be queried through the L1 contract), they need to construct the Sub Proof Tree corresponding to the Index of Proof Tree given during the vote.
Assuming that 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. Then the prover broadcasts the sub proof tree constructed by itself to In the L2 p2p network. After the proposer receives it, it will aggregate all sub proof trees into a block proof.
Then Propsoer submits the aggregated proof to the L1 Rollup contract, and the contract will verify the correctness of the proof and the corresponding state transition results. It should be noted here that if the Prover deliberately fails to submit the proof, not only will he not be able to obtain the block reward dividend promised by the Proposer, but he will also be slashed, because to become a Prover, he needs to pledge Token in advance. Therefore, unlike Proposer (Sequencer), Prover is not Permissionless.
State Advances (state advancement stage) detailed explanation:
After the Block Acceptance Window ends, the Rollup contract will select a block with the highest score to be included in the Rollup ledger, and send the block reward Reward to the Proposer and Prover respectively according to the proportion declared by the Proposer (Sequencer) in advance.
**The above is Aztec's B52 solution. However, the author of this article believes that there are some potential problems with the B52 proposal: **
Question 1: If 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 rewards, so as to ensure that the Proposer has no motivation to deliberately not submit a complete proof. At the same time, Prover can also submit proof directly to the contract.
According to the description of the proposal, it is acceptable to accept a block without a validity proof of complete transactions. This is actually unreasonable: because: zkrollup only declares that the new state corresponding to this block is valid when the validity proof is given.
If the aggregate 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), we It is also impossible to confirm that the new state corresponding to this block is valid.
Therefore, at this time, the reasonable way should be to enter the Block Acceptance Window that waits infinitely until all transaction proofs are submitted.
Question 2: **If the block with the highest score is an illegal block (this is not explained in the B52 scheme). **BP only contains the hash of the transaction sequence, so a malicious proposer can actually deliberately construct problematic transactions, such as double-spend transactions. So at this time, it is actually necessary to add a function in the L1 contract that anyone can submit an illegal proof. This illegal proof is used to prove that the BP with the highest score is an illegal block.
And this kind of report should be rewarded, we can reward the burn token sent by the proposer to the contract to the reporter node who submitted the illegal proof.
**Interesting thinking:**About uncle blocks and redundant Prover Work: B52 scheme will actually use other BPs (who have submitted complete proofs) that appear in this round as uncles after the BP with the highest score in each round appears. block, assign a certain uncle block reward.
This actually follows the approach of the ETH POW consensus mechanism. In order to avoid excessive concentration of computing power, it is necessary to allocate a part of block rewards to unaccepted block proposers (miners) to protect the interests of small mining pools/individual miners and avoid The computing power is monopolized by large mining pools. Therefore, it is also a very smart choice to adopt the uncle block mechanism that Ethereum performs well.
The significance of the B52 proposal in terms of Rollup decentralization: Proposer is decentralized and does not require pledge, and the entry threshold is low; but because you need to build the most valuable blocks yourself, and you need to collect votes from other Proposers , and aggregate all Proofs. In fact, the Proposer’s hardware threshold is not as low as stated in the proposal (for example, the bandwidth may not be very low).
Therefore, it will eventually become a relatively centralized network, similar to Mev-Boost Builder, because the proposer who can finally generate blocks is often the Block Builder that is best at capturing MEV.
At the same time, the Prover in the B52 scheme needs to pledge assets, but because only the sub tree proof needs to be generated, compared with those schemes that need to completely generate the entire block proof, **Prover’s degree of decentralization will be better (hardware requirements can be lowered). **
Active Liveness: The overall network Liveness is good, because L2 has its own p2p network to broadcast transactions and votes/BP, and Sequencer and Prover are relatively decentralized. But we need to solve the two problems we mentioned above. One is that the block with the highest score must be a legal block, and the second is that it needs 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 (downtime) due to the lack of a certain part of the tx proof.
**Censorship Resistance: **If we can guarantee that anyone can publish block proposal BP, and ensure that not only Proposer can submit block proof, then the network will have good resistance to censorship.
**Finality: **The finality of L2 is closely related to the liveness of the network, 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 a BP with the highest score (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, and the block where the transaction you submitted can be accepted.
Inherit L1 security: As an L2 that updates its status by submitting validity proof, it can inherit the security of L1.
Proposal Fernet: Introduce VDF to select legal Proposer
Fernet scheme introduction: Through VDF, in each round of block generation cycle, an estimated score is set for different nodes in the Committee (that is, the set of Sequencer nodes), and the block proposed by the Sequencer with the highest final score will become valid piece.
**First, how to join the Committee? In fact, you need to pledge 16 ETH in L1, **and wait for 4 L1 blocks after the pledge operation is completed, and then join the Sequencer Committee. As for exiting the Sequencer Committee, you need to call the Unstake function in the L1 contract, and then you can get back the remaining amount of your pledge after another 3 days.
Then, what is a VDF? Verifiable Delay Function is a verifiable delay function. This mathematical function satisfies strict serial execution characteristics. It will perform some calculation steps and consume at least a predictable period of time. We record the value calculated by VDF as Score, which satisfies a uniform normal distribution. Therefore, after Sequencer calculates VDF Score, it can judge the probability of being selected as a legal proposer. **
Sequencer's VDF is calculated as follows:
Score = VDF( privatekey , public inputs )
public inputs = { current block number , randao }
randao is a random number used to prevent Sequencer from calculating its own VDF Score at all future block heights in advance
The whole process of Fernet is mainly divided into 3 stages:
Proposal Phase 2. Proving Phase 3. Finalization
**Proposal Phase:**PROPOSAL_PHASE_L1_BLOCKS = 2 Ethereum blocks (this phase will last for 2 L1 blocks)
At the beginning of this stage, each Sequencer will use VDF to calculate its corresponding VDF Score at the current block height. If Sequencer thinks that his VDF Score is likely to win the right to produce a block this time (assuming the Score satisfies a normal distribution), then he will submit a Rollup contract from Proposal to L1. Proposal contains: the hash of the transaction sequence, pointing to which previous L2 block.
unproven block: Only the block contents of the Proposal to the Rollup contract are submitted. Next, **Sequencer needs to send the block contents corresponding to the unproven block and the proof of VDF to the L2 p2p network. **
ProvingPhase: PROVING_PHASE_L1_BLOCKS= 50 L1 blocks (this phase will maintain 50 L1 blocks, about 10 min)
Prover receives all corresponding transactions in Block Contents from the L2 p2p network, and will build Proof for blocks with higher VDF Score. The construction of Proof also adopts the method of multiple Provers collaborating in parallel (similar to the B52 scheme).
Therefore, Sequencer needs to aggregate Proofs corresponding to multiple different transactions into a Block Proof (including VDF Proof) at the end, and submit it to the Rollup contract of L1. Anyone can submit Block Contents that have submitted Block Proof to the Rollup contract.
Finalization: It is necessary to submit an L1 transaction to Finalize the block. A block that can be finalized needs to be satisfied: Block Contents and Block Proof are submitted, and the previous block pointed to must be Finalized. On the basis of meeting the above conditions, you must also have the highest Score.
Pipeline block production mechanism: It should be noted that Fernet adopts a pipeline block production mechanism. When the Proposal phase of the Nth block ends, the Proposal of the N+1th block begins (Aptos and other public chains also have similar practices) . But for the N+1th block, it needs to wait for the Nth block to be Finalized before it can submit the L1 Final Block transaction and pass the verification to become a Final Block.
Potential attack dimensions: If the Sequencer with the highest VDF Score deliberately does not broadcast Block Contents in L2 p2p, it may lead to block reorganization.
Calculation of the number of L2 blocks in reorg: 1+PROVING_PHASE_L1_BLOCKS / PROPOSAL_PHASE_L1_BLOCKS =1+50/2=26 blocks
Solution: Increase the uncle block mechanism to avoid having only one complete candidate block for each L2slot (block generation time slot).
The significance of Fernet in terms of decentralization: Sequencer joins the Sequencer Committee by pledging 16 ETH, and the entry threshold is not high (but not low). Prover does not require any pledge, but there is no penalty if Prover does not generate Proof. This is basically the opposite of the B52 scheme.
**Active Liveness: **The Liveness of the overall network can be guaranteed, because the VDF+uncle block mechanism can ensure that there is more than one block producer in each round.
**MEV: **MEV considerations are the most special. The plan plans to introduce PBS, so that after calculating a high VDF Score as a Sequencer, you can directly find a Block Builder to construct a more valuable block.
**Censorship Resistance: **Fernet will also adopt the same PBS mechanism as Ethereum, so in essence, Fernet’s anti-censorship problem is equivalent to that of Ethereum’s PBS.
View Original
The content is for reference only, not a solicitation or offer. No investment, tax, or legal advice provided. See Disclaimer for more risks disclosure.
How does ZK-Rollup realize the decentralization of sequencer nodes?
Author: 0xhhh, EthStorage; Compiler: Faust, "Geek web3"
Introduction: Since Rollup became popular, the decentralization of Sequencer has always been the focus of the Ethereum/Celestia community, and it is also an insurmountable mountain in Layer2 research and development. In this regard, different Rollup schemes have proposed ideas about node decentralization, providing an extremely broad imagination space 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 proposed by Aztec Labs recently as the starting point to analyze how ZKR realizes the decentralization of sequencer nodes for readers.
Proposal B52: Permissionless sequencer scheme
Proposal B52 intends to achieve the following (ideally):
Decentralized sequencer network, L2 nodes themselves elect each round of proposers
Decentralized prover network, low hardware requirements for prover nodes
Rollup has good resistance to censorship as a whole.
The MEV value generated by L2 is acquired by L2 nodes
When the L2 block is submitted to the DA layer, a more effective finality can be obtained, and the irreversible finality has to wait for the ValidityProof (validity proof) to be submitted
L2 Token can have a good economic model
Both L2 blocks and transaction data are propagated in the L2 p2p network
L2 inherits the security of L1
This scheme divides the entire L2 block production process into three time stages:
Among them, the BPW (block proposal) stage is a process in which multiple sequencers Seuqnecer propose different blocks and compete, and Prover selects a candidate block to give a vote.
BAW (Block Acceptance) is the process in which Prover constructs a Validity Proof for a block and submits it.
Block Proposal Window (block proposal stage):
BPW can be subdivided into three stages: Block Proposal, Block Voting, Aggregation.
Anyone in the Block Proposal (BP) phase can collect transactions and broadcast their own BP content. BP content will contain three parts: txs order hash, prover reward percentage, burn token amount
txs order hash: Proposer selects and sorts the most valuable batch of transactions from the L2 transaction pool (mempool), and then puts the hash value of this batch of transactions into the block it builds.
prover reward percentage: The block reward percentage shared by Sequencer to Prover
burn token amount: The number of L2 Native Token proposed by the Proposer to be destroyed, and then it sends the proposed BP to the L2 p2p network
Block Voting stage:
After Prover receives BP proposed by different Proposers in the p2p network, he will vote for the BP that can get him the most reward. However, the composition of the vote is very special:
Vote={BlockHash, Index of Proof Tree}
BlockHash is the hash of the Proposal that Prover will vote on, and Index of Proof Tree is the leaf index value of the Proof Tree that Prover will participate in building (explained later)
Aggregation aggregation: Proposer collects the votes of Provers for BP in the L2 p2p network, aggregates them and puts them into BP, and submits them to L1 (each BP generally only contains voting records related to itself).
Here, it is necessary to emphasize the prerequisites for BP to be selected and included in the Rollp ledger:
Have the highest score:
SCORE(y) = NUM_PROVERS (x)^3 * BURN_BID(z)^2
NUM_PROVERS (x) is the number of Prover votes obtained by the BP, and BURN_BID is the number of L2 Tokens proposed to be destroyed by the BP. Since the higher the BURN_BID is, the less reward the BP proposer will get in the end, so this value should be set properly.
At the same time, the BP needs to be submitted to L1 before the end of the Block Proposal Window, and the corresponding proof of validity must be uploaded to L1 before the end of the Block Acceptance Window.
Note: In the calculation of BP scores, the number of votes accounts for the largest proportion, followed by the number of burn tokens. At the same time, the B52 scheme allows multiple proposers (actually sequencers) to compete for an effective BP quota
The B52 scheme only requires the Proposer (sequencer) to specify the number of burn tokens in its own BP (similar to the method of EIP1559) without stake tokens in advance, which can make the network more permissionless (no access permission), and is also beneficial to L2 Native Token produces deflation.
In addition, BP does not contain complete transaction data, but only the hash of the transaction sequence. The reason is similar to the Ethereum PBS scheme, which aims to prevent MEV from being spied on by other Proposers.
Block Acceptance Window (block acceptance stage) detailed explanation:
After the Block Proposal Window ends, Prover needs to reveal the complete transaction data corresponding to their BP. If the BP voted by the Prover is selected (the highest score can be queried through the L1 contract), they need to construct the Sub Proof Tree corresponding to the Index of Proof Tree given during the vote.
Assuming that 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. Then the prover broadcasts the sub proof tree constructed by itself to In the L2 p2p network. After the proposer receives it, it will aggregate all sub proof trees into a block proof.
Then Propsoer submits the aggregated proof to the L1 Rollup contract, and the contract will verify the correctness of the proof and the corresponding state transition results. It should be noted here that if the Prover deliberately fails to submit the proof, not only will he not be able to obtain the block reward dividend promised by the Proposer, but he will also be slashed, because to become a Prover, he needs to pledge Token in advance. Therefore, unlike Proposer (Sequencer), Prover is not Permissionless.
State Advances (state advancement stage) detailed explanation:
After the Block Acceptance Window ends, the Rollup contract will select a block with the highest score to be included in the Rollup ledger, and send the block reward Reward to the Proposer and Prover respectively according to the proportion declared by the Proposer (Sequencer) in advance.
**The above is Aztec's B52 solution. However, the author of this article believes that there are some potential problems with the B52 proposal: **
Question 1: If 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 rewards, so as to ensure that the Proposer has no motivation to deliberately not submit a complete proof. At the same time, Prover can also submit proof directly to the contract.
According to the description of the proposal, it is acceptable to accept a block without a validity proof of complete transactions. This is actually unreasonable: because: zkrollup only declares that the new state corresponding to this block is valid when the validity proof is given.
If the aggregate 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), we It is also impossible to confirm that the new state corresponding to this block is valid.
Therefore, at this time, the reasonable way should be to enter the Block Acceptance Window that waits infinitely until all transaction proofs are submitted.
Question 2: **If the block with the highest score is an illegal block (this is not explained in the B52 scheme). **BP only contains the hash of the transaction sequence, so a malicious proposer can actually deliberately construct problematic transactions, such as double-spend transactions. So at this time, it is actually necessary to add a function in the L1 contract that anyone can submit an illegal proof. This illegal proof is used to prove that the BP with the highest score is an illegal block.
And this kind of report should be rewarded, we can reward the burn token sent by the proposer to the contract to the reporter node who submitted the illegal proof.
**Interesting thinking:**About uncle blocks and redundant Prover Work: B52 scheme will actually use other BPs (who have submitted complete proofs) that appear in this round as uncles after the BP with the highest score in each round appears. block, assign a certain uncle block reward.
This actually follows the approach of the ETH POW consensus mechanism. In order to avoid excessive concentration of computing power, it is necessary to allocate a part of block rewards to unaccepted block proposers (miners) to protect the interests of small mining pools/individual miners and avoid The computing power is monopolized by large mining pools. Therefore, it is also a very smart choice to adopt the uncle block mechanism that Ethereum performs well.
The significance of the B52 proposal in terms of Rollup decentralization: Proposer is decentralized and does not require pledge, and the entry threshold is low; but because you need to build the most valuable blocks yourself, and you need to collect votes from other Proposers , and aggregate all Proofs. In fact, the Proposer’s hardware threshold is not as low as stated in the proposal (for example, the bandwidth may not be very low).
Therefore, it will eventually become a relatively centralized network, similar to Mev-Boost Builder, because the proposer who can finally generate blocks is often the Block Builder that is best at capturing MEV.
At the same time, the Prover in the B52 scheme needs to pledge assets, but because only the sub tree proof needs to be generated, compared with those schemes that need to completely generate the entire block proof, **Prover’s degree of decentralization will be better (hardware requirements can be lowered). **
Active Liveness: The overall network Liveness is good, because L2 has its own p2p network to broadcast transactions and votes/BP, and Sequencer and Prover are relatively decentralized. But we need to solve the two problems we mentioned above. One is that the block with the highest score must be a legal block, and the second is that it needs 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 (downtime) due to the lack of a certain part of the tx proof.
**Censorship Resistance: **If we can guarantee that anyone can publish block proposal BP, and ensure that not only Proposer can submit block proof, then the network will have good resistance to censorship.
**Finality: **The finality of L2 is closely related to the liveness of the network, 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 a BP with the highest score (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, and the block where the transaction you submitted can be accepted.
Inherit L1 security: As an L2 that updates its status by submitting validity proof, it can inherit the security of L1.
Proposal Fernet: Introduce VDF to select legal Proposer
Fernet scheme introduction: Through VDF, in each round of block generation cycle, an estimated score is set for different nodes in the Committee (that is, the set of Sequencer nodes), and the block proposed by the Sequencer with the highest final score will become valid piece.
**First, how to join the Committee? In fact, you need to pledge 16 ETH in L1, **and wait for 4 L1 blocks after the pledge operation is completed, and then join the Sequencer Committee. As for exiting the Sequencer Committee, you need to call the Unstake function in the L1 contract, and then you can get back the remaining amount of your pledge after another 3 days.
Then, what is a VDF? Verifiable Delay Function is a verifiable delay function. This mathematical function satisfies strict serial execution characteristics. It will perform some calculation steps and consume at least a predictable period of time. We record the value calculated by VDF as Score, which satisfies a uniform normal distribution. Therefore, after Sequencer calculates VDF Score, it can judge the probability of being selected as a legal proposer. **
Sequencer's VDF is calculated as follows:
Score = VDF( privatekey , public inputs )
public inputs = { current block number , randao }
randao is a random number used to prevent Sequencer from calculating its own VDF Score at all future block heights in advance
The whole process of Fernet is mainly divided into 3 stages:
**Proposal Phase:**PROPOSAL_PHASE_L1_BLOCKS = 2 Ethereum blocks (this phase will last for 2 L1 blocks)
At the beginning of this stage, each Sequencer will use VDF to calculate its corresponding VDF Score at the current block height. If Sequencer thinks that his VDF Score is likely to win the right to produce a block this time (assuming the Score satisfies a normal distribution), then he will submit a Rollup contract from Proposal to L1. Proposal contains: the hash of the transaction sequence, pointing to which previous L2 block.
unproven block: Only the block contents of the Proposal to the Rollup contract are submitted. Next, **Sequencer needs to send the block contents corresponding to the unproven block and the proof of VDF to the L2 p2p network. **
ProvingPhase: PROVING_PHASE_L1_BLOCKS= 50 L1 blocks (this phase will maintain 50 L1 blocks, about 10 min)
Prover receives all corresponding transactions in Block Contents from the L2 p2p network, and will build Proof for blocks with higher VDF Score. The construction of Proof also adopts the method of multiple Provers collaborating in parallel (similar to the B52 scheme).
Therefore, Sequencer needs to aggregate Proofs corresponding to multiple different transactions into a Block Proof (including VDF Proof) at the end, and submit it to the Rollup contract of L1. Anyone can submit Block Contents that have submitted Block Proof to the Rollup contract.
Finalization: It is necessary to submit an L1 transaction to Finalize the block. A block that can be finalized needs to be satisfied: Block Contents and Block Proof are submitted, and the previous block pointed to must be Finalized. On the basis of meeting the above conditions, you must also have the highest Score.
Pipeline block production mechanism: It should be noted that Fernet adopts a pipeline block production mechanism. When the Proposal phase of the Nth block ends, the Proposal of the N+1th block begins (Aptos and other public chains also have similar practices) . But for the N+1th block, it needs to wait for the Nth block to be Finalized before it can submit the L1 Final Block transaction and pass the verification to become a Final Block.
Potential attack dimensions: If the Sequencer with the highest VDF Score deliberately does not broadcast Block Contents in L2 p2p, it may lead to block reorganization.
Calculation of the number of L2 blocks in reorg: 1+PROVING_PHASE_L1_BLOCKS / PROPOSAL_PHASE_L1_BLOCKS =1+50/2=26 blocks
Solution: Increase the uncle block mechanism to avoid having only one complete candidate block for each L2slot (block generation time slot).
The significance of Fernet in terms of decentralization: Sequencer joins the Sequencer Committee by pledging 16 ETH, and the entry threshold is not high (but not low). Prover does not require any pledge, but there is no penalty if Prover does not generate Proof. This is basically the opposite of the B52 scheme.
**Active Liveness: **The Liveness of the overall network can be guaranteed, because the VDF+uncle block mechanism can ensure that there is more than one block producer in each round.
**MEV: **MEV considerations are the most special. The plan plans to introduce PBS, so that after calculating a high VDF Score as a Sequencer, you can directly find a Block Builder to construct a more valuable block.
**Censorship Resistance: **Fernet will also adopt the same PBS mechanism as Ethereum, so in essence, Fernet’s anti-censorship problem is equivalent to that of Ethereum’s PBS.