Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Have configurable number of epochs for protocol upgrades #205

Closed
bowenwang1996 opened this issue May 20, 2021 · 3 comments
Closed

Have configurable number of epochs for protocol upgrades #205

bowenwang1996 opened this issue May 20, 2021 · 3 comments
Assignees
@nikurt
Labels
T-nodeX About usability of NEAR node operation

Comments

@bowenwang1996
Copy link
Collaborator

Currently once 80% of the validators switch to a new protocol version, the upgrade happens in 2 epochs, which may not be sufficient for some validators to upgrade their nodes. At the same time, if there is an emergency upgrade to fix some critical vulnerability, we would like to upgrade to finish as fast as possible. Therefore, it may make sense to distinguish, for every protocol upgrade, whether it is urgent or standard and have different number of epochs between when the majority of validator switch to the new version and when the new protocol kicks in.
@DenysOf
Copy link

DenysOf commented May 23, 2021

I would be happy to see 72/96-hours grace period, but reduce 80% figure to 51% to encourage more validators to upgrade in the given timeframe.

Also can you clarify is it 80% of a total stake or number of validators, please.

@bowenwang1996
Copy link
Collaborator Author

Also can you clarify is it 80% of a total stake or number of validators, please.

Yes. Please refer to https://nomicon.io/ChainSpec/Upgradability.html

@bowenwang1996 bowenwang1996 mentioned this issue Jun 8, 2021
Closed
@janewang janewang added enhancement T-nodeX About usability of NEAR node operation labels Jun 8, 2021
@bowenwang1996 bowenwang1996 mentioned this issue Jul 1, 2021
Closed
@nikurt nikurt self-assigned this Aug 11, 2021
@nikurt nikurt mentioned this issue Nov 17, 2021
Closed
@mzhangmzz mzhangmzz mentioned this issue Nov 19, 2021
Closed
@janewang
Copy link

Here are suggested configurable epochs from validators:

  • 8 epochs for CODE_GREEN and CODE_YELLOW
  • 2 epochs for CODE_RED

@nikurt nikurt mentioned this issue Feb 17, 2022
Merged
near-bulldozer bot pushed a commit to near/nearcore that referenced this issue Mar 4, 2022
@nikurt
NEP205: Delay voting for new version until a certain date and time (#…
cfba9e9 
…6309)

See near/NEPs#205
This PR enables clients to extend the protocol upgrade window, but indirectly. This PR lets clients upgrade early but not announce the fact of the upgrade until a certain date in the future.

Normal upgrades:
* Clients will delay voting until a certain date.

Emergency upgrades:
* Voting for the new version starts immediately and a protocol upgrade becomes effective in 1-2 epochs.
@nikurt nikurt closed this as completed Mar 7, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@nikurt nikurt

Labels
T-nodeX About usability of NEAR node operation
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@janewang @bowenwang1996 @DenysOf @nikurt