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

A tool to estimate time of protocol voting and protocol upgrade #12107

Open
1 of 4 tasks
jancionear opened this issue Sep 18, 2024 · 0 comments
Open
1 of 4 tasks

A tool to estimate time of protocol voting and protocol upgrade #12107

jancionear opened this issue Sep 18, 2024 · 0 comments
Labels
C-good-first-issue Category: issues that are self-contained and easy for newcomers to work on. T-dev-tools

Comments

@jancionear
Copy link
Contributor

jancionear commented Sep 18, 2024

Protocol upgrade in NEAR works as follows:

  • There's a voting date when nodes start voting for the new protocol
  • If 80% of stake in epoch T voted for new protocol, the protocol will be adopted in epoch T+2
  • Epochs T and T+1 still use the old protocol

As an example:

  • A new release is announced and the voting date for protocol version 201 is set to 2024-01-02 12:00 UTC
  • Epoch #99 starts at 2024-01-01 10:00 UTC, the current protocol version is 200.
  • Epoch #100 starts at 2024-01-01 22:00 UTC, the current protocol version is 200.
  • Epoch #101 starts at 2024-01-02 10:00 UTC, the current protocol version is 200.
  • At 2024-01-02 12:00 UTC nodes start voting for protocol version 201, let's assume that 80% of stake voted for it.
  • Epoch #102 starts at 2024-01-02 22:00 UTC, the current protocol version is 200.
  • Epoch #103 starts at 2024-01-03 10:00 UTC, the current protocol version is 201.
  • Epoch #104 starts at 2024-01-03 22:00 UTC, the current protocol version is 201.

The protocol upgrade to version 201 happened at 2024-01-03 10:00 UTC.
(In the real world the numbers aren't that pretty because epochs aren't exactly 12 hours long)

In general we prefer protocol upgrades to happen during working hours of NEAR engineers, which is around 8-22 UTC, so that they can go and fix any problems that could arise because of the upgrade.
Because of that we try to set the voting dates to values which will cause the protocol upgrade to happen at the desired time.

It would be great to have a tool which:

  • Reads past epochs on a given chain and estimates when the future epochs will start
  • Can give us a voting date which maximizes the probability that the protocol upgrade will happen during working hours
  • Can estimate when the protocol upgrade will happen if the voting date is set to some value.

Right now the process of estimating voting and upgrade dates is manual and a bit error prone.

Tasks

@jancionear jancionear added C-good-first-issue Category: issues that are self-contained and easy for newcomers to work on. T-dev-tools labels Sep 18, 2024
@stedfn stedfn linked a pull request Oct 10, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-good-first-issue Category: issues that are self-contained and easy for newcomers to work on. T-dev-tools
Projects
None yet
Development

No branches or pull requests

1 participant