-
Notifications
You must be signed in to change notification settings - Fork 933
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
Fix fork choice on_block
tests and update test format
#2577
Conversation
@ajsutton @tuyennhv If you'd like to try the updated test vectors, I dumped new fork choice test vectors to: https://github.com/hwwhww/consensus-spec-tests/tree/fork-choice-pr2577 (b23ed05 version) p.s. It doesn't fix the |
Update: @tuyennhv confirmed that Lodestar passed all fork choice tests against this new branch. 🙌 |
Sorry got distracted from this. I've never worked out how to build the actual test vectors from the source (only got as far as running them against the spec implementation), do you have instructions for that or is there a tarball somewhere? |
If you'd like to download from source, it required Git LFS installed.
If LFS has been installed correctly,
Or you can trigger it by
The test vectors will be under |
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 got a little hung up on what was actually being tested in the valid case, but figured it out!
Looks correct to me
tests/core/pyspec/eth2spec/test/phase0/fork_choice/test_on_block.py
Outdated
Show resolved
Hide resolved
|
||
# Now build a block at later slot than finalized *epoch* | ||
# Includes finalized block in chain and the skipped slots | ||
block = build_empty_block_for_next_slot(spec, target_state) |
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 block is valid wrt the finalized epoch (including the skip slots), but this block isn't the head, right?
apply_next_epoch_with_attestations
for epoch 3 and 4 will have created blocks of much higher weight and win out
So -- Does adding this block change anything? or does it catch a regression in the prior fork choice implementations?
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.
and if block
is supposed to be the head? can we check that it is against a dynamic call to get_head()
?
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.
Ah, I see. It's just checking in on_block
can even be run anymore which would yield valid: False
if it didn't 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.
Ah, I see. It's just checking in on_block can even be run anymore which would yield valid: False if it didn't work
Right, it is for comparing with test_on_block_finalized_skip_slots_not_in_skip_chain
(valid: False) test case.
checks
: add checkpoint epoch number and rephrase them in dict. Example:test_new_justified_is_later_than_store_justified
: there was a missingtick
step.test_new_finalized_slot_is_justified_checkpoint_ancestor
: remove the uselesstick
step.test_on_block_finalized_skip_slots_not_in_skip_chain
andtest_on_block_finalized_skip_slots
:test_on_block_finalized_skip_slots_not_in_skip_chain
used non-genesis anchor state and block to initialize fork choice store, which was hacky and having potential issues (Issues with fork choice and non-genesis anchors #2566 explained it)