From a9a75a08a0940a492586c619e697604cdb705298 Mon Sep 17 00:00:00 2001 From: tersec Date: Tue, 21 Nov 2023 10:35:57 +0000 Subject: [PATCH 1/2] disallow valid <-> invalid equivocation --- src/engine/paris.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/src/engine/paris.md b/src/engine/paris.md index 3c8e388d6..28fe01c8f 100644 --- a/src/engine/paris.md +++ b/src/engine/paris.md @@ -111,9 +111,11 @@ Payload validation process consists of validating a payload with respect to the 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. +4. Client software **MUST** not classify the same payload as either both `INVALID` and `VALID` or `INVALID_BLOCK_HASH` and `VALID`. -5. The process of validating a payload on the canonical chain **MUST NOT** be affected by an active sync process on a side branch of the block tree. For example, if side branch `B` is `SYNCING` but the requisite data for validating a payload from canonical branch `A` is available, client software **MUST** run full validation of the payload and respond accordingly. +5. 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. + +6. The process of validating a payload on the canonical chain **MUST NOT** be affected by an active sync process on a side branch of the block tree. For example, if side branch `B` is `SYNCING` but the requisite data for validating a payload from canonical branch `A` is available, client software **MUST** run full validation of the payload and respond accordingly. ### Sync From 76da22f20fb83c4ec9fb684a3b4fc6e178fc88bb Mon Sep 17 00:00:00 2001 From: tersec Date: Thu, 7 Dec 2023 09:43:12 +0000 Subject: [PATCH 2/2] Update src/engine/paris.md Co-authored-by: Mikhail Kalinin --- src/engine/paris.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/engine/paris.md b/src/engine/paris.md index 28fe01c8f..9f6661945 100644 --- a/src/engine/paris.md +++ b/src/engine/paris.md @@ -111,7 +111,7 @@ Payload validation process consists of validating a payload with respect to the payload satisfying the above conditions. * Client software **MUST NOT** surface an `INVALID` payload over any API endpoint and p2p interface. -4. Client software **MUST** not classify the same payload as either both `INVALID` and `VALID` or `INVALID_BLOCK_HASH` and `VALID`. +4. Payload validation process **MUST** be idempotent with respect to payload's validity status (`VALID | INVALID`), i.e. a payload which validity status is `INVALID (INVALID_BLOCK_HASH)` **MUST NOT** become `VALID` and vice versa at any point in time when it subsequently runs through the validation process. Client software **MAY** change payload status from `INVALID` to `SYNCING | ACCEPTED` as long as the payload remains `INVALID` as a result of any further run of the validation process. 5. 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.