Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TEST-40: Remove all dependencies on ibc-v2 #14

Merged
merged 4 commits into from
May 18, 2022

Conversation

shellvish
Copy link
Contributor

@shellvish shellvish commented May 16, 2022

Summary

Removed tendermint-spn and cosmos-sdk CLI, both of which used IBC-v2.

Specifically:

  1. Added StrideApp to app.go (replaces previous generic App object). Created necessary helpers to make this a valid implementation (e.g. GetIBCKeeper, GetStakingKeeper, etc)
  2. Removed OpenAPI routes for the app (I don't believe we were using these)
  3. Added encoding.go, which is inspired by QS's implementation. Very similar to Osmosis's implementation (virtually identical, but Osmosis defines structs in a separate file). I'm unsure exactly what this is doing, but I believe encoding transactions to be sent over (using the "Amino" protobuf protocol?)
  4. Created genaccounts.go which defines AddGenesisAccountCmd (from Osmosis + QS), which adds a command line argument to add accounts to genesis (with vesting! although unclear if they receive voting rights)
  5. Added root.go file that defines a cmd line interface (using Cobra)

PLEASE tell me if you want more comments anywhere in this commit, I'm always happy to improve code readability

Test plan

ignite chain serve now works properly, and we're able to get a functioning chain!

@asalzmann
Copy link
Contributor

At a high level, is the approach here to emulate the interchain-accounts-demo approach by swapping out the CLI?

@shellvish
Copy link
Contributor Author

basically yeah, although it's mostly inspired by Osmosis + QS (although both of them are p similar to the implementation in interchain-accounts-demo

Copy link
Contributor

@asalzmann asalzmann left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall lgtm! Just a few small comments

@@ -3,29 +3,29 @@ module github.com/Stride-labs/stride
go 1.16

require (
github.com/cosmos/cosmos-sdk v0.45.3
github.com/cosmos/cosmos-sdk v0.45.4
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like there are a bunch of versioning updates in this file, were these auto-generated?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, yes, although they're unnecessary. I previously thought if we updated the cosmos-sdk it would resolve our v2/v3 bugs, and then I never downgraded again. We can revert this if desired

@@ -76,20 +76,23 @@ func (app *App) prepForZeroHeightGenesis(ctx sdk.Context, jailAllowedAddrs []str

// withdraw all validator commission
app.StakingKeeper.IterateValidators(ctx, func(_ int64, val stakingtypes.ValidatorI) (stop bool) {
_, err := app.DistrKeeper.WithdrawValidatorCommission(ctx, val.GetOperator())
if err != nil {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why remove the error checking here?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I had the same Q. Seems like it was inspired by Osmosis' implementation (QS does the same thing). Though I wonder if both those implementations are outdated relative to the error checking that ignite provides by default.

Hard to know whether we need the handling here. Seems like the SDK does some error handling but not a ton

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually I think I like Ignite's version better -- I just checked the git blame and see that Osmosis' code for this section was written 2 years ago haha

https://github.com/osmosis-labs/osmosis/blame/e3f09f3734e8b325df10a24af587084b3965cd46/app/export.go#L76

"github.com/cosmos/cosmos-sdk/server"
sdk "github.com/cosmos/cosmos-sdk/types"
authtypes "github.com/cosmos/cosmos-sdk/x/auth/types"
authvesting "github.com/cosmos/cosmos-sdk/x/auth/vesting/types"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

More info on this here https://docs.cosmos.network/main/modules/auth/05_vesting.html#intro-and-requirements

Importantly, "For all vesting accounts, the owner of the vesting account is able to delegate and undelegate from validators, however they cannot transfer coins to another account until those coins are vested."

If vest investors on chain, we should probably use period vesting

"Periodic vesting, where coins begin to vest at ST and vest periodically according to number of periods and the vesting amount per period. The number of periods, length per period, and amount per period are configurable. A periodic vesting account is distinguished from a continuous vesting account in that coins can be released in staggered tranches. For example, a periodic vesting account could be used for vesting arrangements where coins are relased quarterly, yearly, or over any other function of tokens over time."

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good find and I think we should use this IFF we can find a way to restrict them from delegating. Seems like vesting is written so that all vesting options allow delegation (and thus I believe the accrual of staking rewards, which we do NOT want to allow). The other option is something manual e.g. we hold all the tokens and transfer some to investors once a month (not too difficult, though admittedly not as "clean" as something like a vesting module)

Copy link
Contributor

@riley-stride riley-stride May 18, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One option would be to fork the vesting module, but I am hesitant to open that can of worms (high downside, low upside)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed, I'm a bit worried about forking it too. We can ask investors their preferences here, it's possible everyone is fine just signing a contract saying they won't stake

// own app.toml to override, or use this default value.
//
// In simapp, we set the min gas prices to 0.
srvCfg.MinGasPrices = "0stake"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here's how Osmosis allows for gas prices to be 0! We should take not of this. @vish-stride can you add a ticket to JIRA to track this and a TODO here referencing the ticket?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like this is a local parameter set on individual nodes (unclear if we need to make any updates to our codebase to enable 0 fee transactions)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor

@riley-stride riley-stride left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall this looks good. Sorry you had to grind through this one and thanks for sticking it out. Added some light comments but overall looks like a lot of imported logic from QS and Osmosis.

One overarching Q that jumps out (evidenced by Aidan's Q about your removing an error check) is whether we should put more faith is Osmosis' live code (which was however written long ago) or Ignite's scaffolded code (likely less battle tested, but newer)

@shellvish shellvish merged commit c5a50d2 into main May 18, 2022
riley-stride pushed a commit that referenced this pull request Sep 5, 2022
…rsion

Switch version to recommended_version, add compatible_versions
asalzmann pushed a commit that referenced this pull request Jan 25, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants