P2P clarifications when introducing engine_getBlobsV1

specs/deneb/p2p-interface.md

@@ -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_getBlobsV1` 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.
 
@@ -309,6 +310,14 @@ 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 the beacon chain state transition
 
+###### Usage of `engine_getBlobsV1` engine API method
+In addition to `BlobSidecarsByRoot` requests, recent blobs recovery MAY also be done by querying the Execution Layer via `engine_getBlobsV1`.
+Implementers are encouraged to leverege this method to encrease the likelihood of incorporating and attesting to the last block when its proposer is not able to publish blobs on time.
+
+Client MAY use this method when serving `BlobSidecarsByRoot` requests.
+
+Client MUST publish the corresponding `blob_sidecar` whenever successfully recovers blobs via `engine_getBlobsV1`.
+
 ##### BlobSidecarsByRange v1
 
 **Protocol ID:** `/eth2/beacon_chain/req/blob_sidecars_by_range/1/`