Skip to content

Instantly share code, notes, and snippets.

@jaekwon

jaekwon/gist:7c7e12f035438530cc2db4b4e2f9ffcb

Last active March 29, 2019 00:50
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save jaekwon/7c7e12f035438530cc2db4b4e2f9ffcb to your computer and use it in GitHub Desktop.
Save jaekwon/7c7e12f035438530cc2db4b4e2f9ffcb to your computer and use it in GitHub Desktop.
Download ZIP
Raw
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.

  • After the second proposal is determined to be accepted, upgrade to the cosmoshub-2 chain to use the Cosmos SDK release v0.34.0, along with the necessary updates to the genesis file, at a time to be determined by the second proposal.

Overview

The Cosmos Network was launched with no possibility to transfer ATOMS, mainly for security purposes to ensure that the release is stable and facilitate any rollbacks should the need for them arise.

More than eleven days have passed since the launch of the mainnet network and no faults have appeared in the stability and security of the network. It is our belief that the network is ready to handle the enablement of ATOM transfers, a critical feature of any blockchain network. In order to achieve this, the maximum size of each block also needs to be updated to handle the associated increase in the number of transactions.

Original and Expedited Governance Rules

  • Original Governance Rules - the governance rules as currently implemented, namely, decisions are decided to have passed only after 40% quorum has been reached within the governance period after the deposit threshold has been reached.

  • X-Hours Expedited Governance Rules - instead of waiting the full governance period, the proposal is deemed to have been accepted once +2/3 of bonded stake has voted in favor of the proposal, for a continuous duration of X-hours. Currently this requires custom querying to determine, but it may become encoded procedurally as a second type of proposal in the future.

Expedited governance ruling is necessary in some unforeseen circumstances, and in some cases especially when the scope of an expedited proposal is predetermined from an earlier proposal, it may become safer. Here, we propose to use a combination of two proposals -- first, this proposal, which is evaluated by the Original Governance Rules, and a second proposal to be evaluated later by 24-hour Expedited Governance Rules, to upgrade the blockchain.

To make Expedited Governance Rules safer, we remove the original quorum condition of 40%, and require that +2/3 of all bonded stake vote YES and stay that way for X-hours.

Proposal

We are proposing that:

  • the community accepts the current release (v0.33.0) of the Cosmos SDK running on chain cosmoshub-1 as stable;
  • the Tendermint development team push a new release (v0.34.0) of the Cosmos SDK with the following scope:
    • what is currently published under github.com/cosmos/cosmos-sdk and github.com/tendermint/tendermint in their respective develop branches
    • any further non-consequential changes or bug-fixes as determined by the Tendermint team.
    • due to the expedited nature of the second proposal, no changes may intentionally be suggested that hurts the delegators in favor of the validators.
  • a new testnet (gaia-14k) is specifically set up to run and test the new version with the appropriate changes in the genesis file to:
  • after a subsequent second proposal, the mainnet is upgraded to use the new release and amended parameters, if no critical issues are found on testnet.

The main repercussion of these two proposals is that the fundamental feature of value transfer in a blockchain is fully enabled on the Cosmos network along with the upgrade to release v0.34.0 on the cosmoshub-2 chain. Furthermore, the maximum size of each block is increased to facilitate the transfer of value.

Possible blockers

We see three main possible reasons for the delay of the transfer enablement milestone:

  • A critical issue is identified during the testing phase of the new release.
  • Community agreement that the launch of Voyager is imperative before the transfers can be enabled.
  • Community agreement that the current voting power distribution is not decentralised enough and that this should be remedied before the enablement of the transfers.
  • Other objections by community agreement that are decided (by Expedited Governance Rules) after this or the second proposal are passed, but before the deadline for upgrading as determined by the second proposal.

Proposed upgrade process

We propose that the transfer enablement is performed in the following way:

  1. A new v0.34.0 release of the Cosmos SDK is pushed by the Tendermint team (via the @tendermint_team twitter, https://medium.com/tendermint, and https://forum.cosmos.network).
  2. A new testnet (gaia-14k) running the new release is launched as follows:
    • Issue genesis file with the following modifications to the cosmoshub-1 genesis file:
      • ‘genesis_time’ set to an appropriate date
      • ‘accounts’ adapted from gaia-13k
      • ‘chain_id’ set to gaia-14k
      • ‘block_size’
      • 'max_bytes' set to 150000
      • 'max_gas' set to 1500000
    • 'send_enabled' set to true
    • ‘blocks_per_year’ set to 4,855,015 – should proposal 1 be accepted by the community
  • Collect ‘gentxs’ for inclusion in the gaia-14k genesis file.
  • Issue final genesis file and launch new testnet.
  1. If no critical issues, such as chain halts, are identified on gaia-14k, a second proposal is proposed to be evaluated by 24-hour Expedited Governance Rules with the following spirit:
  • The mainnet is upgraded to the new version and chain ID cosmoshub-2 after block height XXX (to be determined in the second proposal). This will involve:
    • The issue of the new cosmoshub-2 genesis file with amended parameters.
    • The switching off of cosmoshub-1 nodes on block XXX.
    • The upgrade of the nodes to Cosmos SDK release v0.34.0, along with the necessary update of the genesis file.
    • The relaunch of the upgraded nodes on the cosmoshub-2 chain.
  • The second proposal should include only be voted by each validator/delegator if each validator/delegator deteremines that the testnet from step 3 was a succeess, and the scope of changes of for v0.34.0 is within the bounds of what is defined in this proposal. NOTE: If any delegators determine that validators voted in favor of a second proposal that hurt the delegators in favor of the validators, they may undelegate from these validators in the future.
  • The second proposal may include some modifications to the process. It is expected valudators carefully follow the instructions on the second proposal, but ultimately it is the responsibility of the validators to evaluate their readiness to run the proposed software by voting YES or NO (or NO-WITH-VETO) on the second proposal. There shall be no punishment for voting NO in the second proposal, if justification is provided (ideally in the memo field of the vote transaction).

Any bug fixes, as defined by the Tendermint development team, encountered during the operation of the gaia-14k testnet and committed to the master branch after the release of v0.34.0, will automatically be approved as per the endorsement of this proposal.

In the event of critical issues having been identified on testnet, the enablement process should be stopped ultimately with a NO decision on the second proposal, which is ideally (but not necessarily) determined by a third proposal citing the critical issue and decided by 24-hour Expedited Governance Rules. Then, a new proposal for the enablement of the transfers will be developed, taking into consideration any repercussions of the identified issues.

Persisting data from cosmoshub-1

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

Forum link

The following forum can be used to discuss this proposal:

For reference, see also:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment