Update eip7928.md #711
Update eip7928.md #711
Conversation
I have added one specification for the `engine_newPayloadV5` method.
According to the Amsterdam upgrade, when the `blockAccessList` field is missing in `engine_newPayloadV5`, the error message: `-32602: Invalid params` should be returned. However, without specifying which error code should be returned, the `{status: INVALID, latestValidHash: null, validationError: errorMessage | null}` may be wrongly returned according to the previous description, which may lead to inconsistencies among clients. Therefore, I think it is necessary to clearly specify the should-be-returned error code.
| 1. Client software **MUST** return `-38005: Unsupported fork` error if the `timestamp` of the payload does not fall within the time frame of the EIP-7928 activation. | ||
|
|
||
| 2. Client software **MUST** validate the `blockAccessList` field by executing the payload's transactions and verifying that the computed access list matches the provided one. | ||
| 2. Client software **MUST** return `-32602: Invalid params` error if the `blockAccessList` field is missing. |
There was a problem hiding this comment.
- Client software MUST check that provided set of parameters and their fields strictly matches the expected one and return
-32602: Invalid params errorif this check fails. Any field havingnullvalue MUST be considered as not provided.
Which kind of covers this case, but it might be missed because stated two forks ago. So, it is probably a good practice to be specific about new fields that must be checked when processing a call of a new version of a method
|
Hi @mkalinin , The reason I submitted this PR is that I observed the text in the The main point is that in Therefore, I believe one of these two files should be modified or one should be deleted to avoid inconsistent behavior caused by client developers using two different specifications. |
|
Given that EIP-7928 is SFIed for Amsterdam, I think it makes sense to remove eip7928 doc from the spec and use amsterdam doc in its replacement. cc @nerolation |
|
Closing in favour of #715 |
2 participants
I have added one specification for the
engine_newPayloadV5method.According to the Amsterdam upgrade, when the
blockAccessListfield is missing inengine_newPayloadV5, the error message:-32602: Invalid paramsshould be returned. However, without specifying which error code should be returned, the{status: INVALID, latestValidHash: null, validationError: errorMessage | null}may be wrongly returned according to the previous description, which may lead to inconsistencies among clients. Therefore, I think it is necessary to clearly specify the should-be-returned error code.