4.5.4.Engine blob access

The fields are encoded as follows:

• blob: DATA - FIELD_ELEMENTS_PER_BLOB * BYTES_PER_FIELD_ELEMENT = 4096 * 32 = 131072 bytes (DATA) representing a SSZ-encoded Blob as defined in EIP-4844.
• proof: DATA - KZGProof as defined in EIP-4844, 48 bytes (DATA).

Consensus layer clients MAY use this method to fetch blobs from the execution layer blob pool.

Note: This is a new method introduced after Cancun. It is defined here because it is backwards-compatible with Cancun.

Request

• method: engine_getBlobsV1
• params:
  1. Array of DATA, 32 Bytes - Array of blob versioned hashes.
• timeout: 1s

Response

• result: Array of BlobAndProofV1 - Array of BlobAndProofV1, items of which may be null.
• error: code and message set in case an error occurs during processing of the request.

Specification

1. Given an array of blob versioned hashes client software MUST respond with an array of BlobAndProofV1 objects with matching versioned hashes, respecting the order of versioned hashes in the input array.

2. Client software MUST place responses in the order given in the request, using null for any missing blobs. For instance, if the request is [A_versioned_hash, B_versioned_hash, C_versioned_hash] and client software has data for blobs A and C, but doesn’t have data for B, the response MUST be [A, null, C].

3. Client software MUST support request sizes of at least 128 blob versioned hashes. The client MUST return -38004: Too large request error if the number of requested blobs is too large.

4. Client software MAY return an array of all null entries if syncing or otherwise unable to serve blob pool data.

5. Callers MUST consider that execution layer clients may prune old blobs from their pool, and will respond with null if a blob has been pruned.