EIP-7917 from a Preconf Protocol Perspecitve

This document explains the issues faced by preconfirmation protocols due to limited visibility of upcoming proposers in Ethereum's current EVM setup. It describes how lookahead instability affects impacts current solutions, particularly after recent Max EB increase. Finally, it highlights how EIP-7917 addresses these issues by directly providing stable and accessible lookahead data to the EVM.

Background: Preconfs

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

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

Problem: Lack of Visibility on Lookahead

In the inbox contract (where L2 blocks are submitted) of a based rollup, we want to check if the submitter is the next opted-in proposer in the lookahead, like this:

The challenge arises in implementing the lookahead.getNextPreconfer() function within the EVM. Currently, only past proposers are visible through the beacon root. The EVM does not provide access to current or future proposers.

Optimistic Lookahead Submission

In our Taiko preconf PoC , we addressed this visibility issue by having the first preconfirmer of an epoch optimistically submit the lookahead for the next epoch. Because past proposers can be verified in the EVM through the beacon root, the submitted lookahead can be retroactively checked, allowing for slashing of dishonest lookahead submissions.

Lookaheas Instability

In Ethereum's beacon chain, the RANDAO value at the end of epoch N-1 determines validator duties for epoch N+1. Since the lookahead is computed based on the RANDAO, during epoch N it's possible to estimate the lookahead for epoch N+1.

However, this is only an approximate estimation. The exact lookahead for the next epoch isn't available in advance because validators' effective balances can change at the epoch boundary, altering the final lookahead.

This issue was relatively minor before the Electra upgrade, as effective balance changes primarily occurred through slashing events, which are:

• Infrequent.
• Easily detectable via the Validator.slashed field on the beacon chain, preventing incorrect slashing of honest lookahead submitters.

Avoiding incorrect slashing is crucial, as penalizing proposers for events beyond their control would harm the adoption of preconfirmations.

Impact MaxEB Increase

Following the introduction of Max Effective Balance (EIP-7251), effective balances can now increase due to rewards or deposits beyond the previous 32 ETH cap. As a result, non-slashing activities, like attestation rewards, can alter the lookahead.

Although lookahead-altering effective balance changes remain rare—as detailed by dapplion here—the significant issue is that these reward-based lookahead changes are not provable on-chain, unlike slashing events. Consequently, the optimistic lookahead submission approach breaks, as we risk incorrectly slashing honest lookahead submitters.

How EIP-7917 Helps Preconfs

EIP-7917 resolves these issues by eliminating lookahead instability altogether. More importantly, it removes the need for optimistic lookahead submission or other "hacks" to achieve lookahead visibility in the EVM. Under EIP-7917, lookahead data will be directly stored in the beacon state, making it accessible in the EVM via the beacon root and Merkle proofs.

Other Reasons For EIP-7917

Introducing a fully deterministic lookahead fixes a long-standing beacon chain design oversight, as highlighted by Danny Ryan’s comment below:

In general I belive it is a natural engineering improvement to the protocol, and simplifies security analysis of the protocol (e.g., checkign that no EB grinding attack are possible) and may simplify the CL implementation as they no longer have to care about the (very rare) edge case of lookahead changes at epoch boundry.