Cosmos Hub 3 Upgrade Proposal C (abandoned)

#1

Edit: Abandoned for Proposal D in favour of a new block height: Cosmos Hub 3 Upgrade Proposal D

Looking for feedback on this:

This proposal is intended to supersede Cosmos Hub 3 Upgrade Proposal B, which we have deemed to be flawed.

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 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.0 to upgrade the Cosmos Hub. We are proposing to export the ledgerā€™s state at Block Height 1823000, which we expect to occur on Sunday, September 15, 2019 at or around 2:00 pm UTC. We are proposing to launch Cosmos Hub 3 at 60 minutes after Block Height 1823000.

Instructions for migration: https://github.com/cosmos/gaia/wiki/Cosmos-Hub-2-Upgrade

Decision

We are signalling that:

  1. This proposal supersedes Proposal 14, Cosmos Hub 3 Upgrade Proposal B, regardless of the outcome of Proposal 14.
  2. The Gaia 2.0 implementation is aligned with the list of high-level changes approved in Cosmos Hub 3 Upgrade Proposal A.
  3. We are prepared to upgrade the Cosmos Hub to cosmoshub-3 based upon

a) Commit hash: 3c70fee433956ba32e35705193a5f7a7d5b63277;
b) The state export from cosmoshub-2: Block Height 1823000;
c) Genesis time: 60 minutes after the timestamp of Block Height 1823000.

Cosmos Hub 3 Upgrade Proposal B (abandoned)
#2

Also looking for RTs for visibility: https://twitter.com/Ether_Gavin/status/1166820073107075074

#3

Is there a procedure for obtaining the UTC timestamp and is this documented in the linked upgrade process?

Will there be a fallback plan if the chain fails to start?

1 Like
#4

Feedback on the proposal as a whole - I think it would be best to avoid amending an existing in-flight proposal (since it has not passed) and simply provide a new proposal that specifies the entire upgrade process as desired. Abandon the existing proposal.

2 Likes
#5

I agree. I will revise this proposal.

#6

Proposed recovery scenario in case the chain fails to start.

In the event that a validator determines that the cosmoshub-3 chain is unlikely to start,oor if target upgrade block time + 6 hours has elapsed without block generation, validators MUST resume signing on cosmoshub-2. During the upgrade process, Validator MUST preserve a snapshot of node state on the target block height to preserve recovery of their validator and sentry nodes to the cosmoshub-2 chain.

Governance procedures on the cosmoshub-2 chain will be used determine a future course of action for the network.

2 Likes
#7

Figment will vote ā€˜noā€™ on Proposal 14, and my intention is to push a new governance proposal that supersedes Proposal 14. Please note that I have edited this post with the new draft proposal.

#8

Iā€™ve requested that @bez add this recovery plan and instructions for obtaining the target export block timestamp for validators: https://github.com/cosmos/gaia/issues/116

@roman, thank you for bringing attention to these items.

#9

Updated the upgrade instructions with a section on recovery and how to get a blockā€™s canonical UTC timestamp. Feedback welcome!

1 Like
#10

Proposal 15 is live and in the ā€˜deposit periodā€™: https://hubble.figment.network/cosmos/chains/cosmoshub-2/governance/proposals/15

Spread the word!

#11

Proposal 15 didnā€™t exit the deposit period before September first.

Now the earliest the vote period on Proposal 15 will end is September 16th which will be after the proposed block upgrade.

It seems like either we wonā€™t wait the full voting period and treat a majority vote before Sept 15th as binding or a new proposal will be required.

1 Like
#12

Are there any concerns with considering it as a majority vote?

#14

I donā€™t like this. I already dislike that we did it for proposal #5, but at least for that it was agreed upon in proposal #3. I donā€™t like the idea of breaking the on-chain governance procedures for something as important as coordinating a hard fork especially when it doesnā€™t seem that time urgent (like proposal #8 was).

I think we should just make a new proposal, preferably one whose hard fork block is based as a delta from the block number in which the proposal ends.

If this concern is the 120 ATOMs that have already been deposited, I plan on making a proposal that deposited atoms on proposals that donā€™t make it to voting period should be refunded. And if that passes, some community pool proposals to refund the people whoā€™ve already been affected by that. Iā€™ve just been waiting for this hard fork to be over to make that proposal :sweat_smile:

5 Likes
#15

Oh, also, I donā€™t like that thereā€™s 0 time between knowing whether the hard fork is happening, and it actually happening. Everyone could be prepared to fork, and then suddenly someone decides to change their vote and it swings the result. Would be a shitshow.

1 Like
#16

Yes, I see no reason we should have to use a majority vote in this case, given the lack of time sensitivity. I suppose itā€™s time to draft Proposal D with sufficient timing between the governance phases.

#17

Appreciate the feedbackā€“thanks for engaging :pray:

I was also planning to make a proposal to refund deposited atomsā€“want to collaborate?

Re: block height relative to proposal ending, that could put us into some weird hour of the night on some untimely day, and Iā€™m trying to avoid things like large holidays, daylight savings changes, etc.

Cosmos Hub 3 Upgrade Proposal D
#18

Well itā€™s a good learning experience! My goal is to get validators more engaged in the draft part of the proposal so that we donā€™t end up with Proposal W :joy:

Back to the drawing board for an appropriate day/time: Cosmos Hub 3 Upgrade Proposal D

1 Like