You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There are the post-altair testing initialize_beacon_state_from_eth1 helpers that set previous_version == current_version. It was designed for the testnets.
That said, it seems the previous testnets prefer using phase0 genesis and calling a series of upgrade_to_<fork> at slot 0…
If no one uses it, we may consider removing the post-altairinitialize_beacon_state_from_eth1 from the specs.
The text was updated successfully, but these errors were encountered:
hwwhww
changed the title
Remove post-phase0 initialize_beacon_state_from_eth1 from specs
Remove post-altair initialize_beacon_state_from_eth1 from specs
Apr 9, 2024
we do indirectly use these functions in testing, its not a big deal to move them to just testing code, and would simplify the specs so I support doing it
The genesis generators used in our testing just re-use the upgrade_to_* functions from a phase0 genesis state. The result should be identical. Having to maintain the extra initialize_beacon_state_from_eth1 is just boilerplate.
(copied from our previous discussion)
There are the post-altair testing
initialize_beacon_state_from_eth1
helpers that setprevious_version == current_version
. It was designed for the testnets.That said, it seems the previous testnets prefer using phase0 genesis and calling a series of
upgrade_to_<fork>
at slot 0…If no one uses it, we may consider removing the post-altair
initialize_beacon_state_from_eth1
from the specs.The text was updated successfully, but these errors were encountered: