Glad you’re mentioning this concern. I raised it here (let us know if you’re not in this channel).
The feedback I received was that we could signal on-chain if the block time average deviates substantially. I also like the idea of the time being relative to the export block, and agree that there should be adequate time between the two. The only feedback I received was to shorten the two hour window.
How would an on-chain signal work? Do you mean another proposal closer to the deadline? That is possible, although if it were created last-minute, some validators might not see it & confusion could ensue - I think a relative restart time is likely to be safer (unless there are problems that I haven’t thought of yet).
A second signaling proposal is safer if the first doesn’t include an exact time and mentions that a second will come, so that seems OK too (but this proposal does include an exact time and doesn’t mention a second signaling proposal).
I don’t have a strong opinion on window length, just a general preference for safety over liveness - network upgrades conducted like this are risky operations for validators & users alike, better if all involved have time to proceed carefully without worrying about downtime if they don’t export & restart fast enough.
How about a specific time rather than a specific block height? eg. “the last height at September 15, 2019 at 12:00 pm UTC”
and then a specific genesis time eg. “September 15, 2019 at 4:00 pm UTC”
A specific time won’t work as we don’t have clock synchrony (validators may have differing clocks).
“Last block with timestamp before X time” would work as long as Tendermint enforces that subsequent timestamps are non-decreasing (I don’t remember), although I think it’s a bit more likely to result in operator error since we don’t have an easy way to query that from a node (though we could build one).
I’m in favour of a second proposal to override the genesis time of Gov14 to be relative to the timestamp of block height 1823000.
Main issue I can see with a bigger window is that we start to push our friends in Asia into the middle of the night. If we use a four hour window, genesis may be 3 am in Korea.
How about an 8-hour window? From block height 1,823,000, 9 hours makes genesis at 7pm EDT, 4pm PDT, 8am KST, 1am CET.
Summary of proposed solution
Another proposal that does these:
So do we need to vote for the proposal 14 or wait for the new proposal?
I would suggest a second proposal, #15, that would override first one "Just in case the conditions on Proposal 14 fails due to block time deviation"
The idea is to script a condition similar to: If at block 182XXXX ( few days before the plan ) the UTC time is too late and we are in risk of not having enought time to upgrade, then the genesis time will be relative to the proposed block, in order to give at least 2 hours window. If there is no risk then we keep going with first proposal #14.
Bests
This sounds fine to me, shall we adjust the block height forward a few days so validators have the same amount of time? There seemed to be some concern with 9 hours downtime - I think it’s fine, but probably 4 or 6 hours would also be reasonably safe.
Glad to make the proposal if you like.
I am in favor of not stopping it. but as everyone is in favor of stopping it or most believe it normal, then the best will be the shortest possible time. (minutes unless hours) But if most believe it is the right thing, Im ok too stopping my nodes some hours.
I believe that 2 hours is sufficient time for a validator with zero automation to securely distribute the genesis file, restart multiple sentry and validator node and KMS nodes before an upgrade.
2 hours is plenty of time to do this at a deliberate pace with opportunity to correct errors.
I’m leaning toward proposing a revised genesis time of 120 minutes after the timestamp of Block 1,823,000.
In future, let’s educate the validator set about the importance of downtime relative to the risk of double-signing. I’d like us to consider closing the window between export block and genesis time for upgrades to come. We’ll have a better opportunity to make competing proposals after this upgrade.
Fair enough, I don’t have a strong preference.
Independently, can we push the block height a few days? September 15th conflicts with Tel Aviv Blockchain Week which I think a few validators are involved in.
I don’t think we can avoid conferences (unless they are very big ones). For example, Wanxiang Blockchain Week in Shanghai is apparently Sep 16 to 18. How big is Tel Aviv Blockchain Week, @cwgoes?
Besides having enough time for the gov proposal to pass, I’m optimizing for a day that targets a block height that is most ideal globally, ie. a day that is:
I’m also making it a “round” block number of four sig figs and a time that ideally isn’t the middle of the night any validators. Would love to know if there’s anything else we should be watching out for.
I agree that we are unlikely to be able to avoid all potential conflicts. It would be nice if there were a better way to poll the validators, I really doubt the subset who are reading & replying to this thread is a representative sample.
Tel Aviv Blockchain Week is probably a medium-size conference; I think Wanxiang Blockchain Week is pretty large, in both cases I do not know how many validators plan to attend.
An interesting future option could be a grace period of a few days after upgrades during which downtime slashing does not happen, that would make the process a bit less synchronous (as long as at least 2/3 of stake is online).
Neat idea, re: downtime slashing, although it is already a pretty big window at 18 or 19 hours before a very small slashing.
I’d like to see additional on-chain governance features for coordinating this sort of thing. Eg. a proposal could have multiple options and ranked choice.
Ranked choice proposals are a great idea!
Anyone want to play around with ranked choice voting? I set up this ranked vote for a launch window time: http://t.me/RankedPollBot?start=gm6xciimfcak7ipta656ibfe
Nice, submitted responses (hopefully).
I’m drafting the amendment proposal here: Cosmos Hub 3 Upgrade Proposal C
Please participate! and RT for visibility: https://twitter.com/Ether_Gavin/status/1166820073107075074