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
- Gaia-13003 is a successful test of the upgrade procedure and final code
- State export from
cosmoshub-1 is at block
- Genesis time will be
- 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 \
cosmoshub-1-export.json > > genesis.json
vote for yes.
sounds good to me
Sounds good to me! We are ready to go!
A gist for complete upgrade instructions. Although, we will likely publish a new genesis file.
Sounds good to me! I also vote for yes
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.
Validators running full nodes with the default options are storing the last 100 blocks of state and every 10,000th block.
Curious how other people feel? I don’t think planned downtime during this upgrade is a big deal.
Block 507_900 was calculated using stargazer’s displayed block time of 6s (https://stargazer.certus.one/).
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.
You answered my question as I was writing it.
Thanks for clarifying! In this case, Figment Networks is also in favour of a block height of 500k
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.
Is it not better to be conservative than aggressive in average block time?
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
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.
Is it correct that according to current conditions validators will have ~2,5h to upgrade the software?
It was a mistake for
State export from cosmoshub-1 is at block 507915
to make it into proposal 5.
It was intended to be
State export from cosmoshub-1 is at block 500000
Immutability is hard but the whole point of the level of maturity of the system is we are writing human reabable text.
I think a genesis time of 19:00:00Z can make everyone happy.