EIP4844: couple beacon block and blob sidecar for p2p

[terencechain]

Part of #3043

Here we couple beacon block and blob sidecar under a single gossip topic- beacon_block_and_blob_sidecar. We introduce a new network container SignedBeaconBlockAndBlobsSidecar which consists of SignedBeaconBlock and SignedBlobsSidecar. We also combined the previous gossips beacon_block and blobs_sidecar validations under beacon_block_and_blob_sidecar. I think we can get rid of blob.beacon_block_root and blob.beacon_block_slot, I'm curious to hear more thoughts

cc @protolambda @Inphi

Rationale for coupling: https://notes.ethereum.org/RLOGb1hYQ0aWt3hcVgzhgQ?#Gossip

[dapplion]

:+1: on coupling

[terencechain]

I think we need some clarification on how we want to propagate beacon blocks that don't have sidecars

Do we want to support this? It feels like more complexity and takes us back to de-coupling block and blob

[realbigsean]

I think empty lists in the existing structs here should be sufficient

[Inphi]

I think we need some clarification on how we want to propagate beacon blocks that don't have sidecars

Do we want to support this? It feels like more complexity and takes us back to de-coupling block and blob

Agreed. it isn't clear to me from my reading of the spec that we'll use coupled blocks even when there isn't a sidecar. Let's clarify this in the spec. We can deprecate/remove the old topic used for (decoupled) beacon blocks.

[hwwhww]

should we add the description of how to prepare SignedBeaconBlockAndBlobsSidecar in validator.md?

[terencechain]

should we add the description of how to prepare SignedBeaconBlockAndBlobsSidecar in validator.md?

Good point, I'll update that today