EIP-7917: Deterministic proposer lookahead

EIPs EIPs core
1

Discussion topic for EIP-7917: Deterministic proposer lookahead

Summary

This EIP ensures that the proposer schedule for upcoming epochs is determined and stored in the beacon root at the start of each epoch. By introducing a deterministic proposer lookahead, it eliminates unpredictable changes to the next epoch’s lookahead stemming from effective balance fluctuations (e.g., due to slashings, penalties, or increased validator balances)—an issue exacerbated by EIP-7251’s MaxEB increase. As a result, preconfirmation protocols reliant on a stable, predictable proposer schedule can operate more securely and with less complexity. It also enables straightforward on-chain access to the proposer lookahead via the beacon root, which highly simplifies the on-chain component of preconfirmation protocols. Furthermore, it removes a potential source of grinding attacks via effective balance changes, and potentially simplifies client implementations for lookahead handling.

For more details, refer to the EIP or the consensus-spec changes.

Update Log

  • 2025-03-20: Issue around lookahead instability through MaxEB and it’s impact to preconfs discussed: Fabric Call #001
  • 2025-03-23: Consensus spec change PR opened: consensus-specs/pull/4190
  • 2025-03-24: EIP PR opened: EIPs/pull/9530
  • 2025-03-24: EIP presented: Fabric call #002
  • 2025-03-24: Thread by author summarizing the EIP: Post
  • 2025-03-25: Thread by author answering frequently asked questions: Post

External Reviews

Outstanding Issues

None as of 2025-03-25.

4 Likes
2

Thanks to Lin and Justin for authoring this EIP. It’s a critical piece for enabling based preconfirmation. Let’s support its inclusion in the Pectra upgrade.

1 Like
3

Thanks for the support! (I guess you meant Fusaka, which is the earliest this could be in :slightly_smiling_face:)

1 Like
4

Hey! Neat proposal. I strongly support modifying the protocol to best support based and native rollups. Offering fast and reliable pre-confirmations is a key part of that. However, it appears that the chance the function compute_proposer_index (Electra spec) returns distinct proposers is extremely low (less than once per year).

I ran the numbers here and got very low probabilities of the effective balance change causing issues.

Some questions:

  • How much lookahead do you estimate pre-conf users would need? Giving
  • Is a failure rate of 0.0001% acceptable?
  • Another source of instability, how will you handle missed slots?
  • Quoting from the EIP “This highly simplifies the implementation of on-chain components for based preconfirmation protocols.” can you detail how?
1 Like
5

Hi @dapplion , thanks a lot for the detailed writeup! Good to have these concrete numbers, it really helps. However, even if the possibility of lookahead change is very rare, as long as the possibility is non-zero it remains problematic for preconf protocols, at least in our current design. To explain, some context around lookahead handling in preconf protocols is needed, so wrote this document to provide that: