Configurable number of epochs for protocol upgrades

Development
1

Currently Protocol upgrades trigger when 80% (by stake) of clients upgrade, and non-upgraded nodes have 1 epoch to upgrade. If they don’t upgrade during this epoch, they won’t be able to participate in the chain until they upgrade.

To improve this situation I want to work on a related NEP:
# Have configurable number of epochs for protocol upgrades

Looking for any feedback related to this problem, even a simple +1 or a -1 :slight_smile:

The basic idea is to trigger upgrades not in the next epoch, but after a fixed number of epochs. 8 epochs (roughly 4 days) seems to be a good value, but feedback is very welcome.
The number of epochs can either be set in a config, or simply hardcoded in the client implementation as a constant. A constant is a simpler solution, and exposing it in a config doesn’t have obvious advantages.

To make it possible to quickly fix critical issues, a mechanism for emergency upgrades is needed. I currently consider using the existing mechasim of upgrades after 1 epoch, but there is a proposal to upgrade much faster than that, in <200 blocks.

2

The current state of the proposal is to achieve delaying the protocol upgrade by delaying the voting for the protocol upgrade.
This approach gives nodes extra time to upgrade, but doesn’t require a protocol change. And generally speaking, the simpler the protocol is the better.

More concretely, each release of the node will contain a timestamp defining a point in time after which the validators will announce their support for the new protocol version. Before that point in time, the validators include the current protocol version in the blocks they produce.
This approach also lets perform emergency upgrades with no extra effort. Don’t define the point in time, and the upgrade will happen as soon as the majority of validators upgrade, exactly the same way it’s done today.