elaborate on SSZ serialization of execution requests #597
Conversation
| @@ -37,6 +37,8 @@ Method parameter list is extended with `executionRequests`. | |||
| 3. `parentBeaconBlockRoot`: `DATA`, 32 Bytes - Root of the parent beacon block. | |||
| 4. `executionRequests`: `Array of DATA` - List of execution layer triggered requests. Each list element is the corresponding request type's `request_data` as defined by [EIP-7685](https://eips.ethereum.org/EIPS/eip-7685). Elements of the list **MUST** be ordered by `request_type` in ascending order. | |||
|
|
|||
| **NOTE**: Each element of `executionRequests` is the SSZ serialization of the corresponding field of [`ExecutionRequests` defined in the `consensus-specs`](https://github.com/ethereum/consensus-specs/blob/dev/specs/electra/beacon-chain.md#executionrequests), such that the 0th element is the first field of that container, 1st element is the second field, and so on. | |||
There was a problem hiding this comment.
I think we should move the SSZ part to the param description, while ordering seems to be handled by ethereum/consensus-specs#3976 and not necessary to be in the engine API spec as from what I can see it's mostly related to the consensus layer
There was a problem hiding this comment.
yeah, I moved it there just as the line of text was getting quite long as I was typing the addition out
can try to squeeze it in
There was a problem hiding this comment.
if we drop the ordering though then its not clear which field should be which element in the list
I would think about this in the direction of making the Engine API specs as self-contained as possible
There was a problem hiding this comment.
The order is defined by eip7685 and it actually no matter the order in which fields in the CL container are defined, CL just have to adhere to the eip likewise the engine API and EL
follow up to #591, to pair with ethereum/consensus-specs#3972