We saw a lot of discussion and frustration around the starting times of forks etc, so I thought I’ll draft some ground rules for upgrades/forks during the GoS. For other testnets, I think coordination went very well in the past and there is no need for validators to be online during a network start.
I drafted the following rules which should be discussed: Click here
If we come to consensus, that something like this is useful, I will update this fork and create a pull request to include it in the GoS readme.
Please let me know, what you think. Especially on the 3 / 12 hour timer. Also, I would really like to know what the team thinks about this. In the end, it is their game
Copying the proposed ground rules here, for easy reference -
Rules for network upgrades & forks
The following rules are intended improve coordination and to reduce the fear of not being online during a fork or network upgrade. These rules can only be applied to upgrades/forks initiated by the Cosmos team. Community forks are well inside the rules of the GoS.
All upgrades/forks need to be announced in the Cosmos Validators Technical Updates Riot channel. If there is no announcement in this channel, the upgrade has not been decided on. Other channels are solely for discussions and do not include official announcements.
Every announcement has to include the date & time (in UTC) when the upgrade will happen. Upgrades can happen the earliest 12 hours after they have been announced in the Riot channel. If something minor regarding the upgrade changes after the announcement (eg. minor changes to the genesis file), it needs to be announced in the Riot channel and the timer resets to at least 3 hours . This gives everyone enough time to verify the correctness of files and to update their nodes. Substantial changes that could require intervention reset the timer to the initial 12 hours .
Decisions that require the opinion of the community can either be voted on as an on-chain proposal or - if the network is offline - as a Github issue. The voting period needs to be at least 12 hours , which starts with the Riot channel announcement ( that also includes the voting deadline ). Proposals need to be well defined. That means, they need to precisely explain what happens if the proposal gets accepted, but also what happens if it not gets accepted.
The weakness here is the dependency on the Cosmos team, particularly @zaki, to post the update. I wonder if there’s a way to reduce this dependency?
I’d suggest even minor changes trigger a 12 hour reset. Given the global nature of the validators, 3 hours may not be long enough to prepare.
We should think about what a quorum looks like, how the majority is defined, how the proposal is announced and how long the proposal is open for voting. Maybe a quorum (number of validators required to activate the proposal process) is at least 25% of the number of active (or last active if the network is halted) validators, majority is simple majority, 51%, and voting period defaults to 12 hours.
I’d also suggest that the only recognized conversations for the proposal happen in the Github issue itself. This reduces the dependency on the chat channel and likelihood of key messages getting missed, as is likely to happen with real-time chat.
