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
- [ ] https://github.com/near/nearcore/pull/12114
- [ ] feat: show time based on the given time zone
- [ ] feat: If the voting date is X, when will the protocol upgrade happen?
- [ ] feat: Given a day of the voting date find the hour that maximizes the probability that the upgrade happens during working hours
Protocol upgrade in NEAR works as follows:
As an example:
201is set to2024-01-02 12:00 UTC#99starts at2024-01-01 10:00 UTC, the current protocol version is200.#100starts at2024-01-01 22:00 UTC, the current protocol version is200.#101starts at2024-01-02 10:00 UTC, the current protocol version is200.2024-01-02 12:00 UTCnodes start voting for protocol version201, let's assume that 80% of stake voted for it.#102starts at2024-01-02 22:00 UTC, the current protocol version is200.#103starts at2024-01-03 10:00 UTC, the current protocol version is201.#104starts at2024-01-03 22:00 UTC, the current protocol version is201.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:
Right now the process of estimating voting and upgrade dates is manual and a bit error prone.