Tweaking Fernet

After settling on Fernet as sequencing algorithm, we attempted to simplify it as much as possible to reduce engineering efforts and get to an early initial working version that we could start playing with. This post covers some of the tradeoffs we are evaluating, along with some open problems we are working on and their mitigations!


What we propose to change from the base version linked above.

Removing build-ahead

To remove the risk of L2-reorgs, we propose removing build-ahead for an initial release. This means that the phases for block N+1 would begin once block N has been finalized, not once it has been revealed. This removes reorgs caused by proof withholding attacks.

Note that this turns Fernet into pretty much Sequencer Schmequencer. Should we switch to that name?

Skipping rollup proof verification

Instead of implementing proof batching, we still submit a proof per block, but do not verify it in order to save gas. This guarantees L2 full nodes have access to proofs, so they can verify that the block revealed by the sequencer is valid. Then, to get finalization on L1, every N blocks we aggregate these proofs into a single batch proof and verify it. Note that whether we move forward with this option depends on more analysis on costs. Thanks to the Scroll team for suggesting this one!

Prover commitment

Assuming an out-of-protocol proving scheme, which is the simplest option to begin with, we propose a prover commitment for coordination between sequencer and prover. Once the sequencer has chosen a proving entity (whether it’s an individual, a marketplace, or a network), this entity locks down a certain amount of value as a commitment to generating the proof. This should act as a signal to the network that the proposal from the sequencer is legit, and add more economic security to the finalization of the block.

Sequencer bid

We propose sequencers to be allowed to bid during the proposal phase, as a means to providing a boost to their VRF score. This bid is burnt if they are selected as leader for the slot, whether the block is finalized or not. We expect this bid amount to reflect the amount of MEV extracted from public txs in the block, so burning it ensures the value is not entirely captured by builders, but rather shared across the network (insert ultra-sound meme here). Note that there’s more economic analysis needed before deciding on this option.

Backup phase

To improve liveness, we propose adding a “backup phase” at the end of cycle if no block has been successfully proven, or if no prover commits to proving the block. During this phase, we go full based rollup, where anyone can submit an L2 block to L1. This should discourage sequencers who control two slots in a row from withholding the first block to profit from better MEV opportunities (we assume that more time and more txs equals to more value to extract), since a competitor would be able to capture the MEV from the first batch during this phase.

Merging phases

Still to be defined, but it’d be good to minimize the number of L1 txs we need to send per L2 block. We could possibly merge some of the phases as they are currently outlined, at least in the happy path.

Open problems

What we are still figuring out.

Proof withholding as an option purchase

Since individual tx proofs (think “tx signatures”) are not posted to L1 to save gas, a sequencer may post a tx for which its proof is not available in the p2p network. This can be caused by a tx coming from a private tx pool, or done on purpose by the sequencer as a means to “purchase an option”.

Assuming a vertically-integrated sequencer and prover, the sequencer can include a tx with a massive trade, and it retains full control during the entire slot (~5-10 minutes) on whether to actually “commit” that trade (by proving the block) or “roll it back” (by never disclosing the tx proof). This gives the sequencer an “option” over the asset being traded.

The cost of purchasing the option is equal to the burned sequencer bid, plus the prover commitment, plus potentially a fixed slashed stake. While there is a cost to not exercising it (the missed rewards, though the sequencer can still submit the block without that trade during the backup phase to reap those), the earnings could well outweigh that cost.

Note that this problem exists in Ethereum as well, since a proposer can choose to reveal their block or not, but in Ethereum’s case that window lasts 4 seconds. Also note that competition caused by the sequencer bid would not fix this problem either, since after the “option” has been purchased, there is no incentive towards committing the block.

A solution here is adding an L2 consensus or a data availability layer that verifies or at least guarantees the availability of the individual tx proofs, but this goes strongly against the goal of simplifying the protocol.

L1 congestion slashing honest sequencers

We know we want to punish a sequencer if their block doesn’t get finalized by the end of their cycle, in order to promote liveness. This can be either through a fixed slashing amount, or by virtue of them losing their bid amount. However, an honest sequencer can fail to submit the block contents or proof to L1 due to network congestion, and get penalized anyway. We can mitigate this with longer windows, but this increases block times in the scenarios where sequencers withhold their block.

Edit 1: Updated to reflect @cooper-aztecLabs’s comments below


No, we should leave it as Fernet. Adding build ahead is a (likely) potential future improvement that we have decided should not be in V1, not that it should never be implemented.

What do you mean by this, sorry? When do we finalize it? I currently think we should still finalize per block until we have done a more thorough economic analysis on the potential impact of tx prices. I do not believe this is a decision that has reached internal consensus yet – at least not as far as I’m aware.

My understanding is that you would have a “backup phase” after the prover commitment phase, in addition to the end of the cycle. That way you can guarantee in all cases a block will get produced during a given slot.

Doesn’t it have X amount of additional economic gurarantees? eg. $5,000 extra that is saying this block is more likely to be finalized, than if we do not do a bond?

I think we should wait until we do broader economic analysis to worry about this one. Again, I do not believe this is a decision that has reached internal consensus yet.

Isn’t this related to the prover commitment deposit, not the sequencer’s? While I acknowledge you’re referring to it in the context of vertical integration, it should be referred to separately. Additionally I’d suggest we refrain from using bond as public nomenclature, as it’s not a 1:1 analog with the historical/tradfi definitions.

I believe that this is something @LasseAztec and the smart contracts team are doing some initial analysis on. Further this is something that the cadcad fernet simulation should help us have a more informed understanding of it’s potential impact. I think once we have those two bits of additional information we can spend further time evaluating L1 congestion and what can be done about it.


Hey, weren’t you on vacation? :stuck_out_tongue:

Agree in that there’s still no internal consensus, and we need better numbers on gas costs before making the call. Still, the idea here is not finalizing every single block on L1, but rather making sure the data for doing so is made available for any L2 node. So we generate the proof for each block, as we do today, and we submit that proof to L1 to be available in calldata, but do not actually verify it in order to save gas.

Good point. I’ll edit the post to reflect this!

Fair point. It does have reduced “signal” in that it doesn’t mean that another agent has signalled that the data is available. But I’ll amend here as well!

On this one I was under the impression that we had agreed, but I’m happy to revisit (same as with all the others, to be fair).

Hmm it should be both, right? I’ll think it over a bit more, and replace bond as you suggest.

Thanks for the quick comments @cooper-aztecLabs!


These tweaks exacerbate the sequencer decentralization deficiencies of Fernet. Namely, the hardware and MEV-sophistication requirements favor centralized sequencers.

Hardware requirements for sequencers must be similar to those of Ethereum validators

Out-of-protocol proving is insufficient [1]. Either an (optional) in-protocol auction or PBS would be minimally sufficient.

Sequencer bidding creates centralization: “Sophisticated sequencers” (e.g. higher MEV, cheaper provers) will be able outbid “naive sequencers”, using a lower VRF. This will cause naive sequencers to exit, or sophisticate (e.g. blindly auction off their VRF in a secondary market). PBS addresses this issue by enshrining the auction.
Separately, to avoid the burn, sequencers will collude to keep bids low (e.g. split an out-of-protocol MEV auction with the top VRF holders). This further centralizes stake.

I suggest skipping 1 L1 block (“halting period”) before the “backup phase” begins, to combat Profitable Censorship MEV [2].


I think this option can be mitigated by modelling, the network can set the prover bond to be sufficiently high to deter this, and if a slot is missed and the bond is ever slashed we can use a EIP1559 style mechanism to increase the next bond sharply to prevent this happening regularly. The bond would then decrease back to the target every block slowly.


I’m curious how you are thinking of running this auction? There are some challenges with auctions on L1 in which the Ethereum block builder can be bribed to exclude bids in the auction. In the extreme case, this means all the value is almost fully collected by the L1 proposer. This paper goes into more details if you’re interested (perhaps a bit theoretical, but it gets the main point across)

Yes usually options are valued on expectation so the valuation takes the outcomes in which the option isn’t executed into account.

1 Like

Good point, haven’t given it much thought yet. We were thinking of something pretty vanilla, but given a short proposal phase where this auction would take place, there’s a high chance the L1 block builder could censor. Thanks for flagging this and the link to the paper!


L1 proposer collusion

I am also concerned about running the VRF auction on L1, especially if L1 lacks inclusion lists.

Let the proposal phase be N L1 blocks long. If N sequential L1 validators collude they can capture all fees+MEV, by censoring other bidders.

Elongating the phase has limited value because of increased MEV opportunities later in the phase, and the all-pay nature of the auction disincentivises other bidders.

A partial solution might have the top VRF bid twice, at both the beginning and end of the phase. This would be done with gas-rebates for both bids of the winning VRF.
Additionally, the second-highest VRF bid may be worth rebating if no bid appears early in the phase.

What I think happens is that Lido offers an L2 staking service, and can guarantee their L2 blocks succeed ~66% (N=3) of the time (where they control at least 1 L1 node).

PBS is also succeptible here, and may require a dynamic “halting period” to further combat L1 censorship MEV.

I think it’s worth reconsidering economically-aligned proposals, like based rollup [1] with preconfirmations.

1 Like

The current design assumes that an out of protocol PBS solution like MEVBoost exists. Do you think that is sufficient to address your concerns or PBS needs to be enshrined?

With out of protocol PBS, builder hardware will be sophisticated, sequencer hardware should not be.

MEVBoost is insufficient, because it assumes you have a choice in trusted relay. This tweak means operators must trust the highest-bidding relay or exit.

Are these ideas compatible? If block N verification were deferred, wouldn’t it be the case that block N+1 couldn’t be proposed?

They are. A submitted proof can still be verified by any L2 node, even if it was not verified by the L1 rollup contract. So, for any L2 node, a block can still be “finalized” even if it isn’t for the L1 contract.