Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

elaborate on SSZ serialization of execution requests #597

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

elaborate on SSZ serialization of execution requests #597

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 4 additions & 0 deletions src/engine/prague.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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


#### Response

Refer to the response for [`engine_newPayloadV3`](./cancun.md#engine_newpayloadv3).
Expand Down Expand Up @@ -73,6 +75,8 @@ The response of this method is extended with the `executionRequests` field.
- `executionRequests`: `Array of DATA` - Execution layer triggered requests obtained from the `executionPayload` transaction execution.
* error: code and message set in case an exception happens while getting the payload.

**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.

#### Specification

This method follows the same specification as [`engine_getPayloadV3`](./cancun.md#engine_getpayloadv3) with the following changes:
Expand Down
Loading