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.

Sign up for GitHub

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

Make explicit that the child of LVH is INVALID #254

Merged
merged 5 commits into from
Jul 14, 2022
Merged

Make explicit that the child of LVH is INVALID #254

Changes from all commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
0799788
Make explicit that the child of LVH is INVALID
potuz Jul 4, 2022
7b0ac66
Update src/engine/specification.md
potuz Jul 7, 2022
7b35853
add null option for validhash
potuz Jul 7, 2022
0cbe394
specify that null is only allowed when the block does not exist
potuz Jul 9, 2022
5a6b5e8
Andrew+Misha's comment
potuz Jul 11, 2022
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
9 changes: 7 additions & 2 deletions src/engine/specification.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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.
Expand Down