You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
engine: Make execution requests a sidecar, take 2 (#591)
* engine: extract execution requests from payload
* add executionrequestsv to wordlist
* update engine_getPayloadV4
* Make execution requests a sidecar, take 2
* Turn executionRequests into a sequence of bytes
* Simplify wording
* Clean up wordlist
* Applied suggestions by @marioevz
Co-authored-by: Mario Vega <[email protected]>
* Switch to the nested list representation
* Fix typo
* Apply suggestions from @lucassaldanha
Co-authored-by: Lucas Saldanha <[email protected]>
* Switch getPayloadV4 response to ExecutionPayloadV3
* Replace hash with full executionRequests object for newPayloadV4
* Fix the newPayloadV4 note
* Mention that requestType byte isn't part of encoding
* Mention SSZ encoding in the executionRequests list
* Apply suggestions from @lucassaldanha
Co-authored-by: Lucas Saldanha <[email protected]>
* Update payload.yaml examples
* Drop 32 bytes len from executionRequests definition
* engine: clarification on requests
---------
Co-authored-by: Roman Krasiuk <[email protected]>
Co-authored-by: Mario Vega <[email protected]>
Co-authored-by: Lucas Saldanha <[email protected]>
Co-authored-by: lightclient <[email protected]>
@@ -27,76 +22,20 @@ This specification is based on and extends [Engine API - Cancun](./cancun.md) sp
27
22
28
23
<!-- END doctoc generated TOC please keep comment here to allow auto update -->
29
24
30
-
## Structures
31
-
32
-
### DepositRequestV1
33
-
This structure maps onto the deposit object from [EIP-6110](https://eips.ethereum.org/EIPS/eip-6110).
34
-
The fields are encoded as follows:
35
-
36
-
-`pubkey`: `DATA`, 48 Bytes
37
-
-`withdrawalCredentials`: `DATA`, 32 Bytes
38
-
-`amount`: `QUANTITY`, 64 Bits
39
-
-`signature`: `DATA`, 96 Bytes
40
-
-`index`: `QUANTITY`, 64 Bits
41
-
42
-
*Note:* The `amount` value is represented in Gwei.
43
-
44
-
### WithdrawalRequestV1
45
-
This structure maps onto the withdrawal request from [EIP-7002](https://eips.ethereum.org/EIPS/eip-7002).
46
-
The fields are encoded as follows:
47
-
48
-
-`sourceAddress`: `DATA`, 20 Bytes
49
-
-`validatorPubkey`: `DATA`, 48 Bytes
50
-
-`amount`: `QUANTITY`, 64 Bits
51
-
52
-
*Note:* The `amount` value is represented in Gwei.
53
-
54
-
### ConsolidationRequestV1
55
-
This structure maps onto the consolidation request from [EIP-7251](https://eips.ethereum.org/EIPS/eip-7251).
56
-
The fields are encoded as follows:
57
-
58
-
-`sourceAddress`: `DATA`, 20 Bytes
59
-
-`sourcePubkey`: `DATA`, 48 Bytes
60
-
-`targetPubkey`: `DATA`, 48 Bytes
61
-
62
-
### ExecutionPayloadV4
63
-
64
-
This structure has the syntax of [`ExecutionPayloadV3`](./cancun.md#executionpayloadv3) and appends the new fields: `depositRequests` and `withdrawalRequests`.
65
-
66
-
-`parentHash`: `DATA`, 32 Bytes
67
-
-`feeRecipient`: `DATA`, 20 Bytes
68
-
-`stateRoot`: `DATA`, 32 Bytes
69
-
-`receiptsRoot`: `DATA`, 32 Bytes
70
-
-`logsBloom`: `DATA`, 256 Bytes
71
-
-`prevRandao`: `DATA`, 32 Bytes
72
-
-`blockNumber`: `QUANTITY`, 64 Bits
73
-
-`gasLimit`: `QUANTITY`, 64 Bits
74
-
-`gasUsed`: `QUANTITY`, 64 Bits
75
-
-`timestamp`: `QUANTITY`, 64 Bits
76
-
-`extraData`: `DATA`, 0 to 32 Bytes
77
-
-`baseFeePerGas`: `QUANTITY`, 256 Bits
78
-
-`blockHash`: `DATA`, 32 Bytes
79
-
-`transactions`: `Array of DATA` - Array of transaction objects, each object is a byte list (`DATA`) representing `TransactionType || TransactionPayload` or `LegacyTransaction` as defined in [EIP-2718](https://eips.ethereum.org/EIPS/eip-2718)
80
-
-`withdrawals`: `Array of WithdrawalV1` - Array of withdrawals, each object is an `OBJECT` containing the fields of a `WithdrawalV1` structure.
81
-
-`blobGasUsed`: `QUANTITY`, 64 Bits
82
-
-`excessBlobGas`: `QUANTITY`, 64 Bits
83
-
-`depositRequests`: `Array of DepositRequestV1` - Array of deposits, each object is an `OBJECT` containing the fields of a `DepositRequestV1` structure.
84
-
-`withdrawalRequests`: `Array of WithdrawalRequestV1` - Array of withdrawal requests, each object is an `OBJECT` containing the fields of a `WithdrawalRequestV1` structure.
85
-
-`consolidationRequests`: `Array of ConsolidationRequestV1` - Array of consolidation requests, each object is an `OBJECT` containing the fields of a `ConsolidationRequestV1` structure.
86
-
87
25
## Methods
88
26
89
27
### engine_newPayloadV4
90
28
91
-
The request of this method is updated with [`ExecutionPayloadV4`](#ExecutionPayloadV4).
29
+
Method parameter list is extended with `executionRequests`.
2.`expectedBlobVersionedHashes`: `Array of DATA`, 32 Bytes - Array of expected blob versioned hashes to validate.
99
37
3.`parentBeaconBlockRoot`: `DATA`, 32 Bytes - Root of the parent beacon block.
38
+
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.
100
39
101
40
#### Response
102
41
@@ -108,9 +47,14 @@ This method follows the same specification as [`engine_newPayloadV3`](./cancun.m
108
47
109
48
1. Client software **MUST** return `-38005: Unsupported fork` error if the `timestamp` of the payload does not fall within the time frame of the Prague fork.
110
49
50
+
2. Given the `executionRequests`, client software **MUST** compute the execution requests commitment
51
+
and incorporate it into the `blockHash` validation process.
52
+
That is, if the computed commitment does not match the corresponding commitment in the execution layer block header,
-`blockValue` : `QUANTITY`, 256 Bits - The expected value to be received by the `feeRecipient` in wei
127
71
-`blobsBundle`: [`BlobsBundleV1`](#BlobsBundleV1) - Bundle with data corresponding to blob transactions included into `executionPayload`
128
72
-`shouldOverrideBuilder` : `BOOLEAN` - Suggestion from the execution layer to use this `executionPayload` instead of an externally provided one
73
+
-`executionRequests`: `Array of DATA` - Execution layer triggered requests obtained from the `executionPayload` transaction execution.
129
74
* error: code and message set in case an exception happens while getting the payload.
130
75
131
76
#### Specification
@@ -134,6 +79,8 @@ This method follows the same specification as [`engine_getPayloadV3`](./cancun.m
134
79
135
80
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.
136
81
82
+
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.
83
+
137
84
### Update the methods of previous forks
138
85
139
86
This document defines how Prague payload should be handled by the [`Cancun API`](./cancun.md).
0 commit comments