From 263f50972415eb79290afc8c752b63ac098f9f7e Mon Sep 17 00:00:00 2001 From: bomanaps Date: Tue, 31 Mar 2026 07:27:17 +0100 Subject: [PATCH 1/2] specify orphaned envelope serving rules --- specs/gloas/p2p-interface.md | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) diff --git a/specs/gloas/p2p-interface.md b/specs/gloas/p2p-interface.md index 417a5b5502..41b9014b0d 100644 --- a/specs/gloas/p2p-interface.md +++ b/specs/gloas/p2p-interface.md @@ -611,6 +611,16 @@ Per `fork_version = compute_fork_version(epoch)`: | -------------------- | -------------------------------------- | | `GLOAS_FORK_VERSION` | `gloas.SignedExecutionPayloadEnvelope` | +Clients MUST respond with payload envelopes from their view of the current fork choice, that is, payload envelopes as included by blocks from the single chain +defined by the current head. Of note, blocks from slots before the finalization +MUST lead to the finalized block reported in the `Status` handshake. + +Clients MUST respond with payload envelopes that are consistent from a single +chain within the context of the request. + +After the initial payload envelope, clients MAY stop in the process of responding +if their fork choice changes the view of the chain in the context of the request. + ##### ExecutionPayloadEnvelopesByRoot v1 **Protocol ID:** `/eth2/beacon_chain/req/execution_payload_envelopes_by_root/1/` @@ -669,3 +679,14 @@ payload envelope in the response. Clients MUST respond with at least one payload envelope, if they have it. Clients MAY limit the number of payload envelopes in the response. + +Clients SHOULD include a payload envelope in the response as soon as it passes +the gossip validation rules. Clients SHOULD NOT respond with payload envelopes +related to blocks that fail gossip validation rules. Clients SHOULD NOT respond +with payload envelopes related to blocks that fail the beacon-chain state +transition. + +For unfinalized blocks, clients MAY respond with payload envelopes whose +`beacon_block_root` is not part of the current fork choice canonical chain. +Unlike range requests, this is a single-item lookup and the requester can verify +canonical status independently. From ce8657c846daa9966b38999b8b6589aa24955432 Mon Sep 17 00:00:00 2001 From: bomanaps Date: Tue, 31 Mar 2026 07:53:19 +0100 Subject: [PATCH 2/2] fix lint --- specs/gloas/p2p-interface.md | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/specs/gloas/p2p-interface.md b/specs/gloas/p2p-interface.md index 41b9014b0d..35bd3013ca 100644 --- a/specs/gloas/p2p-interface.md +++ b/specs/gloas/p2p-interface.md @@ -611,15 +611,17 @@ Per `fork_version = compute_fork_version(epoch)`: | -------------------- | -------------------------------------- | | `GLOAS_FORK_VERSION` | `gloas.SignedExecutionPayloadEnvelope` | -Clients MUST respond with payload envelopes from their view of the current fork choice, that is, payload envelopes as included by blocks from the single chain +Clients MUST respond with payload envelopes from their view of the current fork +choice, that is, payload envelopes as included by blocks from the single chain defined by the current head. Of note, blocks from slots before the finalization MUST lead to the finalized block reported in the `Status` handshake. Clients MUST respond with payload envelopes that are consistent from a single chain within the context of the request. -After the initial payload envelope, clients MAY stop in the process of responding -if their fork choice changes the view of the chain in the context of the request. +After the initial payload envelope, clients MAY stop in the process of +responding if their fork choice changes the view of the chain in the context of +the request. ##### ExecutionPayloadEnvelopesByRoot v1