-
Notifications
You must be signed in to change notification settings - Fork 971
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 DataColumnSidecars, 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_getBlobsV2as soon as they receive a validbeacon_blockordata_column_sidecarfrom gossip. If ALL blobs matchingkzg_commitmentsare 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: