-
Notifications
You must be signed in to change notification settings - Fork 389
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
Conversation
@@ -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. |
There was a problem hiding this comment.
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:
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?
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
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>
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>
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>
This PR proposes the following cleanups to the Shanghai part of the spec:
INVALID_BLOCK_HASH
status and supplant it withINVALID
, 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
andV2
the latter two changes may become a problem as they seem to be backwards incompatible withV1
. 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 handlestatus: INVALID, latestValidHash: null
in the same way asstatus: INVALID_BLOCK_HASH, latestValidHash: null
, replacing the latter with the former must not change anything.