eip7732: add gossip rule for old payloads

[ethDreamer]

This additional gossip rule is needed on the ExecutionPayloadEnvelope per today's breakout room call

[potuz]

Shouldn't this be greater or equal? validators only attest to the CL block to finalize it, there's no payload content in the checkpoint.

Suggested change

	`envelope.slot > compute_start_slot_at_epoch(store.finalized_checkpoint.epoch)`
	`envelope.slot >= compute_start_slot_at_epoch(store.finalized_checkpoint.epoch)`

[ethDreamer]

good catch!

[jtraglia]

Hmm I don't fully understand why "equal to" should be accepted too. Care to expand?

Like why is it different than other messages, eg:

consensus-specs/specs/phase0/p2p-interface.md

Lines 441 to 444 in 6098eb4

	- _[IGNORE]_ The block is from a slot greater than the latest finalized slot --
	i.e. validate that
	`signed_beacon_block.message.slot > compute_start_slot_at_epoch(store.finalized_checkpoint.epoch)`
	(a client MAY choose to validate and store such blocks for additional purposes

Also, if we make this change, we need to update the sentence too:

- The envelope is from a slot greater than the latest finalized slot
+ The envelope is from a slot greater than or equal to the latest finalized slot

[ralexstokes]

i would expect we want symmetry with the other validations

i havent reviewed the latest on the FC here, but i dont see how we would have the condition that we want an execution envelope for an already finalized block

so a simple > seems better

[potuz]

i would expect we want symmetry with the other validations

i havent reviewed the latest on the FC here, but i dont see how we would have the condition that we want an execution envelope for an already finalized block

so a simple > seems better

When we finalize a block, attesters vote for the blockroot of that block, they say nothing about the availability of the payload of said block. So there's consensus that the block is final, but not about its payload. Therefore I think it is more aligned with the spec to not consider the payload as finalized. We could change the finalization and attestation scheme to also include payload information, but I believe the complexity is not worth it.

[jtraglia]

Okay. This makes sense to me. Thanks for explaining.

[ralexstokes]

lgtm

just cuts down on potential DoS risk on this topic

edit: see other comment about >= vs >

[ralexstokes]

not sure how to dismiss my previous review

it does seem like it should be > and NOT >= and then i think we should merge this

[jtraglia]

I've decided to approve/merge this. The last comment from potuz makes sense to me.

But if this turns out to be wrong, we can fix it in a future PR.