Upgrade Cosmos SDK

[faddat]

SDK Upgrade

This issue will be an epic for tracking the SDK upgrade. It's incomplete and when it has a complete list of tasks, this incompleteness message will be removed.

Got an update today that we'll likely wait till 48 to upgrade. Will keep looking for items that will make the upgrade easier overall.

planning

The general process that we have followed when upgrading to SDK47, is to begin by applying really tight linters. The reason for this is that over time, The tight linters actually make the type of fairly challenging merges that tend to be necessary for an SDK upgrade easier.

The best documentation for upgrading is found in the SDK and IBC repositories. We could run into some challenges with newly required getters and the folders under app, which we can solve either by returning to a traditional app.go file or hacking around. Since osmosis now has so many modules, I think that it's likely to make sense to find the workaround for that.

One of the largest items is going to be attending to changes that have been made in the osmosis SDK versus Cosmos SDK 45.

osmosis SDK fork

In order to determine any changes that we may need to make to SDK-47 for osmosis features, we should do a diff of osmosis SDK and cosmos SDK at 45. From that we can create a list which will be tracked in this section.

Distinct tasks

Let's break this into two groups, things that are not breaking changes and can be merged into the SDK45 version of osmosis, and things that are breaking changes and cannot be merged into the SDK45 version of osmosis.

This will reduce the overall size of the diff

things we can merge into 45

• use golangci-lint on tests #5109
• strict gofumpt ("extra" mode) style: do a gofumpt run #5059
  • add gofumpt to docs: ISSUE-190: [editor configuration] Update ide-guide.md docs#191
• stlye: use thelper without linting every test #5064
• refactor: use cosmossdk.io/errors #5065

things that need to go on a 47 feature branch

• new protocol buffers build process
  • remove the third party folder and use imports instead
  • publish everything to the buf registry so that other chains can use osmosis proto types more easily
• Ensure that the CI system that tests upgrades works with 47
• diff cosmos SDK v0.45.15 and osmosis-sdk. Make a list of changes in an issue, and determine which changes if any we want to port to 47
• use the math module
• upgrade to IBC version 7 or 7.1 or 8
  • module paths
  • ibchost to ibcexported
  • importing the client has changed, we no longer use a types folder
• Make sure that we do not use gogo/protobuf anywhere, use only cosmos/gogoproto
• for custom governance proposal types in osmosis, determine if we use the legacy fashion or message based governance
• watch out for changes to coin and coins (something became variadic, I think it's that coins is a variadic array of coin)
• determine if we want to support the group module
  • if yes, talk with the BCNA team, who have put together a really excellent UI for group.
• determine if we want to support the NFT module

Post coding tasks

• deploy on testnet
• test each module, including functionality that is not frequently used, basically roll through The CLI, on testnet. Don't trust every test, nor e2e. Fix things where needed.
• test contract deployment process and update any documentation on that process.
• check that 100% of existing contracts function as expected
• compare ram and CPU usage to osmosis on SDK 45

I'll be opening sub issues for these items over the next couple of days and/ or weeks.

[nicolaslara]

This looks like a good plan. Some notes:

• Keep in mind that there are a few submodules in the repo (osmomath, osmoutils, epochs, ibc-hooks) that may need to be updated in parallel
• IIRC, the fork differences are all on the bank module, so a solution would be to have our own bank module and do a replace. I know there was some work on allowing hooks there, but I'm not sure if that covers all use cases (particularly for supply offsets)

[faddat]

@nicolaslara thanks for reviewing the plan! I haven't yet begun to compare the two SDK's but I like this idea :).

Will take your thoughts into account when working on the ugprade.

I think I'm probably out for the rest of the day, but will be back on the grind with this tomrorow.

regarding the submodules -- when you go work sync, golangci-lint will take the submodules into account, which makes it extra useful.

[faddat]

It occurs to me that we won't know till we know sooooooo...