From 079978852ee4eb8e7c520460066720c5fc630f90 Mon Sep 17 00:00:00 2001 From: Potuz Date: Mon, 4 Jul 2022 16:50:57 -0300 Subject: [PATCH 1/5] Make explicit that the child of LVH is INVALID --- src/engine/specification.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/engine/specification.md b/src/engine/specification.md index 1cb9a354e..9aaa7f094 100644 --- a/src/engine/specification.md +++ b/src/engine/specification.md @@ -219,7 +219,9 @@ 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 validation fails, the response **MUST** contain `{status: INVALID, latestValidHash: validHash}` where `validHash` is the block hash of the unique ancestor of the invalid payload satisfying the following two conditions: + - It is `VALID` + - Any other ancestor of the invalid payload with a higher `blockNumber` is `INVALID` * If the most recent valid ancestor is a PoW block, `latestValidHash` **MUST** be set to `0x0000000000000000000000000000000000000000000000000000000000000000` * Client software **MUST NOT** surface an `INVALID` payload over any API endpoint and p2p interface. From 7b0ac66e3626f61681ac2a299e33ccbdd08443e5 Mon Sep 17 00:00:00 2001 From: Potuz Date: Thu, 7 Jul 2022 08:00:11 -0300 Subject: [PATCH 2/5] Update src/engine/specification.md Co-authored-by: Mikhail Kalinin --- src/engine/specification.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/engine/specification.md b/src/engine/specification.md index 9aaa7f094..a117b9926 100644 --- a/src/engine/specification.md +++ b/src/engine/specification.md @@ -220,7 +220,7 @@ 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 unique ancestor of the invalid payload satisfying the following two conditions: - - It is `VALID` + - It is fully validated and deemed `VALID` - Any other ancestor of the invalid payload with a higher `blockNumber` is `INVALID` * If the most recent valid ancestor is a PoW block, `latestValidHash` **MUST** be set to `0x0000000000000000000000000000000000000000000000000000000000000000` * Client software **MUST NOT** surface an `INVALID` payload over any API endpoint and p2p interface. From 7b358539e1fa108e9843dea00209f53cf51585e9 Mon Sep 17 00:00:00 2001 From: Potuz Date: Thu, 7 Jul 2022 08:03:28 -0300 Subject: [PATCH 3/5] add null option for validhash --- src/engine/specification.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/engine/specification.md b/src/engine/specification.md index a117b9926..c15157cb1 100644 --- a/src/engine/specification.md +++ b/src/engine/specification.md @@ -219,7 +219,7 @@ 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 unique ancestor of the invalid payload satisfying the following two conditions: + * If validation fails, the response **MUST** contain `{status: INVALID, latestValidHash: validHash}` where `validHash` is either `null`, or the block hash of the unique 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` * If the most recent valid ancestor is a PoW block, `latestValidHash` **MUST** be set to `0x0000000000000000000000000000000000000000000000000000000000000000` From 0cbe3943af218a63a3c35f02473da0be287b3b74 Mon Sep 17 00:00:00 2001 From: Potuz Date: Sat, 9 Jul 2022 06:46:00 -0300 Subject: [PATCH 4/5] specify that null is only allowed when the block does not exist --- src/engine/specification.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/src/engine/specification.md b/src/engine/specification.md index c15157cb1..80045a708 100644 --- a/src/engine/specification.md +++ b/src/engine/specification.md @@ -219,10 +219,11 @@ 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 either `null`, or the block hash of the unique ancestor of the invalid payload satisfying the following two conditions: + * If validation fails, the response **MUST** contain `{status: INVALID, latestValidHash: validHash}` where `validHash` is the block hash of the unique 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` - * If the most recent valid ancestor is a PoW block, `latestValidHash` **MUST** be set to `0x0000000000000000000000000000000000000000000000000000000000000000` + + if such a block exists and is a PoS block. `validHash` is `0x0000000000000000000000000000000000000000000000000000000000000000` if such a block exists and it is a PoW block, and `null` otherwise. * 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. From 5a6b5e8c74c82d6a5422a859644c2dcf9fefeaaf Mon Sep 17 00:00:00 2001 From: Potuz Date: Mon, 11 Jul 2022 13:09:42 -0300 Subject: [PATCH 5/5] Andrew+Misha's comment --- src/engine/specification.md | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/src/engine/specification.md b/src/engine/specification.md index 80045a708..75cb70a2c 100644 --- a/src/engine/specification.md +++ b/src/engine/specification.md @@ -219,11 +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 unique 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` - - if such a block exists and is a PoS block. `validHash` is `0x0000000000000000000000000000000000000000000000000000000000000000` if such a block exists and it is a PoW block, and `null` otherwise. + * 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.