[PROPOSAL 926] [VOTING] Signaling Proposal - Expedite Software Upgrade Proposals

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…

Excerpt (1198 of 3037 characters). Read the whole post on the forum ↗

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:

1. Increase the quorum to 66.7% to ensure sufficient participation.
2. 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,

Considering the various features the Hub needs to introduce in the future,
I think 2 weeks is too long.

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.

1. 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.

@Govmos To reduce the risk of bogus expedited proposals, we could increase the expedited min deposit.

Just adding some additional context. Backporting the expedited proposal feature from SDK 0.50 would enable any proposal to be submitted as an expedited proposal. There are three system params that can be set for expedited proposals:

• 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:

[PROPOSAL #][LAST CALL] raise the Governance `MinDeposit` to 500 ATOMs Parameter Change

Change log 2024-02-01 Created initial post 2024-02-16 Moved to “Last Call”. As the poll is currently hesitant between 500 and 1000, we’ll give it another week and move on-chain with the lowest barrier (500) unless the poll shifts significantly enough towards the higher value. Summary This proposal aims to raise the min_deposit parameter of the Governance Module from the existing 250 to 500 ATOMs, effectively doubling it. Details Looking through the recent history of on-chain proposal for the …

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…

Excerpt (1190 of 1249 characters). Read the whole post on the forum ↗

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)…

Excerpt (1197 of 1500 characters). Read the whole post on the forum ↗

freak12techno: 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). Right now I’d say we have three upgrade types: • 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…

Excerpt (1197 of 2341 characters). Read the whole post on the forum ↗

lexa: Separate discussion: should we use governance for emergency upgrades? If so, what voting period? 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…

Excerpt (1197 of 1658 characters). Read the whole post on the forum ↗

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

Edit: Use governance for emergency upgrades

Let’s goooo

Supportive with this idea. But need to consider the risks as well.

@Govmos We could increase the min deposit for expedited proposal to 1000 ATOMs. Given that we want only SoftwareUpgrade proposals to be expedited, this will not really have any negative effects. However, if we do plan to expedite also ClientUpdates, then this can be seen as a barrier for users to unfreeze a light client, especially for a transfer channel without that much traffic.

We suggest considering a collaborative approach for reaching the minimum deposit requirement, where community members collectively contribute to meet the threshold. We respectfully disagree with the notion that a 10k$ deposit is prohibitive. The collective strength of a community is often underestimated. This can be viewed through a risk management lens. Expedited propositions may carry increased risk, and requiring a higher deposit could be seen as one method to manage that risk. If we go two times faster with a week duration for these proposals, we will suggest a bare minimum 2x increase from the regular deposit.