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

Engine API: a bunch of cleanups #338

Merged
merged 1 commit into from
Jan 12, 2023
Merged

Conversation

mkalinin
Copy link
Collaborator

This PR proposes the following cleanups to the Shanghai part of the spec:

  • Sets timeouts whenever missed
  • Makes validation of terminal PoW block conditions optional, so, client devs may remove it if they want
  • Requires EL clients to stop using INVALID_BLOCK_HASH status and supplant it with INVALID, see [RFC] Engine API: remove INVALID_BLOCK_HASH #270 for details (should be a one liner, if not let's debate)

If EL client implementations use the same piece of code for both V1 and V2 the latter two changes may become a problem as they seem to be backwards incompatible with V1. Though, practically it isn't that true as the transition has happened quite long time ago and having no TTD validation should not break anything except for Hive tests (though we should probably remove transition tests from Hive). All CL clients handle status: INVALID, latestValidHash: null in the same way as status: INVALID_BLOCK_HASH, latestValidHash: null, replacing the latter with the former must not change anything.

@@ -92,6 +95,8 @@ This method follows the same specification as [`engine_newPayloadV1`](./paris.md
Similarly, if the functionality is not activated, client software **MUST** return an `INVALID` status with the appropriate `latestValidHash` if `payloadAttributes.withdrawals` is not `null`.
Blocks without withdrawals **MUST** be expressed with an explicit empty list `[]` value.
Refer to the validity conditions for [`engine_newPayloadV1`](./paris.md#engine_newpayloadv1) to specification of the appropriate `latestValidHash` value.
2. Client software **MAY NOT** validate terminal PoW block conditions during payload validation (point (2) in the [Payload validation](./paris.md#payload-validation) routine).
3. Client software **MUST** return `{status: INVALID, latestValidHash: null, validationError: errorMessage | null}` if the `blockHash` validation has failed.
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Alternatively, we may spec this part as following:

Suggested change
3. Client software **MUST** return `{status: INVALID, latestValidHash: null, validationError: errorMessage | null}` if the `blockHash` validation has failed.
3. Client software **SHOULD** return `{status: INVALID, latestValidHash: null, validationError: errorMessage | null}` if the `blockHash` validation has failed.

This allows clients and tests to keep using INVALID_BLOCK_HASH, i.e. no mandatory changes to the client code are imposed by this PR. @lightclient thoughts?

Copy link
Contributor

Choose a reason for hiding this comment

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

if we want to leave the old path open, I think it has to be MUST and then specify it must be one or the other. otherwise, the way SHOULD reads is that they can deprecate the old path and then choice to respond this way or not

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

With a MUST V1 responds with INVALID_BLOCK_HASH while V2 must not do that, which makes it more difficult to use the same handler for both versions of the method. I would keep MUST and re-iterate if pushback.

Copy link
Contributor

@djrtwo djrtwo left a comment

Choose a reason for hiding this comment

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

lgtm

@mkalinin mkalinin merged commit cdc0f5c into ethereum:main Jan 12, 2023
siladu added a commit to hyperledger/besu that referenced this pull request Jan 18, 2023
Update engine API to include some new changes introduced in 
- ethereum/execution-apis#338
- ethereum/execution-apis#337

Signed-off-by: Simon Dudley <simon.dudley@consensys.net>
Signed-off-by: Zhenyang Shi <wcgcyx@gmail.com>
Co-authored-by: Simon Dudley <simon.dudley@consensys.net>
yperbasis added a commit to erigontech/erigon that referenced this pull request Jan 23, 2023
elenduuche pushed a commit to elenduuche/besu that referenced this pull request Aug 16, 2023
Update engine API to include some new changes introduced in 
- ethereum/execution-apis#338
- ethereum/execution-apis#337

Signed-off-by: Simon Dudley <simon.dudley@consensys.net>
Signed-off-by: Zhenyang Shi <wcgcyx@gmail.com>
Co-authored-by: Simon Dudley <simon.dudley@consensys.net>
eum602 pushed a commit to lacchain/besu that referenced this pull request Nov 3, 2023
Update engine API to include some new changes introduced in 
- ethereum/execution-apis#338
- ethereum/execution-apis#337

Signed-off-by: Simon Dudley <simon.dudley@consensys.net>
Signed-off-by: Zhenyang Shi <wcgcyx@gmail.com>
Co-authored-by: Simon Dudley <simon.dudley@consensys.net>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants