# PEEPanEIP-7917: Deterministic proposer lookahead

Justin Drake & Lin Oshitani in conversation with Pooja Ranjan

## Ethereum's Pre-Confirmations and Base Roll-Ups
Justin provides context on Ethereum's goals, focusing on security, scaling, and reducing transaction latency. He explains the [concept of pre-confirmations](), which allow users to receive promises about transaction inclusion backed by collateral. Lin then [presents on EIP-7917](), discussing base roll-ups and pre-confirmations in detail. He explains how base roll-ups decentralize the sequencing process by having L1 proposers sequence on L2 blocks. Lin highlights the challenge of implementing pre-confirmations in base roll-ups due to the need for proposer lookahead information, which is not readily available in the EVM. He introduces an optimistic lookahead scheme as a potential solution, where the first pre-confirmer of an epoch posts the lookahead for the next epoch to an L1 contract.

## Lookahead System Stability and Slashing
Lin discussed two issues with the lookahead system.
* The first issue was the **lookahead availability in EVM**.
* The second issue was the **lookahead instability problem**, which occurred when the effective balance of validators changed during an epoch.

This could lead to retroactive slashing of submitters when the lookahead was incorrect, incorrect slashing of honest entities, which would discourage the adoption of pre-confirmations.

Lin proposed a solution, [EIP-7917](https://eips.ethereum.org/EIPS/eip-7917), which would align the random number and effective balance used to calculate the lookahead, reducing the instability.

## Proposer Lookahead in Beacon State
Lin introduced **a new field added** with the EIP **in the Beacon State**, which stores information like the current slot and validator set. This field, called **proposer lookahead**, is pre-calculated and stored at the epoch boundary. The Beacon State is accessible via the EVM through the beacon root. The lookahead is updated by shifting out the previous epoch's lookahead and updating the new one at the end of each epoch.

This change is relatively simple but has large benefits, including unlocking robust pre-confirmation protocols and simplifying the proposer scheduling protocol. The change was well-received, with one architect calling it a natural change.

## Pre-Confirmation Latency and UX Improvements
Alex, a participant of the call inquired about **the expected pre-confirmation times in real-world conditions and the primary factors influencing actual latency**.

Lin explained that the pre-confirmation protocol's speed depends on the design, and theoretically, it could be as fast as the speed of light. Justin clarified that the total response time for pre-confirmation is one ping time plus one tick, and the total latency would be about 200 ms if one ping time is roughly 100 ms and one tick is also roughly 100 milliseconds.

Simona asked about the **steps needed after the EIP implementation for faster perceived transaction times** to become widely noticeable in wallets and apps. Lin responded that the primary use case right now is L2 pre-confirmations, and the faster UX would be comparable to current optimism or arbitrum. Justin added that there are two pathways to getting pre-confirmations, either through a base roll-up or a centralized sequencer.

## Decentralized Sequencer for Shared Sequencing
Justin discussed the need for a decentralized sequencer to facilitate shared sequencing among roll-ups, such as Optimism and Arbitrum, to unlock network effects. He proposed Ethereum as a neutral option. Pooja asked about the feasibility of a longer lookahead window, to which Justin responded that it's possible but could affect validator exit speed. He suggested a longer lookahead could be useful for building long-dated futures and hedging against base fee variations. Justin also mentioned the need for a certain percentage of proposers to opt in for preconfirmations to get them off the ground.

## Randao Value Calculation and Pre-Conf Discussion
Lin explained the calculation of the Randao value, which is taken from the epoch boundary before P0. The value is mixed into the Randao mix, making it unpredictable to the world except for P0. Lin also clarified that the discrepancy between the Randao value and the effective balance snapshot is a bug that was discovered post facto. Pooja added that there is [an episode with Mikhail K.](https://www.youtube.com/watch?v=wwfOqmCbPNU
) **that explains the calculation of Randao**.

Pooja also asked about the **consideration of possible attacks** in the proposal, to which Lin responded that the lookahead is already available in the network and the EIP doesn't worsen the situation.

Titi, a particpant of the call asked about the edge case in which the block would be full, to which Lin responded that the pre-conf can spread out the auto block inclusion throughout the allocated slots. Justin added that there will be another pre-confe after p3.

## Proposer Role and Lookahead Updates
Lin clarified that a proposer scheduled for a pre-confirmation cannot renounce their role, as it is a deterministic process. However, in a small edge case, it might be possible to change the effective balance to avoid being a proposer. Lin also mentioned that increasing the granularity of the lookahead updates from epochs to slots could help with predictability.

## Ethereum's Future and Rollups Discussion
Justin and Lin discussed the future of Ethereum and rollups. Justin believes rollups are necessary for Ethereum's future due to L1 bottlenecks, estimating L2s will provide 1000 times more capacity than L1. Lin shares his experience writing his first EIP and expresses excitement about participating in Ethereum's development. Both are optimistic about Ethereum's future, with Justin predicting significant growth in value and adoption. They encourage support for the EIP and its inclusion in the next hard fork.

Note: This is AI generated summary with high level edits.