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.
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.
Hey Francesco & @dfs, not sure if I’m misunderstanding–have you seen this comment?
Looking for feedback about the proposal above
Please note that:
- The recovery instructions on Github have not yet been updated
- Validators are in the process of testing the upgrade procedure on a testnet
- 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.
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.
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.
Thanks for continuing to manage this @Gavin. I feel now’s a bit pre-mature to review this in-depth, because many of the details are TBD at the moment.
Here are a few high-level thoughts in the meantime -
1 - The correct s/w version seems to be in flux. The current recommended production version is v0.34.9. However it’s not expected to last long, as another bug has been discovered and a fix is under development.
2 - We should fully test the upgrade process on a testnet, before a vote takes place to upgrade mainnet. This way we can have more confidence in the s/w and our vote. I also suggest following a process like @b-harvest organized.
3 - I feel the upgrade should only be considered successful after maybe 1000 blocks. 1 block isn’t enough. For example, the network hung after a block for many validators during the independent testnet @b-harvest organized. Also, in the past, test nets crashed on a regular basis within approximately the first 30 mins of the network coming online.
Hey all, looking for feedback on Block Height 2,639,000. Targeting 14:34 UTC on Wed, November 20, 2019 for the Cosmos Hub 3 upgrade.
Quick update: Bez has frozen Gaia’s code at v2.0.3. Hyung (B-Harvest) is organizing a testnet upgrade using that code in the next ~7 hours. Thanks to Chris Remus for those suggestions.
Let’s start thinking about a date for upgrade. I’m thinking Dec 3 or Dec 4, looking for feedback.
Proposing Dec 11, Block Height 2,902,000 for the upgrade.
For us December 11th is fine! (stakefish)
Validators take note
There’s a guide to assist with migration here: https://github.com/cosmos/gaia/blob/master/docs/migration/cosmoshub-2.md
You should know that migrating increases the likelihood of equivocation, which currently results in a 5% stake slashing. In other words, there’s an increased risk of double-signing, which results in 5% of the validator’s stake-backing (including delegator stake) being destroyed.
In order to mitigate that risk, ensure that you are using the correct genesis file by comparing its hash with those posted by other validators after the launch of Cosmos Hub 3. If 67% of the voting power is online, you don’t have to have your validator online at genesis–in fact, it is safer to wait until you are ready to launch and taken any necessary precautions.
Note the recovery scenario, for which you should be prepared for in case Cosmos Hub 2 needs to be relaunched.
Preparing to push the proposal live. Please review the testnet version: https://hubble.figment.network/cosmos/chains/gaia-13006/governance/proposals/41
This proposal just went live: https://hubble.figment.network/cosmos/chains/cosmoshub-2/governance/proposals/19
Asking that each validator limit deposit sponsorship to 50 $ATOM max.
Spread the word! https://twitter.com/FigmentNetworks/status/1195027366948593666
Hey validator operators, please check out this article in preparation for migrating to the Cosmos Hub 3: https://blog.cosmos.network/cosmos-hub-upgrade-migration-risks-ad7b59b9c9f2
And please help spread the word: https://twitter.com/cosmos/status/1202318549873811456