-
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
Shard fork choice rule #1773
Shard fork choice rule #1773
Conversation
2a9818b
to
b1b739d
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.
Great start! Did a quick pass. Added some high level comments below, and answered your immediate questions
It might not handle the shard block between the latest finalized slot and the initial shard block slot (PHASE_1_GENESIS_SLOT). Should we keep it?
I'm not sure I follow here. The first shard block would happen at PHASE_1_GENESIS_SLOT
and reference the beacon state at that slot (and thus be in the chain of whatever was finalized prior to that slot)
In get_head: currently using store.block_states[head_beacon_root].shard_states[shard].latest_block_root (the most recent accepted crosslink) as the base shard block. Some sanity confirm would be appreciated.
Sanity checked 👍
I think we still need it in case the beacon chain stale?
I don't think we need this. See my comments below
@djrtwo Thanks for the review!
Ahh this question would be solved by the answer of question 2 😅
ah now i see it, the while loop below it should be able to handle the shard block tree. Thanks! |
2c4d942
to
7a77018
Compare
16b3fba
to
49a900b
Compare
49a900b
to
79b1b4b
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.
great! so close
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.
looks good! (quick comment on multi-line operation style)
9100be6
to
0a107d5
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.
Changelog
- Added a TODO flag for latest message issue. Thanks for the review!
- Added
get_pendings_shard_blocks
per 74204f7#r434780344 - Rework
test_basic
to process multiple beacon blocks and shard blocks- The function
check_pending_shard_blocks
testsget_pendings_shard_blocks
- The function
- Note that for mainnet config, it will run for ~2 epochs
specs/phase1/shard-transition.md
Outdated
@@ -50,6 +50,9 @@ def verify_shard_block_message(beacon_state: BeaconState, | |||
shard: Shard) -> bool: | |||
assert block.shard_parent_root == shard_state.latest_block_root | |||
assert block.slot == slot | |||
next_slot = Slot(beacon_state.slot + 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.
## ISSUE
We have two places call verify_shard_block_message
1. From validator guide get_shard_transition
: beacon_state
the lookahead state where slot = head beacon state slot + 1
2. From shark choice rule on_shard_block
: beacon_state
is the head block.
However, #1704 will remove (1). So I leave it here.
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.
Second thought: #1875
0a107d5
to
a154d0c
Compare
Add check for `block.beacon_parent_root` per Terence's suggestion Update `get_shard_transition` 1. Disable verification: it will be fix in v-guide 2. Use `on_time_slot` to compute offset_slots Rework tests
should be transitioned.
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.
Minor comments. Looking good. Happy to merge soon with #1875
specs/phase1/shard-fork-choice.md
Outdated
# Check the block is valid and compute the post-state | ||
beacon_head_root = get_head(store) | ||
beacon_head_state = store.block_states[beacon_head_root] | ||
assert verify_shard_block_message(beacon_head_state, pre_shard_state, shard_block, shard_block.slot, shard) |
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.
Why do we pass in shard_block.slot
as an independent variable? Is there ever a case that we want the slot
passed in to differ from shard.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.
Yes it seems leftover of outdated assumption. 👍
I realized we can also remove shard
since we got block.shard
, so it's now just verify_shard_block_message(beacon_parent_state, shard_parent_state, block)
🎉
messy drafting!
building test case with #1703 fixes & testing tool.
Questions:
1. Inon_shard_block
, there is a check of "4. Check block is a descendant of the finalized block at the checkpoint finalized slot". It might not handle the shard block between the latest finalized slot and the initial shard block slot (PHASE_1_GENESIS_SLOT
). Should we keep it?get_head
: currently usingstore.block_states[head_beacon_root].shard_states[shard].latest_block_root
(the most recent accepted crosslink) as the base shard block. Some sanity confirm would be appreciated.3. Follow up the discussion in the weekly call,get_filtered_shard_block_tree
is much cleaner than the beacon version (get_filtered_block_tree
), I think we still need it in case the beacon chain stale?TODO