EIP-7917: Deterministic proposer lookahead

EIP-7917: Deterministic proposer lookahead Lin Oshitani (Nethermind Research), Justin Drake (EF)

Outline - What are based rollups/preconfirmations. - Lookahead access in EVM issue. - Lookahead instability issue. - Details of EIP-7917.

Background: Based Rollups and Preconfirmations

What are Rollups? - Rollups scale by posting tx data to L1 but executing them in L2. - So L1 blocks contain L2 blocks, like this: L1 Block L2 Block

What are Rollups? - Rollups scale by posting tx data to L1 but executing them in L2. - So L1 blocks contain L2 blocks, like this: L1 Block L2 Block Who builds this?

Centralized Sequencers tx tx Centralized Sequencer L2 Block Users tx Proposer L2 tx L1 Block L2 Block

Centralized Sequencers tx Centralized Sequencer preconf L2 Block Users Proposer Centralized sequencers can provide "preconfirmations" L1 Block L2 Block

What are Preconfirmations? tx_C Users Centralized Sequencer Time passes Centralized Sequencer preconf Proposer I will promise to include your tx_C at the third position in the L2 block after tx_A and tx_B L1 Block Included in the promised position tx_A, tx_B, tx_C, ...

Centralized Sequencers tx Centralized Sequencer preconf L2 Block Users Proposer Centralized sequencers are great! They bring fast UX However, they are centralized. How do we decentralize? L1 Block L2 Block

Based Rollups tx Users Proposer L1 proposer sequence the L2 blocks. L1 Block L2 Block

Based Rollups tx Users Proposer Based rollups are nice! They: - Inherit L1 censorship resistance and liveness. L1 Block - Enable L1 composability. L2 Block

Based Rollups tx Users Proposer However, this is slow! We must wait L1 block time (12s). How can we make them faster? L1 Block L2 Block

Based Preconfirmations tx Users Preconf Proposer Have the L1 proposer provide preconfirmations. L1 Block L2 Block

Based Preconfirmations tx Users Preconf Proposer Need proposers to explicitly opt-in since they need to be exposed to slashing to disincentivize equivocation. L1 Block L2 Block

Based Preconfirmations Send tx to the next opted-in proposer (= preconfer) Users tx preconf P1 (non-preconfer) current proposer P2 (non-preconfer) P3 (preconfer)

Based Preconfirmations Users tx preconf P1 (non-preconfer) P2 (non-preconfer) B1 B2 P3 (preconfer) B3 Eventually, the preconfer proposes an L1 block that includes the L2 block containing the preconfed txs.

Based Preconfirmations For based preconfrimations, it is important to know the proposer schedule (= the "lookahead")! Users tx preconf P1 (non-preconfer) P2 (non-preconfer) B1 B2 P3 (preconfer) B3

Lookahead Availability in EVM issue

Proposer Lookahead At the start of each epoch (=32 slots) we have visibility of two epochs worth of proposers. This means you always have at least 32 slots worth of lookahead. (kind of, more on this later) P0 Epoch boundary P1 P30 P31 P32 Epoch boundary P33 P62 P63 Slots

Lookahead check in Inbox For based rollups with preconfs, we want the L2 block inbox contract to limit batch submission to the next opted-in proposer in the lookahead.

Lookahead check in Inbox For based rollups with preconfs, we want the batch inbox contract to limit batch submission to the next opted-in proposer in the lookahead. How do we implement this?

Lookahead Availability in EVM In EVM, only past proposers are visible via historical beacon roots. Current and future proposers are not accessible. Current slot P0 P1

Optimistic Lookahead Scheme In Taiko+Nethermind preconf work, the first preconfer of epoch optimistically posts lookahead for next epoch to an L1 contract. The submitter is retroactively slashed if lookahead is incorrect First preconfer in epoch P0 P1 P30 P31 Post lookahead P32 P33 P62 P63

Lookahead Instability Issue

Lookahead Instability This lookahead is mostly accurate. But can change in certain edge cases! P33' P0 Epoch boundary P1 P30 P31 P32 Epoch boundary P33 P62 P63 Slots

How the Lookahead is Calculated Epoch boundary P0 Epoch boundary P1 P30 P31 P32 P33 Two factors are used to calculate the lookahead: - The RANDAO. - The effective balance (EB) of validators. P62 P63

How the Lookahead is Calculated Epoch boundary P0 Epoch boundary P1 P30 P31 P32 P33 P62 Calculate this lookahead P63

How the Lookahead is Calculated Epoch boundary P0 Epoch boundary P1 RANDAO from here P30 P31 P32 P33 P62 P63

How the Lookahead is Calculated Epoch boundary P0 Epoch boundary P1 RANDAO from here P30 P31 P32 EB from here P33 P62 P63

Lookahead Instability Epoch boundary P0 Epoch boundary P1 P30 P31 P32 EB can change here! RANDAO from here EB from here P33 P62 P63

Lookahead Instability Epoch boundary P0 Epoch boundary P1 P30 P31 P32 EB can change here! RANDAO from here EB from here P33' P33 P62 P63

Lookahead Instability Epoch boundary P0 Epoch boundary P1 P30 P31 P32 P33 P62 P63 EB can change here! RANDAO The unpredictability is worsen due to increase of Max EB (EIP-7251) from here as EBs of active validators can grow beyond 32 ETH.

Is it an issue? - From priliminary analysis, lookahead change due to EB change remain rare. - Even if rare, these reward-based lookahead changes are not provable on-chain, unlike slashing events. Consequently, the optimistic lookahead scheme breaks, as we risk incorrectly slashing honest lookahead submitters.

What we have Epoch boundary P0 Epoch boundary P1 RANDAO from here P30 P31 P32 EB from here P33 P62 P63

What we get Epoch boundary P0 Epoch boundary P1 RANDAO from here P30 P31 P32 EB from here P33 P62 P63

How we get it Introduce a proposer_lookahead field to the beacon state. Pre-calculate and store the next epoch lookahead at epoch boundary.

How we get it Introduce a proposer_lookahead field to the beacon state. Pre-calculate and store the next epoch lookahead at epoch boundary. Because it's in the beacon state, it is accessable in EVM via beacon root.

How we get it At start of each epoch, the proposer_lookahead is updated by shifting out the previous epoch’s lookahead and appending the new one to the end. Before epoch boundary: - state.proposer_lookahead = [28, 94, .., 63, 81, 40, ..., 33] After epoch boundary: - state.proposer_lookahead = [81, 40, ..., 33, 47, 89, …, 12] calculate new epoch proposers

Conclusion

Conclusion EIP-7917 is a relatively simple change: - 22 lines of spec change ignoring comments. With large benefits: - Unlocks robust preconfirmation protocols by making a stable lookahead that is available in the EVM via beacon root, completely removing the need of "hacks" such as the optimistic lookahead scheme. - Simplifying the proposer scheduling protocol, which simplifies security analysis and CL code. - It feels natural.