Tracking Issue: Launchpad Release

[ethanfrey]

Summary

After much discussion about the upcoming Stargate (IBC + Protobuf) releases and Hub upgrade, it became apparent that we need to provide better support for all the chains running mainnets on pre-Stargate version. Thus the concept of Launchpad was created to help.

Problem Definition

Launchpad will be a LTS release, compatible with the 0.38.x series. We will backport a few critical DB performance fixes from master and then stabilize Launchpad. At that point, the only ongoing development should be (backporting) bug fixes. This will provide a stable version of the code that any existing chain can easily upgrade to.

The Stargate team will also ensure a well-tested and documented migration path from the Launchpad release to the Stargate release, and if everyone starts the journey to the Cosmos from the same place, it is much less likely to have unexpected issues when migrating existing chains.

We plan to tag the Launchpad release, hopefully by late July, and hope all mainnets can upgrade to it. It should be a simple recompile, restart for 0.38.x chains and a typical upgrade for 0.36 or 0.37 chains. We also ask wallets / explorers / etc to upgrade support to the Launchpad release (which should be non-breaking) and maintain this in parallel to any future Stargate work.

Proposal

We should get input from all Zones and Modules that aim to upgrade to launchpad to ensure the frozen feature set is acceptable to all. If you wish to add an issue or PR to Launchpad, please link it in a comment below. If it is accepted (still a bit unclear how this happens, but @okwme will help organize that), then it should receive a 0.39 LTS (Launchpad) label. We can see all items that belong to Launchpad here:

• Issues
• PRs

I propose that the list of "Launchpad" items be frozen end of day on July 6th, 2020, to give time to organize a stable release with it.

Once these are completed, we tag a release both with a version (eg. v0.38.6) as well as launchpad. All future releases on that line afterwards will have no breaking changes and no new features, only security updates and bugfixes. This should follow the definition of Stable Release, being defined here

---

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged
• Contributor assigned/self-assigned

[ethanfrey]

This PR from @alexanderbez is a major upgrade to DB stability and the concept has been generally accepted for Launchpad on Discord #6505

(It still needs reviews and testing, but definitely should be included in Launchpad)

[alexanderbez]

I think this is a phenomenal idea. What I'm still confused about is what exactly "launchpad" is? From my POV and the way I understand it, launchpad == 0.38.x, which already exists. Apart from the pruning fixes, what else do we want in 0.38?

[ethanfrey]

This is one cherry pick that Fede proposed: #6523
It seems critical for Ethermint.

@alexanderbez 0.38.x should not have breaking changes. Launchpad should have everything to provide a complete, stable platform, as if we didn't dump tons of breaking changes on master as soon as 0.38.0 was cut and actively maintained and backported bugfixes.

0.38.5 is technically not 0.38.x as it is a breaking change, and since 0.39 is taken, we can't really use that number either.. this space between 0.38.x and a release suitable for most projects is "launchpad".

[Codegnosis]

I believe this already has a backport/release/v0.38.x label, but can I request it gets added to launchpad too (if not already flagged)? Issue #6306

Thanks.

[alexanderbez]

I would prefer to stick with the backport label -- it has no semantical difference with launchpad.

[ethanfrey]

Okay, I just saw the backport/release/v0.38.x label. Didn't realize you were using it for the same thing.

I just updated the links in the issue description

[ethanfrey]

In addition to my PRs above, I would like it if we could consider better gas pricing / charging for transactions. After I made my "robust gas pricing issue" I realized this has been discussed many times. The following two seem quite actionable items:

• Tx gas estimation improvement: Tx Gas Estimation Improvement #4938
• Refunding unused but allocated gas: Refunding unused but allocated gas #2150

It would be good to discuss if either (or both) could be in scope for launchpad. If they are, then discuss implementation.

Why I think this is important? Many clients have this issue with gas estimation. A few days ago this came up again in discord: https://discordapp.com/channels/669268347736686612/669274997264613376/727184290818949190 explaining how Ledger Live provides the gas estimate:

@okwme

Is this how all the wallets are dong this? Are the updates in 0.38 and 0.39 going to improve this process at all?

Ledger Live:

For the network fees before any transaction is sent :

• The gas estimation for a transaction provided by gaia node does not simulate the gas cost of reading and writing to the tendermint database.
• Therefore we have to apply a gas_amplifier factor to the estimation gaia gives us back, hoping that it will cover the storage costs.
• We tuned this amplifier to have all transactions passing (we had lower values at the beginning, but internal testing triggered a lot of lost funds because of OutOfGas errors)
• After this (safely high) GasWanted value is computed, we apply the anti-spam multiplier 0.25 uatom/gas and that's the "Network fees" value that you see

[ethanfrey]

Beyond such a large task, there also seem to be a number of non-breaking bug fixes that could potentially be backported (correct me if some have been already):

• (x/staking) Export validator addresses #6529 Export validator addresses (previously was empty).
• (export) Add TimeIotaMs to export GenesisFile #6510 Field TimeIotaMs now is included in genesis file while exporting.
• (x/bank) R4R: Save account for multi sending #6283 Create account if recipient does not exist on handing MsgMultiSend.
• (x/distribution) panic: Cannot encode unregistered concrete type types.MsgFundCommunityPool. #6210 Register MsgFundCommunityPool in distribution amino codec
• (types) types.ChainAnteDecorators() flaws #5741 Prevent ChainAnteDecorators() from panicking when empty AnteDecorator slice is supplied.
• (modules) Low inflation rate creates invalid module account - potential chain halt #5569 InitGenesis, for the relevant modules, now ensures module accounts exist.
• (x/auth) fix #6287 sending multiple transactions from an account make nonce sequence stuck #6291 Fix nonce stuck issue when sending multiple transactions from an account in a same block. Issue behavior is "unauthorized: signature verification failed" for correctly signed transaction.

Also this improvement seems simple: #5896

[alexanderbez]

I've added a backport label to some of those issues, the ones I didn't add it to are either state-machine breaking or would be too much headache to cherry-pick. Thanks for taking a look and gathering those @ethanfrey.

WRT to the beefy two issues you've posted, yes, it would be ideal to get those implemented. But we don't have anywhere near the necessary bandwidth to do them atm. Not to mention, getting those into 0.38 would be...hard if not impossible assuming we're sticking with minor API breaking changes only.

[alexanderbez]

Ok, had some more time to think about this. It seems the best thing to do is:

1. Release 0.38.5 based solely off of 0.38.4 with any necessary security patches. We will not support this version line after this. DONE.
2. Release 0.39.0 (launchpad (LTS)) which is 100% state-machine compatible with the 0.38 line, but includes pruning fixes, Tendermint update, along with any labeled backport issues/PRs (i.e. the launchpad/release/v0.39 branch will become 0.39.0).
   2a. Current PRs that have or will be added to launchpad.
3. What was once being tracked as 0.39 (stargate) will now be tracked as 0.40.0.
4. What was once being tracked as 0.40 (naming???) will now be tracked as 0.41.0.

[alessio]

Sounds like we have solid plan!

[Codegnosis]

Apologies - I referred to the wrong PR in my previous comment - the issue was the message.sender accumulation the Events, and the specific fix was in a comment within the tagged issue - #6306 (comment)

[clevinson]

The label has been updated now to 0.39 LTS (Launchpad).

Currently there are PRs that Bez added labels to, and seem to have general agreement that they fit within launchpad:

• Pruning Refactor (Pruning Refactor #6475)
• fix Sending multiple transactions from an account provides "unauthorized: signature verification failed" #6287 sending multiple transactions from an account make nonce sequence stuck (fix #6287 sending multiple transactions from an account make nonce sequence stuck #6291)
• Save account for multi sending (R4R: Save account for multi sending #6283)
• baseapp: add sdk.Result to simulation response (baseapp: add sdk.Result to simulation response #5839)
• fix types.ChainAnteDecorators() panic (fix types.ChainAnteDecorators() panic #5742)
• Export validator addresses (Export validator addresses #6529)

This leaves the following issues unaccounted for from @ethanfrey's previous list:

• (export) Add TimeIotaMs to export GenesisFile #6510 Field TimeIotaMs now is included in genesis file while exporting.
• (x/distribution) panic: Cannot encode unregistered concrete type types.MsgFundCommunityPool. #6210 Register MsgFundCommunityPool in distribution amino codec
• (modules) Low inflation rate creates invalid module account - potential chain halt #5569 InitGenesis, for the relevant modules, now ensures module accounts exist.

Additionally, @ethanfrey mentioned that #4938 would be great to include, and offered to do a PR & backport for this if it gets approved for Launchpad.

Looking for thoughts from others here on scope (@alessio @aaronc @alexanderbez). Regen team is currently pretty heads down on 0.40/Stargate, and I'd like to keep it that way if possible. Is anyone else interested in trying to cherrypick these last unaccounted issues so they can be folded into Launchpad?

[alessio]

The label has been updated now to 0.39 LTS (Launchpad).

We should use https://github.com/cosmos/cosmos-sdk/milestone/27 instead of the label https://github.com/cosmos/cosmos-sdk/issues?q=label%3A%220.39+LTS+%28Launchpad%29%22+is%3Aclosed (I'm incorporating this into my PR re: stable releases)

[alexanderbez]

@alessio the milestone and label are complimentary. They should be used together.

flow:

1. PR lands on master
2. We discuss that said PR should be backported (i.e. cherry-picked) into a point release (e.g. launchpad)
   2a. A label is added to said PR
3. A PR is made with the cherry-pick against the living backport branch
4. Finally, that PR (step 4), is added to the milestone so we can track it.

[alessio]

Ok that clarifies the scope. It makes sense. Thanks!

[ethanfrey]

Additionally, @ethanfrey mentioned that #4938 would be great to include, and offered to do a PR & backport for this if it gets approved for Launchpad.

I want to repeat this here.. (on discord and some other chats already).

It is a major client issue. The only breaking part is clients needing to reduce the "gas multiplier" to a normal level (so inconvenience if not fixed, definitely not state-machine breaking). I will take it on, as it will vastly help with our attempts to estimate costs of cosmwasm contracts.

[alexanderbez]

We're gonna get #4938 in 🎉

[clevinson]

So in terms of launchpad, seems like we're aligned on @ethanfrey taking on #4938. I'm assuming will we move forward without the following pieces (from @ethanfrey's initial post):

• (export) Add TimeIotaMs to export GenesisFile #6510 Field TimeIotaMs now is included in genesis file while exporting.
• (x/distribution) panic: Cannot encode unregistered concrete type types.MsgFundCommunityPool. #6210 Register MsgFundCommunityPool in distribution amino codec
• (modules) Low inflation rate creates invalid module account - potential chain halt #5569 InitGenesis, for the relevant modules, now ensures module accounts exist.