status-im/eth2.0-specs
2
0
Fork 0
mirror of https://github.com/status-im/eth2.0-specs.git synced 2025-02-03 14:24:24 +00:00
Code Issues Projects Releases Wiki Activity

engine_getBlobV1_clarifications

Browse Source
This commit is contained in:
Enrico Del Fante 2024-08-02 14:19:26 +02:00
parent 9c39645761
commit e872fdb936
No known key found for this signature in database
GPG Key ID: F435EFF90817FBA5
1 changed files with 2 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

3
specs/deneb/p2p-interface.md
View File

@ -184,6 +184,7 @@ The following validations MUST pass before forwarding the `blob_sidecar` on the
- _[REJECT]_ The sidecar's inclusion proof is valid as verified by `verify_blob_sidecar_inclusion_proof(blob_sidecar)`.
- _[REJECT]_ The sidecar's blob is valid as verified by `verify_blob_kzg_proof(blob_sidecar.blob, blob_sidecar.kzg_commitment, blob_sidecar.kzg_proof)`.
- _[IGNORE]_ The sidecar is the first sidecar for the tuple `(block_header.slot, block_header.proposer_index, blob_sidecar.index)` with valid header signature, sidecar inclusion proof, and kzg proof.
*Note:* If client obtains the blob via `engine_getBlobV1` or any other method before receiving the corresponding sidecar via this topic, it MUST NOT consider the tuple as "seen" (i.e. it MUST participate in the dissemination of the blob_sidecar even if it already obtained the blob)
- _[REJECT]_ The sidecar is proposed by the expected `proposer_index` for the block's slot in the context of the current shuffling (defined by `block_header.parent_root`/`block_header.slot`).
If the `proposer_index` cannot immediately be verified against the expected shuffling, the sidecar MAY be queued for later processing while proposers for the block's branch are calculated -- in such a case _do not_ `REJECT`, instead `IGNORE` this message.
@ -295,7 +296,7 @@ Before consuming the next response chunk, the response reader SHOULD verify the
No more than `MAX_REQUEST_BLOB_SIDECARS` may be requested at a time.
`BlobSidecarsByRoot` is primarily used to recover recent blobs (e.g. when receiving a block with a transaction whose corresponding blob is missing).
`BlobSidecarsByRoot` is primarily used to recover recent blobs (e.g. when receiving a block with a transaction whose corresponding blob is missing). In addition, it is possible to retrieve recent blobs by quering the Execution Layer via `engine_getBlobV1` engine API method.
The response MUST consist of zero or more `response_chunk`.
Each _successful_ `response_chunk` MUST contain a single `BlobSidecar` payload.