`PayloadAttributesV1` in spec is consistent with either `engine_forkchoiceUpdatedV1`/`V2` but not `V3`
tersec opened this issue · comments
https://github.com/ethereum/execution-apis/blob/v1.0.0-beta.4/src/engine/shanghai.md#request-1
payloadAttributes
:Object|null
- instance ofPayloadAttributesV1
|PayloadAttributesV2
ornull
, where:
PayloadAttributesV1
MUST be used to build a payload with thetimestamp
value lower than the Shanghai timestamp,PayloadAttributesV2
MUST be used to build a payload with thetimestamp
value greater or equal to the Shanghai timestamp,- Client software MUST return
-32602: Invalid params
error if the wrong version of the structure is used in the method call.
i.e. a payload with the timestamp
value lower than the Shanghai timestamp (which implies a headBlockHash
corresponding similarly to a block with a timestamp strictly lower than the payload timestamp
, i.e. also lower than the Shanghai timestamp), is compatible with either fcuV1 or fcuV2, but not fcuV3, per https://github.com/ethereum/execution-apis/blob/v1.0.0-beta.4/src/engine/cancun.md#request-1
forkchoiceState
:ForkchoiceStateV1
.payloadAttributes
:Object|null
- Instance ofPayloadAttributesV3
ornull
....
payloadAttributes.timestamp
falls within the time frame of the Cancun fork, return-38005: Unsupported fork
on failure.
(with Prague not defining its own fcuV4, it doesn't work in Prague for the fcuV3 validation to be as strict as "within the time frame of the Cancun fork", but would have to be read as within the Cancun or Prague fork, but it does not appear the engine API specs as of v1.0.0-beta.4 acknowledge this; separate issue, in any case)
Indeed, the verbiage around allowing headBlockHash
for fcuV2 corresponding to Paris prevents fcUV1 from being used for Shanghai but not fcuV2 being used for Paris:
- Consensus layer client MUST call this method instead of
engine_forkchoiceUpdatedV1
under any of the following conditions:
headBlockHash
references a block whichtimestamp
is greater or equal to the Shanghai timestamp,payloadAttributes
is notnull
andpayloadAttributes.timestamp
is greater or equal to the Shanghai timestamp.
However,
nimbus-eth1/nimbus/beacon/api_handler/api_forkchoice.nim
Lines 67 to 70 in d795a0e
rejects not only fcUV3/non-null
PayloadAttributesV1
/Paris head block (validly, as that's not a valid combination) but also fcUV2/PayloadAttributesV2
/Paris head block (not validly, because that is an allowed combination).
One weird edge case here is, in the fcuV3/null PayloadAttributes
/Paris or Shanghai head block, is that allowed. The spec isn't very clear here; null
is allowed as one of the payloadAttributes
parameters, but the fcU3 spec goes out of its way to disallow non-null
PayloadAttributesV1
/V2
exactly the same way fcUV2
goes out of its way to allow non-null
PayloadAttributesV1
so there's some evident intent to close down backwards compatibility.
But at least fcuV2 should allow Paris payloads/head blocks, that much seems evident.