-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
Update EIP-7685: exclude empty requests data in commitment #8989
Conversation
Here I am proposing to change the `requests_hash` commitment so that empty items are excluded. The point of this is to ensure a stable empty requests hash which is independent of fork. Having such a hash makes testing a lot easier, and it mirrors how other execution-layer commitments behave.
✅ All reviewers have approved. |
To me this is already a good reason for the change! :) |
The `requestType` of empty lists is no longer part of the requests hash. - ethereum/EIPs#8989
EIPS/eip-7685.md
Outdated
m.update(sha256(r)) | ||
for r in block_requests: | ||
if len(r) > 1: | ||
m.update(sha256(r)) |
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.
m.update(sha256(r)) | |
m.update(sha256(r).digest()) |
* Adopt latest changes to request hash computation The `requestType` of empty lists is no longer part of the requests hash. - ethereum/EIPs#8989 * Avoid nested computeDigest scopes
With this change the order of requests by type is only mentioned in the Rationale which seems to be wrong. The ordering should be either explicitly specified by saying that |
Co-authored-by: Mikhail Kalinin <[email protected]>
I have pushed a more thorough rewrite of the description of the commitment. |
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
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.
All Reviewers Have Approved; Performing Automatic Merge...
Implements changes from these spec PRs: - ethereum/EIPs#8989 - ethereum/execution-apis#599
Apply the [EIP-7685 update] included in [pectra-devnet-5]. [EIP-7685 update]: ethereum/EIPs#8989 [pectra-devnet-5]: https://notes.ethereum.org/@ethpandaops/pectra-devnet-5
The updated EIP-7685 says requests with empty `request_data` should be dropped from `executionRequests` field in the API and ignored for hash calculation. See ethereum/EIPs#8989, ethereum/execution-apis#599 Issue board: #12401
The updated EIP-7685 says requests with empty `request_data` should be dropped from `executionRequests` field in the API and ignored for hash calculation. See ethereum/EIPs#8989, ethereum/execution-apis#599 Issue board: #12401
Apply the [EIP-7685 update] included in [pectra-devnet-5]. [EIP-7685 update]: ethereum/EIPs#8989 [pectra-devnet-5]: https://notes.ethereum.org/@ethpandaops/pectra-devnet-5
The updated EIP-7685 says requests with empty `request_data` should be dropped from `executionRequests` field in the API and ignored for hash calculation. See ethereum/EIPs#8989, ethereum/execution-apis#599 Issue board: #12401 Cherry pick #12985
Apply the [EIP-7685 update] included in [pectra-devnet-5]. [EIP-7685 update]: ethereum/EIPs#8989 [pectra-devnet-5]: https://notes.ethereum.org/@ethpandaops/pectra-devnet-5
Apply the [EIP-7685 update] included in [pectra-devnet-5]. [EIP-7685 update]: ethereum/EIPs#8989 [pectra-devnet-5]: https://notes.ethereum.org/@ethpandaops/pectra-devnet-5 This requires a fix in tests for calldata repricing logic according to ethereum/EIPs#9227
Implements changes from these spec PRs: - ethereum/EIPs#8989 - ethereum/execution-apis#599
Here I am proposing to change the
requests_hash
commitment so that empty items are excluded. The point of this is to ensure a stable empty requests hash which is independent of fork. Having such a hash makes testing a lot easier, and it mirrors how other execution-layer commitments behave.There is also a corresponding engine API change: ethereum/execution-apis#599