Expedited Governance Proposal Option

[iramiller]

Summary

An expedited governance proposal flow would allow for governance proposals to be passed with a much shorter duration when a higher majority level is reached. This feature would allow for coordinated execution prior to submission of a governance proposal in response to security related software upgrades as one example.

Problem Definition

Currently the long voting window is used to provide ample opportunity for users to review governance proposals and vote appropriately to express their opinion on a measure. While this is the expected and desirable behavior, it breaks down in cases where the network needs to respond immediately to threats or vulnerabilities.

The expedited governance proposal option would add a capability for a network to respond rapidly during emergency situations while balancing protection of rights against abuse where a proposal is pushed through quickly without time for proper debate. This can be achieved by providing an additional governance controlled set of parameters that establish a much higher level of approval such as a 67% majority or similar value appropriately chosen by the network.

Today when a severe vulnerability is uncovered the validator community can discuss an upcoming update in private and prepare an update but it is difficult to do this in a way that does not leak advanced warning for someone to prepare an attack against the network while this is occurring. As the value of assets increase further it is conceivable that even one of the individuals associated with an existing validator in these private channels may be tempted to leverage information to mount an attack before a mitigation is in place.

In addition the increased use of the upgrade module and cosmovisor processes to automatically rollout updates has created an environment where the best approach is to use on chain software upgrades in the standard flow and avoid alternative approaches (such as a coordinated halt height).

Proposal

• Create an alternative expedited proposal flow for software upgrades that allows a proposal to be passed early when a configurable high level of participation is reached. This would be implemented as an adjustment to the voting period to move the end point of the proposal forward when the target Yes threshold is exceeded.
• Add a configuration parameters that allows the expedited flow to be enabled or disabled as well as the minimum threshold required for advancement.
• Add the ability to set the block height the upgrade proposal applies as a function of the blockheight the proposal passes with an added margin. This allows a proposal that passes immediately to have an effective blockheight that would otherwise overlap with the voting period if the proposal takes the entire normal voting window to pass.

---

For Admin Use

• [ ] Not duplicate issue
• [ ] Appropriate labels applied
• [ ] Appropriate contributors tagged
• [ ] Contributor assigned/self-assigned

[iramiller]

Potential Concerns Discussed During Initial Architecture Review Introduction

• Overriding Validator Votes by Delegators An expedited governance proposal process will ultimately reduce the opportunity for stakeholders to override the default vote provided by the validator they are delegated against.

• Short Duration Voting Window One of the purposes of governance proposals having a longer duration voting period is to allow stake holders sufficient period of time to research and form an informed decision before making their vote. An expedited governance proposal would negatively impact this process. Including a module parameter for the minimum allowed expedited duration would allow a network to adjust this period to balance the risk for their unique requirements.

• Advancement of Proposals With Limited Participation Currently the Quorum level of a governance proposal can be set low with the idea that given the long voting period anyone who wishes to actively participate will have sufficient opportunity to do so. For an expedited proposal the use of a much higher level of quorum will provide assurances that the proposal has been seen by a sufficient number of stakeholders. The level of quorum for expedited proposals should be a module parameter allowing a network to adjust this value to adjust this period to balance the risk for their unique requirements.

[robert-zaremba]

CC: @sunnya97 - you might be interested to comment on this.

[robert-zaremba]

Things to specify:

• expedited would be a new flag / parameter in a proposal, right?
• Do we want to include a minimum period as well? It would be: proposal passes immediately once the Yes threshold is met and proposal is active for at least the MinExpeditureVotingDuration.
• Should veto be interpreted in the same way?

[sunnya97]

An alternative that I would like is that a voting period can be made shorter but my providing a much larger deposit.

[iramiller]

voting period can be made shorter but my providing a much larger deposit.

An increased fee makes a lot of sense to bond for the increased exigency risk. This fee level along with the other parameters for increased quorum levels, durations of vote, etc would all need to be made available for chains to tailor.

Ultimately the structure of this proposal points towards the idea that you can have a straight forward vote on a proposal as we have today ... or you can post a higher bond and meet a higher standard of quorum with an increased opportunity for veto as a useful tool for an emergency response.

[iramiller]

@sunnya97 / @robert-zaremba ... during the process of working through an ADR for this I realized that the solution to the problem was a bit more generalizable than my first take lead me to believe. Overall I feel that the answer to an emergency process, a standard governance process, and possibly other less critical processes is that each should have the option of tailoring the configuration accordingly. Per the ADR draft that I started my proposed solution now is to capture all of the voting/proposal configuration properties into a named profile such that existing values can become the default and each network can add additional profiles that are appropriate for their specific needs.

This approach I feel also would integrate well with the upcoming migration to a msg dispatch based approach for governance proposals. One obvious hole that I have not resolved is that if the end point of a proposal is variable (proposal closes when threshold is met) then in some cases it would be difficult to properly execute the payload of the proposal... for example a software upgrade proposal needs an upgrade blockheight.

Hopefully my draft ADR can spur some additional engagement as this issue is kind of languishing right now.

[clevinson]

From @iramiller during our architecture review call today - most of this can be taken care of with decision policy (in the upcoming gov/group module alignment work).

The only remaining issue is that all stakers can not vote on groups right now, but the work that is in #9438 gets him what he was looking for.

[robert-zaremba]

I don't see a clear win of Expedited Governance over a hot update with validators / hard fork.

• even if Expedited Governance is up and working, a communication with validators must be established
• I think it's good to keep voting period short anyway: ~5days.
• With Expedited Governance we still need to have long enough voting period. Some hot fixes will need to be shipped immediately - hence hard fork is the only choice
• Some security patches may need to go without general public attention (ouch ... I know it's bad ... but is there a good alternative for confidential security patches?)
• Tendermint has a clear win with hard forks - the minor chain will halt.