Reject Blobs Which Reference Already Finalized Parent Blocks

[nisdas]

Currently we will allow blobs to reference parent blocks which are already finalized. This could allow malicious peers to perform DOS attacks by referencing a very old parent block. Due to the requirements for nodes to verify proposer shuffling for these blobs, you could have a malicous peer force a honest node to perform an excessive amount of epoch transitions to verify the shuffling for the proposer. In order to mitigate this we can simply add the same gossip validation condition that we have for beacon blocks for blobs:

[REJECT] The current finalized_checkpoint is an ancestor of block -- i.e. get_checkpoint_block(store, block.parent_root, store.finalized_checkpoint.epoch) == store.finalized_checkpoint.root

This was encountered when running an Antithesis experiment.

[djrtwo]

makes sense. thanks!

[haxxpop]

Should this be a REJECT or an IGNORE? I'm not sure.

It should probably be just an IGNORE because the block proposer sometimes just doesn't have the latest finalized checkpoint in their view yet without the intention to be malicious.

[nisdas]

@ppopth This follows from here #1985

I think the reason it was reject was because any proposer building on an old parent would technically be reverting the finalized checkpoint. It is possible for a node to be stuck and to produce such blocks, but if that happens I think being more harsh here is warranted.

[haxxpop]

This follows from here #1985

That makes sense then. Thanks.

[mkalinin]

This change should be incorporated into #3531

[tbenr]

Maybe we could merge this to officially signal that this is go to go and rebase #3531 afterwards since it is still under refinement?

[djrtwo]

Merging -- can incorporate into #3531 as @tbenr suggests