[PROPOSAL #16][ACCEPTED] Cosmos Hub 3 Upgrade Proposal D

Hub Proposals Signaling/Text
21

Although I do love this feature, maybe we stick with what the proposal D suggested if it will pass at this stage. Just we need to keep the community being updated with the expecting time in the last few days before the upgrade.

1 Like
22
23

Just a quick question, after 1,933,000 blocks all blocks must be generated under new code base. If we upgrade the software later, for instance around 1,934,000 in public, would that work without slashing and any penalties by catching up the rest of blocks afterwards ?? There are 2 points in this question.

  1. Less than 95% of the blocks in a rolling 10,000 block could be missed under the slashing condition.
  2. Would need some variances between the nodes to upgrade the code to avoid most of nodes going offline at the same time.

If the protocol bears slashing the nodes that have not caught up less than 95%, we might need a schedule or rolling upgrade plan between the nodes ?

Regeards,
Yuya (sanka.network)

1 Like
24

@zaki thoughts on this? I don’t want to guess incorrectly.

25

Sorry again, we went through the upgrade document now and some questions came up internally. Appreciate if somebody could check these questions and answer.

  1. Incompatibility node
    Will we need to stop the existing gaiad just at the block height 1,933,000 on 24th ? We wonder what happens if the non-updated nodes keep sending transactions in the network at the same time. Let’s say we can’t run the existing gaiad and gaiad 2.0.0 at the same time.

  2. Sha256 value
    We saw shasum -a 256 confirmations twice for the exported json and genesis.json for new software, however off course, we think we can’t know that hashed value unless we have the state data by 1,933,000 on 24th.

How can we confirm our hashed value is accurate, by seeing what site or twitter, information in public in realtime when we’re doing an upgrade work ?

  1. Rollback case
    If the network upgrade does not go smooth unfortunatelly and need a roll-back of the network to Cosmos Hub 2, what does the procedure look like and where will that decision be published and when and by who ?

Regards,
Yuya (sanka.network)

3 Likes
26

My current calculation is roughly at Sep 24, 2019, 11:16 AM UTC

1 Like
27

Hi Yuka!

Having difficulty understanding your questions–do you use Telegram? Would appreciate if you could reach out: https://t.me/gavinly

You may also want to try Riot: https://riot.im/app/#/room/#cosmos-validators:matrix.org

28

  1. We will fork the chain at the height. So, blockchains after this height is meaningless to anyone. It does not need to continue running it. I expect the chain will halt very soon after that height.

  2. Hash will be available to compare after the height. Before the height, nobody knows the hash of course. Hash will be shared in many different channels decentralizely including official github or riot channel I expect.

  3. There is no reason for us to rollback before the given height, unless something happens in current binary. Because we are doing a fork upgrade, rollback after the given height is not an option, but will try to launch the new chain again

2 Likes
29

Thanks for your reply. We still have some questions.

  1. We will fork the chain at the height. So, blockchains after this height is meaningless to anyone. It does not need to continue running it. I expect the chain will halt very soon after that height.
    That’s correct. We thought what happens for the inactive node those might not upgrade their code in realtime on 24th. They will be running their nodes and they keep producing their blocks in Cosmos Hub 2 still ? What will be drawbacks of inactive nodes ?

  2. Hash will be available to compare after the height. Before the height, nobody knows the hash of course. Hash will be shared in many different channels decentralizely including official github or riot channel I expect.
    We are on the same page. We can’t know the hash value of that state. Let’s decide what channel and forum we will pulish the hash value information if we need cooperations from all of other validators. Does somebody update the info on github and riot in realtime ?

  3. There is no reason for us to rollback before the given height, unless something happens in current binary. Because we are doing a fork upgrade, rollback after the given height is not an option, but will try to launch the new chain again
    We are not sure about this. Why do we have that recovery plan in the procedure ? We thought we would need to go back to Cosmos Hub 2 if something goes wrong in Cosmos Hub 3 and we can rerun the same software with the recorded state until 1,933,000. Cosmos Hub 2 should still work after a rollback plan.

We’d like to make sure we’re on the same page and every validator do the same on the upgrade date not to make any mistakes.

1 Like
30

  1. Running hub2 itself does not produce any problem if the validator makes uptime in hub3 before slashed.

  2. Cosmos team will. But other validators will also share it in different channels.

  3. Even though we failed to launch hub3 with new binary, we will launch a new chain with current binary. So we dont go back to hub2. It will be hub2.1(new chain) with old binary.

2 Likes