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

Clarify the difference between SYNCING and ACCEPTED #215

Merged
merged 2 commits into from
May 13, 2022
Merged

Clarify the difference between SYNCING and ACCEPTED #215

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
dbed838
Clarify the difference between SYNCING and ACCEPTED
djrtwo May 3, 2022
839fb32
add clarification of accepted
djrtwo May 13, 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
7 changes: 4 additions & 3 deletions src/engine/specification.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -259,12 +259,13 @@ The payload build process is specified as follows:
5. Client software **MUST** respond to this method call in the following way:
* `{status: INVALID_BLOCK_HASH, latestValidHash: null, validationError: errorMessage | null}` if the `blockHash` validation has failed
* `{status: INVALID_TERMINAL_BLOCK, latestValidHash: null, validationError: errorMessage | null}` if terminal block conditions are not satisfied
* `{status: SYNCING, latestValidHash: null, validationError: null}` if the payload extends the canonical chain and requisite data for its validation is missing
* `{status: SYNCING, latestValidHash: null, validationError: null}` if requisite data for the payload's acceptance or validation is missing
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it worth adding something like "all ancestors of the payload are known and comprise a well-formed chain" to {status: ACCEPTED ... statement below. Otherwise, it's not clear that ACCEPTED may only be returned when a chain of payload's ancestors is known.

* with the payload status obtained from the [Payload validation](#payload-validation) process if the payload has been fully validated while processing the call
* `{status: ACCEPTED, latestValidHash: null, validationError: null}` if the following conditions are met:
- the `blockHash` of the payload is valid
- the payload doesn't extend the canonical chain
- the payload hasn't been fully validated.
- the payload hasn't been fully validated
- ancestors of a payload are know and comprise a well-formed chain.

6. If any of the above fails due to errors unrelated to the normal processing flow of the method, client software **MUST** respond with an error object.

Expand Down Expand Up @@ -364,4 +365,4 @@ The payload build process is specified as follows:

6. Considering the absence of the `TERMINAL_BLOCK_NUMBER` setting, Consensus Layer client software **MAY** use `0` value for the `terminalBlockNumber` field in the input parameters of this call.

[json-rpc-spec]: https://playground.open-rpc.org/?schemaUrl=https://raw.githubusercontent.com/ethereum/execution-apis/assembled-spec/openrpc.json&uiSchema[appBar][ui:splitView]=false&uiSchema[appBar][ui:input]=false&uiSchema[appBar][ui:examplesDropdown]=false
[json-rpc-spec]: https://playground.open-rpc.org/?schemaUrl=https://raw.githubusercontent.com/ethereum/execution-apis/assembled-spec/openrpc.json&uiSchema[appBar][ui:splitView]=false&uiSchema[appBar][ui:input]=false&uiSchema[appBar][ui:examplesDropdown]=false