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

refactor(CL/gamm): create CFMMPoolI interface, refactor PoolI (merge 4 - state breaking) #3560

Merged
merged 12 commits into from
Dec 5, 2022

Conversation

p0mvn
Copy link
Member

@p0mvn p0mvn commented Nov 29, 2022

Closes: #XXX

What is the purpose of the change

We would like to drop concentrated-liquidity-main branch to avoid branch synching overhead. As part of that, we are going to be incrementally merging the current concentrated liquidity feature state to main.

All this logic has already been given a round of reviews since we treated concentrated-liqudiity-main branch as main with appropriate review processes.

Note that the large diff stems from regenerating mocks. The actual change is under 250 LOC. The state break stems from proto-registering the new interface.

The main theme of this PR is the following:

  • implements CFMMPoolI defining an interface that all cfmm/gamm pools must implement
  • using CFMMPoolI throughout gamm. Using swaproutertypes.PoolI everywhere else
  • regenerating test mocks to be aligned with the new interfaces

Secondary changes:

  • Implementing GetPoolType() on CreatePoolMsg
  • implementing and testing convertToCFMMPool
  • Switching to using some identical constants and events that have been moved to `swaprouter

For the latest state of the feature that we are merging, see: https://github.com/osmosis-labs/osmosis/tree/concentrated-liquidity-main

See spec: https://github.com/osmosis-labs/osmosis/pull/3052/files

@github-actions github-actions bot added C:app-wiring Changes to the app folder C:simulator Edits simulator or simulations C:x/gamm Changes, features and bugs related to the gamm module. C:x/superfluid C:x/txfees labels Nov 29, 2022
@p0mvn p0mvn changed the title feat(CL): create CFMMPoolI interface, refactor PoolI refactor(CL/gamm): create CFMMPoolI interface, refactor PoolI (merge 4 - state breaking) Nov 29, 2022
@p0mvn p0mvn added the V:state/breaking State machine breaking PR label Nov 29, 2022
// convertToCFMMPool converts PoolI to CFMMPoolI by casting the input.
// Returns the pool of the CFMMPoolI or error if the given pool does not implement
// CFMMPoolI.
// nolint: unused
Copy link
Member Author

Choose a reason for hiding this comment

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

Note: removing this is tracked in #3556

@p0mvn p0mvn marked this pull request as ready for review November 29, 2022 02:45
@p0mvn p0mvn requested review from a team, czarcas7ic and ValarDragon November 29, 2022 02:45
Copy link
Member

@czarcas7ic czarcas7ic left a comment

Choose a reason for hiding this comment

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

LGTM, approving and then can merge on @ValarDragon approval due to state break as discussed previously 🏄🏻‍♂️

Comment on lines +18 to +23
func (k Keeper) MarshalPool(pool swaproutertypes.PoolI) ([]byte, error) {
return k.cdc.MarshalInterface(pool)
}

func (k Keeper) UnmarshalPool(bz []byte) (types.PoolI, error) {
var acc types.PoolI
func (k Keeper) UnmarshalPool(bz []byte) (types.CFMMPoolI, error) {
var acc types.CFMMPoolI
Copy link
Member

Choose a reason for hiding this comment

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

Just to clarify, is it intended to Marshal from PoolI but Unmarshal into CFMMPoolI?

Copy link
Member Author

Choose a reason for hiding this comment

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

Yeah. The reason is convenience. When we create a pool it comes in to gamm as PoolI from swaprouter. As a result, it is cleaner to marshal it directly without having to cast it to CFMMPoolI.

On the other hand, when we get a pool, it is usually to perform some operations within the gamm module. Most of these calculations require CFMMPoolI methods.

Copy link
Member

@ValarDragon ValarDragon Nov 30, 2022

Choose a reason for hiding this comment

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

Its unclear to me that it would be safe to Marshal to CFMMPoolI, I think we may have to always marshal and unmarshal from PoolI. (Which is what is happening here)

At least we would need to double check the serialized bytecode. IIRC, the proto import path + struct name does get serialized into @type

There should be a way for us to check this though, by serializing the interface to JSON

Copy link
Member Author

Choose a reason for hiding this comment

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

I'm going to look into this.

Copy link
Member Author

Choose a reason for hiding this comment

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

Please see test: d7d388d

Copy link
Member Author

@p0mvn p0mvn Nov 30, 2022

Choose a reason for hiding this comment

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

Just noticed that you specified serializing specifically to JSON. Why would JSON matter? Would the test above address your concern?

Copy link
Member

Choose a reason for hiding this comment

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

JSON was suggested just for debugging

)

func (k Keeper) applyJoinPoolStateChange(ctx sdk.Context, pool types.PoolI, joiner sdk.AccAddress, numShares sdk.Int, joinCoins sdk.Coins) error {
func (k Keeper) applyJoinPoolStateChange(ctx sdk.Context, pool types.CFMMPoolI, joiner sdk.AccAddress, numShares sdk.Int, joinCoins sdk.Coins) error {
Copy link
Member

Choose a reason for hiding this comment

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

why does this specifically call for CFMMPoolI but the others use PoolI?

Copy link
Member Author

Choose a reason for hiding this comment

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

There was no reason for this being CFMMPoolI. So I updated it to PoolI which has fewer methods.

Comment on lines 24 to 30
"osmosis.swaprouter.v1beta1.PoolI",
(*swaproutertypes.PoolI)(nil),
&Pool{},
)
registry.RegisterInterface(
"osmosis.gamm.v1beta1.CFMMPoolI",
(*types.CFMMPoolI)(nil),
Copy link
Member

Choose a reason for hiding this comment

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

imo we need to keep the old names here, otherwise we would need a relatively complex state migration.

Copy link
Member

Choose a reason for hiding this comment

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

Alternative is we make state migration code that takes the old type and casts it to a new type. This seems like a complex integrator break, that doesn't seem worth it imo

Copy link
Member Author

Choose a reason for hiding this comment

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

Something to keep in mind on this matter - we have an e2e test that pre-creates pools before the upgrade, runs some swaps against them, performs the upgrade, and runs some swaps again.

If the e2e test is passing, do you think still that the migrations would be necessary?

Copy link
Member Author

Choose a reason for hiding this comment

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

Either way, I will try to understand whether this is unsafe by looking into RegisterInterface(...) logic

Copy link
Member Author

@p0mvn p0mvn Nov 30, 2022

Choose a reason for hiding this comment

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

Reverted to old name to avoid breaking clients:

834bc85

@p0mvn p0mvn force-pushed the roman/cl-pool-refactor branch from d7d388d to 9f01762 Compare November 30, 2022 20:49
@p0mvn p0mvn force-pushed the roman/cl-pool-refactor branch from 9f01762 to 834bc85 Compare November 30, 2022 20:51
@p0mvn p0mvn requested a review from ValarDragon November 30, 2022 20:51
Comment on lines 27 to 28
"osmosis.gamm.v1beta1.CFMMPoolI",
(*CFMMPoolI)(nil),
Copy link
Member

@ValarDragon ValarDragon Dec 1, 2022

Choose a reason for hiding this comment

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

Wait we should keep this as "osmosis.gamm.v1beta1.PoolI"

Copy link
Member Author

Choose a reason for hiding this comment

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

fixed

Copy link
Member

Choose a reason for hiding this comment

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

Now im even more confused, we had one entry at time of this comment, now were back at two entries.

I thought this PR was jsut renaming PoolI -> CFMMPoolI. If so, then there should just be one interface registered, with the interface route being the old one.

x/gamm/types/codec.go Outdated Show resolved Hide resolved
)

func (k Keeper) MarshalPool(pool types.PoolI) ([]byte, error) {
func (k Keeper) MarshalPool(pool swaproutertypes.PoolI) ([]byte, error) {
return k.cdc.MarshalInterface(pool)
Copy link
Member

Choose a reason for hiding this comment

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

err does this work without casting to CFMMPoolI ?

Copy link
Member

@ValarDragon ValarDragon left a comment

Choose a reason for hiding this comment

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

Reviewed synchronously! LGTM, nice job

Theres a test confirming these are serialization equivalent (so the interface serialization didn't include this), we just can't have another interface, that uses this as a constituent interface.

I think for backwards consistency, we should still make the pairs in all 3 spots:
"osmosis.gamm.v1beta1.PoolI" -> CFMMPoolI

"osmosis.swaprouter.v1beta1.PoolI" -> swaprouter.PoolI

@p0mvn
Copy link
Member Author

p0mvn commented Dec 5, 2022

Paths updated as discussed so merging this to continue progressing with the swaprouter merge

@p0mvn p0mvn merged commit fa9293f into main Dec 5, 2022
@p0mvn p0mvn deleted the roman/cl-pool-refactor branch December 5, 2022 19:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C:app-wiring Changes to the app folder C:simulator Edits simulator or simulations C:x/gamm Changes, features and bugs related to the gamm module. C:x/superfluid C:x/txfees V:state/breaking State machine breaking PR
Projects
Archived in project
Development

Successfully merging this pull request may close these issues.

3 participants