-
Notifications
You must be signed in to change notification settings - Fork 50
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
[FLIP 204] Add TargetEndTime
to FlowEpoch
smart contract
#395
Conversation
guarantees time computation doesn't underflow
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.
Looks good! I'll push back the dates on the upgrades so we can get this in
/// | ||
pub struct EpochTimingConfig { | ||
/// The duration of each epoch, in seconds | ||
pub let duration: UInt64 |
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.
Will every epoch always have the same duration? I understand the config can change, but what if the duration changes, but we are using a reference epoch that is before the change? Would we just never do that?
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.
Right now, all epochs have the same duration (1 week on Mainnet). If/when we want to change the duration, then we would change the timing config.
The reference epoch needs to contain a real reference counter that has been used in the past. But the associated duration can be anything we want (it does not need to match the duration that the reference epoch actually took, when it occurred). So there isn't anything stopping us from using a reference epoch that is before the duration change, if we want to.
👍 Initially I thought we would need to push a We should still make sure to go through an epoch transition on Canary before upgrading Testnet/Mainnet to be safe, but otherwise there's no blockers for including this in the next upgrade. |
Addresses #394.
This PR adds the new field
TargetEndTime
to theEpochSetup
event, which will be used by the Cruise Control system to moderate block rate so that epochs end at the desired time. See details in FLIP 204I have not added
targetEndTime
to theEpochStart
event. Here is why:EpochSetup
andEpochStart
events. If we don't store the value, we may communicate different values in different events for the same epoch.