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 Release v2.0.0 · cosmos/gaia · GitHub 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.
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.
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?
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.
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.
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…!
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.
