Discussion: Governance: damage control

[liamsi]

Summary

We still want to limit the governance module to some extent. Long term we might want to limit even certain params but it seems like text-based signalling proposals are the most contentious and should be avoided.

Problem Definition

There are several examples of Cosmos chains that are not able to innovate due to governance canning several potentially impactful proposals.

Proposal

Remove text-based signalling proposals.

Ideally only keep:

• community pool spend proposals
• (limited) set param change proposals

We should potentially discuss this a bit further before jumping into limiting capabilities of the gov module here.

An open question is if we want to remove text-based proposals for hard forks / upgrades.

For Admin Use

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

[musalbas]

Specifically, the governance of Celestia is not intended to be on-chain (dictated by tokenholders), but rely on off-chain social governance like Ethereum, so we should avoid validators/whales thinking that the on-chain governance module is anything more than signalling.

[hxrts]

I was chatting with @liamsi in dms and he asked me to comment on this issue. Couple thoughts:

• Signalling proposals can be removed, comes at the cost of additional work to create Schelling points around large protocol initiatives. Essentially asking the community "should we work on this big project," but I think Celestia can pull it off.
• NoWithVeto could be removed, I've been discussing the same with the Penumbra team. Can make it so like 75% NO will burn the deposit.
• I suggest making a clear public commitment to governance minimization over time. Validators and token holders should be aligned form day 1. Consider even adding it to the genesis text.
• In order to have minimised governance it's best to publicize crystal clear guarantees you intend the system to uphold so a decentralised community can evaluate decisions independently against these criteria.
• Groups module could probably be removed (though it is much easier to use than the cryptographic multisig)
• Ismail said you may do a small community pool. I think these are valuable for marketing and community initiatives. It's a very poor capital allocation system, but it's just a hard problem to create a self-sustaining system that attends to protocol maintenance. Have lots to say about that, but can take the convo elsewhere. If you want the community pool to diminish over time you could eliminate the tax rate and just have a fixed amount in the pool.

[evan-forbes]

Is it okay if we work on this after incentivized testnet? I know this is a state related change, but hopefully this will only involve removing functionality.

[liamsi]

Yeah, it is OK to work on this after incentivized testnet. Though we should decide earlier than later what kind of functionality we want to launch with exactly.

[liamsi]

Current thinking (no final decision yet):

keep:

• community tax and pool
• proposals to change parameters

and remove

• all other text based arbitrary proposals
• upgrade proposals that point to a release

I will look into the legacy gov module as well as the new one. Mainly to look into how much work the above would be. My assumption is that this should be very easy. It might be the case that we need to copy&paste the gov module into our app and modify it though.

[hxrts]

are you keeping any part of the upgrade proposal? having an agreed upon block height is very useful

[musalbas]

IMO on-chain governance ideally shouldn't be used as a schelling point for upgrades because over time this may make it that the chain actually has de-facto on-chain governance by the validators, if the power to do off-chain upgrades is never exercised until it's needed when the validators disagree with the community. In other words, if you never exercise your rights, you'll lose them.

It would be better if the upgrade process is coordinated off-chain, like Ethereum. That being said, Ethereum's PoS protocol has better liveness properties.

In Tendermint if 1/3 of validators disagree with an upgrade, the community could attempt the upgrade with their stake undelegated. However, this may cause the chain to have temporary downtime in order to figure out who stopped validating and may be harder to coordinate.

Maybe the solution could be an upgrade process where the upgrade binary is determined off chain where the upgrade happens at a certain upgrade height, and validators signal on-chain if they plan to upgrade. For the validators that don't signal, their stake could be automatically undelegated at the upgrade height.

[hxrts]

how do you see a governance signalling proposal (with constrained message format) differing from validator signalling as you describe?

[musalbas]

The main difference would be that the upgrade height is decided off-chain, so that the upgrade happens whether or not 2/3 of validators signal for it or not. If less than 2/3 of validators signal for it, then the upgrade will still happen, but the validators that didn't signal will be un-delegated when the upgrade happens.

[mindstyle85]

hey guys, noticed this issue and would just like to make a point or two

• experience from other chains i have is that validators in most cases do support upgrades
• if a validator disagrees, delegators can restake to another validator in one go, so there is no stake missing really, so no issues or downtime is expected if that happens
• other projects usually delegate to a select group of validators, and since the validators are being delegated to by the team/foundation, its in their interest to agree with the team on upgrades and vote accordingly (agoric, umee and axelar are all good examples of that)

Im not sure going back to offchain is the best, except to mitigate any risks you talk about validators not being aligned in the future.

Also something to consider is that the average user wont know much about these upgrades or benefit/downside it has, unless it strictly will be something that impacts them monetary. Most regular users dont even know much about the on chain governance, or participate, or even care (unfortunately). Having these discussions on some forums with the community is usually counter productive, i have seen that a lot of times. So in the end its actually easier to make sure the team and validators are aligned, as those in the end are the ones that validate and secure the network.

Are there any specific reasons or examples when validators went against the core team? I dont think something like eth POW to eth POS is a good example as its understandable that miners were not happy about that, and the change was significant that i dont expect to happen on a POS chain? Other than that i didnt see any issues with upgrades on the chains we are (all tendermint we participate in, solana, avalanche, harmony, etc).

[MicahZoltu]

There exists a set of actors who are validators, and a separate set of actors who are users. These two sets intersect somewhat (an actor can be both a user and a validator), but they aren't entirely overlapping.

When designing protocols you should treat each set of actors independently, even if there is sometimes overlap between them. The blockchain should be targeting features that are beneficial to users, not targeting features that are beneficial to validators. Validators should, for the sake of mechanism design, be considered service providers.

Once you have separated out validators from users, then it should be immediately obvious that validators should not be the ones making decisions for how the protocol should change. Users ideally would be making those decisions, but if they are inaccessible then you need a proxy that is most likely to be aligned with users.

Historically, blockchains have used core devs to be this proxy and it generally works out well in the beginning because the core devs usually are the ones who define the ethos of the chain at the start and users are the people who join/participate because of that ethos. Unfortunately, this deteriorates over time for any blockchain that undergoes a lot of development (e.g., Ethereum) as the core devs change over time from those who originally built the chain (and defined the ethos) to new people who have a different ethos/goals.

---

My personal recommendation is to wait to launch until you are "done" (feature complete), then have a couple of years of upgrades to tune things based on real-world feedback and learning, then ossify governance (only critical security fixes) before there is a chance for the people who are representing the ethos of the chain to turnover (thus causing a change in the ethos of the collective representatives).

Having a fuzzy plan for long term ossification I think is very prone to feature creep. Again, using Ethereum as an example we have seen its roadmap grow massively from its original fuzzy launch plan. All of the features Ethereum devs want to add are good, but it has been made fairly clear that it is never going to ossify. At the same time, we have seen the ethos among core devs start to shift slightly away from the original ethos. Even as far back as The DAO fork we already were seeing signs of ethos shifts.

I think it is unrealistic to believe that those governing the system will remain perfectly aligned with users long term, and so I think there should be a very concrete plan for ossification of the ruleset as soon as possible after launch. I would much rather see Celestia launch later with a concrete and rapid ossification plan than see Celestia launch with a fuzzy or no ossification plan and end up falling to eventual governance capture as always happens.

One last thing to keep in mind is that ossification of Celestia doesn't mean the people who developed Celestia have to stop developing! It just means they can go on to develop a new blockchain (Celestia 2?), or rollups, or whatever. In this post I am only advocating for ruleset ossification of the chain named Celestia with whatever ticker symbol it uses. I am not arguing that developers should stop iterating.

[evan-forbes]

We are planning on #1014, which includes an offchain upgrade mechanism, but until then we will likely have to rely on the normal upgrade mechanism using the upgrade module, gov module, and (optionally) cosmovisor. I definitely agree with others here that we need a firm plan before mainnet.

We could also remove the community pool entirely, which was one recommendation by @cmwaters, which I think is worth discussing.

[evan-forbes]

changed to a discussion, and closing this issue in favor of #1014 and #1569

note that there will also be a blog post accompanying mainnet that will focus on this topic before or at mainnet launch

[MicahZoltu]

Is there a place where continued discussion on this topic will/has occurred #1014 and #1569 seem to be different (more specific) topics? If not, what is the decision making process for the contents of this future blog post?

[evan-forbes]

@MicahZoltu we can continue the discussion in the #1593 discussion thread. This one was closed because it was an issue scheduled for mainnet, but didn't have any concrete specifications as to what should be done between now and then.

The forum might also be a good place to discuss the specifics of governance in a longer form. Presumably we will also have CIPs at some point in time, but I'm not sure if they will be the best place to discuss governance.

As far as the contents of the blog post, I suspect this will be mostly Mustafa's vision, and will likely have more details on setting precedents etc for Celestia.