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.

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

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
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

@janewang
Copy link

Here are suggested configurable epochs from validators:

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

near-bulldozer bot pushed a commit to near/nearcore that referenced this issue Mar 4, 2022
…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
Labels
T-nodeX About usability of NEAR node operation
Projects
None yet
Development

No branches or pull requests

4 participants