-
Notifications
You must be signed in to change notification settings - Fork 12
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
Add Teep & Tock #192
base: master
Are you sure you want to change the base?
Add Teep & Tock #192
Conversation
The approach is in-line with how we have previously handled such grace-periods. An example is the Lightning & Thunder upgrades. Biggest difference here is the duration of the grace-period, which widens the gap/risk of needing to do emergency upgrades between these periods. Typical spacing between network upgrades suggests we can accommodate this window without any disruption to our normal network upgrade schedule at least. |
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.
LGTM. We can update the activation epochs once settled between the maintainers.
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.
Added a note about F3 updates as well for nv25.
upgrades.json
Outdated
], | ||
"activation": { | ||
"mainnet": {}, | ||
"calibrationnet": {} |
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.
I assume we fill this in after the fact? We have a date currently per https://filecoinproject.slack.com/archives/C05P37R9KQD/p1741938432377989
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.
Added the epochs and dates for both upgrades and also the actors CIDs as they currently are for v16. Will let @rjan90 double check all those details.
Co-authored-by: Steve Loeppky <[email protected]>
"calibrationnet": { | ||
"epoch": 2520574, | ||
"time": "2025-03-25T23:00:00Z", | ||
"actors": { |
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.
"calibrationnet": { | |
"epoch": 2520574, | |
"time": "2025-03-25T23:00:00Z", | |
"actors": { | |
"calibrationnet": { | |
"epoch": 2523454, | |
"time": "2025-03-26T23:00:00Z", | |
"actors": { |
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.
Updated to the new Calibnet upgrade epoch/date.
I want to get an nv25->nv26 pairing on the books for if FIP-0100 passes and we decide to deal with the grace period for legacy sector extensions using the network upgrade mechanism.
See: filecoin-project/FIPs#1134 & filecoin-project/builtin-actors#1649 for context on this.
nv26 wouldn't have a new actors build (unless there's a need to get one in between), and I'm proposing the name "Tock" for it.
nv27 would be the next normally scheduled upgrade.
We probably should reconsider using this approach if we think there may be a need for a normally scheduled upgrade before the 90 days are done after nv25 activation. The problem we'll run in to is having calibnet upgrade earlier and then being out of sync with network versions and needing to do some jiggery pokery to get them back in sync again. We'd have to deal with this for an emergency upgrade anyway, but it would be nice to avoid it in the normal flow of upgrades. (@rjan90 you're probably the one to consider this wrt timing)