[PROPOSAL #5][ACCEPTED] Transfer Enablement Proposal (Expedited Cosmos Upgrade Proposal)

• Moderator edit to add link to on-chain proposal: Mintscan - Chain explorer by COSMOSTATION 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…

Excerpt (1196 of 1350 characters). Read the whole post on the forum ↗

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

500,000 block height

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.

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

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

jack:

State export from cosmoshub-1 is at block 507915

what does 507915 mean?

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.

Yes if you don’t want to have any down time.

1900UTC is not very Asian friendly but we can go with it if it makes more people happier.

Current concerns regarding proposal 5

1. IPFS file contains wrong state export block height in point 3 which might confuse validators.

2. Not precise definition when the vote ends/passes exactly with possible veto coming in second before upgrade. Maybe upgrade should happen X blocks after proposal passes not at block Y

3. Short notice given long weekend and public holiday on April 21’th in EU - I would propose upgrade to happen on 25’th rather then 22-23’th so EU people can take notice.

I understand that validator should be able to address emergency situations in timely manner, but planned chain upgrade of the sort is not an emergency situation and 7 days notice after proposal passes under precisely defined conditions should be the standard way to do planned upgrades which would IMO feel secure to all people participating in securing the chain.

`Forbole` has voted NoWithVeto to `proposal 5`. We are very happy with exporting the state at height `500,000`. However, we strongly disagree with these points in the proposal. • The IPFS file stated wrong height at point 3 which can cause confusion. • The genesis time of `cosmoshub-2` is too close to the end of `cosmoshub-1`. The estimated block time of `500,000` will be around `22 Apr 14:40 UTC`. It will be less than 3 hours from the proposed genesis time, which is `22 Apr 17:00 UTC`. Although having some down time is not a big deal, I believe most validators would like to be online at genesis time. • The upgrade process on `gaia-13002` to `gaia-13003` is different from that on the mainnet. It didn’t include state export. In such short time, validators need create the new genesis file, upgrade software and restart the node. I believe it will generate a some problems during the upgrade with those uncertainties. I’m not sure if the community can give enough support during the gap time while it’s the Easter holiday. We hope Cosmos could be more diversified and inclusive, we suggest • We do an upgrade practice from `gaia-13003` to `gaia-14k` with state export. • Have at…

Excerpt (1199 of 1279 characters). Read the whole post on the forum ↗

IMO @asmodat and @kwunyeung’s points are valid but I am still in favor of going ahead with an upgrade on April 22nd.

In my vision, validators who can handle upgrade in ~2,5 hours and have a high level of confidence about it should vote YES. If validators have concerns or sure that this time is not enough for them than vote NoWithVeto. Other reasons are not so critical and can be resolved much easier.

We totally agree with @kwunyeung ,state export should have been tested by creating gaia-14k as specified in proposal #3 as we have seen GoS halted twice because of issues in state export.Also considering typo in block height(very purpose of this proposal) we decided to vote no_with_veto against the proposal.

I’m sorry that I cannot agree with you. I believe most of the validators can do the upgrade in 30mins. However, we would like to respect to those who would like to spend their time to their families and friends during Easter holidays. The gap window is to let the validators choose their favourable time to do the upgrade. You can choose to do this right after height 500,000, or a few hours after you enjoy dinner with your family or in the your normal working hour. This upgrade is not a critical bug fix, disaster recovery or emergency upgrade. If transfer enable is so urgent, a proposal would have appeared on the launch day and we would have enabled it with v0.33.x with a parameter change in cosmoshub-1 genesis file. Many validators would like to be included in the genesis block and keep their chance of proposing blocks. If the genesis time move a few hours later can make more people (not just voting power) happier, why don’t we do so?

After considering it for a few hours, I feel like we have to say no to Prop5 so we don’t set a bad precedent for governance in the Cosmos ecosystem.

If the proposal says to cut over at block 507915 but everyone is choosing to cut over at block 500000 because of consensus they reached in some forum thread, then what is the point of the proposal?

Either we respect the governance system in place, or we don’t have one in the first place.

Personally I don’t care either way if we do it on Easter Monday or Superbowl Sunday. You can never choose a date/time that works for 100% of the planet. It’ll be convenient for some, inconvenient for others - welcome to a global community.

But we set a dangerous precedent when the votes say one thing but the community decides to do another thing “just to move things along” or “because it’s close enough”

I strongly recommend a new proposal be published with the correct block 500000.

Here are my thoughts on the typo. The Text Proposal type is basically a tool for validators to arrive at a shared mental state about what to do next. It’s a signaling mechanism. Ultimately it’s the social consensus and how that translates into actually running the software that matters and not what’s written in a proposal. Text proposals will always end up diverging from reality. If a typo means that 66% of the voting power can’t agree on what the next step is, then it’s good. The document in ipfs is inconsistent. It says 500k is several places and 507915 in one place. The question is does error break the shared mental state? I’m not sure but voting seems to indicate that it does not. But @aurel , @slamper , @roman haven’t weighed in yet. Ultimately we are humans trying to communicate with current participants in the systeam and future participants. I think the typo does degrade the quality of communication but does it do it enough to warrant replacement or are all the actors in the system sharing enough mental state that we can coordinate. There is still time today to submit a proposal that we reach 66% before 500,00k and if we decided to move a proposal 6 without…

Excerpt (1196 of 1393 characters). Read the whole post on the forum ↗

You bring up great points.

1. The votes are an indication of social consensus, and are not social consensus in and of themselves
2. The IPFS PDF says 500000 once, and 507915 once, so technically the 500000 height is in the proposal

I had previously missed the 500000 cited in the command box at the bottom and only zeroed in on bullet 3.

Technically the proposal DOES say 500000 after all… it just also includes one typo.

I agree with Zaki 100%

The typo is not that important since everyone already knows it’s just a typo, not to mention 500,000 is mentioned in several other places.

If anyone is really concerned about the typo, then please make a new proposal to fix the typo ASAP so it can still pass on April 22, or else vote YES for Zaki’s proposal so we can get on with this upgrade already.

It’s always a holiday in some part of the world.

Cosmos is global network with validators all over the world, so we shouldn’t worry so much about regional holidays.

We rather have a network that’s secured by validators that are available 24/7/365, regardless to national or religious holidays.

Certus One voted YES on the proposal since the software is ready, and a NO vote would not be in the interest of our delegators and the network as a whole. We strongly considered voting NO due to a number of severe procedural issues: • No gaia-14k testnet was launched by Tendermint, rather, the gaia-13k testnet was upgraded. While only a minor issue from a technical point of view - the code is still tested - it contradicts the launch timeline in the Transfer Enablement proposal. This means that people have been waiting for a gaia-14k testnet to join and test, which did not happen. Such communication needs to be precise and unambiguous. • A new testnet (gaia-14k) is specifically set up to run and test the new release with the appropriate changes in the genesis file to: • enable the transfer of ATOMS • increase the maximum size of each block to allow more transactions per block • adjust the blocks_per_year parameter as indicated in proposal 1 ( https://ipfs.io/ipfs/QmXqEBr56xeUzFpgjsmDKMSit3iqnKaDEL4tabxPXoz9xc ), if it is approved • The proposal is ambiguous and specifies two distinct block heights. This means that it requires outside context to…

Excerpt (1195 of 1339 characters). Read the whole post on the forum ↗

Staking Fund voted Veto. We cannot accept such mistake on behalf of our delegators.

Perhaps we all know it’s a typo now. But a few years later, people will wonder from looking at the proposal #5 whether the cosmoshub-1 exported at 500,000 or 507,915.

We suggest a new revised proposal.

My vote is No. I do not understand the rush for ATOM Transfer Enablement. As a small validator and as a beginner I want more time. I don’t have ATOMs to sell, I don’t want to buy now. So let’s do a proper job, let’s explain a little bit more what are the steps to be made for update. Thank you everyone for your help.

The Chainflow validator is voting No_With_Veto, for reasons similar to those @kwunyeung detailed and @certus_zl cited. I feel this again is too rushed and we need to set a precedent for more conscious decision making and careful upgrades.

I really don’t see another 12-24 hour delay in transfer enablement harming delegators. In fact, I feel the delay in the interest of clear communication and conscious decision making is one that will ultimately benefit the community, now and for years to come.

Finally, the upgrade instructions gist shared by @bez still includes the wrong block height, i.e. 500,000 -

• Export existing state from cosmoshub-1 .
• Export genesis state to file

$ gaiad export --for-zero-height --height=500000 > cosmoshub_1_genesis_export.json

500,000 is the correct block height

Can the “planned” upgrade be confirmed now including following timeline:

1. stop operation at block 500 001
2. genesis file generation
3. sha256 and md5 hash comparison between validators
4. new chain gets started instantly 2/3’th of validators join cosmoshub-2

This is the procedure we are recommending. https://github.com/cosmos/cosmos-sdk/wiki/Cosmos-Hub-1-Upgrade

We are not recommending an instantaneous start. We reccomending waiting until 17:00 GMT to start.

Trying to get a release of the KMS today that supports halting at block 500,001

Merge pull request #238 from tendermint/zaki/max_height

Zaki/max height

Could this be officially confirmed, that against statements in Proposal 5 every validator should use (not tested) cosmos-sdk version 0.34.1 as suggested by upgrade doc and NOT 0.34.0 otherwise they should await official genesis file on cosmos github instead of generating it themselves.

also is following instruction from official upgrade wiki correct then:

$ python contrib/export/v0.33.x-to-v0.34.0.py cosmoshub_1_genesis_export.json \
  --chain-id=cosmoshub-2 --start-time=2019-04-22T17:00:00Z > genesis.json

or it should be now as follows ?

$ python contrib/export/v0.33.x-to-v0.34.1.py cosmoshub_1_genesis_export.json \
  --chain-id=cosmoshub-2 --start-time=2019-04-22T17:00:00Z > genesis.json

This is not correct.

This file contrib/export/v0.33.x-to-v0.34.1.py does not exist.

could the official cosmos github page publish correct genesis file ? It appears everyone gets different results on the export. Some suggested using jq -S -c M command