EIP-4844: blobs / blocks by root edge case

[dapplion]

When receiving a block with slot close and after EIP4844_FORK_EPOCH with an unknown parent you don't know if the parent will be pre or post EIP4844_FORK_EPOCH. So, should you:

• Use beacon_block_and_blobs_sidecar_by_root:
  • Parent is pre EIP4844: The responder will either error or return empty, spec is not specified. If empty it's unclear if the responder does not have the block or if the block is pre EIP4844. However if it errors, how to handle a mix case where a request of multiple roots, some are pre EIP4844 and some post? If we use a per response_chunk error code for that case, at least Lodestar's logic aborts the entire response stream on the first status != success
  • Parent is post EIP4844: Ok
• Use beacon_blocks_by_root:
  • Parent is pre EIP4844: Ok
  • Parent is post EIP4844: According to the spec After EIP4844_FORK_EPOCH, BeaconBlocksByRootV2 is replaced by BeaconBlockAndBlobsSidecarByRootV1. How should the client respond for this case, and in the case of mixed roots per and post EIP4844? Arguments from first case apply here too.

In Lodestar implementation we currently race both request with 1 root max per request. However would be good to have a well defined interaction between EIP4844_FORK_EPOCH and finalizing EIP4844_FORK_EPOCH.

[tbenr]

Shouldn't you rename the issue "... by root edge case"?
My gut says we should allow the coupled request to retrieve pre 4844. Clients should respond with a zero sidecar. But it might create ssz containers issues (a pre 4844 block into a 4844 blockandsidecar container).

[tbenr]

Another option is let beacon_block_and_blobs_sidecar_by_root return a SignedBeaconBlock instead of BlobsAndBlobsSidecar when block is pre 4844.

[divagant-martian]

Another option is let beacon_block_and_blobs_sidecar_by_root return a SignedBeaconBlock instead of BlobsAndBlobsSidecar when block is pre 4844.

This seems the best option to me. It makes it clear what the peer responding is claiming about the block: either a pre 4844, or post along with it's blob, and allows us to do parent requests in a single rpc call

[realbigsean]

Just to put it in clear terms: beacon_block_and_blobs_sidecar_by_root could always return Union[SignedBeaconBlockAndBlobsSidecar, SignedBeaconBlock]. This seems like a pretty reasonable option to me.