Description
The "fetch blob from EL" was an optimization introduced in #6268 to reduce the delay to block import - nodes can retrieve blobs from EL without waiting for them from gossip, hence making blocks attestable earlier.
In Deneb, engine_getBlobs
can only be called when a node receives a valid beacon block from gossip, as it requires KZG commitments of the blobs to compute version hashes, so that it can query for the associated blobs from the EL.
Under PeerDAS, blobs are transmitted over the network in the form of DataColumnSidecar
s, each of them contains ALL blob KZG commitments for the block. This means we can apply this same optimisation, and query the Engine API for blobs as soon as we receive a DataColumnSidecar
from gossip.
From the latest Distributed Blob Publishing spec PR:
Honest nodes SHOULD query
engine_getBlobsV2
as soon as they receive a validbeacon_block
ordata_column_sidecar
from gossip. If ALL blobs matchingkzg_commitments
are retrieved, they should convert the response to data columns, and import the result.Implementers are encouraged to leverage this method to increase the likelihood of incorporating and attesting to the last block when its proposer is not able to publish data columns on time.
However, with this additional optimisation, any of the 128 columns + the beacon block from gossip can trigger this, which means there's a high likelihood of race condition on these operations, and we should handle the concurrency here accordingly, and make sure we don't perform multiple fetch blob operations at the same time, which could result in wasting CPU cycles and unnecessary IO (repeated writes / block import).
Related issues: