[PROPOSAL][ABANDONED] Cosmos Hub On-chain Governance Proposal Resolution Recommendation

Source: https://medium.com/tendermint/cosmos-hub-on-chain-governance-proposal-resolution-recommendation-7aeb9576fa81 Attn : Atom holders Re : Atom Transfers Proposal: https://cosmos.bigdipper.live/proposals/2 Summary AiB (All in Bits) will work with SimplyVC to propose a slightly modified proposal, with some needed changes, namely, with a new chainID, block size parameters, and a two-phase process for software upgrades. AiB recommends that those who have already voted YES to change their votes to NO for proposal-2. This proposal isn’t intended to delay enabling transfers but to tweak some properties and to get 2/3rds votes on a specific code hash before an upgrade happens. Justification • The desired chain upgrade mechanism for enabling transfers will start the chain from height 0, so it is necessary to bump the chainID to prevent double signing by validators. This is why the chainID ends with a “-1” suffix. The upgrade must change the chainID to “cosmoshub-2”. • The max block size and gas parameters shouldn’t change drastically from the current hub, especially before state syncing is fully implemented. Tendermint state syncing is on our immediate roadmap, once…

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

For now, we recommend that those who voted YES change their votes to NO, and for those who haven’t voted yet to also vote NO. If you agree with this posting, please share it w/ other ATOM validators and delegators. UPDATE: It looks like the 40% quorum will be reached anyways, so our recommendation is to vote NO immediately.

sounds good to me. thanks

Why does this happen now and not while the proposal was being drafted & reviewed?

I think what comes short in this proposal and what most people still don’t realize is the fact that incrementing the chainID and starting with an exported state also means that old states & transactions will not be available on-chain anymore. If they don’t get archived, it will be impossible to verify the consistency of the chain at a later point of time. This will get even more important once the network matures and connects multiple other chains with each other.

While the process of a few, trusted validators verifying the state export on Github and storing a copy of the old chain was sufficient in testnet, I believe we need a much more conservative approach on mainnet. Are there any processes/practices proposed by AiB or the ICF to at least archive those old blockchain states in a trustless/distributed way so that they can be verified by external identities in the future? In my opinion, this needs to be included in a proposal. Maybe a solution using IPFS could be used temporarily, where the hash of the old chain gets included into the new chain?

Best,

Florian from Staking Facilities

I think this can be dealt with later by requiring in the proposal that the block hash for the last block on `cosmoshub-1` be included in the tendermint header for `cosmoshub-2`, and we expect all the validators to retain the blockchain and app/state data. If needed (as voted on later in governance on cosmoshub-2), we have the option of running a second net, a static cosmoshub-1 chain which only serves for syncing and querying purposes, or, Tendermint might be improved to deal with this automatically. Or governance may vote to throw it away if there isn’t much demand for these initial blocks. I agree that we need to avoid doing this in the near future, and we want to preserve block heights across chain upgrades. OTOH projects that are newly getting started will want to employ this kind of strategy in the beginning when stakes are low (to innovate fast), and sometimes you want a major version upgrade of a chain where the logic changes entirely, and requires an export/import to upgrade. Existing web frameworks do this often, and I’ve had to do things like that in iOS apps. Also, Tendermint itself might upgrade in a breaking way in the (more) distant future, and we may want to…

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

I guess I’m not a huge fan of creating an upgrade process the depends on unimplemented Tendermint software changes b/c we want to get an upgrade out next week.

We could just put a blockhash from the last block in the chain-id of cosmoshub-2-<last cosmoshub-1-blockhash>

I’d rather keep the chain id simple and short.

It’ll be part of the UX somewhere and we’ll need to develop a convention… the dash before the version already is a constraint, I don’t think we should be adding more to the chain id without more discussion of that convention/schema for chain-ids.

We don’t need to put the hash for cosmoshub-1 in cosmoshub-2 as long as the expectations are clear about what to suggest the validator community to store (namely the whole chain data for cosmoshub-1), and another proposal can decide to make use of it in the future, including it in the block hash for cosmoshub-2+, probably by adding it to ConsensusParams from the genesis file.

Here’s a draft:

https://gist.github.com/jaekwon/7c7e12f035438530cc2db4b4e2f9ffcb

gistfile1.md

# Summary

 * Agree on a plan to set up a testnet using the Cosmos SDK v0.34.0 release,
along with mainnet conditions, plus transfer enablement and increased block
size, as a testing ground.

 * 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 expedited rules to determine acceptance.

• Introduced “original” vs “expedited” governance rules.
• Added a blip about saving the state for cosmoshub-1.
• Added scope of what is acceptable for v0.34.0
• Added explicit expectation about how to vote for the second proposal

Thanks a lot for the above. We agree on most of it and would like to share some comments. Everything is split by section to make referencing easier. Summary Suggestions: Point 1: “Agree on a plan to set up a testnet” - “Lay out a plan to set up a testnet” Original and Expedited Governance Rules Suggestions: Update the section to: 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 us define: • Original Governance Rules, to be the governance rules as currently implemented, namely, proposals are deemed to have passed if a 50%+1 majority of cast votes, excluding Abstain votes, by the end of the governance period (i.e. two weeks after the deposit threshold has been reached) are in favour of a proposal, a quorum of 40% of bonded stake has cast their vote and there are less than 33.4% Veto votes. • 24 - Hours Expedited Governance Rule, to be a different acceptance mechanism via which a proposal is deemed to have passed if 2/3 + 1 of bonded stake has voted in favour of the pro- posal for a continuous duration of 24-hours. A buffer period, of 24…

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

The 2 phase approach resonates with me. I like the idea of having a phase 2 in which we consciously decide whether the new s/w is ready for production, rather than having that decision made solely by the core development team.

Also, maybe lost in the shuffle, is that v0.34.0 implements a parameter change proposal. This means a parameter change proposal that passes automatically implements the parameter change w/o manual intervention.

After spending 7 months building DAO tools at Aragon, I suggest we don’t take this change lightly. It’s a powerful one.

Okey, Put this new proposal on mainnet. when will we vote it?

Re chainID conventions, I wrote a proposal last summer for the ChainID to be the hash of a new “Chain Description”, where

ChainDescription = <NetworkName>/<BlockVersion>/<AppVersion>/<StateHash>/<ValHash>/<ConsensusParamsHash>

is a complete description of the initial state of the chain. Upgrades could then be defined like:

ChainDescription = <PreviousChainID>/x/<Height>/<ForkDescription>

Where ForkDescription is the ChainDescription for the new chain

I think we should consider something like this.

While I see your rational, I think adding it within this proposal is beyond the scope. There is already a lot going on and we would not like to add extra points of contention.