According to the expedited rules laid down in governance proposal #3 the following criteria needed to be met:
v0.34.0 released by the development team
New testnet launched using that release.
No critical issues found during testing.
v0.34.0 has been released, and the upgrade procedure that will be followed for mainnet was carried out on the gaia-13002 test on April 8th. The network came up with no issues and has been running w/o problems since then. Seeing as the conditions of the expedited process have been followed, we propose the following upgrade path:
Final code hash for Hub 0.34 state machine is 0f7877c23b407e24e56056469e90fe6b8a78d84c
Gaia-13003 is a successful test of the upgrade procedure and final code
State export from cosmoshub-1 is at block 507915
Genesis time will be 2019-04-22T17:00:00Z UTC
Validators can generate the new genesis file by running
# must be run after the chain is stopped using v0.33.2
gaiad export —height=500000 —for-zero-height > cosmoshub-1-export.json
# must be run after the upgrade to v0.34.0
python3 contrib/export/v0.33.x-to-v0.34.0.py —chain-id=cosmoshub-2 \
—start-time=2019-04-22T17:00:00Z \
cosmoshub-1-export.json > > genesis.json
There is some debate between about block for export.
@gamarin proposed exporting at block 507_900 as this would be 10-12 hours closer to the target of 5pm GMT on April 22nd.
I’m in favor of block 500_000 for the following reasons.
in 10 years, no one will remember why we did 507_900 but people will care about the integrity of the token distribution in the Cosmos Hub. A round number will stand the test of history better.
Apparently the real average block time is ~6.8sec, which changes the estimation entirely. With ~6.8sec block time, block 500_000 happens ~1h before 5pm UTC, so it should work perfectly.
This solves the issue, I think we can go with block 500_000.
What are you guys using for an average block time? By my calculation we have just 20 minutes to export, upgrade, and restart:
Export at block 500,000
Current block 451,614
Blocks to go 48,386
Seconds per block 7
Seconds to go 338,702
Unix time now 1,555,612,481
Unix time export 1,555,951,183
Unix time genesis 1,555,952,400
Seconds between export & genesis is 1,217, which is about 20 minutes. What am I doing wrong in this calculation or what am I not understanding about the export to genesis transition? 20 minutes doesn’t give much room for any kind of genesis file validation or upgrade error correction.
I think the genesis time is too tight. I agree 100% with Zaki that planned downtime is not a big deal, so we should have a buffer of a few hours between export and genesis.
By making your calculation at 7 seconds per block, aren’t you skewing your result to a later halt than actually planned? Block time is averaging 6.8s, so the halt should be ~9677 seconds earlier than you’re indicating. ~2 hours 40 minutes.
I don’t feel strongly about it, but block time has been averaging between 6.75 and 6.80 seconds for the last 48 hours. So seems like ~3 hours from halt to genesis, if my math is correct.
500,000 is fine. My calculation is similar to Matt. It’s about 83 hours from now (at height 456,735, taking 6.85s block time), which will be around 22 Apr 3pm UTC. There will only be a 2-hour room for validators to export the genesis file and upgrade software. This is too short for all validators to do the job on Easter Monday. I think at least an 8-hour window is needed for all validators to wake up and clear our minds to make sure we are doing things right.
