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:
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 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).
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.
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
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.”
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.
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.
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.
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.
