status-im
/
eth2.0-specs
mirror of https://github.com/status-im/eth2.0-specs.git
2
0
Fork 0
Code Issues Projects Releases Wiki Activity

clarify fork upgrade conditions

This commit is contained in:
Alex Stokes 2021-05-11 10:58:45 -07:00
parent 5074fcad17
commit f328f77e65
No known key found for this signature in database
GPG Key ID: 99B3D88FD6C55A69
1 changed files with 5 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
specs/altair/fork.md
View File

@ -38,7 +38,11 @@ Note that for the pure Altair networks, we don't apply `upgrade_to_altair` since
### Upgrading the state ### Upgrading the state
After `process_slots` of Phase 0 finishes, if `state.slot % SLOTS_PER_EPOCH == 0` and `compute_epoch_at_slot(state.slot) == ALTAIR_FORK_EPOCH`, an irregular state change is made to upgrade to Altair. If `state.slot % SLOTS_PER_EPOCH == 0` and `compute_epoch_at_slot(state.slot) == ALTAIR_FORK_EPOCH`, an irregular state change is made to upgrade to Altair.
The upgrade occurs after the inner loop of `process_slots` that sets `state.slot` equal to `ALTAIR_FORK_EPOCH * SLOTS_PER_EPOCH` finishes.
Care must be taken when transitioning through the fork boundary as implementations will need a modified state transition function that deviates from the Phase 0 spec.
In particular, the `state_transition` function defined in the Phase 0 spec will not expose the correct time to execute the upgrade in the presence of skipped slots at the fork boundary.
```python ```python
def upgrade_to_altair(pre: phase0.BeaconState) -> BeaconState: def upgrade_to_altair(pre: phase0.BeaconState) -> BeaconState: