# Proposer Preconfirmer Seperation(PPS)

## Intro

In this article, we present a commitment-fullfillment paradigm that allows proposers to delegate the preconfirmation tasks for [Based Rollups](https://ethresear.ch/t/based-rollups-superpowers-from-l1-sequencing/15016).

## Motivation

[Based Rollups](https://ethresear.ch/t/based-rollups-superpowers-from-l1-sequencing/15016) inherits the liveness and decentralization directly from L1, yet the L1 block time(12 seconds) becomes the bottleneck for UX, especially that end users use rollups primarily for its fast transaction confirmations. [Based Preconfirmation](https://ethresear.ch/t/based-rollups-superpowers-from-l1-sequencing/15016) was introduced to address this very issue. In the original [Based Preconfirmation](https://ethresear.ch/t/based-preconfirmations/17353) post, Justin Drake mentioned *Delegated Preconf* as a solution to mitigate a proposer's computational overhead. Here, we want to expand on the idea of *Delegrated Preconf* and introduce a design that proposers, as dencetralized L2 sequencers, could delegate the task of L2 block building to a separate entity - preconfirmers. In the spirit of PBS(proposer-builder-separation), we've named this design PPS(proposer-preconfirmer-separation).

## Glossary

- <ins>Batch</ins>: a roll-up block
- <ins>Attestation Finality</ins>: all ordered transactions in a batch has been successfully attested, via either fraud proof or validity proof, on the bridge smart contract.[^1]
- <ins>Preconfirmation (Preconf)</ins>: a low latency(relative to 12-second block time) promise that the user's transaction will be included in future batches.
- <ins>Preconfirmation Ticket</ins>: a ticket that grants its holder right to sequence rollup transactions for a particular slot.
- <ins>Preconfirmer</ins>: an entity that issues promises to the preconfirmation requestors.
- <ins>Sequencer Finality</ins>: a batch whose transaction order has been determined and ready to be submitted to L1 by the sequencer.
- <ins>Settlement Finality</ins>: When the post execution state root and canonicalize transactions have been posted to L1.

[^1]: soverign roll-ups are outside of the scope for this article

## Rollup Sequencing

### Lifecycle of a Rollup Transaction
<p>
from *"Tiers of Transaction Finality for Rollups"* by Patrick McCorry
</p>

Without loss of generality, a roll-up transaction today generally goes through the following stages before reaching the attestation finality

1. **Transaction Initiation**: A user initiates a transaction through wallets such like MetaMask. MetaMask formats and signs this transaction like a regular Ethereum transaction. Then, MetaMask sends the transaction to the a rollup's RPC endpoint. This endpoint is a rollup node that routes the transaction to the *Sequencer*.
2. **Sequencing**: The Sequencer receives the transaction, validates it, returns a pre-confirmation back to the user, and orders it among other received transactions to reach soft finality.
3. **Batch Posting**: Periodically, the *Sequencer* posts batches of transactions to the bridge contract, who fulfills the role of data availability layer. This action canonicalizes the transactions order before attestation.
4. **Execution Settlment**: Anyone could attest and propose the new roll-up state alongside convincing evidence - validity proof or fraud proof. After an extended period, which could last for 2 weeks for Optmistic roll-ups, the state reaches attestation finality.

### Sequencer Design Choices
There are four general approaches for sequencer design today:

1. **Centralized Sequencer**: While having total control of the system allows for easy feature implementation, centralized sequencers have suboptimal guarantees on pre-confirmations, potential issues with forced transaction inclusions, and liveness risks.
2. **Decentralized L2 Sequencer**: Utilizing a distributed set with meaningful stake enhances the rollup's robustness compared to a single sequencer. However, there may be trade-offs in latency, especially if multiple L2 nodes must vote before confirming a rollup block.
3. **L1-Sequenced** or **Based Sequencing**: A rollup is said to be based when its sequencing is driven by the L1 proposers. This approach offers maximum decentralization as it inherits censorship resistance and liveness directly from L1. However, it lacks certain features like fast pre-confirmations and has data throughput limits.
4. **Shared Sequencer**: Combining the functionality of a decentralized sequencer with the benefits of sharing it with others, this approach eliminates the need to bootstrap your sequencer set. Yet, weaker assurances compared to L1 sequencing exist in interim periods before total L1 finality. Additionally, a shared layer can aggregate committee, economic security, and more across multiple rollups into a single, likely stronger entity than each rollup having its committee.

### Based Sequencing & Based Preconfirmation
L1 sequenced transaction offers maximum decentralization among all four of the designs above but could only offer L1 block time (12 seconds) preconfirmation at best. In comparison, most of roll-ups today use a centralized sequencer that gives sub-second preconf (sequencer finality) to users.

To provide the UX similar to a roll-up with centralized sequencer, [Based Preconfirmation](https://ethresear.ch/t/based-preconfirmations/17353) was introduced.

Based Preconfirmation for a Based Roll-up would work like this[^2]:
<p>from [Based Preconfirmations](https://ethresear.ch/t/based-preconfirmations/17353) by *Justin Drake*</p>
1. Preconfirmer Registration
- Proposers can opt into a staking protocol similar to Eigenlayer, with additional slashing mechanisms, to become preconfirmers.
Alternatively, proposers can delegate preconfirmation duties to third parties to avoid computational overhead.
Preconfirmers and proposers share liveness guarantees, opting into a slashing mechanism to mitigate risks.
2. Preconfirmation Acquisition
- Users initiate off-chain preconfirmation requests, including transactions and fees, to next preconfirmers.
Requests can include validity data and expiration times to prevent delays.
Different promise types require varied data, with tiered fees based on promise types.
3. Preconfirmation Request Processing
- Preconfirmers validate requests, issue commitment to users, and publicly stream preconfirmed roll-up states.
In case of liveness failure, the next preconfirmer could have the right of refusal for accepted transactions to maintain liveness guarantees.
4. Transaction Compression & Blob Posting
- Preconfirmers periodically compress transaction data and generate blobs to post on L1, either independently or with a block builder.

### Open Questions with Based Sequencing & Based Preconfirmation
Despite seemingly simple implementation, there are many underexplored issues associated with Based Sequencing. We want to first identify these issues then provide a design that could address them.

#### Proposer Laziness
- Pricing preconfirmations require sophistication commonly not possessed by validators. Solo stakers are having hard time tunning MEV-Boost. Incentivising them to run an additional piece of software to manage preconfirmations is a touch ask.
- In the original [Based Preconfirmation](https://ethresear.ch/t/based-preconfirmations/17353) post, Justin Drake suggested the delegating the preconfirmation to third parties might be a viable solution to address this issue. However, exactly how a proposer chooses a delegated preconfirmer is still unknown. Is the delegated preconfirmer chosen just-in-time, or could it be based on off-chain agreements? What's the trusted relationship between user, proposer, and delegated preconfirmer? How to arbitrate when preconfirmations are not honored?
- Proposers are the natural providers of preconfirmations, however, proposers likely do not possess the sophistication to manage preconfirmations. This begs the question who should be the party that proposers delegate to. Block builders might be in a good position to manage preconfirmations as they are tasked to carry blobs on-chain; however, this inevitably requires enshrining a subset of block builders. Over the long run, this further accelerate builder centralization. Relays might be in a good position to manage preconfirmations as well, but as most relays are currently merely infrastrucutre providers, it's doubtful whether they could manage the preconfirmatino.

#### Cold Start Problem
- Sufficient L1 validators must opt-in to become preconfirmers to have at least one preconfirmer in the lookahead period(32 slots) with high probability [^3]. What's the go-to-market strategy to incrementally increase the opt-in validator set? Like running MEV-Boost, selling preconfirmation is an additional revenue stream to the validators, hence it shouldn't be a tough sell; however, unlike MEV-Boost, the revenue potential of preconfirmation can only be realized after sufficient L1 validators have opt-in. A go-to-market strategy needs to properly address the catch-22.

[^3]: According to the original [Eth Research post](https://ethresear.ch/t/based-preconfirmations/17353) on based preconfirmation, if 20% of validators are preconfirmers there will be a preconfer with probability at least 1 - (1 - 20%)32 ≈ 99.92% for each epoch.

#### Latency
- The latency for a point-to-point connection between user and a preconfirmer can happen on a order of [100ms](https://wondernetwork.com/pings). However, depending on the selection mechanism for preconfirmer, the latency varies. For instance, if a consensus protocol is introduced, latency likely becomes function of number of consensus protocol participants.

#### Roll-up MEV
- We spoke about bootstrap proposers, but what if none of the L2s are willing to use Based Sequencing. This currently is the challenge faced by many shared sequencers as roll-ups are not willing to simply give up the MEV. Why would they? Therefore, any sensible preconfirmation design needs to factor in the incentivization for roll-up adoptions. Naturally Based Sequencing funnels the MEV profit directly to L1 proposers, this might be economically "aligned", but bussiness wise roll-ups need a fair share of the profit as well.

#### Unpredictable L1 Inclusion Rate
- Preconfirmers manage the sequcing of transactions, but they cannot guarantee blob inclusion or the rollup transaction execution in the validating bridge contract until an opt-in proposer's block. In this case, the preconfirmed transactions are at higher risk of being reorged as they are proposed solely through the opt-in proposer's block unless predicatable inclusion rate from the includers.
- Additionally, preconfirmers need to be aware of the blob usage in the past and present to speculate on the likely usage spikes in the near future to not overpay for inclusion and maintain constant roll-up finality rate. When sequencing multiple roll-ups, to cut down the cost, a sophisticated preconfirmer could even [split the blob and share it among multiple roll-ups](https://arxiv.org/pdf/2310.01155.pdf). It goes back to point of preconfirmer sophistication - blob posting strategy requires prowess in financial engineering.

In the following section, we aim to provide a preconfirmation design, by the name of proposer-preconfirmer seperation(hereinafter PPS), that addresses all of the issues above.

[^2]: The design space and implications for Based Sequencing and Based Preconfirmation are still open questions. This article generally follows the implementation guideline laid out in this [research post](https://ethresear.ch/t/based-preconfirmations/17353) and a [series](https://www.youtube.com/watch?v=2IK136vz-PM) of [community calls](https://www.youtube.com/watch?v=mAGGdPRmhsc&t=324s).

## PPS Design

In this design proposal, we aim to provide a mechanism that seperates the task of block proposal and sales of preconfirmations, where the latter is delegated to a newly introduced class of participants - preconfirmers. Preconfirmers, much like block builders, are sophisticated entities managing the sales of preconfirmations for the proposers. Similar to PBS, where block construction is delegated to agents with specialized domain expertise, managing the sales of preconfirmations also requires specialized skills that's fundamentally different than block building.
(Stanley's version: In this design proposal, we aim to provide a practically usable mechanism for based sequencing and preconfirmation that brings minimal UX degradation, maximal incentive alignment among parties, and forward compatibility. The design introduces a new class of participants - preconfirmers, who receive delegation from L1 proposers to sell preconfirmation, playing a similar role to block builders in PBS, hence the name PPS (Proposer-Preconfirmer-Separation). )


### Design goals
1. **Keeping it based**:
We define "based" as having minimal addition to the current L1 consensus so that rollups inherit the liveness and decentralization properties without reliance on entities external to L1. Extra trust assumptions are introduced only when absolutely necessary.
3. **Fair redistribution of value**:
The value generated from ordering roll-up transactions should be fairly redistributed to every participant in the pipeline. This is especially important for key parties like roll-ups to opt-in the design in the first place.
5. **Fast finality**:
We want to provide similar, if not better, experience to roll-up users with the new design, meaning we must achieve fast transaction finality.
7. **Forward compatibility**:
The design should be fundamentally versatile to enable use cases beyond based sequencing and preconfirmation, and be compatible with Ethereum's future plans like PEPC and Execution Ticket.

### System Overview
In PPS, there are three newly introduced components to the Ethereum transaction pipeline
1. <ins>Proposer Commitment-Fullfillment Protocol</ins> to facilitate fullfillment of rollup transaction requests between user and preconfirmer
2. <ins>Preconfirmation Protocol</ins> to enbale fast transaction finality
3. <ins>Trusted L1 inclusion Device</ins> to guarantee preconfirmed transactions' L1 inclusion

**Proposer Commitment-Fullfillment Protocol**
- A commitment-fulfillment scheme for proposers to make bonding commitments to fully programmable execution conditions. The idea is very much similar to [PEPC](https://ethresear.ch/t/unbundling-pbs-towards-protocol-enforced-proposer-commitments-pepc/13879). In the context of PPS, the proposer commitment-fullfillment protocol primarily concerns obtaining of the preferred and often exclusive right to update roll-up smart contracts from the opt-in proposers.

**Precomfirmation Protocol**
- A preconfirmation protocol that allows delegated preconfirmers to return sub second transaction preconfirmations with finality guarantee.

**Trusted L1 Inclusion Device**
- By working with relay, block builders, and other proposers, preconfirmed rollup transactions could be optmistically included to L1 at a stable rate

### Stages

1. <ins>Preconfirmer Registration</ins>
1. Any party who is interested in becoming a preconfirmer is required to purchase the preconfirmer ticket.
2. Tickets are sold one epoch in advance so that the purchasers would know how many opt-in proposers there will be in the immediate next epoch. The maximum number of ticket one could purchase should be equal to the number of opt-in proposers in the epoch.
3. Ticket sales are state transition functions where a dedicated smart contract is required to record state changes. By purchasing the ticket, one gains the right to be drawn as the preconfirmer.
4. To purchase a ticket, one is required to stake. The stake is enforce a slashing mechanism in events of preconfirmer misbehavior

2. <ins>Proposer Registration</ins>
1. Any proposer who wishes to sell preconfirmations could opt-in by restaking on [EigenLayer](https://www.eigenlayer.xyz/). The re-staking is to enforce a slashing mechnaism in event a rogue proposer gives the preconfirmation delegation to a party not selected via the correct preconfirmation selection process [^4].

[^4]: Running an AVS is not the primary purpose for restaking on EigenLayer, thought it might serve some uses cases down the path. The primary purpose for using EigenLayer as the staking protocol is to make use of the validator stakes without creating a seperate staking mechanism that validators have to opt into.

3. <ins>Preconfirmer Selection</ins>

1. The selection process is a lottery system that could be purely based on randomness, or a pseudo-random, merit based lottery system that factors in the past performance of a preconfirmer.
- The performance is evaluated based on on-chain heuristics such as MEV rebate, tips earned, and stake amount, each with different weight assigned.
4. The lottery is drawn via a dedicated smart contract function that queries the history block data through [Axiom](https://www.axiom.xyz/), or Axiom's randomness oracle. The function is invoked at the last block from the previous epoch so that preconfirmation requestors could have far enough lookahead to know who will be the preconfirmer for the next epoch.
6. For example, if there are three opt-in proposers in the next epoch, the lottery will draw three preconfirmers from a pool of ticke holders.
7. For every epoch, so long as there are opt-in proposers, proposer would delegate the right of preconfirmation sales to the selected preconfirmer. If there are no opt-in proposers, the selection rolls over to the next epoch.
8. After the slot, preconfirmer's execution ticket is burned. And the proceeds of the ticket will be distributed to the L2s.
10. To prevent liveness failure, the opt-in proposer could serve as the back-up preconfirmer when the selected preconfirmer goes off-line.

4. <ins>Preconfirmation Sales</ins>

1. There will be a dedicated RPC endpoint that connects the requestor to the selected preconfirmer.
3. The request takes the form of signed transaction, signed tip transfer, and metadata that may include execution conditions, block number, or timestamp. The tip transfer should be conditional upon the execution of signed transaction. The request should also optionally include an expiration timestamp if the request is time sensitive.
4. Upon receiving a request, the preconfirmer has the option to either accept the bid or not. If the preconfirmer decides to accept the bid, the preconfirmer should sign the request and return the signed request back to the bidder. This commitment will be used to challenge the preconfirmer later in event the preconfirmed transaction's condition was not satisfied, be it simple inclusion or stipulated post-state root. A successful challenge would slash the selected preconfirmer for the tip amount plus penalty.

4. <ins>Transaction Sequencing</ins>
1. Preconfirmer precedence is determined by their slot position in the proposer lookahead, with higher precedence given to smaller slot numbers. A transaction with a preconfirmation promise from the next preconfirmer can be included and executed by any proposer ahead of that preconfirmer. Subsequently, the preconfirmer is responsible for fulfilling any remaining promises on their slot using the inclusion list.

5. <ins>Block Auction</ins>
1. Before the block auction, the preconfirmer should share a preconfirmation list that include all the preconfirmed transactions needed to be included into the current block. This list will serve as a transaction prefix that every block builder should include.
2. A special purpose relay would take block submissions from block builders along with a merkle inclusion proof that proves the submitted block indeed includes the transaction prefix. Any block submission that does not include the transcation prefix or misses the merkle inclusion proof would be discarded for the block auction purpose.
3. A rogue opt-in proposer could take blocks from other relays thus sign a block that does not include the transaction prefix. In such event, the rogue proposer would be slashed for misbehavior.

6. <ins>Challenge Mechanism</ins>
1. Other than fraud proof and validity proof that would work as usual, Axiom allows programmable proofs that offer flexibility to design commitment fullfillment paradigms. One of the issues of preconfirmation is that a preconfirmer could preconfirm a transaction but does not honor the commitment. One could query the historical block to attest whethet the preconfirmation promise was fullfilled. Additionally, different types of preconfirmation conditions could also be attested.

### Analysis

#### PPS as a Solution to Proposer Laziness

- The design of PPS is exactly a form of [delegated preconfimration proposed by Justin Drake](https://ethresear.ch/t/based-preconfirmations/17353). One of PPS' main design goals is to simplify proposer's task for managing preconfirmations
- Pricing preconfirmation tips requires real-time quantitative pricing models to ensure that the limited MEV search space does not encroach the overall block reward to the proposer. Proposers, especially solo stakers, are not well equipped to perform such analysis.
- For a proposer to opt-in, the only requirement is restaking. There's no additional software one needs to run, or additional responsibilities to undertake. Any opt-in proposer is not required to choose which preconfirmer to delegate; instead, it's choosen by a state transition function that factors in a multitude of factors for each preconfirmer.
- The preconfirmer set are completely isolated from the opt-in proposer, and proposer needs not to do anything extra than what they are already doing today other than restaking.

#### PPS as a Solution to the Cold Start Problem

- The Ethereum protocol currently has 32 slot lookahead for proposers. Under PPS, because the preconfirmer is selected in advance based on historical performance, or randomly, by a state transition function, the preconfirmer lookahead is totally up to the logic of state transition function. In other words, the preconfirmation epoch could be extended far longer than 32 slots.
- As a result, when initially the opt-in proposers are scarse, the preconfirmer epoch could be extended to a point where we are confident that there will be at least one opt-in proposer per epoch. As more proposers opt in, we could shorten the lookahead period proportionally.

#### PPS as a Solution to Low Latency Preconfirmation

- As there is only one preconfirmer per epoch, it requires no consensus protocol to delay the preconfirmation request and issurance as the communication is done end-to-end.

#### PPS as a Solution to Preconfirmer Designation

- Naturally, block bulider, relay, proposer, or even roll-up operators all have arguments why they should be a preconfirmer. The nice thing about PPS is the design itself is totally neutral as to who should be the preconfirmer.. Any intreested party could opt in to become a preconfirmer. Since the preconfirmation right is purely based on merit, any performant preconfirmer should be able to stay cash positive. The only cost is the opportunity cost of not being able to use the staked ETH else where.

#### PPS as a Solution to Roll-up MEV

- For roll-ups who wants to leverage based sequencing but afraid to due to losing the grip on MEV, PPS supports MEV rebate through the proceeds from ticket sales.

#### PPS as a Solution to Unpredictable L1 Inclusion Rate

- Opt-in proposers could always include blobs or batch from the roll-up their selected preconfirmers sequence, but there are no requirements for includers to do so. As such, preconfirmed transactions will not reach attestation finality for an extended period of time if there are no opt-in proposers.
- Proposers(inclusing non-opt-in proposers, aka includers) could opt into a similar commitment-fullfillment paradigm to sell blob(blob)space futures.
- These proposers have the option to pre-sell block (blob) space for a premium, with preconfirmers handling the task of selling for a portion of the premium.
- Preconfirmers who manage roll-up preconfirmations could determine blob inclusion rate, factoring in the cost and attestation finality rate. If one preconfirmer is tasked to sequence multiple roll-ups, they could manage the blobspace to reduce transaction cost by [spliting blobs](https://arxiv.org/pdf/2310.01155.pdf) and share it for multiple roll-ups.

#### Fee Breakdown
- In addition to the execution fees, rollups will receive the proceeds from preconfirmation ticket. Since the ticket price adjusts dynamically depending on the demand by the preconfirmers, whose primary motivation is to capture rollup MEV, ticket proceeds can be viewed as a form of MEV rebate indirectly.
- Proposers will receive the preconfirmation tips from the preconfirmers
- Preconfirmers has the right to sequence multiple rollups, enabling them to capture MEV from both single and cross-domain transactions across various rollups..