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
HotShot will need a stake table for the first few epochs, which should be the continuation of the current stake table. However, the Membership implementation has no way of knowing which epoch number will be the "first" epoch.
We should add a new method to Membership that looks something like set_first_epoch(&mut self, epoch: TYPES::Epoch) -> Result<()>, which HotShot will use to mark the first "real" epoch number by calling set_first_epoch on the current consensus epoch number immediately after the upgrade is decided.
The Membership implementation should insert its initial non-epoch stake table at both the given and next TWO epochs (for a total of 3 epochs). In most cases only 2 will be needed, but in an edge case where the upgrade is decided towards the end of an epoch we may not call add_epoch_root on it.
Since nodes may not decide upgrades at the same point, we should ensure (when deploying) that the contract provides the same stake table as the initial stake table for all 3 of these epochs and is not modified until after the 3rd real epoch.
The text was updated successfully, but these errors were encountered:
ss-es
changed the title
Add Stake Table/Epoch roots for first 2 epochs (since they won't have roots decided)
Add Stake Table for first 2 epochs
Feb 6, 2025
HotShot will need a stake table for the first few epochs, which should be the continuation of the current stake table. However, the
Membership
implementation has no way of knowing which epoch number will be the "first" epoch.We should add a new method to
Membership
that looks something likeset_first_epoch(&mut self, epoch: TYPES::Epoch) -> Result<()>
, which HotShot will use to mark the first "real" epoch number by callingset_first_epoch
on the current consensus epoch number immediately after the upgrade is decided.The
Membership
implementation should insert its initial non-epoch stake table at both the given and next TWO epochs (for a total of 3 epochs). In most cases only 2 will be needed, but in an edge case where the upgrade is decided towards the end of an epoch we may not calladd_epoch_root
on it.Since nodes may not decide upgrades at the same point, we should ensure (when deploying) that the contract provides the same stake table as the initial stake table for all 3 of these epochs and is not modified until after the 3rd real epoch.
The text was updated successfully, but these errors were encountered: