EIP-7045 Raising the attestation inclusion slot limit (Increase max attestation inclusion slot)
Final · Consensus & staking · EIP status Final · created 2023-05-18
Extends the window in which a beacon chain attestation can be included in a block from one epoch after creation to the end of the next epoch. This change is needed for the LMD-GHOST security analysis and the fast finality rule.
Why it is needed
Until now, an attestation made by a validator could be included in a block only from the minimum delay (1 slot on mainnet) until SLOTS_PER_EPOCH slots had passed from the creation slot. Giving every attestation an inclusion window of the same length was settled in Phase 0 on the judgment that it is "fair." The alternative considered at the time was to allow inclusion during the current epoch and the next epoch, but then an attestation made early in an epoch would get more chances to be included than one made late in the epoch. However, later research showed that this very alternative design is essential for the current LMD-GHOST security proof and the new finality rule (finalizing a block within about 3 to 4 slots on mainnet under normal conditions). This EIP extends the maximum inclusion slot of attestations to meet that requirement.
What changes
Today
- An attestation can be included in a block only until SLOTS_PER_EPOCH slots after its creation slot
- The inclusion window has the same length wherever in the epoch the attestation was made
- If inclusion is delayed, even a correct target vote may not receive the TIMELY_TARGET_FLAG reward
After EIP-7045
- An attestation made in epoch N can be included up to the last slot of epoch N+1
- The earlier in an epoch an attestation is made, the more chances it has to be included
- A correct target vote receives a nonzero base reward regardless of when it is included
- Gossip propagation is also allowed to match the extended range
Who is affected
- Validators: An attestation that propagates late because of network delays and similar causes can still be included until the end of the next epoch and receive the target reward.
- Client teams: The consensus layer's state transition function and gossip validation conditions must be modified, and the change must be applied together with a hard fork.
- Users and applications: Once the finality rule this change supports is applied, block finality can be confirmed within about 3 to 4 slots under normal conditions.
- Execution layer: There are no changes to the Execution Layer.
In depth
process_attestation change: remove the upper bound check
In the state transition function, remove the slot upper-bound check from process_attestation. Instead, define the inclusion range with two conditions. One is a minimum slot (minimum delay), and the other is that the attestation's target epoch must be the current epoch or the previous epoch. An attestation from epoch N remains valid until the end of epoch N+1, that is, while its target epoch is the 'previous epoch', so the inclusion range is bounded by the last slot of epoch N+1 even without a separate upper bound. This change is included in the Deneb upgrade of Consensus Specs.
Modify get_attestation_participation_flag_indices: exclude inclusion_delay from the target reward
Previously, get_attestation_participation_flag_indices set TIMELY_TARGET_FLAG only when the attestation was included within the SLOTS_PER_EPOCH window, and this flag was required for a correct target vote to earn a reward. This EIP removes the inclusion_delay consideration from setting TIMELY_TARGET_FLAG. As a result, a correct target vote always receives a nonzero base reward as long as it falls within the valid inclusion window. The reward gives clients an incentive to include such attestations in blocks, and this matters for the security analysis. The original text explains that this was the intended behavior under the previous range definition as well.
Expanded gossip conditions
If only the state transition rules change, attestations in the extended window may fail to propagate across the network. The EIP therefore also modifies the validation conditions for individual attestation gossip (the beacon_attestation subnet) and aggregate attestation gossip (beacon_aggregate_and_proof), so that attestations are allowed to propagate by gossip throughout the expanded inclusion range.
Why this range matters for security
Extending the inclusion upper bound to the end of the next epoch is a prerequisite for the security proof of the current LMD-GHOST fork choice rule to hold. The newly proposed confirmation rule also assumes this range, and once it is applied, blocks can be confirmed within about 3 to 4 slots under normal mainnet conditions. The Security Considerations section of the original text states that this change improves LMD-GHOST security, enables a fast confirmation rule, and has no known negative security impact.
Why a hard fork is needed and when it applies
This change alters the consensus layer's block validation rules in a way that is not backward compatible, so it must be applied together with a hard fork. The specification was included in the Deneb upgrade, and the mainnet FORK_TIMESTAMP is 1710338135. There are no execution layer changes, and the test cases are in the deneb test suite of the consensus-specs repository. The status of this EIP is Final.