From 4d972b4bd16e5f600f857650d4f4d2e2364046cd Mon Sep 17 00:00:00 2001 From: Marco Munizaga Date: Tue, 24 Jun 2025 13:31:40 -0700 Subject: [PATCH 1/2] engine_getBlobsV2: Support partial responses Reverts to previous behavior of supporting partial responses. This enables optimizations that require these partial responses. --- src/engine/osaka.md | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/src/engine/osaka.md b/src/engine/osaka.md index e9e059718..14591320a 100644 --- a/src/engine/osaka.md +++ b/src/engine/osaka.md @@ -108,9 +108,7 @@ Consensus layer clients **MAY** use this method to fetch blobs from the executio Refer to the specification for [`engine_getBlobsV1`](./cancun.md#engine_getblobsv1) with changes of the following: 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. -2. Client software **MUST** return `null` in case of any missing or older version blobs. For instance, - 1. 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 `null`. - 2. if the request is `[A_versioned_hash_for_blob_with_blob_proof]`, the response **MUST** be `null` as well. +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 **MUST** return `null` 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. From 76b7dca6f1ae5a9c3e115b5c99ba0cbc3add4278 Mon Sep 17 00:00:00 2001 From: Marco Munizaga Date: Mon, 30 Jun 2025 08:51:45 -0700 Subject: [PATCH 2/2] Update src/engine/osaka.md Co-authored-by: fradamt <104826920+fradamt@users.noreply.github.com> --- src/engine/osaka.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/engine/osaka.md b/src/engine/osaka.md index 14591320a..e5b859d91 100644 --- a/src/engine/osaka.md +++ b/src/engine/osaka.md @@ -108,7 +108,8 @@ Consensus layer clients **MAY** use this method to fetch blobs from the executio Refer to the specification for [`engine_getBlobsV1`](./cancun.md#engine_getblobsv1) with changes of the following: 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. -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]`. +1. 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]`. +2. If one or more of the requested blobs are unavailable, the client **MUST** return either `null` or 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 either `null` or `[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 **MUST** return `null` 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.