[PROPOSAL #948][PASSED] Gaia v19 Software Upgrade

Background

The Gaia v19 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 (~ one 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 one week as software upgrade proposals are expedited.

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

The focus of this release is the upgrade of Cosmos SDK to v0.50 – this release uses v0.50.8-lsm, a special Cosmos SDK branch with support for LSM. Consequently, it also upgrades the following dependencies:

A release candidate can be found here.

Testing and Testnets

The v19 release has gone through rigorous testing, including e2e tests and integration tests. In addition, v19 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 (v18).

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.

10 Likes

Obvious no-brainer and 100% yes from Quokka Stake.

One question though: is this fix Optimising querying for validator delegations · Issue #15162 · cosmos/cosmos-sdk · GitHub gonna be included? This should optimise the delegators query greatly, and the lack of it on Hub mainnet as of now is a part of the reason why the most of the public node owners block this endpoint on their end, and I also use it quite heavily on my side for my monitoring tools.

I asked for it to be backported to Hub v0.47/v0.45 prior to that, but the team said it’s better to wait for it as a part of 0.50 upgrade (which is reasonable), so I really hope to see it here.

3 Likes

Yess! The Hub upgrading to Cosmos SDK to v0.50 and CometBFT v0.38!

3 Likes

Hub on SDK v.50 must have been a major feat! Congrats to you and the team @mpoke!

3 Likes

@freak12techno Yes, this issue was fixed by refactor: add delegations by validator index by atheeshp · Pull Request #15731 · cosmos/cosmos-sdk · GitHub and it was included in SDK 0.50. So it will be part of the v19 upgrade.

1 Like

We are delighted to see this happening ! This newer version comes with a load of new features. Readers can have a loot at all the changes here.
pro-delegators-sign

3 Likes

Good development, let’s hope people will talk about this.

Reminder of an issue we saw on testnet:

CometBFT bump and the introduction of ABCI++ had some issues with external signers. To avoid issues, operators need to either use direct signing or ensure that their external signers are on the right versions and properly configured.

  • Horcrux version v3.3.0 or v3.3.1
  • TMKMS v0.14.0 with config set to enable vote extensions (example)

Thanks to Paul at Everstake for highlighting this.

1 Like

Thanks Lexa! For additional visibility, I’ll include this as a note when sending an upgrade reminder directly to operators.

1 Like