-
Notifications
You must be signed in to change notification settings - Fork 997
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
Incorporate state_transition.py into state transition spec #1018
Conversation
The state transition spec should be reasonably self-contained, limiting the amount of "magic" outside of it. This PR is a first step in this direction, specifically for operation processing.
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.
My first pass.
Generally, I think that's the right direction 👍, but I'd be inclined to favor to see more description in code comment to help understand. :)
specs/core/0_beacon-chain.md
Outdated
process_randao(state, block) | ||
process_eth1_data(state, block) | ||
process_operations(state, block.body) | ||
# verify_block_state_root(state, block) |
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'd say enable it in the spec, and hack it in the tests.
/cc @djrtwo
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.
a bit torn here.
options:
- uncomment and leave as is
- add
verify_state_root
boolean inprocess_block
andstate_transition
and a note about in which context you would run it as True or False (receiving a block vs building a block) - have
verify_block_state_root
live outside of the state transition function entirely and as a note on block validity below.
I think I like (2) the best, but am open to debate.
*
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.
My suggestion would be for the test bench to populate the state_root
immediately prior to verification in case it is set to ZERO_HASH
. That way we can keep the spec clean. Could that work?
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.
some sort of monkey patch?
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.
Yes
Thanks @hwwhww for the good feedback :) I agree regarding comments. The |
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.
like it. a few notes
specs/core/0_beacon-chain.md
Outdated
process_randao(state, block) | ||
process_eth1_data(state, block) | ||
process_operations(state, block.body) | ||
# verify_block_state_root(state, block) |
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.
a bit torn here.
options:
- uncomment and leave as is
- add
verify_state_root
boolean inprocess_block
andstate_transition
and a note about in which context you would run it as True or False (receiving a block vs building a block) - have
verify_block_state_root
live outside of the state transition function entirely and as a note on block validity below.
I think I like (2) the best, but am open to debate.
*
unsure of the exception handling. See #1059 (comment) |
I think we should revert the exception handling here and get it merged and discuss otherwise in #1059 |
Done. Feel free to merge :) |
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.
removing approve to discuss state root validation
@JustinDrake We didn't decide on how to handle state root validation. I moved the Waiting for comment before merge |
Makes sense. I like the idea of inlining it!
We probably want to clean this up eventually but don't want to block this PR. Suggest merging :) |
This PR incorporates
state_transition.py
(along with a significant cleanup) into the state transition spec. This limits "magic" outside of the spec and addresses #946. We generally reduce fluff, increase readability, and reduce line count (20 lines in the spec, 140 lines overall). A bug is also fixed with the addition ofassert state.slot < block.slot
instate_transition
.