Get blobs from the EL's blob pool

[michaelsproul]

Proposed Changes

This PR implements an experimental optimisation to fetch blobs via JSON-RPC from the EL. If a blob has already been seen in the public mempool, then it is often unnecessary to wait for it to arrive on P2P gossip. This PR uses a new JSON-RPC method (engine_getBlobsV1) which allows the CL to load the blobs quickly from the EL's blob pool.

Spec here:

• Define engine_getBlobsV1 ethereum/execution-apis#559

This PR works in tandem with my changes to Reth:

• Implement engine_getBlobsV1 paradigmxyz/reth#9723

TODO before merging:

• Check engine capabilities before call
• Wait for spec to be agreed on by EL clients
• Broadcast blobs from EL over P2P

[michaelsproul]

Should also consider re-publishing blobs from the EL on gossip in order to speed up propagation network-wide!

[dapplion]

Really nice! This makes a lot of sense and can definitely improve status quo before peerdas.

Should also consider re-publishing blobs from the EL on gossip in order to speed up propagation network-wide!

Some options:

• Just insert message in gossip duplicate cache so the app layer is not notified and we just forward
• Add a condition in blob gossip verification to consider a blob valid if it's already in the da_checker
• Actually publish blob: depending on our publishing rules this can lead to greater amplification of total network bandwidth. We could only publish to our current set of mesh peers. Could couple this with IDONTWANT control message

[michaelsproul]

My latest commit with IPC doesn't work (yet), but here's a summary of performance using HTTP:

• Decoding the blob txn hashes from the transaction bytes seems to be nearly instantaneous, with the log occurring the same millisecond as Blobs from EL - start request.
• Reth often responds with all blobs in around 8-20ms, very quick!
• Constructing the KZG inclusion proofs takes around 5ms per blob (30ms for 6). Some room for optimisation here.
• Processing in the data availability checker also takes around 5ms per blob (30ms for 6).

In total this puts the latency for all blobs to be fetched and processed at 20+30+30 = 80ms total for 6-blob blocks. Compared to gossip, the additional cost is <= 50ms, because the DA processing is required for gossip blobs too, and they require KZG inclusion proof verification rather than construction.

[dapplion]

Processing in the data availability checker also takes around 5ms per blob

What's taking so long? Could be that it's verifying the kzg proof? If yes that can be skipped as you have just created it in the same process

[dapplion]

Notes regarding future compatibility of this feature with PeerDAS:

PeerDAS importability condition is to have seen and validated its custody columns. If a node can get all block's blobs from the EL pool (and they are valid) it is guaranteed that it can recompute its custody columns. Therefore, if a node has seen all block's blobs it can "optimistically" consider that block as an available head before importing the columns. At that moment it can choose to either:

• compute its custody columns from the blobs
• wait for the columns to arrive from gossip

There's no consensus safety degradation from this optimistic behavior. Only that the node is announcing to its peers "I have imported block X, with my custody columns being Y". Then its peers can request via ReqResp said columns which the peer does not have yet. The node should make sure to compute or receive the columns before TTFB_TIMEOUT to prevent losing peers.

[michaelsproul]

Finally got a chance to update the Reth prototype & this PR to match new spec:

• Define engine_getBlobsV1 ethereum/execution-apis#559

Seems to be working

[michaelsproul]

Closing in favour of:

• Improving blob propagation post-PeerDAS with Decentralized Blob Building #6268