Cosmos Hub 3 Upgrade Proposal B (abandoned)

#1

Edit: We have abandoned this proposal and posted this as a replacement - https://hubble.figment.network/cosmos/chains/cosmoshub-2/governance/proposals/15

Looking for feedback on this:

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 1774000, which we expect to occur on Wednesday, September 11, 2019 at or around 4:22pm UTC. We are proposing to launch Cosmos Hub 3 at 6:22pm UTC on Wednesday, September 11, 2019.

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

Decision

We are signalling that:
  1. The Gaia 2.0 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: 3c70fee433956ba32e35705193a5f7a7d5b63277;
b) The state export from cosmoshub-2: Block Height 1774000;
c) Genesis time: Epoch 1568222520.


JSON format

{

“repo”: “https://github.com/cosmos/gaia/releases/tag/v2.0.0”,

“commit_hash”: “3c70fee433956ba32e35705193a5f7a7d5b63277”,

“export_block_height”: “1774000”,

“genesis_time”: “1568222520”

}

#2

Looks great to me. Looking forward to pulling out the bowtie!

1 Like
#3

…Gentleman Jack! :man_in_tuxedo:

#4

1/2 hours early will much friendly to Asian friends.

#5

Heya! Not sure I follow–are you asking for the upgrade to be earlier?

#6

Yes. launch at around 4:00PM UTC.

1 Like
#7

Makes the state export around 7am PST, difficult for Tendermint team on the west coast.
Perhaps we could alternate between 4pm and 6pm UTC each time there’s an upgrade. Thoughts?

#8

It seems that 16:00pm UTC is best time for all of us.

time%20zone
time zone.png989Ă—633 44.2 KB

3 Likes
#9

Don’t need 2 hours for state export. Maybe 1 hour is enough.

#10

September 12~14 is thanks giving holiday for most Asian countries. It is the biggest family holiday in Korea and China. It is strongly recommended to do an upgrade after the holiday or 1~2 day earlier.

This statement is from strong agreement of 4 Korean validators, B-Harvest, A-Team, Cosmostation, and CoinOne.

6 Likes
#11

Our holiday start from 13th to15th September.

1 Like
#12

+1

Thanks for posting this!

1 Like
#13

Agreed, 6:22 pm UTC equals 2:22 am in China :sweat_smile:

#14

Thank you @Gavin for planning this.

On timing:
I think what @ping suggest is good. But maybe 1 hour earlier so our friends in Korean can rest earlier.

On dates:
Having it prior to the holidays (before 11 Sept) might be better - reason being there is Wanxiang Blockchain Week in Shanghai right after the holidays (16 to 18 Sept), which I believe many validators will attend.

2 Likes
#15

Time is not friendly to Asian friends, I disagree with the time.It seems that 16:00pm UTC is best time for all of us.

#16

1 or 2 hours earlier would be best for all of us including Korea and Japan. I would say 2 pm or 3 pm UTC. Thanks.

#17

Sept 11 1600 UTC is fine for us as long as it won’t touch 12-14 Sept for the Mid Autumn Festival. Otherwise, it’s better be the week after.

#19

Hey all! Thanks for all the info, I’m glad to see so much participation.

I’m going to revise the proposal:
State export for Block Height 1,823,000 to target Sep 15 ~2pm UTC (7am PDT).
Genesis epoch 1568563077, so upgrade at 3:57pm UTC (~1am KST).

FYI, doing Sep 15 because I don’t want everyone in China/Korea away on holiday directly after a major upgrade…!

1 Like
#20

Awaiting deposits: https://hubble.figment.network/cosmos/chains/cosmoshub-2/governance/proposals/14

#21

Apologies for not bringing this up prior to proposal creation (just read this thread), but I am quite concerned about the specification of an exact restart time instead of one relative to the export block timestamp.

Have you calculated the expected deviation (error bars) on the time estimate for block 1,823,000? If network conditions and/or the stake distribution change, even a little, over the next month, that height may come more quickly - in which case the network might experience an unnecessarily long downtime - or more slowly, in which case operators might not have enough time to upgrade, creating unnecessary operational risk. It is perfectly possible that block 1,823,000 happens after 3:57 PM UTC, in which case it is unclear what would happen.

I think a version of this proposal which specified a relative, as opposed to absolute, restart time would be safer, and I would advise that the relative offset be on the order of four or five hours instead of two - the cost of a few hours of downtime is low, better to ensure that validators have sufficient leeway to upgrade carefully.

2 Likes