Cosmos Hub 3 Upgrade Proposal D

It doesn’t seem wise to depend on new software being developed and deployed.

2 Likes

Thanks @Gavin for your hard work on this.

As long as it avoids a large holiday (12th ~ 15th Sept) here in South Korea, we are fine with the date.
Since Cosmos is global and validators are spread all over world, we understand that some validators will eventually have to bear with the timezone.

3 Likes

I agree on the target time and also date (24th)

0.035sec(0.5%) average blocktime volatility means about 2.5 hours of volatility for 20days.
So, we have to admit that the timing can have roughly ±2.5hours volatility.

2 Likes

If this is simple and the software can be tested to confirm safe, I would prefer halting at a specific time with the software.

Or can we think of a mechanism that validators with 34% voting power in total can stop gaiad at a certain time to halt the chain and we pick the latest height? Otherwise, the block time difference will always make us don’t have agreement on upgrade time.

1 Like

Specific time needs a feature on SDK I guess.
2.5hour variance is acceptable imo. My reply was just informing community about such magnitude of variance.
Enforced halt with 34% power seems too risky solution and looks less democratic.

We are already quite delayed for this upgrade, so I hope we focus on deciding a solution. After we decide, we can discuss again about future collaboration process.

3 Likes

Sounds good.

Let’s not overengineer this - absolute time works just fine. Better to spend time figuring out how to avoid halt-and-reset upgrades in the future.

2 Likes

I’m absolutely fine if we agree on a certain height and notice the time variance.

2 Likes

I’m prepared to proceed with pushing this proposal on-chain for deposits today :sparkler:

I will set the export height to 1,933,000 and assume a block time average of 6.99 seconds, targeting Sep 24, 2019 @ 1:53 pm UTC. I’m grateful for the amount of feedback I’ve received, both publicly and privately :pray:

I’d like to note that there is a high probability of variance from my assumed block time average of 6.99 seconds/block.

These are my calculations:
If the average block time is 6.94s, then we’ll reach 1,933,000 on Sep 24, 2019 @ 10:38 am UTC.
If the average block time is 7.04s, then we’ll reach 1,933,000 on Sep 24, 2019 @ 5:08 pm UTC.

4 Likes

https://github.com/cosmos/cosmos-sdk/pull/5005 allows for halt-time config which we could cherry pick into a point release if desired.

2 Likes

It really make job easier if we use time to halt blockchain.

1 Like

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

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

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

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

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

1 Like

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

  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

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
  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