Skip to content

Commit de1f396

Browse files
MarcoPoloraulk
andcommitted
add engine_getBlobsV3 method
CL clients can make use of partial responses to exchange just the missing cells. This method allows the CL to request partial responses from the EL. Co-Authored-By: raulk <raul.kripalani@gmail.com>
1 parent bc5a37e commit de1f396

File tree

2 files changed

+196
-1
lines changed

2 files changed

+196
-1
lines changed

src/engine/openrpc/methods/blob.yaml

Lines changed: 168 additions & 1 deletion
Large diffs are not rendered by default.

src/engine/osaka.md

Lines changed: 28 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -115,6 +115,34 @@ Refer to the specification for [`engine_getBlobsV1`](./cancun.md#engine_getblobs
115115
4. Client software **MUST** return `null` if syncing or otherwise unable to serve blob pool data.
116116
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.
117117

118+
### engine_getBlobsV3
119+
120+
Consensus layer clients **MAY** use this method to fetch blobs from the execution layer blob pool, with support for partial responses. For an all-or-nothing query style, refer to `engine_getBlobsV2`.
121+
122+
#### Request
123+
124+
* method: `engine_getBlobsV3`
125+
* params:
126+
1. `Array of DATA`, 32 Bytes - Array of blob versioned hashes.
127+
* timeout: 1s
128+
129+
#### Response
130+
131+
* result: `Array of BlobAndProofV2` - Array of [`BlobAndProofV2`](#BlobAndProofV2), inserting `null` only at the positions of the missing blobs, or a `null` literal in the designated cases specified below.
132+
* error: code and message set in case an error occurs during processing of the request.
133+
134+
#### Specification
135+
136+
> To assist the reader, we highlight differences against `engine_getBlobsV2` using italic.
137+
138+
1. Given an array of blob versioned hashes client software **MUST** respond with an array of `BlobAndProofV2` objects with matching versioned hashes, respecting the order of versioned hashes in the input array.
139+
2. Given an array of blob versioned hashes, if client software has every one of the requested blobs, it **MUST** return an array of _`BlobAndProofV2`_ objects whose order exactly matches the input array. For instance, if the request is `[A_versioned_hash, B_versioned_hash, C_versioned_hash]` and client software has `A`, `B` and `C` available, the response **MUST** be `[A, B, C]`.
140+
3. If one or more of the requested blobs are unavailable, _the client **MUST** return an array of the same length and order, inserting `null` only at the positions of the 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]`. If all blobs are missing, the client software must return an array of matching length, filled with `null` at all positions._
141+
4. 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.
142+
5. Client software **MUST** return `null` if syncing or otherwise unable to generally serve blob pool data.
143+
6. Callers **MUST** consider that execution layer clients may prune old blobs from their pool, and will respond with `null` at the corresponding position if a blob has been pruned.
144+
145+
118146
### Update the methods of previous forks
119147

120148
#### Cancun API

0 commit comments

Comments
 (0)