search

near / nearcore

Reference client for NEAR Protocol
https://near.org
GNU General Public License v3.0
2.3k stars 601 forks source link

🔷 [ProjectTracking] Sequential protocol upgrades in one release #10911

Open posvyatokum opened 3 months ago

posvyatokum commented 3 months ago

Goal

Have several protocol upgrades in one release.

Background

We performed two resharding on mainnet via making targeted 1.38 release. And although this feature would not have helped a lot in that situation (as we only decided to do the second resharding after the testnet already has been resharded once), the flow of releasing one binary that has two protocol upgrades separated by two days is easier than trying to release two binaries on one week and make sure that all of the community is adopting both changes in time.

Context

We have exactly one protocol upgrade per release (it can be empty, but we still agree that we want to bump protocol version every release). As a result, this upgrade can include roll-out of several features at once. Bundling features is dangerous, and for some features it is even impossible. This creates a situation, where features developers have to be aware of each others release dates and make sure that their feature is stabilised only in the next release.

Why should NEAR One work on this

  1. Separating feature adoptions make debugging incidents easier.
  2. We can add new protocol feature in 1.x.1 release instead of creating 1.x+1.0 release (this part is not that important), and make the release of 1.x.1 before adoption of 1.x.0 protocol version, while giving validators ability to upgrade either before or after the first voting date (this is extremely useful).
  3. We can massive upgrades in per-shard upgrades or separate steps. For example, moving shard boundaries without changing a number of shards in one release requires a complex development and testing of a new feature. Changing it in two steps -- split "traveling" range of accounts into separate shard, and the merge "traveling" range with "destination" range -- requires developing and testing only one new flow, that is merging of two shards.

What needs to be accomplished

From technical point of view, we need to support a vector of voting dates, and refactor https://github.com/near/nearcore/blob/f37edc01ee97488d1cb866badb8911040105345e/core/primitives/src/upgrade_schedule.rs#L52.

Main use case

  1. Dependant feature stabilisations
  2. Multi-feature releases

Links to external documentation and discussion

TODO: add link to how voting works

Estimated effort

TODO: precise estimation This project is quite short. One engineer should be done in two weeks.

Assumptions

TODO

Pre-requisites

TODO

Out of scope

TODO

Task list

TODO

wacban commented 3 months ago

We should absolutely do this and it conveniently seems like a relatively easy task. Once it's done we should also establish some good practices around having separate versions and dates for different features within one release. The only drawback that I see is that the latter features within a release will get a little less time in testnet but that is easily fixable.

wacban commented 1 month ago

I'm going to look into it. We may want to do it in 1.41 to separate congestion control and stateless validation.