x/gov Improvements

[alexanderbez]

Creating this issue in the osmosis repo, although, if accepted, would be implemented in our fork of the Cosmos SDK.

There are a few improvements to the x/gov module that if made would provide huge benefits for users and gov UX, all of which can be implemented independently with different priorities, although should be implemented with all of them in mind. I'll outline as follows:

NOTE: These presume that x/gov is not operating under the x/group approach that is slated for SDK 0.46), so would be subject to change again once Osmosis upgrades to v0.46.

1. 2/3 Majority Emergency Voting Periods

There have been a few instances where a chain needs to enact an emergency upgrade via a text proposal, but needs to bypass the standard voting period, where once 2/3+ of voting power vote yes (or no) by a certain time (e.g. 24h after proposal creation), the proposal is considered "accepted". See Osmosis prop 226 as an example.

Notably, this would most likely be useful on Text-based proposals, but there can be cases made where this could prove to be useful on other proposal types as well.

The high-level implementation would look like follows:

• Set an Expedited (bool) field on proposal types and the interface.
• Set an ExpeditedDuration (time.Duration) field on proposal types and the interface.
• Update x/gov to store an additional index for expedited proposals
• Modify EndBlock in x/gov to:
  • Additionally iterate over all mature expedited proposals and execute the proposal if 2/3+ majority.
  • Proposals would "inherit" same execution path and rules as normal proposals if 2/3+ majority is not met after being mature.

2. Proposal-based Voting Periods

In the same light as (1), there are many instances where the community and validators of the network would desire that certain proposal types have a different voting period than the "base" one. E.g. an incentive update proposal would arguably require less time to mature than compared to a software upgrade proposal which could be deemed more contentious.

The high-level implementation would look like follows:

• Set a VotingPeriod field on proposal types and the interface. When zero-value, assume base voting period is used.
• Set a CustomVotingPeriodQuorum param in the x/gov module
• Update x/gov to set the existing maturity index to account for custom voting periods
• Modify EndBlock in x/gov to:
  • When iterating over mature proposals, if a proposal has a custom voting period, ensure CustomVotingPeriodQuorum is met.

3. Custom Proposer-based Voting Periods

This is similar to (2) and given that to modify the custom VotingPeriod of a proposal type, a hard-fork upgrade would be required, I propose we combine (2) and (3) such that the custom VotingPeriod is provided by the proposal's proposer. Everything else remains the same.

[alexanderbez]

So after syncing with @ValarDragon, we agreed that we'll stick with (1) and (2) and leave it open for iteration and improvement for when we upgrade to SDK v0.46 in the future.

For (2), we'll have to have x/gov keep a []ProposalVotingPeriod in its params:

type ProposalVotingPeriod struct {
	MsgType      string // e.g. "/cosmos.params.v1beta1.ParameterChangeProposal"
	VotingPeriod time.Duration
}

Then when handle submitting the proposal, we do a lookup and attempt to match the type. If the type exists, we use it. Otherwise, we use the base/default voting period.

[p0mvn]

What is the purpose of ExpiditedDuration when we have https://github.com/osmosis-labs/cosmos-sdk/blob/949254a6d6fd2163471942d39db5639ae0a3d1b9/x/gov/types/gov.pb.go#L252-L253 VotingEndTime that can be set to a shorter value?

Is it sufficient to only have a Expedited boolean?

[alexanderbez]

@p0mvn I didn't realize we had that field as I completely forgot Osmosis made existing modifications to x/gov. I was operating under the pretense of the core SDK module. So yes, you're probably correct in that we don't need ExpeditedDuration. Correct me if I'm wrong @ValarDragon

[p0mvn]

Makes sense, the difference should be minimal.

@alexanderbez Where do you see me helping out? I'm fine with taking any part that I can help out on

[mattverse]

Same here! Available to parrelize on any fronts

[ValarDragon]

We modified voting end time? I don't remember us changing that, are we sure its not in SDK v0.44.x? Looks like its there in upstream: https://github.com/cosmos/cosmos-sdk/blob/v0.45.4/x/gov/types/gov.pb.go#L253

That value there isn't provided by the user, its set by the state machine upon a proposal entering voting period

[alexanderbez]

You're right @ValarDragon -- my comment/proposal still stands then I think.

[p0mvn]

These are all now complete, the only remaining part is to approve #1 via governance and release