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.

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

engine: exclude empty requests in requests list #599

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open
Changes from all commits
Commits
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: 2 additions & 2 deletions src/engine/prague.md
Original file line number Diff line number Diff line change
Expand Up @@ -35,7 +35,7 @@ Method parameter list is extended with `executionRequests`.
1. `executionPayload`: [`ExecutionPayloadV3`](./cancun.md#executionpayloadv3).
2. `expectedBlobVersionedHashes`: `Array of DATA`, 32 Bytes - Array of expected blob versioned hashes to validate.
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.
4. `executionRequests`: `Array of DATA` - List of execution layer triggered requests. Each list element is a `requests` byte array as defined by [EIP-7685](https://eips.ethereum.org/EIPS/eip-7685). The first byte of each element is the `request_type` and the remaining bytes are the `request_data`. Elements of the list **MUST** be ordered by `request_type` in ascending order. Elements with empty `request_data` are excluded from the list.
Copy link
Contributor

Choose a reason for hiding this comment

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

Elements with empty request_data are excluded from the list.

Is it worth mentioning in the case that all 3 (deposit, withdrawal, consolidation) requests are missing, executionRequests will still contain an empty array?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Do you feel strongly that it has to be mentioned? All other parameters are also mandatory, but we do not write "parentBeaconBlockRoot must not be null" either. I feel that the type, Array of DATA, already means it will always be present and a JSON array.


#### Response

Expand Down Expand Up @@ -79,7 +79,7 @@ This method follows the same specification as [`engine_getPayloadV3`](./cancun.m

1. Client software **MUST** return `-38005: Unsupported fork` error if the `timestamp` of the built payload does not fall within the time frame of the Prague fork.

2. The call **MUST** return `executionRequests` list representing execution layer triggered requests obtained from the `executionPayload` transaction execution. Each element of the list corresponds to the 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.
2. The call **MUST** return `executionRequests` list representing execution layer triggered requests. Each list element is a `requests` byte array as defined by [EIP-7685](https://eips.ethereum.org/EIPS/eip-7685). The first byte of each element is the `request_type` and the remaining bytes are the `request_data`. Elements of the list **MUST** be ordered by `request_type` in ascending order. Elements with empty `request_data` are excluded from the list.

### Update the methods of previous forks

Expand Down
Loading