Preconf Lookahead and MaxEB

Preconfirmations rely on reliably accessing the proposer lookahead. However, Ethereum currently does not allow reliable retrieval of the lookahead for epoch N+1 during epoch N, which becomes problematic when looking up the next preconfer at epoch boundries. This issue is potentially exacerbated by the increasing MaxEB parameter (EIP-7251). This document outlines the problem to initiate discussion on potential solutions.

Background: Preconfs

In based preconfirmations, the next opted-in proposer within the L1 lookahead provides preconfirmations, as illustrated below:

Therefore, reliably retrieving the lookahead information is crucial for preconfirmation systems. Users rely on this data to identify the next expected preconfirmer, and preconfirmers depend on it to accurately determine when they should begin their preconfirmation duties.

Problem: Lookahead in Epoch Boundries

Things work well when the next preconfer is within the lookahead of the current epoch. However, complications arise if no preconfer exists in the remaining lookahead of the current epoch, forcing users/preconfers to examine the next epoch's lookahead to determine the upcoming preconfirmer.

(Note: I am writing the above paragraph based on limited understanding of EIP-7251 and CL specs in general, let me know if I got anything wrong.)

Open Questions

• Can EB change at epoch boundry due to deposits/withdrawals? Or only via slashing and rewards?
• Is it possible/feasable to change the CL specs to enable stable lookahead for next epoch? Maybe at epoch boundries, reflect the EB changes after calculating the lookahead for the epoch?

Appendix: Possible Mitigation without CL changes

The first preconfirmer in an epoch is assigned to the Epoch Bridge Preconfirmer (EBP), selected via RANDAO from the set of opted-in proposers. We give the EBP enough "buffer", and during the buffer the EBP can broadcast a "handover" signed commitment that hands over the preconfing right to the next preoconfer in the lookahead. Since the next preconfer is in the same epoch, it should be reliably retrievable.

However, this approach has the following downsides due to the fact that the EBP most likely isn't the proposer during the given buffer period:

• They cannot directly ensure the inclusion of preconfirmed transactions into L1 blocks, necessitating a buffer period to enable mempool inclusion.
  • Even with a buffer, transaction inclusion isn't guaranteed, hence increasing the risk of preconfirmation faults due to failures to include preconfirmed transactions on L1.
• They cannot provide L1↔L2 composability guarantees, as they do not control any of the L1 blocks during their assigned slots.