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
  • 2025-04-15: PEEPanEIP EIP-7917: Deterministic proposer lookahead: Video
  • 2025-05-29: EIP-7917 SFI’d for Fusaka with target of fusaka-devnet-1 in ACDC #158: Summary

External Reviews

Outstanding Issues

None as of 2025-03-25.

7 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:

6

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

1 Like
7

Does this EIP imply that implementation of Whisk/SSLE is not going to be possible?
Attack on proposers is considered in the EIP from RANDAO perspective but DoS is also a potential issue

8

Thanks for the questions! Both good points worth clarifying here.

Does this EIP imply that implementation of Whisk/SSLE is not going to be possible?

Not really. Many SSLE constructs do not remove the lookahead but rather replace it with an encrypted one. This EIP will be fully compatible with this, as it can just be a “deterministic encrypted lookahead.” There’s also a deeper question about combining preconfirmations with SSLE, though. Technically, they can coexist—for instance, by having the SSLE proposer reveal themselves with a ZK proof (as suggested by Justin in the original preconf post). It is also worth noting that APS envisions more sophisticated (i.e., more DDoS‑resistant) execution proposers, reducing the need for SSLE.

Attack on proposers is considered in the EIP from RANDAO perspective but DoS is also a potential issue

Is this about SSLE being important for DoS prevention and concern that this EIP will block it? If so, it is answered above.

If it’s about the concern of having a more deterministic lookahead leading to more DoS vectors (a common question we get), this EIP doesn’t really “increase” the DDoS attack surface. A very high approximation of the next epoch lookahead is already visible in current-day Ethereum, as EB usually doesn’t change during epochs. This EIP simply makes this “very high approximation” to “deterministic”.

1 Like
9

Thank you very much for the quick and thorough answer!

I see it doesn’t make such a difference in practice compared to current situation, got it. There haven’t been much work on Whisk recently so I see the SSLE should to be updated to accommodate preconfs

1 Like
10

If deterministic look-ahead lets a builder know—or at least strongly expect—that it will win several consecutive payloads, could it game the fee-adjustment logic (base-fee or blob-fee) by nudging the values up or down over that streak to boost its own revenue at users’ expense?

1 Like
11

I belive this answer above is also relevant to your question:

If it’s about the concern of having a more deterministic lookahead leading to more DoS vectors (a common question we get), this EIP doesn’t really “increase” the DDoS attack surface. A very high approximation of the next epoch lookahead is already visible in current-day Ethereum, as EB usually doesn’t change during epochs. This EIP simply makes this “very high approximation” to “deterministic”.

So right now, in current-day Ethereum, we already have an “almost” deterministic lookahead, this EIP just changes that to “completely” deterministic. So whatever exploitation vector exists with having a visible and public lookahead existed before this EIP and will continue to exist after this EIP. There are discussions about mitigating the exploitation vector via public lookaheads (e.g., SSLE, shorter lookahead, etc) but those are independent discussions from this EIP I would say.

1 Like
12

This makes a lot of sense - thanks!

… absolutely. This EIP just made me think about it again :smiley:

1 Like