-
Notifications
You must be signed in to change notification settings - Fork 973
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
Simplify Altair "genesis" #2323
Conversation
I think the |
Yes you're right - I thought I'd tried that in the past but apparently got it wrong somehow. If I forcibly create a phase0 "spec" to parse that initial block then the Altair fork choice tests pass for me. Note that the Altair genesis reference tests do not run I'm a big fan of being able to start from a pure Altair genesis and not need any phase0 code because that leaves the possibility of eventually dropping phase0 support from codebases entirely and just using a later anchor state to sync from. Not sure if we'll ever actually do that but it would be really nice if it were at least possible so new clients can just implement the latest spec instead of having to implement every historical phase as well. |
Thanks @ajsutton for the reply! Right, so this PR also fixes #2318. I think we need to add other more fork choice rule tests around the fork boundary. (not in this PR) @djrtwo @protolambda
|
Agree that we should be able to test both Altair at genesis and Altair at some point after Phase0. I think we also want a config where Altair doesn't kick in though (ie It sounds like it would be really useful to be able to say "minimal spec but with altair fork at epoch X". Otherwise we're going to get a bit of an explosion of configs as we add more forks. |
@ajsutton I updated the docs in 666f847:
Keeping /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 few minor comments. I'm okay with this approach but am concerned about being able to more dynamically set fork slots for testing
ALTAIR_FORK_SLOT = FAR_FUTURE_EPOCH
-- Why are we setting it to far future epoch instead of GENESIS_SLOT
? Don't we want the fork to by default happen for all of the tests today?
EDIT: I remember now that we did this for safety
Should fork slots be a part of the core config? Maybe these should live in a separate file. Core configs are often used for compile targets and are expected to be few and far between, but we'll likely want fork slots to be highly configurable.
Issue
state
withupgrade_to_altair
:https://github.com/ethereum/eth2.0-specs/blob/6f095fc6916dcb7803b6cded68c0367f72a14f06/tests/core/pyspec/eth2spec/test/context.py#L76-L89
It assumes that
ALTAIR_FORK_SLOT
is0
in the test cases. Therefore, afterupgrade_to_altair
, the resultstate.latest_block_header
is from Phase 0latest_block_header
.block_1.parent_root
points to.on_block
, the givenblock.parent_root
must be known instore
. (assert block.parent_root in store.block_states
)https://github.com/ethereum/eth2.0-specs/blob/6f095fc6916dcb7803b6cded68c0367f72a14f06/tests/core/pyspec/eth2spec/test/helpers/fork_choice.py#L61-L62
Now think about the Altair-only testnets, where
ALTAIR_FORK_SLOT == 0
. With the current spec, the initialization is like:initialize_beacon_state_from_eth1
to getgenesis_state: phase0.BeaconState
.genesis_block = phase0.BeaconBlock(state_root=hash_tree_root(genesis_state))
upgrade_to_altair
to getstate: altair.BeaconState
get_forkchoice_store(state, genesis_block)
state: altair.BeaconState
andgenesis_block: phase0.BeaconState
It could be simplified if not using
upgrade_to_altair
:initialize_beacon_state_from_eth1
to getgenesis_state: phase1.BeaconState
.genesis_block = altair.BeaconBlock(state_root=hash_tree_root(genesis_state))
get_forkchoice_store(genesis_state, genesis_block)
state: altair.BeaconState
andgenesis_block: altair.BeaconState
Proposed solutions
context.py
] We can just usecreate_genesis_state
helper to generate the “initial state” for Altair or other versions.spec.BeaconBlock
instead ofphase0_spec.BeaconBlock(state_root=genesis_state.hash_tree_root())
beacon-chain.md
] Addinitialize_beacon_state_from_eth1
in Altair specs, which is only used in the test suite and for testnets.Pros:
Cons:
initialize_beacon_state_from_eth1
andupgrade_to_altair
. But I think we can refactor it to be acceptable.upgrade_to_altair
: after this change, onlytest_fork.py
tests will coverupgrade_to_altair
.