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

Hey Cosmos validators–let’s get the first major upgrade moving! :rocket:

Cosmos Hub 3 Upgrade Proposal D is currently the exact same as Proposal C, except that the block height has not been set yet:

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:

  1. A date leading into a long weekend for many people
  2. A date during or leading into a large holiday
  3. During or right before a large conference
  4. Around daylight savings time changes

Keep in mind that it takes 14 days for the voting period to end, and it could take 5 days to get the requisite deposits (I like small deposits so that many can all signal that they are ready to proceed).

1 Like

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.

2 Likes

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?

1 Like

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.

1 Like

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?

4 Likes

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

1 Like

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

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

1 Like

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

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

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.

1 Like

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