EIP-7917: Deterministic proposer lookahead

[linoscope]

Edit: Ethereum Magicians post for any general discussion around the EIP: https://ethereum-magicians.org/t/eip-7917-deterministic-proposer-lookahead/23259

Currently, the proposer lookahead for the next epoch is unstable because the effective balance (EB) may change before the next epoch due to slashing events, deposits, or withdrawals occurring in the current epoch. The recent increase in the maximum EB further exacerbates this instability, as EB can now exceed the previous 32 ETH cap. This instability complicates the operation of preconf protocols, as described in this document: https://hackmd.io/@linoscope/preconf-lookahead

In this PR, we address this issue by stabilizing the proposer lookahead for the next epoch. We achieve this by calculating and recording the lookahead for epoch N+1 in the beacon state at the beginning of epoch N.

Furthermore, a highly valuable side effect of this approach is that the proposer lookahead becomes available within the beacon state, making it possible to retrieve the lookahead in the EVM using the beacon root and Merkle proofs. Having direct access to lookahead in the EVM greatly simplifies implementing the on-chain components of preconf protocols.

TODO:

• Add more text to the specs
• Add more tests (EB changes, fork activation transition, etc).
• Assign a proper EIP number

[ralexstokes]

an immediate step will be targeting fulu instead of electra :)

[linoscope]

an immediate step will be targeting fulu instead of electra :)

Ah, thanks for pointing out. Fixed in 0a37fe7

[JustinDrake]

Great job Lin :)

[mkalinin]

Proposer lookahead is a new constraint for the protocol which for instance constraining approaches with secret leader election that has been explored in the past. If we accept this change, we should explicitly mention that we give up on anything like SSLE unless I misunderstood something

[linoscope]

Proposer lookahead is a new constraint for the protocol which for instance constraining approaches with secret leader election that has been explored in the past. If we accept this change, we should explicitly mention that we give up on anything like SSLE unless I misunderstood something

Thanks for bringing this up! Indeed, SSLE is something to consider - But I am not sure if we have to go so far as to "give up" on SSLE with this change. This PR is just making the existing design of having multiple epochs worth of lookahead (having MIN_SEED_LOOKAHEAD) more explicit. If we are to implement SSLE, we will have to drastically change how the proposer_lookahead field is handled or even deprecate it, and all preconf protocols will need to adjust. But they will have to make drastic changes anyway with SSLE regardless of this, so I don't think it's a blocker on the preconf protocol side. Or do you see this being a potential blocker on the CL/spec side for SSLE?

[mkalinin]

Or do you see this being a potential blocker on the CL/spec side for SSLE?

Each new protocol constraint is hard to remove when it becomes a downstream dependency. One of the ways to go would probably be to say that there can be no lookahead if SSLE is introduced in the future, explicitly emphasising that this feature is unreliable long term

[linoscope]

Each new protocol constraint is hard to remove when it becomes a downstream dependency.

Makes sense, rather than removing the field, just having an empty list for proposer_lookahead would be better in terms of downstream impact. And that is exactly what SSLE is anyway, having zero lookahead.

One of the ways to go would probably be to say that there can be no lookahead if SSLE is introduced in the future, explicitly emphasising that this feature is unreliable long term

This makes sense too, and I agree it's worth mentioning in specs and EIP. Thanks for the feedback!

[potuz]

Is there a security analysis anywhere for this feature? There are good descriptions of the current mechanism on @benjaminion
book https://eth2book.info/capella/part2/building_blocks/randomness/ and @vbuterin https://notes.ethereum.org/@vbuterin/SkeyEI3xv#Aside-RANDAO-seeds-and-committee-generation and https://web.archive.org/web/20160723105229/https://vitalik.ca/files/randomness.html

Describing how the preferred solution would be to get proposal rights JIT, which this PR takes us further away from it.

Besides a security analysis of knowing the proposing schedule ahead of time, I agree with @mkalinin that this proposal seems to give up on SSLE as it's currently developed.

[terencechain]

Side note: wondering if it makes sense to update get_beacon_proposer_index to use state.proposer_lookahead feels like a nice optimization here

[linoscope]

Thanks for the feedback @potuz !

Is there a security analysis anywhere for this feature? There are good descriptions of the current mechanism on @benjaminion book https://eth2book.info/capella/part2/building_blocks/randomness/ and @vbuterin https://notes.ethereum.org/@vbuterin/SkeyEI3xv#Aside-RANDAO-seeds-and-committee-generation and https://web.archive.org/web/20160723105229/https://vitalik.ca/files/randomness.html

Describing how the preferred solution would be to get proposal rights JIT, which this PR takes us further away from it.

Yeah, security definitely needs consideration, and I’ll add a section in the upcoming EIP. In short, this proposal does not alter the “RANDAO delay” used in the lookahead—the lookahead of epoch N is still determined by the RANDAO of epoch N - MIN_SEED_LOOKAHEAD - 1 (which becomes available at the start of epoch N - MIN_SEED_LOOKAHEAD). The only difference is that it changes the “effective balances delay”: rather than using the effective balances (EB) at the start of epoch N, it now uses the EB at the start of epoch N - MIN_SEED_LOOKAHEAD.

And actually, by aligning the RANDAO and effective balances in this way, the proposal removes any chance of validators adjusting their EB after seeing the RANDAO outcome, which is an attack vector to consider. No such attack has been found so far, but this change removes the possibility, hence simplifying the security analysis.

Besides a security analysis of knowing the proposing schedule ahead of time, I agree with @mkalinin that this proposal seems to give up on SSLE as it's currently developed.

I don’t think we need to "give up" on SSLE. From what I’ve heard, the currently proposed SSLE constructions still include a lookahead, albeit an encrypted one. In those designs, we could reuse the proposer_lookahead field by changing its type to something like List[EncryptedValidatorIndex]. And if a construction were to remove lookahead entirely, we could simply set proposer_lookahead to an empty list, meaning this wouldn’t be a blocker.

That said, any such changes would introduce additional complexity around preconfs, but that complexity arises regardless of this change.

[linoscope]

Side note: wondering if it makes sense to update get_beacon_proposer_index to use state.proposer_lookahead feels like a nice optimization here

Makes total sense! And actually we already do this here: https://github.com/ethereum/consensus-specs/pull/4190/files#diff-bcf6567bc8bd905058f44340eeb4ec690c396543644748b7fb5918e4e4d15141R193

[dapplion]

RE SSLE: The key feature of secret leader election is: "the proposer at slot N is only known by the proposer at slot N with some lookahead". Then no-one can DoS the proposer, only if the proposer keeps its proposal slot private. This is completely opposite to the pre-confirmation requirement: "users (i.e. everyone) know the proposer at slot N with some lookahead".

If we enshrine the users' need to know the proposer ahead of time, under SSLE the proposer will be incentivized to make its proposal public. Implementing SSLE under this reality is technically possible but probably useless. Unless there's some intermediary that's doubly trusted (i.e. the builder) to whom the proposal can reveal its proposal slot, and then the builder somehow handles the pre-conf.

[linoscope]

RE SSLE: The key feature of secret leader election is: "the proposer at slot N is only known by the proposer at slot N with some lookahead". Then no-one can DoS the proposer, only if the proposer keeps its proposal slot private. This is completely opposite to the pre-confirmation requirement: "users (i.e. everyone) know the proposer at slot N with some lookahead".

If we enshrine the users' need to know the proposer ahead of time, under SSLE the proposer will be incentivized to make its proposal public. Implementing SSLE under this reality is technically possible but probably useless. Unless there's some intermediary that's doubly trusted (i.e. the builder) to whom the proposal can reveal its proposal slot, and then the builder somehow handles the pre-conf.

Hi @dapplion , thanks for the comment! While I don’t think this EIP truly “blocks” SSLE (as mentioned here), I agree that the interaction between preconfs and SSLE is an interesting topic in its own right. As you mention, while it is possible to have preconfs and SSLE co-exist by having the proposer intentionally reveal their identity (e.g., by providing a ZK proof that they are the next preconfer as suggested by Justin), as you say incentivizing that does seem to defeat the purpose of SSLE, at least to some extent.

However, with APS we kind of get the "have only the builder reveal their identity for preconfs" thing you mention. The execution proposer, likely a builder or some sophisticated auctioneer, will have the capacity to handle DDoS. Consequently, protecting the proposer becomes less critical—one reason I’ve heard SSLE isn’t considered a top priority right now.

[linoscope]

I have created an Ethereum Magicians topic on this EIP here: https://ethereum-magicians.org/t/eip-7917-deterministic-proposer-lookahead/23259

Feel free to post any questions/comments/suggestions there, any input is highly appreciated!

[dapplion]

However, with APS we kind of get the "have only the builder reveal their identity for preconfs" thing you mention. The execution proposer, likely a builder or some sophisticated auctioneer, will have the capacity to handle DDoS. Consequently, protecting the proposer becomes less critical—one reason I’ve heard SSLE isn’t considered a top priority right now.

Agree, I don't want to block pre-confs on SSLE given current trends and reality

[linoscope]

Thanks everyone for the feedback so far! I have added two more tests:

• Test that the pre-Fulu "approximation" lookahead matches the post-Fulu state.lookahead at the fork boundary: Commit Link (83daa1e)
• Test that attestation rewards alter next-epoch lookahead pre-Fulu, but leave it unchanged post-Fulu: Commit Link (b1b0144)

Now I have covered the test cases I initially had in mind, and the PR is ready for another round of reviews. Any feedback is welcome 🙂