-
Notifications
You must be signed in to change notification settings - Fork 618
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
Conversation
// 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 |
There was a problem hiding this comment.
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
There was a problem hiding this 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 🏄🏻♂️
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 |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please see test: d7d388d
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
x/gamm/keeper/share.go
Outdated
) | ||
|
||
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 { |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
x/gamm/pool-models/balancer/codec.go
Outdated
"osmosis.swaprouter.v1beta1.PoolI", | ||
(*swaproutertypes.PoolI)(nil), | ||
&Pool{}, | ||
) | ||
registry.RegisterInterface( | ||
"osmosis.gamm.v1beta1.CFMMPoolI", | ||
(*types.CFMMPoolI)(nil), |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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:
d7d388d
to
9f01762
Compare
9f01762
to
834bc85
Compare
x/gamm/types/codec.go
Outdated
"osmosis.gamm.v1beta1.CFMMPoolI", | ||
(*CFMMPoolI)(nil), |
There was a problem hiding this comment.
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"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fixed
There was a problem hiding this comment.
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.
) | ||
|
||
func (k Keeper) MarshalPool(pool types.PoolI) ([]byte, error) { | ||
func (k Keeper) MarshalPool(pool swaproutertypes.PoolI) ([]byte, error) { | ||
return k.cdc.MarshalInterface(pool) |
There was a problem hiding this comment.
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 ?
There was a problem hiding this 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
Paths updated as discussed so merging this to continue progressing with the swaprouter merge |
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 tomain
.All this logic has already been given a round of reviews since we treated
concentrated-liqudiity-main
branch asmain
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:
CFMMPoolI
defining an interface that all cfmm/gamm pools must implementCFMMPoolI
throughout gamm. Usingswaproutertypes.PoolI
everywhere elseSecondary changes:
GetPoolType()
onCreatePoolMsg
convertToCFMMPool
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