# Execution Tickets Lite

## Overview
Execution Tickets Lite(hereinafter ETL) is an out-of-protocol design of the [Execution Tickets](https://ethresear.ch/t/execution-tickets/17944)(hereinafter ET) that aims to achieve ET's design goals with minimal protocol level changes.

Much like PBS is the precursor to ePBS, ETL serve to be the lighter, simpler, and dumber version for the in-protocol ET.

## Glossary
- **Beacon proposer** – The validator selected as the proposer for a given beacon round (same as today).
- **Blockspace(blobspace) futures**: A financial instrument allowing users to reserve block space in advance for future transactions
- **Execution Tickets**: A voucher for participation in the execution lottery. Tickets are sold by the beacon chain for the rights to propose future execution blocks. See [Execution Tickets](https://ethresear.ch/t/execution-tickets/17944).
- **JIT Block Auction**: Builders commit to the contents of their block at the time of bidding, thereby binding themselves to a specific block state.
- **Preconfirmation**: Preconfirmation in this article generally refers to ["soft preconfirmation"](https://docs.google.com/presentation/d/1sXJA9vCzJ3sT-3FyrH6CBrOnkjBERiWnvc8gQxilnoM/edit#slide=id.p)
- **Slot Auction**: Builders bid without committing to specific block contents initially, allowing them to select and provide these contents at a later time during their allocated slot. See [Block vs. Slot Auction PBS](https://mirror.xyz/0x03c29504CEcCa30B93FF5774183a1358D41fbeB1/CPYI91s98cp9zKFkanKs_qotYzw09kWvouaAa9GXBrQ).

## Design

The design follows the mechanism laid out in the post [Execution Tickets](https://ethresear.ch/t/execution-tickets/17944) but with two major differences
- <ins>There will be only one lottery</ins>: there won't be an execution proposer round in ETL as it requires protocol-level updates. Instead, the beacon proposer for the designated slot will have the right to sell the execution tickets by running an off-chain auction much similar to MEV-Boost.
- <ins>Execution tickets are not distributed randomly but auctioned off</ins>: compared to the [ET](https://ethresear.ch/t/execution-tickets/17944), where the execution tickets are randomly assigned to the ticket holders with a fixed lookahead period, execution tickets under ETL are auctioned off to the participating bidders at the beginning of each epoch with a lookahead into the immediate next epoch(32 slots in total), where the winning bidder will become the de facto ticket holder for the slot. This effectively creates a [future-looking slot auction](https://mirror.xyz/0x03c29504CEcCa30B93FF5774183a1358D41fbeB1/CPYI91s98cp9zKFkanKs_qotYzw09kWvouaAa9GXBrQ) for block construction as opposed to a [JIT block auction](https://collective.flashbots.net/t/when-to-sell-your-blocks/2814).

The rationale for the proposed distinctions are:
1. <ins>The two-lottery system would require a protocol level change</ins>: as ETL aims to require minimal modifications to the existing protocol, one-lottery system where execution ticket assignments are delegated to off-protocol mechanisms is much prefered.
2. <ins>Random allocation of execution tickets discourage pariticipation</ins> : as a transitional step towards ET, ETL takes the existing protocol landscape into account. Initially, block builders are expected to be the primary purchasers of execution tickets in the primary market. With the random allocation of execution tickets, every participant has an equal chance to obtain the ticket, which reduces a single party's competitve edge. As such, the allocation of tickets is based on probability rather than merit. This would discourage specialized block builders from engaging with ETL as their expertise are not properly compensated.

### Lifecycle of An Execution Ticket

1. At the beginning of each epoch, execution tickets for the upcoming 32 slots are sold by individual validators who choose to participate in the slot auction. Validators can only auction off their tickets for the current epoch and immediate next epoch so long as the validator's slot has not passed.
2. After selecting a winner according to their own evaluation metrics, validators issue the execution ticket to winners. This ticket, representing a commitment that the validator will only accept block from ticket holders, can be freely traded in a secondary market. Validators are obligated to accept blocks from ticket holders for their respective slots, with failure to do so being a slashable offense.
3. A ticket buyer can start selling [preconfirmations](https://ethresear.ch/t/based-preconfirmations/17353) or [blockspace(blobspace) futures](https://hackmd.io/@qiprotocol/ry621KjQa) [^1] so long as he/she has re-staked on Eigenlayer-like restaking protocols. Re-staked or not, ticket holder should be able to start building blocks immediately much like an auction winner in [slot auctions](https://mirror.xyz/0x03c29504CEcCa30B93FF5774183a1358D41fbeB1/CPYI91s98cp9zKFkanKs_qotYzw09kWvouaAa9GXBrQ).
4. At the designated slot for block proposal, the holder of the execution ticket is responsible for delivering the block to the validator who sold the ticket. This step finalizes the process where the ticket holder, having secured the right to build the block, fulfills their part of the agreement by sending the block to the selling validator. The execution ticket is burned after the block proposal.

[^1]: pre-confirmation is a form of blockspace futures. See https://twitter.com/qi_protocol_/status/1754076962220282250

### Requirements
#### Validator
<ins>Re-Staking Requirement for Validators</ins>:
- Validators intending to sell slots must must have restaked on Eigenlayer-like restaking protocols for accountability
- Purpose: Enables the imposition of penalties for misconducts.

<ins>Execution Tickets Sales Timing</ins>:
- A validator should be able to start selling the slot immediately upon knowing which block he/she will be proposing, which according to the current protocol spec, at least 1 epochs(32 blocks) in advance;
- Condition: if the current slot is $S_c$ and current epoch is $E_c$, a validator should be able to sell his/her slot $S_n$ so long as
- he/she is in the epoch $E_c$ or $E_{c+1}$, and
- $S_n$ is larger than $S_c$

<ins>Prohibition on Self-Proposing After Auction</ins>:

- Validators are prohibited from proposing a block themselves if they have auctioned off that slot.
- Purpose: Upholds the integrity of the agreement with the execution ticket holder.

<ins>Non-Interference with Block Content</ins>:

- Validators must not alter the content of the block submitted by the auction winner.
- Purpose: Prevents validators from exploiting the informational value of the execution ticket holder’s work.

<ins>Validation Proof for Sold Slots</ins>:

- Validators are required to provide proof of their role for the sold slot.
- Purpose: Protects execution ticket holders from being "catfished" by fake validators.

#### Execution Ticket holder
<ins>(Re)Staking Requirement for Sales of Forward Looking Promises</ins>:

- Execution ticket holders engaging in blockspace futures sales or providing pre-confirmations must have restaked on Eigenlayer-like restaking protocols for accountability.
- Purpose: Enables the imposition of penalties for misconducts.

<ins>Inclusion Guaranttees</ins>:

- Obligation for holders to include transactions from sold blockspace futures in the block.
- Purpose: Ensures that holders honor forward-looking commitments, with non-compliance resulting in slashing.

<ins>Sales of Execution Tickets on Secondary Market</ins>:

- Holders may resell execution tickets, provided all previously sold forward-looking promises are fulfillable by the new buyer.
- Purpose: Prevents the failure to honor previously made commitments.

<ins>Restrictions on Resale Timing</ins>:

- Execution tickets can be resold only if the current slot number is less than the execution ticket's slot number.
- Purpose: Prevents the sale of expired or irrelevant execution tickets.

### Implementation Guide

#### Re-staking

ETL leverages re-staking protocols such like EigenLayer to enforce penalties for programmed misconducts such like block content modification by the validator after accepting blocks from the execution ticket holder. Additionally, execution ticket holders who sell blockspace futures or preconfirmations are also required to (re)stake as "margin requirement".

Take Eigen Layer for example, all participating validators should form an AVS distributed validation set to police the behavior of other validators.

#### Validator & Slot Verification

Communication between bidders and selling validator requires a secure protocol. For a bidder to verify the selling validator is indeed the proposer for the said slot, one could query the `pubkey` of a validator for a slot using [`getProposerDuties` API](https://ethereum.github.io/beacon-APIs/#/Validator/getProposerDuties) to verify the cryptographic identity. Then, validators should encrypt messages using their public keys and sign them with private keys. Receivers, in this case bidders, authenticate the sender's identity by verifying the signature against the sender's public key, as obtained from the [Beacon API](https://ethereum.github.io/beacon-APIs/#/Validator/getProposerDuties).

Success response of `getProposerDuties`

{
  "dependent_root": "0xcf8e0d4e9587369b2301d0790347320302cc0943d5a1884560367e8208d920f2",
  "execution_optimistic": false,
  "data": [
    {
      "pubkey": "0x93247f2209abcacf57b75a51dafae777f9dd38bc7053d1af526f220a7489a6d3a2753e5f3e8b1cfe39b56f43611df74a",
      "validator_index": "1",
      "slot": "1"
    }
  ]
}

#### Slot Auction
To faciliate the communication between seller/validators and execution ticket buyers, a [sidecar](https://www.oreilly.com/library/view/designing-distributed-systems/9781491983638/ch02.html) similar to [MEV-Boost](https://github.com/flashbots/mev-boost/) is necessary. The major difference is that ETL requires no [relays](https://ethresear.ch/t/mev-boost-merge-ready-flashbots-architecture/11177) as the middleman to accept bids and broadcast blocks. Therefore, a ticket selling validator will accept blocks as one would under the current PBS architecture but will broadcast the block without relying on a relay.

#### Bid Commitments by the Execution Ticket Holders

If an execution ticket holder wants to sell preconfirmations or blockspace (blobspace) futures, they must send back commitments to signal acceptance of the bids. Later, such commitments will be used for challenge in event the execution ticket holder does not honor the commitment. To implement the commitment scheme, a lightweight rollup with faster block time could be implemented. See ["Bid commitments through a customized roll-up"](https://hackmd.io/c_KIsSgrRo2c8BpembQPXQ?view#Protocol-Description) for more details.

#### Proof of Block Intactness

A rogue validator could steal MEV transactions from the block submitted by a ticket holder, or insert transactions into the block to manipulate the state. In short, allowing the validator to alter the content of the block opens up numerous attack vectors to abuse the system. Since ETL will not rely on relays, we'll use a cryptographic way to prove the block intactness. Here is how:

- For every block submitted, it has to include a specific transaction that calls a state-changing function with the merkle root of all transactions (excluding itself) as an argument. The purpose is to store the merkle root as a smart contract state prepared for challenge later. [^2] This merkle root is stored in a smart contract for future verification. When challenged, possibly with zk-coprocessors like [Axiom](https://www.axiom.xyz/), the stored merkle root must match a newly re-constructed root from the block's transactions. A mismatch would indicate validator tampering, leading to slashing.
<em>Merkle root for a block</em>
- There's an issue with wrongly constructed merkle root. For example, when a ticket holder submits a block to the validator but miscalculated the merkle root, validator shouldn't be slashed because of the mismatch when later challenged. To address this, ticket holder should also submit the block to data availability service such like [EigenDA](https://www.blog.eigenlayer.xyz/intro-to-eigenda-hyperscale-data-availability-for-rollups/) so that the merkle root and transactional data is made available later when challenged.

## Analysis

### Decoupling MEV from Validators

ETL decouples MEV reward from validators as only the ticket auction proceeds would go to the validator. In a way, however, MEV reward is baked into the auction proceeds as buyer would factor in the MEV reward when they bid for a ticket. Assuming the amount of MEV remains the same for slot auction vs JIT auction, validators' revenue should also remain the same.

### Retirement of Relays

The suggested system doesn't depend on trusted relays to safeguard against validators potentially misappropriating the MEV. Instead, it leverages zk-coprocessors such like Axiom to query the historical block data to examine if the block content has been modified after the block submission to the validator.

### Pricing of Execution Ticket

#### Primary Market

Let's denote the price of execution ticket for block $B_i$ as $P$. The validator’s intention to sell the execution ticket hinges on the condition that $P$ surpasses the expected revenue from the JIT block auction.

$P$ > $E_{validator}(PriorityFee_{Validator} + MEV_{Validator})$,[^3]

where

$E_{validator}$: Validator's expected revenue
$PriorityFee_{Validator}$: Validator's expected priority fee at $B_i$.
$MEV_{Validator}$: Validator's expected MEV at $B_i$.

Conversely, a buyer’s willingness to bid for the execution ticket in advance is contingent upon the exected revenue from holding the execution ticket surpasses participating the JIT block auction. Thus, the price $P$ should always be less than buyer's expected revenue to at least breakeven.

$P$ < $E_{Buyer}(PriorityFee_{Buyer} + MEV_{Buyer} + PreConfirmation_{Buyer})$,

where

$E_{Buyer}$: Buyer's expected revenue
$PriorityFee_{Buyer}$: Buyer's expected priority fee at $B_i$.
$MEV_{Buyer}$: Buyer's expected MEV at $B_i$.
$PreConfirmation_{Buyer}$: Buyer's expected preconfirmation tips at $B_i$.

Therefore, a successful sale would take place only when

$E_{Buyer}$ > $P$ > $E_{validator}$

Seperately, since the ticket is determined through an auction, the $P$ is also influenced by the competitive dynamic among bidders. Due to the different strategies invovled to extract MEVs and sell preconfirmations, different buyers would value the execution ticket differently.

#### Secondary Market

The price of execution ticket will gradually reach its "true" value as time elapses, much similar to the concept of [theta decay](https://tickertape.tdameritrade.com/trading/what-is-theta-in-options-trading-15953) in option pricing. This is the because the information a ticket holder possesses increase overtime.

## Open Questions

### Multi-block MEV

As suggested by the [original post on execution ticket](https://ethresear.ch/t/execution-tickets/17944), multi-block MEV becomes much easier under the proposed system. While there are temporary solutions, like preventing the same entity from consecutively purchasing tickets, a more thorough examination balancing the costs & benefits are necessary to address this issue effectively.

### Validator Revenue

["When to Sell Your Blocks"](https://collective.flashbots.net/t/when-to-sell-your-blocks/2814) suggests auction revenue might be lower for early auctions, yet the changing market structure could change the paradigm of block building and additional services such like preconfirmations could potentially increase the auction revenue. The bottom line is the overall market outlook is unclear. Techniques such like [agent based modeling](https://en.wikipedia.org/wiki/Agent-based_model) should provide a framework to understand the market dynamic.

[^2]: The merkle root should be functionally similar to the [`transaction_root`](https://flow.com/engineering-blogs/ethereum-merkle-patricia-trie-explained) in the [`execution_payload_header`](https://ethereum.org/developers/docs/blocks#block-anatomy), with the difference that the `transaction_root` merkelize all transactions in a block whereas the merkle root excludes the transaction that stores the merkle root as smart contract state.

[^3]: For simplicity, we assume the bid a block builder would submit at during a JIT block auction equals a block's total priority fee plus MEV