diff --git a/src/engine/specification.md b/src/engine/specification.md index 6536bb12b..efbfb2c18 100644 --- a/src/engine/specification.md +++ b/src/engine/specification.md @@ -219,8 +219,13 @@ Payload validation process consists of validating a payload with respect to the 3. Client software **MUST** validate a payload according to the block header and execution environment rule set with modifications to these rule sets defined in the [Block Validity](https://eips.ethereum.org/EIPS/eip-3675#block-validity) section of [EIP-3675](https://eips.ethereum.org/EIPS/eip-3675#specification): * If validation succeeds, the response **MUST** contain `{status: VALID, latestValidHash: payload.blockHash}` - * If validation fails, the response **MUST** contain `{status: INVALID, latestValidHash: validHash}` where `validHash` is the block hash of the most recent *valid* ancestor of the invalid payload. That is, the valid ancestor of the payload with the highest `blockNumber` - * If the most recent valid ancestor is a PoW block, `latestValidHash` **MUST** be set to `0x0000000000000000000000000000000000000000000000000000000000000000` + * If validation fails, the response **MUST** contain `{status: INVALID, latestValidHash: validHash}` where `validHash` **MUST** be: + - The block hash of the ancestor of the invalid payload satisfying the following two conditions: + - It is fully validated and deemed `VALID` + - Any other ancestor of the invalid payload with a higher `blockNumber` is `INVALID` + - `0x0000000000000000000000000000000000000000000000000000000000000000` if the above conditions are satisfied by a PoW block. + - `null` if client software cannot determine the ancestor of the invalid + payload satisfying the above conditions. * Client software **MUST NOT** surface an `INVALID` payload over any API endpoint and p2p interface. 4. Client software **MAY** provide additional details on the validation error if a payload is deemed `INVALID` by assigning the corresponding message to the `validationError` field.