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

• Moderator edit to add link to on-chain proposal: Mintscan - Chain explorer by COSMOSTATION Hey Cosmos validators–let’s get the first major upgrade moving! Cosmos Hub 3 Upgrade Proposal D is currently the exact same as Proposal C, except that the block height has not been set yet: docs.google.com Figment Networks - Cosmos Hub 3 Upgrade Proposal D Cosmos Hub 3 Upgrade Proposal D Figment Networks September 5, 2019 Context This proposal is intended to supersede flawed Cosmos Hub 3 Upgrade Proposal B (“Gov 14”) and Cosmos Hub 3 Upgrade Proposal C (“Gov 15”), regardless of their outcomes. This... I’m looking for input on an ideal date to target for the proposal–help me draft it now in order to minimize the need for repeated proposals. I think the target time should be 2:00pm UTC with a 60 minute delay for genesis . If we can agree on that, let’s pick a date. Here’s are dates I want to avoid : • A date leading into a long weekend for many people • A date during or leading into a large holiday • During or right before a large conference • Around daylight savings time changes Keep in mind that it takes 14 days for the voting…

Excerpt (1194 of 1348 characters). Read the whole post on the forum ↗

Any issues with Tuesday, September 24, 2019? At 7 seconds per block, Block Height 1,935,000 targets Tue, Sep 24, 2019 @ 2:24pm UTC.

Once again, why not do it off a delta number of blocks from the end of the proposal? That would avoid a Proposal C situation from possibly happening again?

Hey @sunnya97, perhaps you’re not aware of my reply to your point the first time you suggested it.

My thinking is that the voting period for the proposal could begin at an unpredictable time ie. when the deposit period ends. That could put us into some weird hour of the night on some untimely day, and I’m trying to avoid things like large holidays, daylight savings changes, etc.

I do think a relative offset is a bit safer, but I understand the concern about weird hours of the night, and the deposit period ending timing is indeed unpredictable if multiple people collectively contribute the deposit.

There should be plenty of time to deposit on this proposal (if submitted soon) such that the voting period completes before the proposed export block, so I don’t have any substantial concerns.

Thanks @Gavin for all your work on this.

cc @zaki @bez - any concerns on your ends?

Looks great for me! Excited to put on the bowtie!

Ah, sorry didn’t see that. I think that’s okay, less preferentialism towards a specific timezone. Cosmos is global, after all

If you really want, you can try to time the proposal starting the voting period at a time you like, so that the hard fork time is exactly 14 days + delta block height later

My hope for this proposal is that we receive many small deposits, so I don’t want to incentivize people to compete for a certain block height.

My bet is that we’ll have on-chain upgrades in future

Hey @cwgoes, I was just chatting with @kwunyeung about the export block height for the upgrade.

Kwun prefers we select a specific UTC time instead of block, and I cited your concerns (including https://t.me/c/1323641888/18653)

He figures if we use “timestamp > X time,” that should work.
“As long as there are blocks with timestamp > X time and we pick the earliest one. Then we can all agree with the same block height.”

Thoughts? cc: @zaki @bez

For this mechanism to feasible, I believe we will need to write some kind of new software either in the KMS or gaiad or likely both.

This will need to be backported 0.34 and also merged to master.

Basically we need to implement the feature from this issue. https://github.com/cosmos/cosmos-sdk/issues/4979

It seems doable within the time window but do people want a proposal that depends on software that doesn’t exist yet.

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

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.

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.

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

bharvest:

So, we have to admit that the timing can have roughly ±2.5hours volatility.

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.

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.

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.

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

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

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

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.

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

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

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.

Gavin (Ether_Gavin)

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)

@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. GitHub cosmos/gaia Cosmos Hub. Contribute to cosmos/gaia development by creating an account on GitHub. • 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. • 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 ? • 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…

Excerpt (1197 of 1241 characters). Read the whole post on the forum ↗

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

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

Thanks for your reply. We still have some questions. • 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 ? • 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 ? • 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,…

Excerpt (1199 of 1674 characters). Read the whole post on the forum ↗

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.