Skip to content

Commit

Permalink
Update EIP-7045: minor copy and link updates
Browse files Browse the repository at this point in the history
Merged by EIP-Bot.
  • Loading branch information
djrtwo authored Jun 21, 2023
1 parent 8788879 commit a2ea76c
Showing 1 changed file with 9 additions and 5 deletions.
14 changes: 9 additions & 5 deletions EIPS/eip-7045.md
Original file line number Diff line number Diff line change
@@ -1,7 +1,7 @@
---
eip: 7045
title: Increase max attestation inclusion slot
description: Increases max attestaton inclusion slot to the last slot in `N+1` where `N` is the epoch containing the attestations slot.
description: Increases max attestaton inclusion slot to the last slot in `N+1` where `N` is the epoch containing the attestation's slot.
author: Danny Ryan (@djrtwo)
discussions-to: https://ethereum-magicians.org/t/eip-7045-increase-attestation-slot-inclusion-range/14342
status: Draft
Expand All @@ -22,7 +22,7 @@ Attestations can currently be included after some minimum delay (`1` slot on mai

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.
This specification thus increases the max inclusion slot for attestations in accordance with the learned security proof and confirmation rule needs.

## Specification

Expand All @@ -38,12 +38,14 @@ 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 just rely on 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.
* Modify [`process_attestation`](https://github.com/ethereum/consensus-specs/blob/95f36d99cf4aa59974da06af24ef9a7c12d3c301/specs/deneb/beacon-chain.md#modified-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`](https://github.com/ethereum/consensus-specs/blob/95f36d99cf4aa59974da06af24ef9a7c12d3c301/specs/deneb/beacon-chain.md#modified-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.
Additionally, the specification modifies the [attestation](https://github.com/ethereum/consensus-specs/blob/95f36d99cf4aa59974da06af24ef9a7c12d3c301/specs/deneb/p2p-interface.md#beacon_attestation_subnet_id) and [aggregate attestation](https://github.com/ethereum/consensus-specs/blob/95f36d99cf4aa59974da06af24ef9a7c12d3c301/specs/deneb/p2p-interface.md#beacon_aggregate_and_proof) gossip conditions to allow for gossip during this extended range.

## Rationale

Expand All @@ -57,6 +59,8 @@ Previously, `get_attestation_participation_flag_indices` would only set the `TIM

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.
Expand Down

0 comments on commit a2ea76c

Please sign in to comment.