4.5.4.Engine blob access

Dencun blob retrieval

engine_getBlobsV1 accepts ordered versioned blob hashes and returns one positional blob and proof bundle for each hash. A missing item is null. The method has a one-second target timeout and supports at least 128 hashes.

Fusaka blob retrieval

engine_getBlobsV2 accepts ordered versioned blob hashes and returns all requested extended blobs and cell proofs or one top-level null. The method has a one-second target timeout.

engine_getBlobsV3 accepts the same ordered hash list and returns a positional array, using null only for missing items. A top-level null means that the execution client cannot serve the blob pool at all. The method has a one-second target timeout.

Each returned proof set covers every cell in the extended blob. The caller checks versioned hashes and KZG proofs before it turns blobs into data columns.

Glamsterdam cell retrieval

engine_getBlobsV4 takes an ordered array of versioned blob hashes and a 16-byte cell-index bit array. The same selected indices apply to every blob. The Amsterdam Engine API gives the call a one-second timeout and requires support for at least 128 hashes. Draft EIP-8070 instead specifies a 500-millisecond timeout; implementations must not treat that draft value as the Amsterdam contract. The response keeps request order and returns one BlobCellsAndProofsV1 result per hash. A missing blob is a positional null. A present blob may contain null cells, and each such cell has a matching null proof. A syncing or otherwise unavailable execution client returns a top-level null. An oversized request returns -38004; pruned data returns null at the affected position. Each non-null proof is a 48-byte KZG proof. This local method lets the consensus client request selected cells without using devp2p.

For engine_getBlobsV1, a syncing client may return an array of null items.

For the all-or-nothing and partial methods, a syncing or unavailable client may return top-level null.