[PROPOSAL #2][REJECTED] Proposal: Plan for enabling Atom Transfers

Hi Cosmonauts,

This post has been cleared.

The proposal can be found as proposal 2 on the cosmoshub-1 chain.

Cosmos | Cosmos Hub 1 | ATOM Transfer Enablement

A plan is proposed to set up a testnet using the Cosmos SDK v0.34.0 release, along with mainnet conditions, plus transfer enablement and increased block size...

https://cosmos.bigdipper.live/proposals/2

The discussion is to be moved to: Post-Launch Roadmap - Proposal: Atom Transfers

Thank you for the draft proposal @Simply-VC. One thing that is somewhat not obvious in the draft is the proposal itself. The proposal must be submitted on the mainnet (cosmoshub-1) and not on a testnet (gaia 14k). The testnet should be used for testing new changes and parameters while making sure acceptance criteria is met.

Thanks for the proposal draft!!

I want to add one more parameter change on 14k.

Currently we have params in genesis as below

“block_size”: {
“max_bytes”: “150000”,
“max_gas”: “1500000”
},

This prevent blockchain from producing blocks with more than 7~8 txs.

I expect a risk that if a spammer wants to bring a traffic jam in Cosmos Netowork,
it is very cheap and efficient because of these parameters.
(1m txs will delay normal txs for 80days, and it will cost only less than several hundreds of atom)

I suggest at least 100 times of these parameters in 14k to test.
If the test is succussful, we can discuss whether we want it in mainnet or not.

By all means the block maximum gas will increase.

Thanks for the feedback @bharvest and @bez
I’ve added some clarifications regarding where proposals are to be submitted and also included as you pointed out the obviously necessary increase in block size.

So part of the trade off space I see with testnets in the QA process for an upgrade is

If we require the testnet to start with a state snapshot from mainnet, it will take longer for the testnet to start but there may be enough political legitimacy there to set a short voting period and use the testnet to coordinate an exact blockheight for a mainnet upgrade.

The other way to do it is to use gaia account states that we have been using for testnets for a fast boot up.

Hi,

Just have two Questions:

• how long would the voting period of the prosposal be
• could the blockheight be set to Block 250.000, as it would hit the cosmos milestone

I am agreed that testing Atom transfer at Gaia 14k with SDK 0.34.0.

Lets start the transfers voting guys… Block Height 250,000 is perfect! Lets do it!!

@dsgnsupporter and @kreiosx3: block 250k would be in about 9 days, so that’s not possible, as the proposal vote will take at least 14 days.

Zaki brought up a good point. These proposals take 14 days to vote on each, and therefore this whole process will take quite some time with this method.
I am, in principal, not really in favour of undergoing the height/commit proposal vote on the testnet itself as it limits the voting power of low self-delegation validators or inactive delegators. Apart from the fact that since this proposal since this proposal is relevant to cosmoshub-1, it should be done on cosmoshub-1.

Changes we suggest:
This proposal will also propose a block height and software version for the upgrade so that only one proposal will be needed.
There will be breakout conditions for any critical issues, where we can submit another proposal to agree on another upgrade timeline.

Endorsing Zaki’s comment – avoiding the step of collecting gentx transactions for a decentralized start is desirable. I think using the gaia account states from the current testnet is adequate.

Hubble now has a functioning faucet, which will make it easy for anyone not in the state on gaia-13k to join.

Feedback on the plan was posted here:

Post-Launch Roadmap - Proposal: Atom Transfers Proposal Ideas

A proposal has been created here which would enable transfers and links to this page. I thank the proposal authors (“Simply VC”) for their efforts and look forward to enabling transfers, but I (individually, not representing any official entity) have serious concerns with this proposal as written. Specifically: Network upgrade process: dual-proposal vs. single-proposal I think a dual-proposal process for software upgrades would be safer and provide a higher degree of certainty for node operat…