Cosmos Hub 3 Upgrade Proposal E

Hey Cosmos validators–let’s take another crack at our first major upgrade! :rocket:

Figment Networks - Cosmos Hub 3 Upgrade Proposal E

This proposal follows Cosmos Hub 3 Upgrade Proposal D (“Prop 16”), which passed in vote, but failed in execution. This proposal is intended to succeed where Prop 16 failed.

This proposal is intended to signal acceptance/rejection of the precise software release that will contain the changes to be included in the Cosmos Hub 3 upgrade. A high level overview of these changes was successfully approved by the voters signalling via Cosmos Hub 3 Upgrade Proposal A.

We are proposing to use this code https://github.com/cosmos/gaia/releases/tag/v2.0.1 to upgrade the Cosmos Hub.

We are proposing to export the ledger’s state at Block Height [TBD], which we expect to occur on [MONTH DATE], 2019 at or around [TIME] UTC. Please note that there will likely be a variance from this target time, due to changes in block time.

We are proposing to launch Cosmos Hub 3 at 60 minutes after Block Height [TBD].

Instructions for migration: https://github.com/cosmos/gaia/wiki/Cosmos-Hub-2-Upgrade
Please note the failure criteria and recovery scenario in the case that the migration procedure fails or in the case that cosmoshub-3 fails to start.

Notification of failure will be made in this channel: https://riot.im/app/#/room/#cosmos_validators_technical_updates:matrix.org

Decision

We are signalling that:

  1. The Gaia 2.0.1 implementation is aligned with the list of high-level changes approved in Cosmos Hub 3 Upgrade Proposal A.
  2. We are prepared to upgrade the Cosmos Hub to cosmoshub-3 based upon
    a. Commit hash: [TBA]
    b. The state export from cosmoshub-2 at Block Height [TBD]
    c. Genesis time: 60 minutes after the timestamp at Block Height [TBD];
  3. We are prepared to relaunch cosmoshub-2 based upon
    a. A non-trivial error in the migration procedure and/or
    b. The failure of cosmoshub-3 to produce a block by 180 minutes after the timestamp of Block Height [TBD]
    c. Cosmos SDK v0.34.8: [URL]
    d. The ‘recovery’ instructions section of this procedure: https://github.com/cosmos/gaia/wiki/Cosmos-Hub-2-Upgrade;
  4. The upgrade is considered complete after cosmoshub-3 has produced one (1) block.

Looking for feedback about the proposal above :point_up:

:white_check_mark: Please note that:

  1. The recovery instructions on Github have not yet been updated
  2. Validators are in the process of testing the upgrade procedure on a testnet
  3. We should begin proposing dates after validators are satisfied with the results of #2.

Hey thanks for the work.
After too many propos, sorry, but Im not sure what propos have to read to follow the changes for this propo.

Can elaborate all the changes or is only about software upgrade

Everything should be in the proposal. I suggest reading it carefully and then please let me know if anything appears to be missing.

Hi Gavin, thanks for setting up this proposal. I’ve posted my response on the document. Would like to suggest a longer upgrade time window, something like 2-3 hours, just in case.

1 Like

Thanks for working on this Gavin.

Prior to running with and publishing a 5th upgrade proposal and possibly restricting ourselves to a timeline, we should independently work out the process of fully testing the migration and upgrade. As has been initiated by B-Harvest.

I think getting this right is more important than performing the upgrade asap, as it’s beneficial to work out and actually go through a thorough test. We can always go over the steps later on, for a 2nd time, for the proposal’s sake.

Thanks for the effort of creating this proposal.

I think it’s too early for that proposal. First we need a version that fixes the migration error, as far as I know version 2.0.1 will produce the same error. Also we should probably use a gaia version with an upgraded cosmos-sdk (since there was a security issue in cosmos-sdk v0.37.1).

When we have a version we could use (I’m not sure what the state is) we should probably do a dry-run on a testnet. FrancescoSVC already mentioned that B-Harvest initiated that.

After this is done we could think about a proposal, now seems too early.

1 Like

Hey Francesco & @dfs, not sure if I’m misunderstanding–have you seen this comment?

Looking for feedback about the proposal above :point_up:

:white_check_mark: Please note that:

  1. The recovery instructions on Github have not yet been updated
  2. Validators are in the process of testing the upgrade procedure on a testnet
  3. We should begin proposing dates after validators are satisfied with the results of #2.

@Gavin Sorry I completely missed that reply.
As for feedback:
The Gaia Version which should be [TBD]. (This tripped me up when reading the proposal, hence my first response.)

Also what irks me a bit is the notification of failure. It seems like a centralized approach. Who’s going to post that notification? If it just means that validator operators can signal their status over there, that’s fine I guess, but maybe it should be worded differently.

60 minute time frame is fine by me.

Hope that helps.

1 Like

Agreed, it is a centralized approach. AiB (so Jack, Bez, or Zaki) would likely post the notification. Let’s get thinking about how to decentralize this or at least make this less centralized.

My concern is that there can be a lot of noise in the other channels. I wonder if we could create an off-chain interface for signalling intention based upon voting power.

1 Like

I think failure determination is a social consensus. It was last time. Social weight isn’t equal to voting weight.

The testnet with the fixed migration software should be launched today. The proposal should include the testing results and information of the testing process for reference and verifications.

1 Like