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

remove explicit reference to engine method

Browse Source
This commit is contained in:
Enrico Del Fante 2024-10-02 12:33:42 +02:00
parent 63ad07b450
commit 4531fe629c
No known key found for this signature in database
GPG Key ID: F435EFF90817FBA5
1 changed files with 4 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -34,7 +34,7 @@ The specification of these changes continues in the same format as the network s
- [BeaconBlocksByRange v2](#beaconblocksbyrange-v2) - [BeaconBlocksByRange v2](#beaconblocksbyrange-v2)
- [BeaconBlocksByRoot v2](#beaconblocksbyroot-v2) - [BeaconBlocksByRoot v2](#beaconblocksbyroot-v2)
- [BlobSidecarsByRoot v1](#blobsidecarsbyroot-v1) - [BlobSidecarsByRoot v1](#blobsidecarsbyroot-v1)
- [Usage of `engine_getBlobsV1` engine API method](#usage-of-engine_getblobsv1-engine-api-method) - [Blobs recovery via local execution layer client](#blobs-recovery-via-local-execution-layer-client)
- [BlobSidecarsByRange v1](#blobsidecarsbyrange-v1) - [BlobSidecarsByRange v1](#blobsidecarsbyrange-v1)
- [Design decision rationale](#design-decision-rationale) - [Design decision rationale](#design-decision-rationale)
- [Why are blobs relayed as a sidecar, separate from beacon blocks?](#why-are-blobs-relayed-as-a-sidecar-separate-from-beacon-blocks) - [Why are blobs relayed as a sidecar, separate from beacon blocks?](#why-are-blobs-relayed-as-a-sidecar-separate-from-beacon-blocks)
@ -311,11 +311,11 @@ Clients SHOULD include a sidecar in the response as soon as it passes the gossip
Clients SHOULD NOT respond with sidecars related to blocks that fail gossip validation rules. Clients SHOULD NOT respond with sidecars related to blocks that fail gossip validation rules.
Clients SHOULD NOT respond with sidecars related to blocks that fail the beacon chain state transition Clients SHOULD NOT respond with sidecars related to blocks that fail the beacon chain state transition
###### Usage of `engine_getBlobsV1` engine API method ###### Blobs recovery via local execution layer client
In addition to `BlobSidecarsByRoot` requests, recent blobs recovery MAY also be done by querying the Execution Layer via `engine_getBlobsV1`. In addition to `BlobSidecarsByRoot` requests, recent blobs recovery MAY also be done by querying the Execution Layer (i.e. via `engine_getBlobsV1`)
Implementers are encouraged to leverage this method to increase the likelihood of incorporating and attesting to the last block when its proposer is not able to publish blobs on time. Implementers are encouraged to leverage this method to increase the likelihood of incorporating and attesting to the last block when its proposer is not able to publish blobs on time.
Client MUST publish the corresponding `blob_sidecar` whenever successfully recovers blobs via `engine_getBlobsV1`. Client MUST publish the corresponding `blob_sidecar` whenever successfully recovers blobs via local execution layer client.
##### BlobSidecarsByRange v1 ##### BlobSidecarsByRange v1