# [RFC] Based Ticketing Rollup

# TLDR

“Based Ticketing Rollup” concept is a design proposal for a decentralised rollup. It starts from the concept of a Based rollup and adds Execution Tickets to address its weak points.

- Rollup slots are defined as `N` (`N`>1) number of l1 slots where only one proposer - `L2 proposer` - can propose rollup sequence. `N` can be used to modify the sequencing velocity.
- The rollup protocol uses the L1 to offer two types of tickets - **proposal tickets** and **enforcement tickets**.
- Lottery draw among the **proposal** ticket holders determines the next `X` rollup slot proposers. These L2 proposers can propose the rollup transaction list. Tickets revenue flows into the rollup.
- Lottery draw among the **enforcement** ticket holders determines the next `X` rollup slot `L2 enforcers`. These `L2 enforcers` communicate and enforce validity rules of the proposed transaction list to the proposers. They can offer various UX services like preconfirmation with post-state commitments. Tickets revenue flows into the rollup.
- Any ticket holder needs to have a stake in order to be punished for misbehaviour. A natural extension is to tap in the massive Ethereum L1 stake via Eigen-Layer style restaking + opt-in slashing conditions. This will allow (or can be limited to only) L1 validators to buy tickets and perform the rollup protocol roles.
- Ticket holders of multiple rollups can enable Universal Synchronous Composability (USC).

This concept is not necessarily oposed from the original [based rollup](https://ethresear.ch/t/based-rollups-superpowers-from-l1-sequencing/15016) concept. Rather this concept can serve as a hybrid transition period, until high enough L1 validators count enroll into based sequencing at which point ticketing can be forgone.

# Background

A [Based rollup](https://ethresear.ch/t/based-rollups-superpowers-from-l1-sequencing/15016) is characterised by pre-block-building sequencing - an ordered list of L2 transactions is submitted to L1 smart contract and when it is included in the L1 chain it is used to build an L2 block. The order of the rollup blocks is consistent with the order of the sequencing transactions in L1. The actors monitoring the L1 can see the sequencing transactions and build one block per sequencing transaction. With this concept the rollup inherits the ordering and censorship resistance of L1. In the original based sequencing concept the sequencing is completely permissionless and uses the “total anarchy” concept - any user can be a proposer. This also ensures liveness of the network.

The [L1 execution tickets](https://ethresear.ch/t/execution-tickets/17944) proposal sees the L1 staker duties of block proposal and chain validation being separated. Stakers are still assigned to attestation committees and perform validation duties, however the block proposal duties are subject to a different lottery-based mechanism. Any staked validator can purchase one of two types of tickets - execution slot tickets and beacon slot tickets. Out of the purchased ticket holders a protocol lottery draws the next epoch beacon block and execution block proposers. The execution block proposers propose the execution block for their slot (likely using their MEV pipeline). The beacon block proposers propose the beacon block that no longer includes commitment to the execution block transaction list, but includes a censorship resistance mechanism - an inclusion list.

# Based Ticketing Rollup

This document outlines a design for a decentralised rollup combining the strengths of the two ideas above. Combining them together, this document argues, we can achieve preconfirmation-enabled, Universal Synchronous Composability(USC)-enabled, MEV-retaining based rollup, reusing the L1 economic security, liveness guarantees and censorship resistance.

Lets define rollup slots `S` as `N` (`N`>1) number of L1 slots where only a selected proposer can propose rollup sequence. `N` can be used to modify the sequencing velocity.

There are three main roles in the proposed concept:

- L2 Proposer - `proposer` - Tasked with the job to propose a L2 transaction list in the L1 for a specific rollup slot. This actor will ideally also be L1 staked validator opting-in for additional slashing conditions.
- L2 Enforcer - `enforcer` - Tasked with maintaining a list of **validity conditions** that the next proposed transaction list of the next rollup slot should comply with. Such conditions can be the guaranteed inclusion of a transaction and/or the resulting post transaction state of the rollup. This actor will ideally also be L1 staked validator opting in for additional slashing conditions.
- L2 Builder - `builder` - Sophisticated entity separate from the proposer tasked with the creation of the most economically efficient transaction list given the validity conditions broadcasted by the enforcer.

In similar fashion to the L1 execution tickets concept, the proposed design introduces two lottery mechanisms.

Firstly, via designated L1 contract, the rollup protocol can offer **proposal tickets**. For every L1 epoch the rollup protocol selects a set 32/`N` proposal tickets at random (using the L1 RANDAO). Each respective holder of a ticket in the drawn set is eligible to be the `proposer` for the corresponding Rollup slot. This means that the drawn proposal ticket holder is responsible for creating and submitting the transaction list of the slot. This transaction list should comply with the validity conditions indicated by the `enforcer`

Secondly, via designated L1 contract, the rollup protocol can offer **enforcement tickets**. For every L1 epoch the rollup protocol selects a set 32/`N` enforcement tickets at random. Each respective holder of a ticket in the drawn set is eligible to be the `enforcer` for the corresponding Rollup slot. This means that the drawn enforcement ticket holder is responsible for crafting and broadcasting the validity conditions of the block.

Both proposal and enforcement tickets, hereinafter referred just as tickets unless specified otherwise, can only be bought by L1 stakers that have opted-in for additional slashing conditions via eigenlayer-style restaking. This will enable the protocol to reuse the L1 economic security and allow them to drive further capital efficiency.

Proceeds from ticket sales are retained in the rollup protocol contracts and are subject to use by the rollup. **These can be split as profit for the rollup, further profits by actors, or be burned for alignment with Ethereum.**

Separating the role of the proposer from the role of the enforcer enables the proposer to be quite “unsophisticated” actor - all they need is economic power to buy tickets. All of the rest of their tasks can be outsourced to the block building pipeline. This lowers the implied requirements to be a proposer and increases the entities that can assume this role. The enforcer, on the other hand, needs to be a sophisticated actor in order to perform the censorship-resistance and ux services safely. In theory one entity can play all three roles and be vertically aligned.

## Interaction Flow

1. An L1 Staker `A` restakes and opts-in to be а L2 Proposer. An L1 Staker `B` restakes and opts-in to be а L2 Enforcer.
2. `A` buys proposal tickets
3. `B` buys enforcement tickets.
4. `A`s ticket gets drawn and is now the next L2 Proposer. `B`s ticket gets drawn is now the next L2 Enforcer.
5. Users submit transactions to a public mempool or send privately transactions to L2 builders. Subset of the users connect to `B` requesting them to perform various UX services requiring enforcement on the upcoming proposal.
6. `B` continuously updates `A` and/or the L2 block building pipeline on the validity conditions for the upcoming proposal.
7. `A` auctions the L2 block building to L2 block builders. The L2 block builder combines their private orderflow with the public L2 mempool to create L2 block obliging to the `B` validity conditions.
8. `X` (`X` ≥ 1) L1 slots before the rollup slot end `B` broadcasts an L1 transaction indicating and committing to the validity conditions that `A` should honour.


9. `A` selects winning bid from the L2 block builders and broadcasts the sequencing transaction in L1. The transaction needs only to be covering the base fee + tip (to practically guarantee inclusion) or is included in the L1 beacon block inclusion list.

## Monopoly Rights

Similarly to the Execution tickets concept the ticket holders for the next slot have monopoly over the proposal transaction list and the validity conditions respectively. Both actors have opportunity to capitalize on this monopoly in various ways.

L2 Proposers can extract MEV from the transaction list, similarly to the current L1 Proposers in the block building pipeline. Importantly the L2 Proposers have already paid the protocol for these monopoly rights when they have purchased tickets.

L2 Enforcers can profit from offering additional UX services via their monopoly over the proposal validity rules. One such example is post-state pre-confirmation by creating validity conditions about top-of-the-list contents. Importantly, in order to keep the economic viability of the proposer role, the top-of-the-list contents as specified by the validity rules should be limited in terms of gas consumed. Similarly to the proposal tickets, the enforcers have already paid the protocol for the monopoly right over the validity rules.

Both these rights are used via L1 transactions - The L2 proposer sends a sequencing transaction to the L1 and the L2 enforcer sends validity rules transaction. While the validity rules are p2p communicated from the enforcer to the proposer ahead of time, there are scenarios where due to misbehaviour or network faults the p2p communicated validity rules differ from the rules indicated in the L1 transaction. In order to allow the proposer (and the block building pipeline) to react to the actual L1 committed validity rules, the parameter `X` is introduced, indicating the number of L1 blocks prior to the proposal deadline that the validity conditions should be submitted. *(This concept assumes L1 with SSF)*

## Types of preconfirmations
Several types of preconfirmations are possible with this design.

First type of preconfirmation is transaction **inclusion preconfirmation**. The inclusion preconfirmation guarantees the inclusion of a transaction in the subsequent rollup slot. These are useful for use cases like simple transfers.

Second type of a preconfirmation is the stronger post-execution **state preconfirmation**. It allows specifying a desired state of the rollup after the execution of the transaction. These are useful for more complex usecases like DEX trades and/or arbitrage.

Both preconfirmation types require the `enforcer` to enforce the inclusion of a certain user transaction. The main difference comes in the ordering of the transactions. Within the context of the block, the **inclusion preconfirmed** transaction can be located anywhere in the block. The **state preconfirmation** transaction requires a specific ordering of the transactions list up to the inclusion of this transaction.

State preconfirmation requires more sophistication to commit to the validity conditions and enforce them. Transactions prior to the target one can change the pre-execution state and make the desired post-state invalid, thus rendering the whole preconfirmation invalid. In practice this means that the enforcer must maintain and commit to an ordered list of transaction at the top of the list.

## Tickets Pricing, Ticket Resale & Lottery Draw Mechanism

Similarly to the Execution Tickets proposal the rollup can adjust the targeted tickets in circulation by adjusting the price of the tickets. A higher price per ticket as function of the existing unused tickets will maximize the profit generated by the protocol. Sane actors will continue buying tickets as long as they are expecting to be profitable from these tickets.

The primary way to profit from proposal tickets will be to earn the transaction fees and MEV generated by the transactions in this slot. The primary way to profit from enforcement tickets will be to earn fees from offering additional UX services. As the ticket holders purchase their tickets prior to realising their profits it is safe to assume that sane actors will account for volatility risks and adjust their maximum price per ticket they are willing to pay.

Secondary way to profit from proposal tickets is to resale them just-in-time. Tickets get purchased prior to being drawn and assigned to rollup slot. The uncertainty of when the ticket is going to get drawn in a slot can be accounted for by sophisticated actors by purchasing tickets already assigned to a slot and paying a premium for that. This sale can be considered Just-in-time (JIT) sale.

Ticket resale mechanism is still TBD.

As stated above the design utilizes lottery to decide on the eligible actors for the rollup slots in the next epoch. In order to submit a proposal the proposer needs to prove ownership of the winning ticket. Using the L1 RANDAO as source of randomness, the winning ticket can be deterministically calculated.

## Possible Proposer and Enforcer Violations

Both proposers and enforcers can violate the protocol mechanisms. In case of violations both parties can partially or fully lose their L1 stake. This is why only restaked L1 stakers can participate in the tickets lottery. Bellow you can find a short list of violations and faults that the actors can be punished for.

- Proposer liveness fault - the L2 proposer misses to get L1 sequencing transaction included within their rollup slot. This fault can be objectively proven by the L1 smart contract.
- Enforcer liveness fault - the L2 enforcer misses to get the L1 transaction indicating the validity conditions for the rollup slot. This fault can be objectively proven by the L1 smart contract.
- Invalid proposal - the L2 proposer submits invalid transaction list or a list that does not comply with the validity conditions submitted by the enforcer. This violation can be proven via ZK proof.
- Invalid validity conditions - the L2 enforcer submits validity conditions that cannot be honoured by honest proposers or exceed the top-of-the-block gas limit allotted to them. This violation can be proven via ZK proof.

## Extension to USC

The rollup design naturally lends itself to become part of a wider universal synchronous composability (USC).

Assuming multiple rollups using the based ticketing design, USC can be achieved when the L2 proposers for the next rollup slot align and synchronise. This might be achieved through vertical integration, or when a single party purchases (like through JIT sale) the coinciding proposing tickets for multiple rollups.

When one and the same party is in control of the sequencing of multiple rollups they can ensure synchronous composability and atomic cross-chain transactions. This kind of composability is necessary to address Ethereums fragmentation problem.

# Strategic Importance of Based Ticketing
This concept is not necessarily oposed from the original based sequencing concept. Rather this concept can serve as a transition period, until high enough L1 validators count enroll into based sequencing, at which point ticketing can be forgone.

Using based ticketing as Based Sequencing V1 will:

- Enable teams to start use most of the based sequencing powers and guarantees right away
- Enable the development of important infrastructure and mechanisms that will be important for full based sequencing - Generalised MEV-Boost,

# Concept Analysis

The following paragraphs are an attempt to showcase the extent to which the proposed concept satisfies the [rollup endgame requirements](https://ethresear.ch/t/unified-endgame-rollup-requirements/18733).

## L1 Sufficiency

The proposed rollup design inherits its L1 sufficiency from the based sequencing concept. All the information in order to get to the latest state of the rollup can be found in the L1 historical state.

## **Subjective finality**

The proposed rollup design inherits its subjective finality from the based sequencing concept. Given finality of the L1, any actor monitoring the L1 is able to reason about the final state of the rollup by the sequencing transactions included in the L1 chain.

## **Objective finality**

The proposed rollup design makes no assumption nor suggestion about the finality mechanism of the rollup from the perspective of L1. It is the choice of the rollup designer to include fraud proofs, validity proofs or other finality mechanism.

## **Robust liveness**

The proposed rollup design leaves it to the designer to choose the parameter `S` - the number of L1 blocks that a rollup slot spans. Within this concept the rollup designer can further embed anti-censorship rules in order to constrain $\texttt{T}_C$ as number of rollup slots. Furthermore, the proposed rollup design, enables fast preconfirmation practically shortening the confirmation time for the user and improving the UX.

The proposed punishment for liveness fault and the nature of the lottery draw makes the rollup design inherit liveness guarantees similar to the ones of Ethereum L1 using the execution tickets concept.

## **Robust finality**

The proposed rollup design makes no assumption nor suggestion about the finality mechanism of the rollup from the perspective of L1. The choice of finality mechanism of the rollup designer will influence the satisfaction of this requirement.

## **L1 leadership**

The proposed rollup design uses the L1 RANDAO for source of randomness for the suggested lotteries. Furthermore the ticket purchasing is happening in L1. Apart from these it is the choice of the rollup designer to put the mechanisms in place to satisfy this requirement.

## **Economic viability**

The proposed rollup design economical viability is controlled by its actors. Both L2 proposers and enforcers are assumed to be sane actors with various risk tolerance and ability to extract value from their monopolies. It is reasonable to assume that the actors will account for the risk of pre-payment for monopoly and price the tickets accordingly.

## **Permissionless role access**

The proposed rollup design has no special pre-reserved roles for entities. Any actor that meets the necessary requirements (economical and behavioural) can assume the respective roles.

## **Actors diversity**

The proposed rollup design does not downgrade nor upgrade the actors diversity compared to the L1 execution tickets proposal.

The proposed rollup design **downgrades** the sheer permissionless nature of sequencing that the “total anarchy” approach that the original based sequencing concept employs. This tradeoff however ensures economic viability and greatly enhanced user experience.

## **Excellent user experience**

The proposed rollup design has a major focus on enabling various user experience improvement mechanisms. The design naturally supports post-state preconfirmations, and is USC-enabled without requiring any further protocol changes.

The cost of regular transactions will be influenced by the choice of the designer for the length of the rollup slot `S` and additional mechanisms like compression.

While the design introduces additional new L1 transaction for committing to validity rules, the cost for this transaction should be fully covered by the fees that the users will be willing to pay for the UX improvements (i.e. preconfirmation tips).

# Conclusion

Although still in their exploration phases, both based sequencing and execution tickets concepts are among the most promising items on the Ethereum roadmap. The proposed design concept above combines the two to draw the best of both worlds and offer a design aligned with the end-game of the rollups.

# Open Questions and Design Areas

- What will be the design for the IL? Do we want to base ourselves on the current L1 IL spec? Should we guard the enforcement tickets from becoming just a top-of-the-block MEV auction?
- Can validity conditions L1 transaction be skipped and safely replaced by cryptographic commitments?
- Can validity conditions submission deadline be removed safely?
- How to differentiate between enforcers “liveness fault” and “no validity condition”?
- Do we need to and how do we ensure that the enforcer has not been communicating widely different validity conditions compared to the one posted in L1?
- Generalised MEV-Boost Design Space
- Mechanism for tickets lottery
- Mechanism for proving misbehaviour
- Secondary Market for IL and Proposal tickets
- Impact on other infrastructure - Wallets, Dapps, etc
- Object format for preconfirmation requests and commitments
- Timing games for rollup slots