-
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
Rework shard block and fraud proof (shard state transition) spec #1703
Conversation
4c0afb4
to
3fc86f3
Compare
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.
Wow! I have a lot of comments and there are things to work through, but great job!
This stuff is... complicated. A lot of subtleties and moving parts.
I tried to hit the high points on this wave of review. Let's iterate and I'll do another deeper review after.
(I haven't reviewed the changes/additions to testing yet)
specs/phase1/fraud-proofs.md
Outdated
else: | ||
proposal = get_winning_proposal(beacon_state, choices) | ||
|
||
shard_parent_root = hash_tree_root(proposal.message) |
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.
This will signal that the parent root was an empty proposal. If the shard slot is skipped, then the parent should be the previous non-skipped 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.e., the actual shard chain should only be composed of actual proposals and not these empty skip blocks as flags for the skip slot
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.
Right, shard_parent_root
could be the indicator for some cases, e.g., offset_slots = [x+1, x+2, x+3]
where slot x+1
is non-skipped, x+2
and x+3
slots are skipped.
We can see x+3
is a skipped slot since it shares the same shard_parent_root
as x+2
, but we can't tell if x+2
is skipped from its shard_parent_root
though.
536c073
to
010201c
Compare
Thanks @djrtwo! Changelog
|
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.
awesome!
Another wave of comments. getting close :)
specs/phase1/fraud-proofs.md
Outdated
``` | ||
|
||
```python | ||
def compute_shard_transition_digest(beacon_state: BeaconState, |
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.
This isn't currently a function of the beacon state but could see it using it in Phase 2.
It'd be nice if we get this interface right for Phase. Just a note to think about it some more
specs/phase1/fraud-proofs.md
Outdated
slot: Slot, | ||
shard: Shard) -> bool: | ||
assert block.shard_parent_root == shard_state.latest_block_root | ||
assert block.beacon_parent_root == get_block_root_at_slot(beacon_state, slot) |
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.
This assumes that we won't use this function during the slot that the shard block was created (otherwise get_block_root_at_slot(beacon_state, slot)
would fail).
Do you think this is a safe assumption?
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.
It seems likely due to "TODO these validations should have been checked upon receiving shard blocks" that we might want to have validators use this before attesting during the slot the shard block was created
We can wait until we get back to the validator guide to modify if you want
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, I suppose the shard fork choice rule I'm working on will guarantee the given shard blocks are validated. The validator guide can assume that the validator already has the head shard block. I'll revisit the shard transition section again in the fork choice rule PR or after it.
tests/core/pyspec/eth2spec/test/phase_1/block_processing/test_process_crosslink.py
Outdated
Show resolved
Hide resolved
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 implemented most of these in Prysm phase1 client. Just a few minor comments :)
specs/phase1/fraud-proofs.md
Outdated
``` | ||
|
||
```python | ||
def verify_shard_block_message(beacon_state: BeaconState, |
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.
might be best to move verify_shard_block_message
and verify_shard_block_signature
under helpers since they are only used by helper methods
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.
Yep! To make less burden for the reviewers, I'll rearrange the code sections at the end of this PR review.
specs/phase1/fraud-proofs.md
Outdated
### Shard state transition function | ||
|
||
```python | ||
def shard_state_transition(beacon_state: BeaconState, |
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 naming of shard_state_transition
is pretty similar to get_shard_transition
, but I can't think of a better name now...
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.
Yeah "transition" is everywhere 😅
Open to suggestions!
1b11dff
to
055d5e0
Compare
Substantive changelog
|
Note, |
Looks good in general! I'm happy to merge soon and move on with subsequent testing PRs |
`get_shard_committee`
Co-Authored-By: terence tsao <[email protected]>
Fix the wrong `get_shard_proposer_index` parameters order Phase 1 WIP Add shard transition basic test Fix lint error Fix
Co-Authored-By: Danny Ryan <[email protected]>
PR feedback from Danny and some refactor 1. Add stub `PHASE_1_GENESIS_SLOT` 2. Rename `get_updated_gasprice` to `compute_updated_gasprice` 3. Rename `compute_shard_data_roots` to `compute_shard_body_roots` Apply shard transition for the skipped slots Refactor `shard_state_transition` Get `beacon_parent_root` from offset slot Add more test Add `verify_shard_block_message` Add `> 0` Keep `beacon_parent_block` unchanged in `is_valid_fraud_proof` Remove some lines Fix type Refactor + simplify skipped slot processing
Use `ShardBlock` in `shard_state_transition` PR feedback 1. Rename `ShardState.data` -> `ShardState.transition_digest` 2. Rename `compute_shard_transition_data` to `compute_shard_transition_digest` 3. Add `assert state.slot > PHASE_1_GENESIS_SLOT` just in case, may move it later Add `get_post_shard_state` as a pure function wrapper
Co-Authored-By: Danny Ryan <[email protected]>
Fix wrong field names Fix `build_attestation_data` and other PR feedback from Danny and Terence 1. Rename `get_previous_slot` to `compute_previous_slot` 2. Break down `build_empty_block` into `get_state_and_beacon_parent_root_at_slot`, use it in `build_shard_block` 3. Set defult `slot` to `shard_state.slot + 1` in `build_shard_block` Update `verify_shard_block_message`: check beacon_parent_root at fork choice rule stage instead of state transition Fix `beacon-chain.md` 1. Fix typo `attestation.slot == state.slot` -> `attestation.data.slot == state.slot` in `is_winning_attestation` 2. Check `verify_shard_transition_false_positives` **after** `process_operations` 3. Fix `shard_attestations` filter in `process_crosslinks`: since attestations come from block, should use `attestation.data.slot + MIN_ATTESTATION_INCLUSION_DELAY == state.slot` 4. [TBD] Allow empty `light_client_signature` to make the tests pass 5. [TBD] Add `is_shard_attestation`, filter out empty `ShardTransition()` Rework `test_process_crosslink` Add basic phase 1 `test_blocks` Add more test cases Revert `is_shard_attestation` and fix test cases backward compatibility. Remove `test_process_beacon_block_no_shard_transition` and consider it as invalid case.
2c4d942
to
7a77018
Compare
👍 Added a comment to note that.
I refactored the tests and I'm happier with it now 😄 |
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.
great job!
lets mergee
Issue
How did I fix it
beacon-chain.md
proposer_index
to shard block since the proposal index helps clients to validate the block in network level.get_light_client_committee
a bit.get_shard_proposer_index
function callsapply_shard_transition
attestation.slot == state.slot
->attestation.data.slot == state.slot
inis_winning_attestation
verify_shard_transition_false_positives
afterprocess_operations
shard_attestations
filter inprocess_crosslinks
: since attestations come from block, should useattestation.data.slot + MIN_ATTESTATION_INCLUSION_DELAY == state.slot
light_client_signature
to make the tests passphase1-fork.md
:PHASE_1_GENESIS_SLOT
, set it toSLOTS_PER_EPOCH
now.