Define engine_getBlobsV1

[michaelsproul]

Engine API specification for a new optional getBlobsV1 method.

The purpose of this method is to allow consensus clients to fetch blobs from the EL blob pool, so that:

• It reduces the delay for a block to become available and attestable, if the blobs aren't received via gossip in a timely manner e.g. due to limited proposer bandwidth, or high latency at the receiving node.
• Secondly it enables "decentralized blob building", which reduces the likelihood of a block getting orhpaned if the block proposer isn't able to publish the blobs quick enough due to bandwidth constraints (e.g. home stakers with limited bandwidth or stakers in remote locations). High capacity nodes can fetch blobs from their EL blob pools, build the blob sidecars and publish it to the network on behalf of the proposer. This will help self builders today (which statistically include a higher number of blobs in their blocks), and will become an important component to keep local block building viable for home stakers when blob count increases in the near future.

Co-authored with @jimmygchen

[mkalinin]

A few nits, otherwise, looks good to me!

[mkalinin]

LGTM!

[LukaszRozmej]

Would it be possible to query by tx hash instead of blob version hashes? EL generally store by tx hash. We can add another mapping but it will complicate things a bit. Or pairs of txhash+blobversionhashes.

EDIT: decided on ACCD that CL doesn't have the tx hashes.

[lightclient]

Is there a reason this should be in the engine API vs the regular eth api? I lean towards the latter.

[smartprogrammer93]

@lightclient i disagree. i dont see why this should move to eth API. it will only be used by CL clients. I dont see any other usage. Additionally, it is way better to keep all methods used by CL in the engine API. i hate the fact that they have to use eth API for other things (like eth_getLogs etc)

[tbenr]

This is my analysis of an actual case that could have been avoided by a good adoption of this PR
https://hackmd.io/@dsjdqQDBRp66btjRzfxjbw/r1OuFG7AA

I think we should prioritize this

[g11tech]

lgtm