Change log:
05-28-2024: Original Post
06-03-2024: Revised text to reflect community feedback, mirroring what’s on chain, and to add prop number in title
Intro
This is a signaling proposal for the introduction of expedited proposals on the Cosmos Hub. Expedited proposals can have shorter voting durations and a higher tally threshold. If an expedited proposal fails to meet the threshold within the shorter voting duration, then it is converted to a regular proposal and voting restarts under regular voting conditions. Expedited proposals were introduced in Cosmos SDK v0.50, which means they will need to be backported to the special branch of Cosmos SDK v0.47 used by the Cosmos Hub.
There are several use cases for expedited proposals, such as fraud resolutions or participating in Neutron governance, that will be addressed by future signaling proposals. An immediate use case is reducing the voting duration of Software Upgrade proposals and, consequently, speed up the Cosmos Hub upgrade process. We propose to expedite Software Upgrade proposals to one week with the tally threshold set to 66.7% (the default for expedited proposals). Note that all previous proposals starting with the v8 upgrade passed with at least 99% Yes votes.
ExpeditedVotingPeriod – Duration of the voting period of an expedited proposal. Our suggestion is to set it to one week.
ExpeditedThreshold – Minimum proportion of Yes votes for an expedited proposal to pass. Our suggestion is to set it to the default value of 0.67.
ExpeditedMinDeposit – Minimum deposit for an expedited proposal to enter voting period. Our suggestion is to set it to 500 ATOMs.
In addition to the backport, we will add an ante handler in Gaia to expedite only certain proposals. Our current proposal is only to allow SoftwareUpgrades to be expedited.
Proposal Outcomes
The following items summarize the voting options and what they mean for this proposal:
Upon a YES vote:
The voting period for Software Upgrade governance proposals will be changed to one week in the next Cosmos Hub upgrade.
Upon a NO vote:
The voting period for Software Upgrade governance proposals will remain unchanged (i.e., two weeks).
NO WITH VETO - A ‘NoWithVeto’ vote indicates a proposal either (1) is deemed to be spam, i.e., irrelevant to Cosmos Hub, (2) disproportionately infringes on minority interests, or (3) violates or encourages violation of the rules of engagement as currently set out by Cosmos Hub governance. If the number of ‘NoWithVeto’ votes is greater than a third of total votes, the proposal is rejected and the deposits are burned
ABSTAIN - You wish to contribute to quorum but you formally decline to vote either for or against the proposal
I’m all in for the idea. I’d maybe even suggest decreasing the voting time for such proposals to smaller period, like 3-5 days, given that during the emergency upgrade the validator set had shown it can be even done in less than 24 hours, for a more fast way for expedited proposals to reach the mainnet.
One thing I am not sure I got right about the proposal: does it also affects the regular SoftwareUpgrade proposals? I think the perfect way to deal with it is to have regular SoftwareUpgrade proposals (with shorter voting time), and those with some emergency fixes (as expedited proposals and with longer voting time).
We support this update proposal and believe that an expedited process is necessary. We have long advocated for greater flexibility in the governance framework. Although we initially envisioned an even shorter period for certain cases, we fully endorse a gradual approach.
We suggest two additional considerations:
Increase the quorum to 66.7% to ensure sufficient participation.
Do not refund deposits if the quorum is not met at the end of the vote.
These measures would help prevent sybil attacks in expedited proposals. While these parameters may not seem relevant for a week-long vote, they could be beneficial for shorter durations. Hub’s governance safety should never be compromised!
We hope these suggestions will be helpful.
Govmos,
does it also affects the regular SoftwareUpgrade proposals?
The aim is to change the voting duration for all SoftwareUpgrade proposals to one week. We’ll continue to coordinate emergency upgrades via existing channels (Discord, email list) and provide the code with at least 24h in advance (in case it’s not a critical vulnerability that is being fixed). Are you suggesting to have non-critical emergency upgrades also go through governance and introduce for this another proposal with a voting period of 1-2 days? This could indeed facilitate the process.
Increase the quorum to 66.7% to ensure sufficient participation.
If you look at previous software upgrade proposals, the quorum is usually below 60%. I agree that in principle 66.7% makes sense as the network requires 66.7% to upgrade anyway. However, my concern is that increasing it might lead to software upgrade proposals not reaching quorum, especially in the reduced 1-week voting period.
That’s a pretty fair point. The real problem lies with big validators not participating in governance ! But you are correct, this proposition to raise quorum might not be appropriate! Moreover, we have power to use veto to counter Sibyl, which is a decent security guarantee. Perhaps we should explore the possibility of reducing the veto threshold to 25% for expedited proposals as an alternative to raising the quorum to 66%. I welcome your thoughts on this matter.
I’d say, if the voting period for regular upgrade proposals (like v16 for example) would be 1 week, and the voting period for emergency upgrades (like the one on 7th March) would be, let’s say 2-3 days, that would be the perfect solution.
That’d allow faster regular and planned upgrades (IMO the current 2 weeks is a bit slow), while also allowing to conduct emergency upgrades without using the halt-height and do it all via governance.
What do you think of that?
Moreover, we have power to use veto to counter Sibyl, which is a decent security guarantee. Perhaps we should explore the possibility of reducing the veto threshold to 25% for expedited proposals as an alternative to raising the quorum to 66% . I welcome your thoughts on this matter.
@Govmos Currently, Cosmos SDK doesn’t allow setting another veto threshold for expedited proposals (see here). However, I’m not worried about sybil attacks for expedited software upgrade proposals as, indeed, the community has the power to veto and slash the deposit. I think keeping the veto threshold to 33.4% is good enough (1/3+ of the voters can veto). Reducing it to 25% might make it easier for a small subset of the network to block upgrades.
I’d say, if the voting period for regular upgrade proposals (like v16 for example) would be 1 week, and the voting period for emergency upgrades (like the one on 7th March) would be, let’s say 2-3 days, that would be the perfect solution.
That’d allow faster regular and planned upgrades (IMO the current 2 weeks is a bit slow), while also allowing to conduct emergency upgrades without using the halt-height and do it all via governance.
What do you think of that?
@freak12techno I think that would be a good idea. Unfortunately, the voting period for expedited proposals is a system param (see here). So at least for now, we still need to use the halt-height for emergency upgrades.
ExpeditedVotingPeriod – Duration of the voting period of an expedited proposal. Our suggestion is to set it to one week.
ExpeditedThreshold – Minimum proportion of Yes votes for expedited proposal to pass. Our suggestion is to setting to the default value of 0.67.
ExpeditedMinDeposit – Minimum deposit for an expedited proposal to enter voting period.
In addition to the backport, we will add an ante handler in Gaia to only allow certain proposals to be expedited. Our current proposal is to only allow SoftwareUpgrades.
Another interesting one would be ClientUpdates to unfreeze clients faster. We could add it to this signaling proposal if the community would like to have it.
Is it possible to have a different voting periods for all of the non-upgrades proposals + regular proposals and for expedited proposals that apply emergency upgrades?
My idea was:
if it’s a non-upgrade proposal, it is submitted with a regular voting period (like 2 weeks that we have now, IMO it may be decreased and I opened a topic on it on this forum beforehand, but probably this goes out of scope of this discussion)
if it’s a regular upgrade, it is submitted with a regular voting period (same as above)
if it’s an emergency upgrade, it’s submitted as expedited proposal and therefore has way shorter voting period (like 2-3 days)
(also probably some other things, like IBC unfreeze as you’ve outlined above my post also can go via a shorter voting period as expedited ones
So TLDR: not having 3 types of voting periods (regular proposals; upgrades; emergency upgrades) but 2 (regular proposals + regular upgrades; emergency upgrades + stuff that needs to be applied fast, like IBC unfreeze).
Do you think it’s manageable or whether this is a good idea in general?
Indeed, multiple options are available, and we support yours as well.
Expedited props with a higher deposit may offer a good balance without having to introduce modification. We have already proposed to raise the min_deposit to 500 ATOMs in this post:
What would be your suggestion to an appropriate deposit threshold for the expedited proposal?
Our hunch would be to set it at least 3-5x higher.
Is it possible to have a different voting periods for all of the non-upgrades proposals + regular proposals and for expedited proposals that apply emergency upgrades?
This is possible. The two params would be voting_period and expedited_voting_period.
IMO it may be decreased and I opened a topic on it on this forum beforehand, but probably this goes out of scope of this discussion
I think that’s indeed a separate discussion and it’s for the community to decide if changing voting_period to 1 week is a good idea. There were proposals in the past that require a longer time of discussion, so I’m not sure if people are comfortable with 1 week voting period for all proposals. But I would move this discusion on a separate thread.
if it’s a regular upgrade, it is submitted with a regular voting period (same as above)
This means that nothing is going to change with regard to regular upgrades before the previous discussion on the value for voting_period is concluded.
To simplify the discussion:
For now, we expedite regular upgrades to one week.
We start a separate discussion on the voting period for all gov proposals.
Once this discussion is concluded, we update the process for upgrades accordingly.
Agree with all of it, except for one thing that either contradicts the rest or I misunderstood.
For now, we expedite regular upgrades to one week.
Is it all upgrades that are expected to be expedite and take one week? My thought is there are some upgrades that can be put into governance for a longer period (for example, like the last Gaia v17 upgrade; for me it seems fair to put it through a longer governance period for everybody to have a chance to look into the code) and for some it’s really crucial to land them on mainnet ASAP (and these should be submitted as expedited and therefore have shorter voting period).
I’d propose 1) having even shorter expedited proposals voting period (maybe 2-3 days; given that the Hub has an excellent validator set that is always reacting accordingly if there are some emergency upgrades or something, reaching the quorum within that small voting period should be achievable while allowing to land upgrades/IBC unfreezes/other emergency stuff on mainnet as soon as possible) and using it for emergency stuff (regular upgrades IMO shouldn’t be expedited), 2) leaving the voting period for the regular upgrades as 2 weeks (same we have now) and 3) opening another discussion whether we want to reduce the voting time for all proposals (or some types of them, as you’ve suggested) - for me it seems like having 2 weeks of voting is a lot and can be decreased, but this for sure goes out of scope of this discussion.
Regular upgrades which contain major gaia-only features (e.g., ICS, ICS 2.0)
Regular upgrades which do not contain major gaia-only features
Emergency upgrades which patch bugs or vulnerabilities
I do not think we should have different governance processes for regular upgrades depending on the features included. Once the target version is on-chain, the code should be frozen except in a few rare cases (e.g., updating a genesis file to include the CCV state) so the voting period is really not a good time for people to be reviewing code in order to give feedback and make their judgment. If something new is uncovered during voting period, it means something has gone wrong in the previous steps – maybe an audit is overlapping with the voting period, maybe the proposal went live before people had time to play with the features on testnet.
Imo, there should be a very high degree of confidence in the code itself before it goes on-chain at all, since being on-chain means it cannot be changed (only cancelled or skipped).
I think the proposal as-written is good:
1 week voting for all software upgrade proposals (off-chain, we uphold the social commitment to doing proper testing and training before the proposal is on-chain)
2 week voting for all other proposal types
Emergency upgrades continue to occur without using governance
Separate discussion: what should the voting period be for all non-software-upgrade proposal types?
Separate discussion: should we use governance for emergency upgrades? If so, what voting period?
I would not be in favour of anything faster than 1 week for voting right now. We have a really responsive validator set for emergencies but no one can run at emergency-level responsiveness at all times. If an upgrade isn’t urgent, I think validators should get a week to vote at their leisure.
I’d love to have that and I think that’s a topic that’s worth discussing, do you mind creating another thread outlining your (probably both your personal one and as a Hypna representative) vision on that?
My vision is: a governance is way more suitable for upgrades than having non-governance emergency upgrades via halt-height from the technical side, as with a governance upgrade your node would just crash and you’ll know it in advance, given that you have a proper monitoring, while when using halt-height if you forget about it your node would just continue working with the older binary, causing consensus mismatch if the upgrade was consensus breaking.
Additionally, with governance proposals you can just go to the explorer and find the ones that contain software upgrade, while there’s no on-chain info about the upgrades done via halt-height.
Lastly, you can build tools to fetch the on-chain data on upgrades and stuff, but you cannot build bots to track Discord notifications about needing to set the halt-height, and as for me, I prefer relying on my monitoring infra rather than on Discord chats (because it’s way easier to miss a Discord message than an alert that will keep sending you messages until you resolve it).
So considering all of the above, it would be really great if all of the upgrades, even the emergency ones, would go through governance, and for it to be quick, it needs a way shorter voting period as having to wait 7 days to vote on an upgrade proposal to fix an emergency issue is sometimes unacceptable.
I can start a new thread, yep! We had a great talk about this in stand up today and there are some layers to it that I think should be included in the conversation.
My first concern is the change management – I support this proposal to expedite software upgrade proposals on the condition that we are not also introducing another change to the software upgrade proposal process at the same time! I think the best way to spoil an otherwise great change is to do too much at once
