Skip to content
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

Merged
merged 29 commits into from
Jun 8, 2020
Merged

Shard fork choice rule #1773

merged 29 commits into from
Jun 8, 2020

Conversation

hwwhww
Copy link
Contributor

@hwwhww hwwhww commented Apr 29, 2020

messy drafting!
building test case with #1703 fixes & testing tool.

Questions:

  • 1. In on_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?
  • 2. 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.
  • 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

  • add more tests

Copy link
Contributor

@djrtwo djrtwo left a 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

specs/phase1/shard-fork-choice.md Outdated Show resolved Hide resolved
specs/phase1/shard-fork-choice.md Outdated Show resolved Hide resolved
specs/phase1/shard-fork-choice.md Outdated Show resolved Hide resolved
specs/phase1/shard-fork-choice.md Outdated Show resolved Hide resolved
@hwwhww
Copy link
Contributor Author

hwwhww commented May 1, 2020

@djrtwo Thanks for the review!

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)

Ahh this question would be solved by the answer of question 2 😅
Unrelated FYI: in upgrade_to_phase1, we set the initial shard_state.slot to PHASE_1_GENESIS_SLOT. So the first valid shard block would be at slot PHASE_1_GENESIS_SLOT + 1. Which means, after beacon state transition:

  1. if state.slot == PHASE_1_GENESIS_SLOT, then state.shard_states[shard].slot == state.slot
  2. else, state.shard_states[shard].slot < state.slot
    We could remove the a slot delay at phase 1 boundary by setting default shard_state.slotto PHASE_1_GENESIS_SLOT - 1 though. Does that make sense to you?

get_filtered_shard_block_tree

ah now i see it, the while loop below it should be able to handle the shard block tree. Thanks!

@hwwhww hwwhww force-pushed the hwwhww/signed_pattern branch from 2c4d942 to 7a77018 Compare May 1, 2020 18:35
@hwwhww hwwhww force-pushed the hwwhww/shard_fork_choice branch from 16b3fba to 49a900b Compare May 1, 2020 18:56
@hwwhww hwwhww force-pushed the hwwhww/shard_fork_choice branch from 49a900b to 79b1b4b Compare May 5, 2020 13:43
@hwwhww hwwhww changed the base branch from hwwhww/signed_pattern to dev May 5, 2020 13:44
Copy link
Contributor

@djrtwo djrtwo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

great! so close

specs/phase1/fork-choice.md Show resolved Hide resolved
specs/phase1/shard-fork-choice.md Outdated Show resolved Hide resolved
specs/phase1/shard-fork-choice.md Outdated Show resolved Hide resolved
specs/phase1/shard-fork-choice.md Outdated Show resolved Hide resolved
specs/phase1/shard-fork-choice.md Outdated Show resolved Hide resolved
specs/phase1/shard-fork-choice.md Outdated Show resolved Hide resolved
Copy link
Contributor

@djrtwo djrtwo left a 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)

@hwwhww hwwhww changed the title [WIP] shard fork choice rule Shard fork choice rule Jun 4, 2020
@hwwhww hwwhww marked this pull request as ready for review June 4, 2020 12:35
@hwwhww hwwhww force-pushed the hwwhww/shard_fork_choice branch from 9100be6 to 0a107d5 Compare June 4, 2020 12:41
Copy link
Contributor Author

@hwwhww hwwhww left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@dankrad @djrtwo

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 tests get_pendings_shard_blocks
  • Note that for mainnet config, it will run for ~2 epochs

specs/phase1/shard-fork-choice.md Outdated Show resolved Hide resolved
@@ -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)
Copy link
Contributor Author

@hwwhww hwwhww Jun 4, 2020

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Second thought: #1875

@hwwhww hwwhww mentioned this pull request Jun 4, 2020
16 tasks
@hwwhww hwwhww force-pushed the hwwhww/shard_fork_choice branch from 0a107d5 to a154d0c Compare June 5, 2020 18:39
hwwhww added 4 commits June 6, 2020 02:39
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
Copy link
Contributor

@djrtwo djrtwo left a 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 Show resolved Hide resolved
specs/phase1/shard-fork-choice.md Outdated Show resolved Hide resolved
specs/phase1/shard-fork-choice.md Outdated Show resolved Hide resolved
specs/phase1/shard-fork-choice.md Outdated Show resolved Hide resolved
# 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)
Copy link
Contributor

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?

Copy link
Contributor Author

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) 🎉

@hwwhww hwwhww merged commit f279e30 into dev Jun 8, 2020
@hwwhww hwwhww deleted the hwwhww/shard_fork_choice branch June 8, 2020 17:39
@hwwhww hwwhww mentioned this pull request Jun 9, 2020
17 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants