[EIP-7732] ExecutionPayloadEnvelopesByRange RPC #4120
Conversation
There was a problem hiding this comment.
LGTM. However, I think we may want to consider the option of getting these payloads blind. When range syncing an unfinalized long chain, the EL will have the option to download blocks from a given hash on the EL p2p chain, while the CL will still need the envelope to sync the CL state. I envision that this decoupling of blocks with payloads will actually be useful in the future for long range syncing.
I see. In that mode we will be always optimistically syncing, from CL perspective. |
There was a problem hiding this comment.
I think we should add more detail to this, similar to how we frame blocks by range. Examples:
Requests payload in the slot range [start_slot, start_slot + count), leading up to the current head block as selected by fork choice. For example, requesting payloads starting at start_slot=2 and count=4 would return the payloads at slots [2, 3, 4, 5]. If slot 4 were empty in the previous example, the returned array would contain [2, 3, 5].
PayloadByRange is primarily used to sync historical payloads.
The request MUST be encoded as an SSZ-container.
The response MUST consist of zero or more response_chunk. Each successful response_chunk MUST contain a single ExecutionPayloadEnvelope payload.
Clients MUST keep a record of signed execution payload envelopes seen on the epoch range [max(GENESIS_EPOCH, current_epoch - MIN_EPOCHS_FOR_BLOCK_REQUESTS), current_epoch], where current_epoch is defined by the current wall-clock time. Clients MUST support serving requests for execution payloads within this range.
Peers unable to reply to block payloads within the MIN_EPOCHS_FOR_BLOCK_REQUESTS epoch range SHOULD respond with error code 3: ResourceUnavailable. Such peers that fail to reply successfully to this range of requests MAY get descored or disconnected at any time.
Note: Although clients that bootstrap from a weak subjectivity checkpoint can begin participating in the networking immediately, other peers MAY disconnect and/or temporarily ban an un-synced or semi-synced client.
Clients MUST respond with at least the first payload that exists in the range, if they have it, and no more than MAX_REQUEST_BLOCKS payloads.
The following payloads, where they exist, MUST be sent in consecutive order.
Clients MAY limit the number of payloads in the response.
The response MUST contain no more than count payloads.
Clients MUST respond with payloads from their view of the current fork choice -- that is, payloads from the single chain defined by the current head. Payloads from slots before finalization MUST lead to the finalized payload reported in the Status handshake.
|
@terencechain just wanted to avoid this repetitions TBH. I don't mind adding that if you fill strongly. |
slotto be present inExecutionPayloadEnvelope