Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

disallow VALID <-> INVALID equivocation #493

Merged
merged 2 commits into from
Dec 13, 2023
Merged
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 4 additions & 2 deletions src/engine/paris.md
Original file line number Diff line number Diff line change
Expand Up @@ -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`.
mkalinin marked this conversation as resolved.
Show resolved Hide resolved
tersec marked this conversation as resolved.
Show resolved Hide resolved

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

Expand Down
Loading