EIP-7045: Increase max attestation inclusion slot

[djrtwo]

Pretty much a two line change in the state transition spec:

1. expand attestation slot inclusion range to be the current and next epoch -- change
2. set target timeliness flag if target correct at all disregarding inclusion delay (other than just process_attestation validly including in it's range) -- change

As well as the modificaiton of the p2p gossip conditions to support this.

The rest is generally copy paste functions and a lot of boiler plate.

As for testing, I've made the relevant process_attestation tests be for the max_inclusion_slot which is spec/fork aware. As well as adding one explicit test for SLOTS_PER_EPOCH inclusion that should be valid for all forks

todo:

• additional testing
  • integration test that spans a fork boundary. Attestation created in N that can be included at end of epoch N+1 where N+1 is the fork epoch

[terencechain]

Not sure how much it matters, but in the previous feature-specific spec, the mentioned changes propagated up to process_operation than process_block. It's a little unnecessary, but wanted to point that out

[ppopth]

Why do we do this only for the target timeliness flag only but not the source timeliness flag as well? I saw this line

    if is_matching_source and inclusion_delay <= integer_squareroot(SLOTS_PER_EPOCH):

[djrtwo]

Why do we do this only for the target timeliness flag only but not the source timeliness flag as well? I saw this line

    if is_matching_source and inclusion_delay <= integer_squareroot(SLOTS_PER_EPOCH):

We want validators to be rewarded for correct FFG vote no matter when it makes it on chain -- so anytime in the maximum range.

Source correctness reward "splits the difference" between the timeliness of head and the timeliness of target in the chances to get rewarded when included on chain. This doesn't change that consideration

[arnetheduck]

Raised during the call: are there designated aggregators listening on the right subnet that can pick up these attestations when they come late?

[djrtwo]

Raised during the call: are there designated aggregators listening on the right subnet that can pick up these attestations when they come late?

Proposers are already and would continue to be the aggregators of last resort for late or non-previously-picked-up attestations. This is clearly imperfect due to a given stretch of proposers not having perfect coverage off attestation subnets, but 7045 is a strict improvement by giving both more time and more potential proposers to pick up missing attestations.

Altered networking, late aggregators, etc is orthogonal to the issue of extending this deadline, as the problem currently exists with the 32-slot inclusion deadline and at least is stable if not improvved with the extended deadline here.

[hwwhww]

Note to myself:
The fork-choice on_attestation validation only requires assert target.epoch in [current_epoch, previous_epoch], where the current epoch is the computed with store. So it should be irrelevant to this change.

This PR looks good to me. Just some proofread comments. 👍