More use cases for middleware

[ethanfrey]

While adding the general fee mechanism to ICS, @AdityaSripal introduced the concept of a middleware. I think this idea is very powerful; however, with only one use case it may be missing some details. In this discussion, I would like to show another proposed protocol which I believe could only be implemented with some middleware design, but I am unsure if the current middleware design encompasses it.

I would love to kick off a discussion on how we could implement such a protocol, if middleware is the proper approach, and any enhancements that might be needed.

Protocol Definition

There will soon be multiple IBC-enabled DEX. The current workflow is (1) ics20 transfer tokens to the DEX (2) swap on the DEX and maybe (3) send swapped tokens to another chain. Given the volatility of many DEX, and the ability to put spread/limit on the proposed swap, it is very possible that (2) fails. To make a DEX more attractive for participants who hold assets on the origin chains, we could propose a new protocol ICS-DEX that with 1 IBC packet:

• Transfers the tokens to the DEX
• Performs a swap on the DEX

If the swap fails, the packet returns an error and the tokens are released from escrow on the source chain (never transferred). There is also less latency, in that you do not need to wait for the first message to be committed, and then sign a new transaction, this happens as fast as a single ICS20 transfer.

Issues Encountered

I could build a custom module on both sides that implements this, but there is one critical issue: if my custom module moves the tokens, it will have a different hash that tokens moved over ics20. That is, if I send Regen to Osmosis via transfer/channel-7/urgn, it will have a different hash than tokens moved over dex-swap/channel-12/urgn, and thus the custom module could not mint tokens that are usable in the pair that mainly works with the ics20 transfer tokens.

Proposed Solutions

I would like to be able to "wrap" a contract along with a send, and then have a verifiable send passed into the contract on the other side. This is much like what x/wasm does in transferring tokens and then passing that (verified) info to the contract as a MessageInfo struct: https://github.com/CosmWasm/wasmd/blob/master/x/wasm/keeper/keeper.go#L311-L319

In some world I could imagine this built via middleware:

client: ibctransfer-wrap(dex-send)
server: ibctransfer-wrap(dex-receive)

This would require 2 points:
(1) ibctransfer-wrap is implemented in the same ibctransfer module and is able to pool tokens sent via this joint channel with tokens send via the typical pool. Since these are both maintained by ibctransfer, would this ever be possible, even with some checks?
(2) the ibctransfer-wrap module would need to take data from dex-send and add data to dex-receive, that is... it would not be transparent to the wrapped module.

Maybe middleware is not the proper approach here?

I would love to get feedback on the problem space and any possible solutions, whether or not they use middleware. While this use case is rather simple and may not be to important, I think the general solution of a protocol that couples sending tokens (ICS20 or NFT or other?) with another function call will be a very useful primitive, and we should figure out some way to make this work.

(In CosmWasm CW20, CW721, and CW1155 we have this sort of functionality to tell the token contract to transfer a token, then call into another contract - escrow, dex, etc - to use the token. I can provide links if this is useful)

[AdityaSripal]

I like this idea a lot and agree it would be nice to have the sender specify some action that must happen atomically with the transfer.

This is implementable with middleware.

Middleware Solution

So on the sending side we need to send the regular ICS20 transfer info, and we must also send over IBC the desired trade that we want to make with these tokens.

So one option is to wrap transfer with middleware that encodes the dex swap into the transfer packet. Thus on the sending side the middleware takes the outgoing packet and adds the dex information (from user-submitted multi-msg Tx) into the packet before sending it to core IBC. (It could do this by adding proto-fields or by constructing a new packet type (dex-packet) that keeps the old transfer packet information as well)

On the receiving end, the middleware can deconstruct the packet and store the dex swap information in some variable during pre-processing. It passes the original transfer packet to the receiving ICS-20 (it can do this again by just creating a transfer packet and filling the fields in with info from dex-packet). If the transfer's receive is unsuccessful, just return the unsuccessful ack to core IBC.
If the transfer's receive is successful, then try to do the dex swap as part of the post-processing logic of middleware. If it passes, send successful ack to core IBC.
If it fails, then create an unsuccessful ack and send to core IBC (this ignores success ack from ICS-20). Core IBC will rollback all changes made by the application stack (both middleware and ICS-20), and write unsuccessful ack to state.
Relayer can relay unsuccessful ack and user on sender side gets back their tokens.

So sender only sends a single tx on sender side. On failure, their tokens are only escrowed for as long as it takes for relayer to do round trip (relay packet and relay ack).

This same technique could be done for any atomic thing you want done over IBC.

Limitations

(1) ibctransfer-wrap is implemented in the same ibctransfer module and is able to pool tokens sent via this joint channel with tokens send via the typical pool. Since these are both maintained by ibctransfer, would this ever be possible, even with some checks?

From my understanding you want tokens from dex-transfer channel to be pooled with tokens from transfer channel? This is not really possible to do, it would require that the dex-transfer module know the channel-ID of the transfer channel you want to pool with. This seems hard to do without hardcoding the default pool's channel ID into the dex-transfer state. If you do that, then you could just recreate the exact denom assuming you give the same minting permissions to both modules (Currently in the SDK there is no denom-level check for minting permissions, IBC name prefix is implicitly preserved until cosmos/cosmos-sdk#9238 is in). But if you do this you may as well just create a custom module that purposefully name-collides with the desired ICS20-channel's denom anyway.
cosmos/cosmos-sdk#7906

I think that's a very bad approach to take and will be unsafe. We should keep channel pools isolated.

We are seeing that there are canonical channels between chains that DEXes are using to make swaps. I would prefer that to enable this feature, DEX makes the canonical transfer channel a channel with the dex middleware. Rather than having two channels that are merging their pools together

[ethanfrey]

We are seeing that there are canonical channels between chains that DEXes are using to make swaps. I would prefer that to enable this feature, DEX makes the canonical transfer channel a channel with the dex middleware. Rather than having two channels that are merging their pools together

This is a good point.

So, if this ICS20/Dex combo solution binds a port and this allows both transfer+swap and transfer only actions, then we can make this the default ics20 link? This is a very good observation and makes a great simplification - don't try to make 2 channels equivalent, rather use a different channel as the default (customary) channel.

I guess it might be easier to define a custom protocol that is a superset of ICS20, and implement that one rather than try to do it with middleware.

Thank you for the feedback. Good food for thought and I will ponder this design a bit more.

[AdityaSripal]

Yes I guess the benefit of middleware in this case is to not reuse code, or if you'd like to reuse this same atomic swap idea with some other underlying application (maybe NFT swaps if that ends up being a separate ICS)

But if its just this usecase you could just reimplement transfer and add this functionality

[giansalex]

I built an example for osmosis, using middleware and ICS4Wrapper

https://github.com/disperze/ibc-osmo

[ethanfrey]

I just saw https://github.com/disperze/ibc-osmo/blob/master/proto/interswap/v1beta1/packet.proto which seems like a nice extension of ibc transfer to allow swaps. Seems like a nice idea.

Can you link to where you use the middleware pattern?

[giansalex]

Is used here:
Osmosis UI test: https://osmosis-ibc.web.app/pool/1
Swap Tx on Juno testnet: 9B122534DAC88B0C1669DCB7FECF3A7CCA7F2CA91267455EB5ACAC4F1D88E725