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.
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? Separately - does it matter that we accept this or not? I only mention it to highlight that a proposal which reduces noise is easier to grok.
Proposed upgrade process
Is this necessary to list in this proposal given that there will be another proposal with 0.34.0 and the actual upgrade vote? Circles back to what this proposal is trying to accomplish and whether it is even necessary. The broader community is aware that efforts are moving towards enabling transfers. I would be in favor of 1) smaller scoped proposals and 2) waiting until 0.34.0 is released and adjusting the proposal to describe the actual upgrade.
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 allowance of such a governance rule. However, in general, we have to understand that it’s hard to have a unanimous decision and we can’t have a proposal for everything.
It is assumed that if transfers are to be enabled, then this means that the community agrees that the current release and mainnet are stable. You’re correct in saying that this line is redundant.
We have to essentially justify the trade-off of setting off the ATOM enablement process now and reducing the time to deployment vs leaving everything as is, waiting for full and thorough testing on testnet and then having a proposal with final version that takes a bit more than 2 weeks to get approved. (This avoids further delays and is also related to what is said in pt. 1)
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.
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.
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.
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
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
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.
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.
To lay out a strategy for the whole upgrade process, from release to testing to upgrade.
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 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.
thanks for the work.