-
Notifications
You must be signed in to change notification settings - Fork 5.3k
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
base: master
Are you sure you want to change the base?
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.
File
|
for r in requests: | ||
m.update(sha256(r)) | ||
for r in block_requests: | ||
if len(r) > 1: |
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.
Ok, this works, but this assumes that request_type
is one byte, which is not specified.
I would also somewhere note that this thus checks that there is any request_data
(without request_data
then r
len is indeed 1 (assuming that it is a Bytes1
type)). I initially thought this was off and should be len(r) >= 1
.
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.
The type will always be one byte. We should probably add that to the EIP.
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
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