# Based Preconfs FAQ
[Rohan Shrothrium](https://twitter.com/0xtrojan_) , [Samuel Laferriere](https://twitter.com/samlafer)

Huge thank you to [Justin Drake](https://twitter.com/drakefjustin?lang=en) for his thorough review and feedback.

## Rollups

In order to make this FAQ self-contained, we will quickly explain a view of what rollups are in order to ground the future questions about based and preconf rollups in a common understanding.

The idea for rollups is to bank on ethereum for DA and settlement, and hence only have to deal with sequencing and execution themselves. Arbitrum has a great [visualization](https://docs.arbitrum.io/inside-arbitrum-nitro/#sequencing-followed-by-deterministic-execution) of an L2 transaction lifecycle
which clearly outlines these two separate roles:
- **sequencer** accepts transactions, orders them, and posts them to the L1 chain
- **validator/executer/prover** nodes take the sequenced batches of transactions and run them through the rollup's state transition function, compute the post batch state root, and post the state root commitment to the L1 bridge contract

Both of these roles are currently centralized on most rollups, but there has been a lot of work on decentralizing them, and based rollups are one way to decentralize the sequencing role.

## Preconfirmations

### What are preconfirmations?

One great UX benefit of the current centralized sequencers on L2s is that they can give users "preconformations", which are tx receipts returned as a promise from the sequencer that the user's transaction will land on L1 in an order which will result in the tx receipt being valid (see the "soft guarantee" sequencer feed in the [above image](#Rollups)). These preconfirmations however are "soft" in the sense that they are not enforced by anything other than trust.

The goal of based preconfirmations is to provide this same benefit while having decentralized sequencing done by the L1.

### What are the different types of preconfs?

Justin Drake mentions that ethereum provides 3 "modules"

From a user's perspective, those can be translated into different transaction guarantees:
- inclusion (DA)
- ordering (sequencing)
- execution (settlement)

Preconfs can be given for any ordered subset of these. For eg, [inclusion lists](https://eips.ethereum.org/EIPS/eip-7547) represent an inclusion guarantee. However, based preconfirmations, in most cases, represent execution guarantee. This can either be a post-tx state root, or some subset of it, such as a guaranteed trade output amount.

## Based Rollups

### What are based rollups?

Based rollups were first defined in https://ethresear.ch/t/based-rollups-superpowers-from-l1-sequencing/15016. Quoting the definition from that writeup:

> A rollup is said to be based, or L1-sequenced, when its sequencing is driven by the base L1. More concretely, a based rollup is one where the next L1 proposer may, in collaboration with L1 searchers and builders, permissionlessly include the next rollup block as part of the next L1 block.

### Why are based rollups needed/interesting?

Vitalik has recently said that he's about [3x less confident in the "simplify L1 even at the expense of more complicated L2s" concept than he was 5 years ago](https://x.com/VitalikButerin/status/1760449291951423576?s=20), and that [it can actually be worth adding some pretty sophisticated L1 features to reduce the code burden of L2s and allow them to be reasonably simple](https://x.com/VitalikButerin/status/1760449900397912505?s=20).

Based rollups, in this regard, have two benefits:
- they reuse ethereum's PBS infrastructure, which removes the need for rollup teams to run their own sequencing infrastructure, which can and [have](https://blockworks.co/news/arbitrum-suffers-partial-outage) gone down.
- they decentralize the currently centralized sequencer landscape, with benefits to liveness, censorship resistance
- they do so in a credibly neutral way, which is required for shared sequencing
- they allow synchronous composability (derived from shared sequencing)

### How exactly do they work?

There are many ways to achieve a based rollup, but in order to be more concrete, we'll give an example here. Vitalik had proposed in his original rollup article the "[total anarchy](https://vitalik.eth.limo/general/2021/01/05/rollup.html#who-can-submit-a-batch)" version for batch submission, which allows literally anyone to submit a batch to the L1. One caveat is that his article did not separate transaction submission (sequencer role) from state root submission (validator/prover role) as we outlined at the beginning of this FAQ, as can be seen from this quote

> Generally, everyone agrees that in order to be able to submit a batch, a user must put down a large deposit; if that user ever submits a fraudulent batch (eg. with an invalid state root), that deposit would be part burned and part given as a reward to the fraud prover.

This fraudulent state root submission is purely a concern of the validator/prover role, and making this role permissionless is something that is still being worked on, see for eg Arbitrum's [BOLD](https://medium.com/offchainlabs/bold-permissionless-validation-for-arbitrum-chains-9934eb5328cc) proposal.

When separating these two concerns, making the total anarchy version work is much easier, as fake transactions in a batch can simply be discarded by the validators/proposers when calculating the next state root. This approach is precisely what Taiko [proposed](#Are-there-any-based-rollups-live).

### Why would rollups be interested in running a based rollup, forgoing MEV profits?

Rollup teams are making very good [profits](https://dune.com/sealaunch/rollups-profits), why would they be willing to give up some of them? First, we need to understand how L2 fees are split between different entities. Taiko has a great diagram expanding on this

In other words, after paying Ethereum for transaction batch fees (whether calldata or eventually blob space) and "settlement" (state root commitment/proof verification) fees, as well as paying provers and proposers for their work, all of the leftover revenue from user transactions are are taken as revenue by the rollup governing entity (whether a company like coinbase or a DAO).

The proposer has extra revenue possibilities due to MEV opportunities. The entity able to sequence is able to capture a lot of "hidden" revenue, the major one being CEX-DEX arbitrages. Doing this effectively can be very profitable, but also requires high capital and operational costs.

Thus the two main sources of revenue for centralized rollups is L2 tx fees and MEV opportunities. The largest portion of revenue comes from L2 tx fees, while the MEV opportunities also comes with burdens of having to run infra and paying for devops to maintain six 9's on the sequencer. Based rollups' value proposition can thus be seen as only retaining L2 tx fees source of revenue, and outsourcing the proposer role to the L1 builders.

### Are there any based rollups live?

Not as of March 31, 2024. Taiko was the first rollup to announce they would eventually switch to a based rollup [architecture](https://taiko.mirror.xyz/y_47kIOL5kavvBmG0zVujD2TRztMZt-xgM5d4oqp4_Y), but this has not happened yet.

## Based Preconfirmations

Based preconfirmations have the same goal as normal preconfirmations, but are a lot more intricate due to the decentralized rotating nature of decentralized/shared/based sequencing.

### How can preconfirmations be given in the context of based rollups?

Based rollups, by using PBS to sequence rollups, lose the ability to give users preconfirmations. Justin Drake proposed in https://ethresear.ch/t/based-preconfirmations/17353 an architecture for based rollups to also be able to offer preconfs, in a way that is actually enforceable via slashing.

### Is the design in the above ethresearch post still valid?

Yes, but Justin Drake's most recent design is available [here](https://notes.ethereum.org/WLuNFaliQiqw7Zhd-7AnmQ?view), and is an improvement on the original design in that it does not require inclusion lists nor a hard fork. See Justin's presentation of this architecture in the first 15 minutes of the [Ethereum Sequencing and Preconfirmations Call #1](https://www.youtube.com/watch?v=2IK136vz-PM).

### What is the ELI5/TLDR explanation for based preconfs?

A subset of ethereum validators opt in to the based preconf service. Those are the "sequencers" in the below picture, who are allowed to sequence transactions of rollups that have registered to the service. Includers can include transactions, but not sequence them, in that the next sequencer is allowed to reorder the includers' transactions, and even include more transactions of its own in between them.

As a user of a based preconf rollup, I can either send my transactions to some alt-mempool, paying a priority fee for the includer to include my transaction, or I can directly communicate with the next preconfer (slot n+1 in the pictures above and below) and pay a (most likely higher, but in some rare cases could be lower, or even negative!) preconf fee to request a preconfirmation. The preconfer can accept this fee by returning me a signed promise that contains some form of post-execution result/state, which guarantees that my transaction will be sequenced in a position that will result in that result/state, lest the preconfer be slashed. I, or the preconfer, can then further send the transaction and promise to a builder, for that transaction to be more faster included in an L1 block.


In order for the preconfer not to get slashed, it would need, during its slot, to include a "system" transaction containing ordering metadata (pointers to previously posted data) that reorders all the transactions included during the non-preconfing slots ahead of it that it hadn't itself already preconfed.


The "L2 preconfer-tx" in the last block would indicate to the derivation pipeline the order in which the transactions 1-5 should be sequenced in order to respect the preconfs that the preconfer has already given out, if any. In this specific example, a possible resulting derivation pipeline ordering for the L2 could be: tx1, tx5, tx6, tx7, tx2, tx4, tx3? The system "preconfer tx" would have thus ordered tx2, tx4, and tx3 in this order, possibly also by inserting other transactions in between.

### Who can participate as a preconfer

Literally any ethereum validator is allowed to sign up.

The only requirement for preconfs to be honorable is that the preconfer needs to have unique top-of-block proposing powers. Hence, theoretically, the person giving preconfs could be any of:
- Proposer himself
- Someone proposer has uniquely delegated to (mev-boost relay pre-ETs)
- Someone who has bought the entire proposal slot (could be builder if we had block futures auctions like MEVA)
- This could be enforced out-of-protocol in some secondary market enforced with EL slashing rules potentially

### Isn't pricing preconfirmations hard and requires sophisticated actors?

Yes, so a typical validator would most likely not be able to run such a service. Hence only validators who are sophisticated enough would onboard to this service.

### How can we prevent stake centralization around these sophisticated proposers?

[Execution Tickets](https://ethresear.ch/t/execution-tickets/17944) is one idea to shield the protocol from sophisticated proposers, where the idea is that validators would not by default ever get to propose a block. Proposers would need to buy execution tickets in order to participate in the proposing lottery, which would allow for mev-burn and all sorts of other benefits.

### Who gets to assume the preconfer role in a world without execution tickets?

One idea in the meanwhile is to proceed similarly to mev-boost, and have proposers delegate out-of-protocol and trustedly delegate their preconfing role to a third party entity that they fully trust. This could be a relay, in a construction that would resemble [pepc-boost](https://efdn.notion.site/PEPC-FAQ-0787ba2f77e14efba771ff2d903d67e4#2dfe02bc6dcd48878c82647676ca8d68).

Proposers would still connect to multiple relays for PBS, but would further select one favorite relay, labeled "gateway" in the below diagram, to give preconfs on their behalf.


### What happens to builders in this construction?

Builders continue building L1 blocks but are forced by the preconfing relay to include L2 transactions that have been preconfed. In order to give time for the builder to build a block and bid in the PBS auction, the relay (delegated preconfer) will have to stop sending the builder new preconfs sometime before the end of the 12s slot. Justin Drake mentions [here](https://youtu.be/2IK136vz-PM?si=6GYdYVnZWzNsvRO7&t=1621) that "if it takes a builder 100ms to build a block, then at the very least they need to have all the information 100ms before the PBS deadline".

### Why would users pay for preconfs?

The main reason for normal users to pay is better UX: they get an instant green checkmark on their wallets, and they immediately know the execution price of their swaps.

Sophisticated users such as market makers might also want to pay for this in order to enable more involved trading strategies, which could ultimately lead to better prices for normal users.

### Why would preconfers sell preconfs as opposed to taking the entire 12s slot to build an optimal block?

The main intuition is that preconfers stand to make more money with preconfirmation tips.

[Uri Klarman](https://twitter.com/uriklarman) goes into more detail with respect to this perspective [here](https://www.youtube.com/watch?v=2IK136vz-PM&t=1756s). His cofounder Eyal gave a talk last year at ethdenver where [he explains](https://youtu.be/Rvqt_kkGcfw?si=jAg0S_409BCo7jf0&t=1273) that most CEX-DEX arbs are captured during the last second of a block, for eg by using [bid cancellations](https://ethresear.ch/t/bid-cancellations-considered-harmful/15500). So a lot of the between-block volatility value is destroyed, which based preconfers could capture.

### How does the rollup bridge contract know the preconfers sequence?

Generate a merkle proof against beacon state root coming from eip-4788. Can also use a SNARK to replace the Merkle Proof, especially for zk-rollups who are already using snarks.

### Are based preconfs going to lead to vertical integrations of builders-relays/preconfers?

Giving relays delegated power to give based preconfs could lead to builders wanting to offer this functionality, and hence lead to further acceleration of [builder-relays](https://collective.flashbots.net/t/builderelay/2688).

### How are preconfs related to other EIPs?

With inclusion lists and based preconfs, proposers will eventually have 3 jobs:
- run the pbs auction
- propose an IL for the next slot
- sequence rollups + give preconfs

In its current state, ILs would most likely be given by the proposer himself, but the pbs auction and based preconfs would both rely on a trusted relay. Giving these new powers to relays is somewhat counter to the current trend towards optimistic-relaying whose goal is to remove their powers. Epbs could further remove relayer trust (but see [this](https://x.com/ralexstokes/status/1755723939026743484?s=20)), but based preconfs will only be trustless after Execution Tickets.

### What can a proposer do with its power?

Given the 3 proposer powers listed above, what can a proposer do with it?

- use it himself
- block/blob preconf: Can sell it ahead of time (either in some MEVA like auction, or via ETs, which are another kind of auction)
- block/blob JIT auction: this is pbs
- tx inclusion preconfs: via ILs
- tx receipt (state) preconfs: via based rollup preconfs

### Why does the proposer need to delegate to a "preconfing relay" instead of doing it himself?

Question asked [here](https://youtu.be/2IK136vz-PM?si=_uTV3ayYCdXNLh5s&t=2141). Justin Drake's answer:
- at the minimum you need to be running full nodes for these rollups to know the basefee and be able to price the preconfs
- but you also need the bandwidth to be able to process all the transactions on all the rollups simultaneously
- you also need to shield your IP
- you need to have collateral

### What happens if a preconfer's block is reorged?

If a block gets reorged, the preconf promises will not be upheld. Without includers constantly including preconfed transactions, the users will have to wait until the preconfer's block(that can be upto 30 blocks ahead) gets finalised.

Ellie's [short talk](https://youtu.be/mAGGdPRmhsc?si=_gypAfi_3qQi312T&t=86) covers how based sequencing can result in bad user experience.

### How are based preconfs related to slot/block futures?

Based preconfs can be seen as transaction futures, which are very different from slot/block futures.

There is however a relationship between them. PBS can be seen as JIT block auctions, which make it impossible for builders to provide transaction preconfs, because they don't know before the end of the slot whether their block is going to win the auction. Selling the ability to uniquely build the block ahead of time (slot auction) makes any builder who wins this auction able to give preconfs! Hence, in some sense, slot futures can be seen as a prerequisite to give transaction preconfs.

### What can a (delegated) preconfer be slashed for?

A fraud proof showing that a preconf was not honored (whether not included at the correct transaction index, or some part of the signed tx receipt is false) would lead to the preconfer being slashed for either
- Safety: If the preconfer violated promise
- Liveness: If the preconfer fails to propose a block in it's slot.

### How much stake does a (delegated) preconfer need to stake?

From [this](https://notes.ethereum.org/WLuNFaliQiqw7Zhd-7AnmQ?view) (economics section):
"1000 ETH is probably safe given that it’s larger than the largest MEV-boost bid value to date"

### Do proposers also get slashed?

Without execution tickets, the validators could get the relayer slashed by not signing on the block headers, for a small beacon chain liveness leak. This seems to indicate that proposers also need to be highly bonded, which is not possible for most home stakers.

### What about builders?

In the context of [optimistic relays](https://github.com/michaelneuder/optimistic-relay-documentation/blob/main/proposal.md), they [will need more collateral](https://youtu.be/2IK136vz-PM?si=neXp6hxGLiZ3aACu&t=2555) to make sure they respect the preconfs.

### Do delegated preconfs create incentives for collusion?
If two consecutive preconfers collude, one can just steal a large enough MEV with just getting slashed for liveness faults. The first preconfer does not propose a block in their slot even though they have made multiple preconfs, the next preconfer can build an L2 block that violates the preconf promises (after seeing a large MEV opportunity).

This might mean that liveness faults would need to be priced just as much as safety faults.