Title: EIP_7917__Deterministic_proposer_lookahead
Category: EIPs

Author: linoscope
Date: 2025-03-25T12:27:07.235Z

Discussion topic for EIP-7917: Deterministic proposer lookahead


Ethereum Improvement Proposals


EIP-7917: Deterministic proposer lookahead
Pre-calculate and store a deterministic proposer lookahead in the beacon state at the start of every epoch





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

2025-03-23: Discussion around the feature starting in consensus-specs/pull/4190

Outstanding Issues
None as of 2025-03-25.

Author: dantaik
Date: 2025-03-27T10:48:39.066Z

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.

Author: linoscope
Date: 2025-03-27T15:35:40.769Z

dantaik:

Let’s support its inclusion in the Pectra upgrade.


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

Author: dapplion
Date: 2025-04-02T19:24:36.575Z

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.


HackMD



EIP-7917: How often does it help? - HackMD
Beacon proposers are selected with this function





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?

Author: linoscope
Date: 2025-04-03T11:03:27.584Z

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:



HackMD



EIP-7917 from a Preconf Protocol Perspecitve - HackMD
What happens if we don't have a

Author: poojaranjan
Date: 2025-04-30T14:17:55.335Z

PEEPanEIP-7917: Deterministic proposer lookahead with @linoscope & @JustinDrake