HomeEIPsNewsletter
EIPsEIP-7045
EIP-7045

Increase max attestation inclusion slot

Increases max attestaton inclusion slot to the last slot in `N+1` where `N` is the epoch containing the attestation's slot.
FinalStandards Track: Core
Created: 2023-05-18
Danny Ryan (@djrtwo)
Discussions ForumOriginal Proposal LinkEdit
1 min read

EIP-7045, titled "Increase max attestation inclusion slot," proposes an increase in the maximum attestation inclusion slot from attestation.slot + SLOTS_PER_EPOCH to the last slot of epoch N+1, where N is the epoch containing the attestation slot. This change is crucial for the current LMD-GHOST security analysis and the confirmation rule. The proposal modifies the process_attestation function to remove the upper bound on the slot check and instead rely on the minimum slot and the target epoch being in either the current or previous epoch. It also modifies the get_attestation_participation_flag_indices function to set the TIMELY_TARGET_FLAG without considering inclusion_delay, ensuring that extended inclusion attestations have a non-zero reward. The proposal also modifies the attestation and aggregate attestation gossip conditions to allow for gossip during this extended range. The rationale behind this proposal is that extending the max inclusion slot to the end of the next epoch is critical for LMD-GHOST security proofs and confirmation rule. The document mentions that this proposal introduces backward-incompatible changes to the block validation rule set on the consensus layer and must be accompanied by a hard fork. There are no known negative impacts on security.

Video
Anyone may contribute to propose contents.
Go propose
Original

Abstract

Increases max attestation inclusion slot from attestation.slot + SLOTS_PER_EPOCH to the last slot of epoch N+1 where N is the epoch containing the attestation slot.

This increase is critical to the current LMD-GHOST security analysis as well as the confirmation rule.

Motivation

Attestations can currently be included after some minimum delay (1 slot on mainnet) up until SLOTS_PER_EPOCH slots after the slot the attestation was created in. This rolling window of one epoch was decided upon during Phase 0 because the equal inclusion window for any attestation was assessed as "fair". The alternative considered path was to allow inclusion during the current and next epoch which means attestations created during the start of an epoch have more potential slots of inclusion than those at the end of the epoch.

Since this decision, it has become apparent that the alternative design is critical for current LMD-GHOST security proofs as well as a new confirmation rule (which will allow for block confirmations in approximately 3-4 slots in normal mainnet conditions).

This specification thus increases the max inclusion slot for attestations in accordance with the learned security proof and confirmation rule needs.

Specification

Constants

NameValueComment
FORK_TIMESTAMPTBDMainnet

Execution layer

This requires no changes to the Execution Layer.

Consensus layer

Specification changes are built into the Consensus Specs Deneb upgrade.

The specification makes two minor changes to the state transition function:

  • Modify process_attestation to not have an upper bound on the slot check and instead define the inclusion range via the minimum slot as well as the target epoch being in either current or previous epoch.
  • Modify get_attestation_participation_flag_indices to set the TIMELY_TARGET_FLAG without consideration of inclusion_delay to ensure that the extended inclusion attestations have a non-zero reward.

Additionally, the specification modifies the attestation and aggregate attestation gossip conditions to allow for gossip during this extended range.

Rationale

Extended max inclusion slot

As discussed in the Motivation, extending this max inclusion slot to the end of the next epoch is critical for LMD-GHOST security proofs and confirmation rule.

Removal of inclusion_delay consideration for target reward

Previously, get_attestation_participation_flag_indices would only set the TIMELY_TARGET_FLAG (and thus reward for an attestation with correct target vote) if the attestation was included within a SLOTS_PER_EPOCH window.

The inclusion_delay consideration for this flag is removed to ensure that whatever the valid inclusion window is for an attestation, it can receive a baseline non-zero reward for correct target. This ensures that clients will still attempt to pack such attestations into blocks which is important for the security analysis.

Note, this was the intended behavior with the previously defined range which was equivalent to the max.

Backwards Compatibility

This EIP introduces backwards incompatible changes to the block validation rule set on the consensus layer and must be accompanied by a hard fork.

Test Cases

Test cases for this EIP can be found in the deneb test suite of the consensus-specs repository.

Security Considerations

This improves LMD-GHOST security as well as enables a fast confirmation rule.

There are no known negative impacts to security.

Copyright and related rights waived via CC0.

Further reading
Anyone may contribute to propose contents.
Go propose

Not miss a beat of EIPs' update?

Subscribe EIPs Fun to receive the latest updates of EIPs Good for Buidlers to follow up.

View all
Serve Ethereum Builders, Scale the Community.
Resources
GitHub
Supported by