[PROPOSAL #3][ACCEPTED] ATOM transfer enablement v2

• Moderator edit to include link to on-chain proposal: #2 ATOM Transfer Enablement v2

Following Simply VC’s discussions with Jack and Jae from the Tendermint team we have revised our governance proposal on the enabling of transfers and are looking for the community’s opinion on the proposed process.

Update (3 April):

The proposal is now live on the network as Proposal #3: ATOM Transfer Enablement v2.

Cosmos | Cosmos Hub 1 | ATOM Transfer Enablement v2

A plan for enabling ATOM transfers is being proposed, which involves the release and test of Cosmos SDK v0.34.0 and a strategy for the network to accept the ...

https://cosmos.bigdipper.live/proposals/3
https://ipfs.ink/e/Qmam1PU39qmLBzKv3eYA3kMmSJdgR6nursGwWVjnmovpSy

Feedback from a quick reading (not getting into the weeds) of the proposal. After this proposal is passed and after successful testing, and after the software Git hash for v0.34.0 has been finalized, conduct a second proposal which includes the specific Git hash, using an expedited governance rule to determine acceptance. I don’t immediately see the benefit of having a placeholder proposal for the sake of having a proposal. The wheels are in motion for 0.34.0 software and testnets with transfers - any proposal should wait until the software is out to indicate the upgrade path. In order not to unduly delay the release process, a two-step governance setup is being proposed, in the next section, for the release of v0.34.0. Before proceeding, let we define: As a voter - I’d prefer to see a this as a separate proposal. I may support transfers but not expedited governance or vice versa. By bundling these together I have to decide which is more important to me when I vote. By separating, I can vote on each as desired. The community accepts the current release (v0.33.0) of the Cosmos SDK running on chain cosmoshub-1 as stable; Isn’t this the de-facto currently?…

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

Thanks for this work.

Thanks for the reply @roman . We went through your message and given our opinion on each of the points. • This proposal will be used to also plan out how the testnet is to be set up and run. What you’re saying is that we should include only the upgrade from testnet to mainnet, however we thought it would be better to be more thorough and lay out the process to go from development, testing and merging into mainnet. The mainnet upgrade must be planned out beforehand so as to replicate all agreed upon conditions on testnet. • I would like to highlight the fact that the new rule is not meant to be used for anything else apart from the 2nd proposal. So essentially you are only ever voting for the transfer enablement via this process, with no introduction of long term process changes, which can be introduced later by the community. I do agree that more clear cut proposals are favourable. Having both the introduction of a new proposal-specific governance rule and software upgrade process within the same proposal is a wider scope than ideal. If the consensus is that separating them is the best way forward, another proposal can be submitted at the same time to decide on the…

Excerpt (1192 of 1945 characters). Read the whole post on the forum ↗

From the Riot chats:

jeelim l A-team
i’ve actually translated and shared this proposal draft with some of atom holders in korea to see if they have any opinions about it thanks for the work.

i have a simple question about 24 hours expedited governance rule. if less than 2/3 of bonded stake agrees/votes, does the governance proposal close and we have to propose a new governance proposal?

Matthew @ Simply VC
The expedited rule is there to make the process faster, but if 2/3 bonded stake have not voted yes for a continuous 24-hr period, then the normal governance process will be followed. We can actually update the draft accordingly so it is clear.

Looks good. Hopefully the community is able to act fast to enable transfers (ATOM transfers should have been part of the launch)

Ownership begets interest and attention.

Thanks for the work on this - looks good.

For me, a key point is knowing the specific implementation (ideally commit) that will be accepted as a result of the vote. Happy to see this is now the case.

When you do expect to put forward the proposal?

The terms in the proposal are ok but why not wait submitting it till v0.34.0 is released?

@mdyring

We are aiming to submit the proposal for voting tomorrow, Wednesday April 3, at 10:00am UTC.

@kwunyeung

The proposal aims to outline the whole upgrade process, from release, testing and the actual upgrade.

I don’t think it makes any difference whether or not v0.34.0 has been released. If we wait for v0.34.0 to be released, it’d still need to be tested to be considered valid for mainnet.

We did not want transfers enabled initially as to ensure stability in the network and the initial genesis parameters.

v0.34.0 should be released within the day.

IMHO it is clearly amazing decision just because it is a good way to bootstrap a governance procedure in terms of usage

Agree with @roman. Proposals must be as ATOMic as possible which is not the case here.

Sounds like 3 propos inside one.
If a then b
If b then c
If c then d.

Still not understand that.
And still not understand why have to made a propo for run a testnet.
And why the propo is ready before the release is tested?
Why this propo is discussed in a close door unless in public riot room where are all validators available?
Ty

I agree most of the content of the proposal.

Although we might can just neatly test 0.34 without this proposal and decide upgrade by a governance proposal when testing 0.34 is finished, we are experiencing a learning curve of governance procedure, so I think it is beneficial to put all these reasonings in blockchain, as a reference of governance textbook.

Let’s discuss further on how long 0.34 should be tested to be confident that it is good for send-enabling cosmoshub-2

Regarding the length of gaia-14k, we think that 1 week of an error-free testnet is sufficient.

For example, v0.33.0 was tested for around 6 days between 7 to 13 March prior to mainnet launch.

B-Harvest suggest super massive tx spams simulation on gaia-14k.

It is our first time of active send enable feature on mainnet. Also, current network has very low min-fee, which might cause quite fragile validator stability. In addition, there are so many validators who were not in GoS hence lack of experience of tx spam prevention readiness.

Validators should provide evidence for their delegators that they are completely ready for preventing tx spams to relieve their delegators from tx spam risk.

I hope all validators could be ready for the tx spams for the smooth launch of 0.34 on mainnet. So, I respectfully recall @slamper, @certus_zl to give them such mission on gaia-14k again.

Let’s rock and roll tx spamming!!

I think seeing some form of load testing on the next tesnet would be great assuming we have a bulk of the same mainnet validator set operating the testnet.

With regards to the proposals, it’s still not clear to me why a dual-proposal structure is needed. It would seem more sensible to wait for the v0.34.0 SDK/Gaia release and base a proposal off of that release/hash.

The aim of the dual-proposal is two-fold:

1. To lay out a strategy for the whole upgrade process, from release to testing to upgrade.

2. To avoid delays to the transfer enablement process. If we do not have a dual-proposal, and only have one proposal after testnet is deemed to have been successful, then a further minimum of two weeks would have to pass before the mainnet upgrade can happen. We wanted to allow for a clear process for testing and also provide a quicker way for the community to accept and proceed with an upgrade.

I prefer a dual proposal system.

I think ultimately, it should be governance choosing, purely in the ideal spec-land, of what the next state machine version should be. The second proposal is then saying, do we agree that this state machine delta matches the ideal change we wanted.

Great to see voting’s begun! Let’s get these ATOMS moving guys

Agree on spam tx testing on 0.34 testnet.

Adding our evaluation to this proposal and the way forward here. We voted YES and are in favor of a dual proposal system, but we do see the need for a clear specification of the two-phase upgrade process in the future to avoid mixing governance decisions and changes to the governance process as done in this proposal.

I have some concern about the expedited gov rule. If the proposal 3 passes, I’m afraid the expedited gov rule will be a precedent reference to many other situation. In the future, in what circumstances should we apply this gov rule?

I think it’s better we experiment with expedited proposals now than later, especially with something as simple as token transfers

You are assuming we already have expedited proposal.

Thanks for this thoughtful, complete and well written proposal @FrancescoSVC

I voted yes, now have a couple questions that didn’t impact my decision -

A buffer period of 24 hours is also put in place from the time of full deposit payment to the possible start of the continuous 24-hours required. Note that this mechanism currently requires custom querying to determine.

Please carlify the buffer period. Does it start after enough stake is deposited to initiate the proposal? Is that the idea?

We want to preserve the blockchain and app state data for cosmoshub-1. In the future we may include these in the blockchain header perhaps as consensus parameters (which get loaded from the genesis file).

Several entities have volunteered to store the data for cosmoshub-1, including Simply VC, the Interchain Foundation, and Tendermint Inc. All validators are encouraged to retain this data and provide it at cost to anyone who requires it to serve the chain. A later governance proposal will determine what to do with this data.

What is the best way to preserve this data, i.e. which files on a validator should be preserved?

The expedited rule proposed is only limited to this particular proposal.

If in the future some proposal would recommend to use a similar expedited rule, then the community can vote on it within the scope of that proposal.

Hello everyone!
As per our blog post, Figment Networks has voted ‘yes’ to Cosmos Governance Proposal 3, which can be verified on Hubble here. We’re satisfied with Cosmos SDK v0.34, but we were ambivalent about expediting the governance process.

Thus, we have drafted three proposals for software changes:

1. A formalized process for issuing non-emergency Cosmos SDK software upgrades.
2. A formalized process for issuing emergency Cosmos SDK software updates.
3. A formalized process for issuing critical Cosmos SDK software updates.

Please comment in Google Docs, on the Cosmos forum posts, or on Twitter. We’re using these guidelines to draft our proposals–join us to help establish community standards for best practices in Cosmos governance