[PROPOSAL XXX][DRAFT] Gaia v18 Software Upgrade

[btruax]

Background

The Gaia v18 release is a major release that will follow the standard governance process by initially submitting this post on the Cosmos Hub forum. After collecting forum feedback (~ 1 week) and adapting the proposal as required, a governance proposal will be sent to the Cosmos Hub for voting. The on-chain voting period typically lasts 2 weeks.

On governance vote approval, validators will be required to update the Cosmos Hub binary at the halt-height specified in the on-chain proposal.

Proposed Release Contents

This release adds the following features:

• Permissioned CosmWasm (as per prop 895) enables the governance-gated deployment of CosmWasm contracts. See this forum discussion for more details on what contracts should be deployed on the Hub.
• Skip’s feemarket module (as per prop 842) enables the dynamic adjustment of the base transaction fee based on the block utilization (the more transactions in a block, the higher the base fee). This module replaces the x/globalfee module.
• Expedited proposals (as per prop 926) enable governance proposals with a shorter voting period (i.e., one week instead of two), but with a higher tally threshold (i.e., 66.7% of Yes votes for the proposal to pass) and a higher minimum deposit (i.e., 500 ATOMs instead of the 250 for regular proposals). Initially, only MsgSoftwareUpgrade and MsgCancelUpgrade can be expedited.

The release also bumps the following dependencies:

• Golang to v1.22
• Cosmos SDK to v0.47.16-ics-lsm
• IBC to v7.6.0
• ICS to v4.3.0-lsm

A release candidate can be found here.

Testing and Testnets

The v18 release has gone through rigorous testing, including e2e tests, integration tests, and differential tests. Differential tests are similar to integration tests, but they compare the system state to an expected state generated from a model implementation. In addition, v18 has been independently tested by the team at Hypha Co-op.

Validators and node operators have joined a public testnet to participate in a test upgrade to a release candidate before the Cosmos Hub upgrades to the final release. You can find the relevant information (genesis file, peers, etc.) to join the Release testnet (theta-testnet-001), or the Interchain Security testnet (provider).

Potential risk factors

Although very extensive testing and simulation will have taken place there always exists a risk that the Cosmos Hub might experience problems due to potential bugs or errors from the new features. In the case of serious problems, validators should stop operating the network immediately.

Coordination with validators will happen in the #cosmos-hub-validators-verified channel of the Cosmos Network Discord to create and execute a contingency plan. Likely this will be an emergency release with fixes or the recommendation to consider the upgrade aborted and revert back to the previous release of gaia (v17).

Governance votes

The following items summarize the voting options and what it means for this proposal:

YES - You agree that the Cosmos Hub should be updated with this release.

NO - You disagree that the Cosmos Hub should be updated with this release.

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 the quorum but you formally decline to vote either for or against the proposal.

[Govmos]

We welcome this update. Although we initially opposed wasm on Hub due to cautionary considerations, we’ve since observed efforts to provide guidelines for this crucial functionality, addressing our primary concern

@jtremback

What should go on the Hub: CosmWasm is a great tool for programming a chain’s core logic, Stargaze does this. This will be very helpful for teams to build on the Hub more quickly and flexibly

• A CosmWasm contract should only be deployed on the Hub if it adds an important piece of core functionality to the Hub, and it cannot be deployed on Neutron while preserving the same functionality.
• Examples of what could go on the Hub:
  • A DAO which is tied tightly into the Hub’s governance, for example having the ability to modify parameters, deploy funds from the community pool, or direct inflation. These things would be unnecessarily complicated to do on a consumer chain.
  • An upgrade to ICS which needs the ability to slash validators or delegators for infractions on other chains (AKA Mesh Security). This would not be secure on a consumer chain.
  • An IBC client for Rust-based blockchains. This needs deep integration into the IBC system and by definition doesn’t make sense on a consumer chain which is itself connected over IBC.

Source: Discussion: Hub CosmWasm guidelines?

Regarding the other proposed updates, we already shared our positive feedback and therefore we warmly welcome them in v18. This proposal will be an easy YES vote for our validator.

[freak12techno]

Obvious no-brainer and “yes” from us. A few question regarding the expedited proposals:

@btruax

Expedited proposals (as per prop 926) enable governance proposals with a shorter voting period (i.e., one week instead of two), but with a higher tally threshold (i.e., 66.7% of Yes votes for the proposal to pass) and a higher minimum deposit (i.e., 500 ATOMs instead of the 250 for regular proposals). Initially, only MsgSoftwareUpgrade and MsgCancelUpgrade can be expedited.

1. Does that mean that all of the upgrade proposals after v18 being applied on mainnet would be expedited?
2. If MsgSoftwareUpgrade and MsgCancelUpgrade both are expedited, they’d have equal voting time, so given that usually the timespan between software upgrade proposal passing and the upgrade being applied is really small, there won’t be much time to submit the MsgCancelUpgrade proposal so it’d actually be passed before the upgrade is applied. That issue actually isn’t changed with introducing expedited proposals, but I wonder if there’s actually a use case for MsgCancelUpgrade considering what I wrote above?
3. I remember on a forum thread on expedited proposals there was a discussion on also adding MsgUpdateClient (or whatever name of the message is for IBC channel unfreeze); was this idea eventually abandoned, or would it be included later at some point?

Would be lovely if someone from the team can clarify this.

LFG!

[mpoke]

Does that mean that all of the upgrade proposals after v18 being applied on mainnet would be expedited?

It depends on the team submitting them as a flag needs to be set. We plan to submit all the software upgrade proposals after v18 as expedited.

If MsgSoftwareUpgrade and MsgCancelUpgrade both are expedited, they’d have equal voting time, so given that usually the timespan between software upgrade proposal passing and the upgrade being applied is really small, there won’t be much time to submit the MsgCancelUpgrade proposal so it’d actually be passed before the upgrade is applied. That issue actually isn’t changed with introducing expedited proposals, but I wonder if there’s actually a use case for MsgCancelUpgrade considering what I wrote above?

The purpose of the MsgCancelUpgrade is to be submitted while the MsgSoftwareUpgrade is in voting so that the chain doesn’t halt once the height in the proposal is reached.

I remember on a forum thread on expedited proposals there was a discussion on also adding MsgUpdateClient (or whatever name of the message is for IBC channel unfreeze); was this idea eventually abandoned, or would it be included later at some point?

We can add it at a later point. The main concern at the moment was MsgSoftwareUpgrade and we didn’t want to block this. If the community feels we should also expedite client upgrades, then we can for sure add it.