Hello everyone!
Introduction
Intention of this post is to get your opinion & feedback on the fast-tracking mechanism available to the Technical Committee. I will give a brief overview of the matter & the dilemma around it, but I’m expecting readers to check out the official governance docs & read about the Technical Committee themselves.
One of the roles of the Technical Committee is to fast-track external proposals made by the Main Council, when they see this as necessary. Fast-track itself doesn’t allow for any sudo-like privilege, instead it only allows to instantly create a referendum (and to specify custom voting duration & enactment delay).
In general, the way governance works is that each week one proposal is upgraded to a referendum. There are two tracks, one for public proposals & one for external proposals. Every week a different track is chosen, and its proposal upgraded.
This is good since the whole process isn’t so fast so that token holders don’t have time to react/vote.
The “Dilemma”
Now let’s consider an action like Runtime Upgrade, which is the reason for writing this post. Anyone can propose it via the public proposal, but it is somewhat expected that this proposal will come from the Main Council.
Sometimes, when we need to deploy a bug fix, it’s expected that Technical Committee will use the fast-track to get referendum going ASAP. This is necessary for the safety & liveness of the network.
However, for regular runtime upgrades, it’s questionable whether if or when this should be used.
We can consider two alternatives.
Use Fast Track Only For Emergency
With this approach, the code of conduct says that we should only use fast-track when it’s related to an emergency action. This can range from runtime upgrade to simple maintenance mode on dApp staking.
The benefit of this approach is that it’s very clear; fast-track should be used only for emergencies.
The major drawback of this approach is that it will consume one voting slot for the referendum. This means that e.g. a public proposal might will need to wait 1 week longer than usual to potentially be upgraded into a referendum.
E.g.
- Day 0 - Main Council makes an external proposal for runtime upgrade.
- Day 1 - Launch Period is ending, public proposal gets upgraded to a referendum
- Day 8 - Referendum finishes, runtime upgrade proposal is upgraded to a referendum
- Day 15 - Assuming the referendum passed, runtime upgrade authorization is scheduled for enactment. New public proposal is upgraded to a referendum.
- Day 17 - Runtime upgrade is enacted.
This isn’t the worst case scenario, and runtime upgrade enactment can take even longer if the external proposal is made just AFTER another external proposal has been upgrade to a referendum.
Use Fast Track To Immediately Upgrade Proposal To Referendum
With this approach, the code of conduct says that we can use fast-track to instantly create referendum for runtime upgrade, allowing the token holders to immediately start voting.
NOTE: This doesn’t mean that the Technical Committee can enact the upgrade themselves. The voting scheme is also the same with or without the fast track. The ONLY difference is that voting starts sooner rather than later.
Reusing the example from the previous subchapter, scenario would look like:
- Day 0 - Main Council makes an external proposal for runtime upgrade, referendum is started via the fast-track.
- Day 1 - Launch Period is ending, public proposal gets upgraded to a referendum
- Day 7 - Assuming upgrade referendum passed, delay enactment of the upgrade authorization is scheduled.
- Day 8 - Referendum finishes, and a new one can begin (it can once again be public proposal).
Note that in only half the period we get two referendums.
Also, on day 8, another public proposal can be upgraded to a referendum - in this way the runtime-upgrade action doesn’t take away from the referendum capacity.
Please do share your thoughts, ideas, concerns, etc.
I’ll open up the poll on Subsquare platform once enough comments have been received.
