Bellatrix -- Fork Logic¶
Introduction¶
This document describes the process of Bellatrix upgrade.
Configuration¶
Name | Value |
---|---|
BELLATRIX_FORK_VERSION |
Version('0x02000000') |
BELLATRIX_FORK_EPOCH |
Epoch(144896) (Sept 6, 2022, 11:34:47am UTC) |
Helper functions¶
Misc¶
Modified compute_fork_version
¶
Fork to Bellatrix¶
Fork trigger¶
TBD. Social consensus, along with state conditions such as epoch boundary,
finality, deposits, active validator count, etc. may be part of the decision
process to trigger the fork. For now we assume the condition will be triggered
at epoch BELLATRIX_FORK_EPOCH
.
Note that for the pure Bellatrix networks, we don't apply upgrade_to_bellatrix
since it starts with Bellatrix version logic.
Upgrading the state¶
As with the Phase0-to-Altair upgrade, the state_transition
is modified to
upgrade the BeaconState
. The BeaconState
upgrade runs as part of
process_slots
, slots with missing block proposals do not affect the upgrade
time.
If state.slot % SLOTS_PER_EPOCH == 0
and
compute_epoch_at_slot(state.slot) == BELLATRIX_FORK_EPOCH
, an irregular state
change is made to upgrade to Bellatrix. The upgrade occurs after the completion
of the inner loop of process_slots
that sets state.slot
equal to
BELLATRIX_FORK_EPOCH * SLOTS_PER_EPOCH
.
When multiple upgrades are scheduled for the same epoch (common for test-networks), all the upgrades run in sequence before resuming the regular state transition.