-
Notifications
You must be signed in to change notification settings - Fork 169
feat(tools,forks): Extend EEST to support EIP-7928 payload #1866
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
Draft
raxhvl
wants to merge
12
commits into
feat/block-access-list
Choose a base branch
from
feat/eip-7928/framework-updates
base: feat/block-access-list
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Draft
Changes from all commits
Commits
Show all changes
12 commits
Select commit
Hold shift + click to select a range
4172364
✨ feat(EIP-7928): Add BAL header
raxhvl 0723798
🧹 chore(EIP-7928): bal_hash header
raxhvl fc4b64e
🧹 chore: Revert changes to EELS resolution
raxhvl 9fcf163
🧹 chore: Populate bal_hash env
raxhvl 3c19014
✨ feat(EIP-7928): Add BAL to block body
raxhvl d79a022
✨ feat(EIP-7928): Add pokebal package
raxhvl ecd4047
✨ feat: update env
raxhvl 1ad04f0
✨ feat: Engine API specs
raxhvl c990f17
🧹 chore: remove pokebal
raxhvl 02c43c2
🐞 fix: bal_hash validation
raxhvl 64a3a99
🧹 chore: consistent naming for bal payload
raxhvl 8b1275b
🧹 chore: clear test file
raxhvl File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
I feel this belongs to the
Result
returned from the transition tool after executing the state transition.Environment
is more for things that affect the EVM execution and/or are observable in the EVM context.If we put it in
Result
, we can catch it in here:execution-spec-tests/src/ethereum_test_specs/blockchain.py
Lines 522 to 533 in 485ff27
and then even verify it during the test by using
header_verify
as in this example here.Uh oh!
There was an error while loading. Please reload this page.
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.
Hi @marioevz I see this differently. The test supplies the following to the client as part of a block:
In the PR (1) and (2) is part of a test. (3) is computed by the framework from (2).
State transition
The client's state transition function takes all three to produce a block. In addition to executing the transactions, the client:
The Client and NOT test verifies hash
The client MUST reject the block if computed hash does not match the provided one. ref: spec
If hash is not supplied as an input to the client it will not be able to perform this check. Hence its inclusion in
ENV
.Uh oh!
There was an error while loading. Please reload this page.
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.
Let me know if I misunderstood anything in this flow.
We are trying to fill tests here to generate a test fixture with a built block to then test against clients. So we are essentially testing the EL's ability to locally build a valid block when we're filling tests. This block is then sent as a payload to a client via the test fixture. So I feel like we could actually perform the check at the
Result
level here. If we build our BALs and compute our own hash to check against, what we need from the filler (let's say this is EELS) is that they compute their own BALs internally, generate the hash, and we validate that this hash is the expected hash in the result withheader_verify=Header(bal_hash=correct_bal_hash)
. And we can test any invalid cases withrlp_modifier=Header(bal_hash=invalid_bal_hash)
andexception=BlockException.INVALID_BLOCK_HASH
(or a more appropriate bal hash exception).I think this comes into play when we're executing the test payload against a client. They will now have a filled block in the test fixture, with the hash that we validated is correct, and they should indeed correctly raise on an invalid hash according to the spec.
Am I missing anything @raxhvl? Does this go along with what you were thinking @marioevz?