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

Hub Proposals Signaling/Text
21

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

1 Like
22

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

23

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.

2 Likes
24

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.

  1. The IPFS file stated wrong height at point 3 which can cause confusion.
  2. 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.
  3. 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

  1. We do an upgrade practice from gaia-13003 to gaia-14k with state export.
  2. Have at least 12-hour room for validators to do the upgrade after the upgrade practice.
7 Likes
25

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

2 Likes
26

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.

27

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.

1 Like
28

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?

1 Like
29

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.

5 Likes
30

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 typo I’d probably just send 413 atoms to cosmos1e5mnjg4d6qprkash7vuseahgk2grrj43nk56sj once transfers are enabled.

But time is growing late and I would love to hear more in the next few hours.

5 Likes
31

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.

2 Likes
32

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.

2 Likes
33

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.

3 Likes
34

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.

  • The proposal is ambiguous and specifies two distinct block heights. This means that it requires outside context to interpret, which is workable (as discussed above), but less than ideal.

We will vote NO on any future proposals that contain such mistakes.

5 Likes
35

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.

3 Likes
36

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.

37

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

38

500,000 is the correct block height

5 Likes
40

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
1 Like
41

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

1 Like