Transfer Enablement Proposal

#1

According to the expedited rules laid down in governance proposal #3 the following criteria needed to be met:

  1. v0.34.0 released by the development team
  2. New testnet launched using that release.
  3. 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:

  1. Final code hash for Hub 0.34 state machine is 0f7877c23b407e24e56056469e90fe6b8a78d84c
  2. Gaia-13003 is a successful test of the upgrade procedure and final code
  3. State export from cosmoshub-1 is at block 507915
  4. Genesis time will be 2019-04-22T17:00:00Z UTC
  5. 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
8 Likes
#2

vote for yes.
sounds good to me

#3

Sounds good to me! We are ready to go!

#4

A gist for complete upgrade instructions. Although, we will likely publish a new genesis file.

2 Likes
#5

Sounds good to me! I also vote for yes

#6

500,000 block height

#7

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.

  1. 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.

  2. Validators running full nodes with the default options are storing the last 100 blocks of state and every 10,000th block.
    https://github.com/cosmos/cosmos-sdk/blob/develop/store/types/pruning.go#L34

Curious how other people feel? I don’t think planned downtime during this upgrade is a big deal.

3 Likes
#8

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.

2 Likes
#9

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.

#10

You answered my question as I was writing it. :slight_smile:

#11

Thanks for clarifying! In this case, Figment Networks is also in favour of a block height of 500k :+1:

1 Like
#12

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.

#13

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.

#14

Is it not better to be conservative than aggressive in average block time?

#15

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.

#16

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.

1 Like
#17

Is it correct that according to current conditions validators will have ~2,5h to upgrade the software?

#18

what does 507915 mean?

#19

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.

1 Like
#20

I think a genesis time of 19:00:00Z can make everyone happy.