[PROPOSAL 937][PASSED] Gaia v18 Software Upgrade
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.,…
Excerpt (1194 of 3729 characters). Read the whole post on the forum ↗
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 Discussion: Hub CosmWasm guidelines? 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…
Excerpt (1196 of 1549 characters). Read the whole post on the forum ↗
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. • Does that mean that all of the upgrade proposals after v18 being applied on mainnet would be 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? • I remember on a forum thread on expedited proposals there was a discussion on also…
Excerpt (1198 of 1435 characters). Read the whole post on the forum ↗
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?…
Excerpt (1194 of 1411 characters). Read the whole post on the forum ↗