post-devcon 4844 spec updates

[djrtwo]

A number of spec modifications need to happen after discussions at devcon:

1. Couple block and blob sidecar in a single gossip topic -- beacon_block_and_blob_sidecar
   • Keep proposer signature on the sidecar to ensure a party cannot mutate OR we have to do the sidecar / blobtx KZG verifications
2. Reduce MIN_EPOCHS_FOR_BLOBS_SIDECARS_REQUESTS to ~2 weeks or lower
3. Clarify Blob availability requirement in fork-choice by specifying an is_data_available() check for importing a block
4. Consider MAX_REQUEST_BLOBS_SIDECARS value
   • Currently 128 which is a very large amount of data, but you only MUST respond to 1st
   • Is this "only first" requirement (and the mirror to blocks by range) sufficient for load balancing or should teh value be reduced?
5. TBD -- potentially reduce blobs per block down to an appropriate value after testing and simulations
   • Note, this can be done now to something like 128KB/256KB if 1MB/2MB is blocking important testing
6. TBD -- based on 4844 load tests and lighthouse episub tests, finish episub spec and potentially make it suggested or mandatory

[hwwhww]

@djrtwo
I believe these items have been solved except for the final episub spec?

[arnetheduck]

We're leaning towards libp2p/specs#548 as replacement for episub - I haven't seen much activity on the episub front lately though @AgeManning would know more maybe.

[AgeManning]

Yep, I think we can do the IDONTWANT message as a precursor to episub.

Episub has a very large parameter space and its not immediately obvious the best parameters for our network. It requires more analysis and is something we have put on hold for a bit in favour of some more direct gains. However we've added some more resources to our team to take up this analysis.

So we're happy to go with IDONTWANT and if we can see some gains in episub, we may push that later on.

[hwwhww]

Thank you @arnetheduck @AgeManning for your responses! Closing this issue now unless anyone wants to reopen it.