Alternate PBS: A PBS Proposal for Based Rollups

[CTra1n]

This article introduces Alternate PBS, a new PBS proposal for based rollups. Alternate PBS allows MEV income generated on the based rollup to be captured by the rollup itself, as opposed to being captured through priority payments to the proposer of the sequencing chain. This addresses one of the biggest challenges faced by based rollups, as identified by based rollup guru Justin Drake at Devconnect, Istanbul 2023, a view which is already being reiterated. Alternate PBS also addresses another concern related to stealing based rollup blocks. Without careful construction, proposers of the sequencing chain can observe based rollup blocks built by unaligned rollup builders, and rebuild these blocks for themselves. This allows the sequencing chain proposer to receive the value of the built blocks without the cost of building (just copying).

Motivation

Taiko is an example of a based ZK-rollup L2 blockchain. Taiko’s L2 blocks are proposed and sequenced on Ethereum L1, with ZK-proven state transitions later posted to the L1. Based rollups, where L2 transactions are sequenced by an L1, naturally inherit many of the properties of Proposer-Builder Separation (PBS). The L2 builders compete for inclusion on the L1, which effectively acts as the block proposer/sequencer for the L2. Inclusion of L2 blocks in the L1 is controlled by the L1 proposers/block builders, who implicitly run an auction among L2 builders, with the winning bid guaranteeing inclusion in the L1. This provides strong guarantees of censorship resistance for the L2 blockchain, while allowing for a permissionless set of L2 block builders, and potentially many L2 block proposals per L1 block.

However, the competition for inclusion in the L1 block results in almost all L2 block-building revenue, including MEV, being paid to the L1 to guarantee orderly inclusion vs. other L2 builders. By allowing anyone to submit blocks to the L1 mempool, this also allows L1 builders and searchers to “steal” L2 blocks, by observing L2 block contents, and rebuilding them for themselves.

In this document, we propose Alternate PBS as an amendment to this design currently used in Taiko. Alternate PBS has the following properties:

1. L2 retains L2 block revenue.
2. L2 block stealing is mitigated.
3. Permissionless L2 block production.
4. L2 inherits L1 censorship resistance.
5. Multiple L2 block proposals possible per L1 block.

Protocol Description

In addition to the permissionless roles of builders that currently exist in based rollups like Taiko (Taiko also requires ZK provers, although we generalize here to focus on based-rollups as a whole), we introduce a set of trusted proposers. Access to the set of trusted proposers can be controlled via a Proof-of-Governance protocol (alternatives such as PoS are also possible). These trusted proposers do not affect the safety or liveness of the protocol (provided certain precautions, as outlined later in this proposal, are taken).

For every L1 block, there is a designated L2 proposer from the trusted set with an exclusive right to propose an L2 block to the L1. This is enforced by an L1 contract deployed on behalf of the L2, which has knowledge of the proposer set.

Note: This is an amendment to the current Taiko L1 smart contract. The contract on the L1 only needs to be aware of the set of trusted proposers. Another contract can enforce trusted proposer behaviour.

Trusted proposers are free to run a local instantiation of MEV-Boost, or build blocks themselves. If proposers are trusted for example, proposers can run the auction themselves. Otherwise delegated MEV-Boost using a trusted intermediary could be preferred.

In the case of based ZK-rollups, proposers must also provide a commitment from a prover, possibly the proposer themselves, to provide a proof for their proposed blocks to be valid. This commitment is typically a financial collateral that is returned when the relevant proof is provided. For increased decentralization of the proposer set, this could be outsourced through a prover market, as proposed already for Taiko.

In each L1 block, it is possible to override the exclusive right of the trusted proposer set by triggering an overridePermissions() function. This allows any player calling overridePermissions() to propose an L2 block to the sequencing based L2 sequencing contract instead of the trusted proposer for that L1 block. Calling overridePermissions() requires the burning of a contract-specified _backdoorFee() amount, which is a function of the number of times overridePermissions() has been called in the last n blocks (n and _backdoorFee() will be the subject of further analysis). _backdoorFee() is paid to the L2 treasury.

Each L2 MEV-Boost auction must settle sufficiently long before the proceeding L1 block is proposed to allow for propagation to the builder network, and inclusion in that L1 block. This notion of sufficiently long is at the discretion of the trusted proposer. The longer the auction is run typically corresponds to greater bids and auction revenue. This should be taken in consideration with the relevant risks of not propogating the L2 block(s) to the L1 mempool in a timely manner for L1-inclusion.

)

Our proposed design only affects the rules of how L2 blocks can be sequenced in the L1. Although we would expect the trusted proposers to only sign-off on valid L2 blocks, this is not critical to the protocol. State verification happens after L2 blocks have been sequenced on the L1, as in typical based rollups.

However, depending on the trust placed in these proposers, a sequenced L2 block signed-off by the trusted set of proposers can be seen as verification that some/all of the transactions in a block will be executed. On the above scale, this moves our design slightly away from a pure based rollup. In a typical based rollup, sequencing a block on the L1 does not require any L2-related entities to sign-off on the block.

Our proposed design only affects the rules of how L2 blocks can be sequenced in the L1. Although we would expect the trusted proposers to only sign-off on valid L2 blocks, this is not critical to the protocol. State verification happens after L2 blocks have been sequenced on the L1, as in typical based rollups.

However, depending on the trust placed in these proposers, a sequenced L2 block signed-off by the trusted set of proposers can be seen as verification that some/all of the transactions in a block will be executed. On the above scale, this moves our design slightly away from a pure based rollup. In a typical based rollup, sequencing a block on the L1 does not require any L2-related entities to sign-off on the block.

Permissionless PBS in the presence of a set of trusted players

Using a trusted set of players to enforce certain behaviours in a protocol should raise some concerns when trying to create a permissionless protocol. To ensure permissionless PBS for an L2, we need to ensure anyone can produce a block for the L2 using Alternate PBS. That is the function of the overridePermissions() function. Any L2 builder willing to pay _backdoorFee() in the L1 smart contract managing L2 block proposal can call overridePermissions().

An objective measure of the permissionlessness of _backdoorFee() may be unrealistic. Thinking about its value on a scale, and what values it should have under various network conditions, will help to set the function appropriately.

An objective measure of the permissionlessness of _backdoorFee() may be unrealistic. Thinking about its value on a scale, and what values it should have under various network conditions, will help to set the function appropriately.

With a parameter such as _backdoorFee(), we have a lot of freedom to strike a desired balance between full permissionlessness (_backdoorFee() = 0) and permissionless in name only (setting _backdoorFee() > feasible value of any L2 block). Too high, and the trusted proposers can extract rents as builders become forced to use the trusted channel, while too low, and the permissionless channel will dominate, and most of the L2 revenue will be paid to the L1 (which this proposal is intended to address).

We envision a reactive _backdoorFee(), which drops quickly when L2 blocks have not been proposed, but not so quickly so as to incentivize concurrent-block L1 strategies from L1 builders (e.g. censor L2 blocks in the current L1 block to drop _backdoorFee() to 0 in the next L1 block, then extracting L2 value “for free” in that block).

Additionally, the level of trust in the trusted set will dictate the mechanisms we use to ensure they behave correctly. For example, the constraints on a proof-of-governance set will be significantly less than those required for a permissionless proof-of-stake set.

Handling multiple L2 blocks per L1 block

Proposers, whether those elected from the trusted set, or those paying _backdoorFee(), can propose arbitrarily many L2 blocks, within reason, per L1 block. Each L2 block must contain a prover commitment, meaning each block should be worth at least the cost of proving to the proposer (who is tasked with finding a prover) and the additional L1 cost associated with a larger L1 transaction. With respect to the proposer-run MEV-Boost auction, each additional L2 block therefore discounts the bid by an amount specified by the proposer.

To allow for multiple L2 blocks to be constructed per L1 block in an L2-specific MEV-Boost module, we introduce a proof_cost() function. proof_cost() is a monotonically increasing function which takes as input a number of L2 blocks required to be proven by an L2-defined deadline (as is defined currently for Taiko for example), and outputs a price for which the designated proposer/prover will provide those proofs.

Bids to MEV-Boost must be accompanied by a commitment to pay proof_cost() for the number of L2 blocks attached to each bid. This allows for bids to be considered independently of the number of L2 blocks to be proposed, within some reasonable limit. For example, the L2 blocks’ contents must fit into the L1 block.

Properties of Alternate PBS

Now let’s revisit the properties outlined at the beginning of the document, and how Alternate PBS inherits them.

1. L2 retains L2 block revenue: By allowing a trusted set of L2-native entities to run an auction for block building, the L2 is able to retain block revenue within the L2 ecosystem. Either:
   1. These proposers controlled by governance and trusted by the protocol to run an auction and report the winning bids correctly, in which case the revenue of the auction can be routed to the L2 treasury.
   2. These proposers are not controlled by governance (~decentralized) and not trusted. In this case, L2 proposers capture proceeds for themselves, importantly still keeping the proceeds in the L2 ecosystem. If this were expected, _backdoorFee() can no longer depend on the reported proceeds from the trusted auction.
2. L2 block stealing is mitigated: When blocks are proposed through the trusted proposer set, only one block proposer can proposed per block, preventing block stealing. However, when overridePermissions() is called, block stealing is back on the menu for L1 builders and searchers.
3. Permissionless L2 block production: By allowing anyone to override the trusted set by paying _backdoorFee() (and some payment to the L1 proposer to insure inclusion), we are able to keep the entire protocol permissionless.
4. L2 inherits L1 censorship resistance: As in 3, the trusted set can be overrode when censorship is suspected. This can even be enforced by removing _backdoorFee() when multiple L1 blocks are added without containing any L2 blocks.
5. Multiple L2 block proposals possible per L1 block: Addressed already in the Handling multiple L2 blocks per L1 block section above).

Conclusion

We propose a design framework for a permissionless PBS protocol for L2 blockchains. This framework facilitates permissionless block building and ensures network liveness, while also retaining revenue generated from L2 block production within the L2 itself. This is done by creating two complimentary channels for block production, one trusted and one permissionless. The intention is that the trusted channel will be responsible for producing most of the blocks, while the permissionless channel ensures that L2 blocks can always be force-included in the L1. In the presence of such a permissionless channel for block building, the trusted channel will be forced to perform as expected, or risk all block builders only using the permissionless channel, and L2 block revenue being paid entirely to L1 proposers and builders, as it is currently done.

For any questions related to R&D for PBS on L2s, please reach out to the team:

flashbots

• product management: @Tomasz
• design review: @dmarz , @Quintus .

Nethermind:

• engineering: Jorge Mederos, Paweł Nowosielski, Jinsuk Park.
• mechanism design: @CTra1n .
• architecture review: @swp0x0 .
• project management: Cameron Loo.

[jsky]

I have a few questions on the design

My understanding is that this design allows for multiple L2 blocks in a given L1 block, but doesn’t provide pre confirmations on those blocks, is this correct?

Are there more details on how proposing a block via the backdoorFee is done? My assumption is that the rollup’s fork choice is such that a trusted proposer block is used unless a backdoorFee greater than the floor is present in the L1 block for a given height. In the event there are multiple backdoorFees the highest paying one is chosen. I can think of a few potential issues.

First, a trusted proposer can be griefed at the cost of the backdoorFee, losing their revenue opportunity for their block while potentially still paying L1 fees. This can potentially be mitigated by paying the backdoorFee to the skipped proposer but this likely has other implications.

Second, payment of a backdoorFee to include a block essentially becomes a MEV auction above a certain price tier, this may be desirable when considering the L2s revenue collection, though at the cost of previously stated griefing concerns. This could also lead to a large number of non canonical L2 blocks being posted to L1.

Third, this all seems to be a layer on top of the existing L1 PBS. This leaves it vulnerable to what C-Node (https://twitter.com/colludingnode) calls Profitable Censorship MEV (link to talk).

[CTra1n]

@jsky

My understanding is that this design allows for multiple L2 blocks in a given L1 block, but doesn’t provide pre confirmations on those blocks, is this correct?

You’re right. The multiple blocks decision was more to keep it inline with the current Taiko design, as opposed to a hard and fast rule. The notion of preconfirmations is still possible (I briefly mentioned this to @JustinDrake), although this would require an even more complex backdoorFee() function. One possibility would be to drop backdoorFee() to 0 for designated preconfers. This would have other implications, but all preconf hope is not lost!

@jsky

Are there more details on how proposing a block via the backdoorFee is done? My assumption is that the rollup’s fork choice is such that a trusted proposer block is used unless a backdoorFee greater than the floor is present in the L1 block for a given height. In the event there are multiple backdoorFees the highest paying one is chosen.

So there is only one value for backdoorFee() in any given block. If multiple builders want to pay it, we expect the highest bribe to get ordered first in the L1 block; just as it is done in Taiko today without the fee.

@jsky

payment of a backdoorFee to include a block essentially becomes a MEV auction above a certain price tier

This is exactly right.

@CTra1n

We envision a reactive _backdoorFee(), which drops quickly when L2 blocks have not been proposed, but not so quickly so as to incentivize concurrent-block L1 strategies from L1 builders (e.g. censor L2 blocks in the current L1 block to drop _backdoorFee() to 0 in the next L1 block, then extracting L2 value “for free” in that block).

The third issue is something that we are also concerned about. Ideally there is “big trust” in the trusted set (high unreactive backdoorFee()) to mitigate “Profitable Censorship MEV”. There are other censorship vectors, but a hope would be the cost to censor corresponds almost directly with reduced auction bids.

[jsky]

@CTra1n

The third issue is something that we are also concerned about. Ideally there is “big trust” in the trusted set (high unreactive backdoorFee()) to mitigate “Profitable Censorship MEV”. There are other censorship vectors, but a hope would be the cost to censor corresponds almost directly with reduced auction bids.

If I’m understanding the design correctly, my concern is that the backdoorFee is a way to avoid the set of L2 proposers from censoring. Ideally this results in the L2 proposer for a given L1 block always proposing a block (or set of blocks). However, it doesn’t resolve the ability and economic incentive for a L1 proposer to censor the L2 block, whether it is proposed by the trusted proposer or someone paying the backdoorFee.

Another concern is if a backdoorFee payment is separate from its associated L2 block then a L1 proposer can censor one and not the other. But if they’re combined into a single tx you end up with a potentially relevant overhead in data submitted to the mempool, as well as the block itself in the event that a L1 proposer includes multiple backdoorFee txs for whatever reason. This separation of bid from block contents is essentially what MEV Boost relies solve.

Regardless, this seems like an interesting design, though I’m of the (biased) opinion that if we’re introducing intermediary layers to tx submission for L2s, which seems inevitable given the need to buy fractions of blobs post 4844, we should also get fast confirmations.

At a high level Astria’s design looks quite similar to this in that the shared sequencer proposer set will initially be Proof of Governance and will run a PBS auction for block creation. The core tradeoff seems to be a on the shared sequencer for censorship resistance in exchange for fast confirmations. I’m not convinced you couldn’t have both, though the mechanism design gets rather complicated even without getting into siloed vs shared rollup sequencers.

[CTra1n]

@jsky

However, it doesn’t resolve the ability and economic incentive for a L1 proposer to censor the L2 block, whether it is proposed by the trusted proposer or someone paying the backdoorFee.

There shouldn’t be much of an incentive for an L1 proposer to censor a block from the trusted L2 set if the value of the block is less than backdoorFee. In this case, as long as the L2 block pays a sufficient fee, the block should be included. Otherwise, the value of the L2 block is greater than the backdoorFee, in which case, censoring/stealing comes into play. Are you thinking of something more malicious from the L1 proposer? You mention economic incentive to censor, so maybe an example might help?

@jsky

if we’re introducing intermediary layers to tx submission for L2s, which seems inevitable given the need to buy fractions of blobs post 4844, we should also get fast confirmations.

Makes sense. As I mentioned in the first reply, I think backdoorFee() can be more expressive and allow for something like the preconfirmations mentioned here. Can the slots/blocks where preconfirmations are allowed also allow for MEV retention? This is a tricky question.

Things could get wacky and the right to be a preconfirmer could be auctioned in advance: “If you are the L1 proposer for block N and you pay preconfirm_backdoorFee(N,…), you can be designated as a preconfirmer for that block”.

@jsky

a high level Astria’s design looks quite similar to this in that the shared sequencer proposer set will initially be Proof of Governance and will run a PBS auction for block creation.

That’s always an option. I guess the parallel with our proposal would be “should the rollups themselves run their own value-capturing auction before entering the shared sequencer auction?”

[jsky]

@CTra1n

Are you thinking of something more malicious from the L1 proposer? You mention economic incentive to censor, so maybe an example might help?

I don’t think there’s an incentive for L1 proposers to censor.

@CTra1n

I guess the parallel with our proposal would be “should the rollups themselves run their own value-capturing auction before entering the shared sequencer auction?”

Using a shared sequencer vs a dedicated sequencer and the implications of revenue sharing and such is tangential.

The useful comparison is a general Astria style design with a distinct PoG/PoS network for the L2 which runs a PBS auction for block production. The L2 sequencer set can give fast soft commitments, but firm commitments from the L1 can be delayed or censored by L1 proposers. The L2 has full control to capture revenue, up to and including MEV Burn with an ePBS design. However, the design doesn’t provide for a fallback mechanism to submit blocks directly to the L1, and so has weaker censorship resistance properties.

AIUI the alternative PBS design proposed also assumes the creation of a L2 specific set of block proposers which run in parallel to the L1 chain. The proposers do not give fast soft commitments in the current design, but this is potentially doable with some form of based pre confirmations. Notably, L2 block production isn’t dependent on the L2 block proposers and falls back to permissionless block production through the L1 via the backdoorFee. Thus it inherits the full censorship resistance of the L1.

I believe these designs converge if:

• An “Astria style” separate sequencing layer is able to implement a way for block production to fallback to L1
• A based alternative PBS design is able to provide fast soft confirmations

[gets]

This design is quite a departure fron pure based rollups, considering in practice most blocks shouldn’t be sequenced by the L1. Is it not better characterized as an escape hatch design?

Also, why can’t the backdoor fee be paid to the rollup?

[CTra1n]

@gets

This design is quite a departure fron pure based rollups, considering in practice most blocks shouldn’t be sequenced by the L1. Is it not better characterized as an escape hatch design?

What makes this “escape hatch” different is the guarantees of execution one receives when an L2 block is included. Typically escape hatches only guarantee forced exit from the L2. They aren’t very expressive. Paying backdoorFee provides execution guarantees for almost any valid transaction.

Your concern points to one of the questions to which I don’t think there is a universal right answer. How low/high does backdoorFee need to be to be considered based/sequenced by a centralized committee? I think it’s best described as a scale, as was pointed out in this section.

If backdoorFee is 0, it is still based right? What about if backdoorFee is some maintenance/operational cost for the rollup validators?

[evan-forbes]

one alternative mechanism that I’ve heard other discuss in the past is similar to this one.

where we set a base fee for creating a block that presumably goes to the rollup, and then then anything over the basefee goes to the proposer of the L1 (minus the base fee there ofc).

that can be defined as a based rollup, with a fork choice rule that requires a basefee (not commenting how that basefee is determined) to create a block

the round robin fork choice rule described here imo is an implementation detail that can be tacked onto the basefee rule later or using other arbitrary schemes.

For example, there is always some base fee that goes to the rollup, and some proposers get refunded for that base fee because the rollup token holders like them or because it was their turn. This accomplishes the a similar thing, except now how refunds are dolled out is completely arbitrary. Also if we remove the requirement of round robin refunds, then we can maintain the benefits of a based rollup, mainly that the proposer set is the same as the L1.