feat: middleware support for ICS20 #533

thomas-nguy · 2021-11-10T14:23:34Z

Description

Based on interchains-account implementation (https://github.com/cosmos/ibc-go/pull/417/files)

closes: #347

Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.

Targeted PR against correct branch (see CONTRIBUTING.md)
Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
Code follows the module structure standards.
Wrote unit and integration tests
Updated relevant documentation (docs/) or specification (x/<module>/spec/)
Added relevant godoc comments.
Added a relevant changelog entry to the Unreleased section in CHANGELOG.md
Re-reviewed Files changed in the Github PR explorer
Review Codecov Report in the comment section below once CI passes

lgtm-com · 2021-11-10T14:50:52Z

This pull request introduces 1 alert when merging ae0629b into 823ef67 - view on LGTM.com

new alerts:

1 for Useless assignment to field

thomas-nguy · 2021-11-16T07:03:22Z

modules/apps/transfer/keeper/msg_server.go

@@ -19,8 +22,14 @@ func (k Keeper) Transfer(goCtx context.Context, msg *types.MsgTransfer) (*types.
 	if err != nil {
 		return nil, err
 	}
+
+	channelCap, ok := k.scopedKeeper.GetCapability(ctx, host.ChannelCapabilityPath(msg.SourcePort, msg.SourceChannel))


@colin-axner I am not totally sure how I should handle the channel cap here. I moved it to the msg_server level. Is there anything else that needs to be done?

Sorry for the delayed reply! This looks good to me, although I'm not sure it matters if ics20 continues to claim the channel capability in the channel handshake callbacks.

@AdityaSripal Do we want to allow applications using ics20 as middleware to claim the capability?

@thomas-nguy Is it desirable for your use case for the connected application to be capable of sending packets? Otherwise I'm thinking maybe we should leave all the capability management as it was. Essentially only allowing the connected application to get information about the ICS20 transfer, but not act upon it

Not necessary, but I did claim here to preserve the original behavior.

Before it was claimed at "SendTransfer" level, but this line needs to be removed since the capability is now passed by parameter

So in this case, we should have some sort of conditional logic that only claims capability if im.app is nil. This applies to both port and channnel capabilities.

Do you refer to this section @AdityaSripal ?

The capability here is claim by the msg_server which is outside the middleware layer. Not sure to understand which check you want to do

lgtm-com · 2021-11-16T07:45:38Z

This pull request introduces 1 alert when merging 9b4ac36 into 823ef67 - view on LGTM.com

new alerts:

1 for Useless assignment to field

fedekunze · 2021-12-28T18:12:02Z

what's the status of this PR? @thomas-nguy

fedekunze

LGTM, @AdityaSripal can you reply to the comment above?

@thomas-nguy can you add a changelog entry?

modules/apps/transfer/ibc_module.go

lgtm-com · 2021-12-28T18:31:36Z

This pull request introduces 1 alert when merging a019faf into 4523ef5 - view on LGTM.com

new alerts:

1 for Useless assignment to field

codecov-commenter · 2022-01-03T11:25:37Z

Codecov Report

Merging #533 (4d8f264) into main (ce71056) will decrease coverage by 0.15%.
The diff coverage is 48.27%.

@@            Coverage Diff             @@
##             main     #533      +/-   ##
==========================================
- Coverage   79.56%   79.40%   -0.16%     
==========================================
  Files         145      145              
  Lines       10625    10640      +15     
==========================================
- Hits         8454     8449       -5     
- Misses       1755     1773      +18     
- Partials      416      418       +2

Impacted Files	Coverage Δ
...nterchain-accounts/controller/keeper/grpc_query.go	`100.00% <ø> (ø)`
.../27-interchain-accounts/controller/keeper/relay.go	`86.04% <ø> (ø)`
...s/27-interchain-accounts/host/keeper/grpc_query.go	`100.00% <ø> (ø)`
modules/apps/transfer/types/msgs.go	`95.23% <ø> (ø)`
modules/core/02-client/legacy/v100/store.go	`71.29% <ø> (ø)`
modules/core/02-client/types/msgs.go	`75.95% <ø> (ø)`
modules/core/03-connection/types/msgs.go	`85.93% <ø> (ø)`
modules/core/04-channel/keeper/keeper.go	`84.41% <ø> (ø)`
modules/core/04-channel/types/msgs.go	`77.24% <ø> (ø)`
modules/core/keeper/msg_server.go	`62.40% <ø> (ø)`
... and 6 more

colin-axner · 2022-01-03T11:50:01Z

To help push this along, I'm going to pull out some of the changes into a separate pr, primarily allowing transfer to hook up to a middleware like ics29. This change is very small and doesn't change any ics20 functionality (simply adding the ics4Wrapper interface)

I like the direction of this pr (excluding OnRecv from supported callbacks). I'd like to resolve the channel capability discussion with @AdityaSripal once he returns to work. I'm leaning towards only allowing applications connecting to ics20 from below to act as logging for now. I think logic that requires returning of acknowledgements (such as triggers ie sending an IBC packet) require more thoughts as we may need to change the ics20 acknowledgement format to wrap the returned acknowledgements

colin-axner · 2022-01-03T12:04:20Z

modules/apps/transfer/ibc_module.go

+		return nil
+	}
+	// call underlying app's OnChanOpenAck callback with the counterparty app version.
+	return im.app.OnChanOpenAck(ctx, portID, channelID, counterpartyVersion)


What's the reasoning for now adding callbacks for OnChanOpenTry and OnChanOpenConfirm?

not much reason beside adding more flexibility, might be useful for the wired app? if not it should return nil anyways?

colin-axner · 2022-01-03T12:09:26Z

modules/apps/transfer/keeper/msg_server.go

@@ -19,8 +22,14 @@ func (k Keeper) Transfer(goCtx context.Context, msg *types.MsgTransfer) (*types.
 	if err != nil {
 		return nil, err
 	}
+
+	channelCap, ok := k.scopedKeeper.GetCapability(ctx, host.ChannelCapabilityPath(msg.SourcePort, msg.SourceChannel))


@thomas-nguy Is it desirable for your use case for the connected application to be capable of sending packets? Otherwise I'm thinking maybe we should leave all the capability management as it was. Essentially only allowing the connected application to get information about the ICS20 transfer, but not act upon it

AdityaSripal

For middleware architecture, the underlying base app must be the one to claim capability.

So in this case, we should have some sort of conditional logic that only claims capability if im.app is nil. This applies to both port and channnel capabilities.

Can we have some usecases presented to see how this will be used in real life so we can see if that is workable in those cases? cc: @fedekunze

Also, please wrap all callbacks to allow maximum flexibility to underlying apps

fedekunze · 2022-01-06T21:17:39Z

Can we have some use cases presented to see how this will be used in real life so we can see if that is workable in those cases?

Our main use case is to enable IBC hooks that can execute trigger different functionality (eg: claiming airdrop tokens)

colin-axner · 2022-01-07T11:45:40Z

@thomas-nguy sorry that this is just being brought up now, but have you thought about making your hooks be the middleware application?

I had suggested to @fedekunze to do this for claiming airdrop tokens and @AdityaSripal pointed out that this is also possible for post processing hooks.

The middleware would simply call the ICS20 application callbacks and then would perform any custom logic as desired. Acting as a pass through module (not modifying acknowledgements and errors)

This would render this pr unnecessary. I think logically it makes sense that ICS20 is a base application that would never need to call additional logic. Any custom logic should simply wrap ICS20 (either performing the logic before or after calling ICS20). Does this make sense?

thomas-nguy · 2022-01-07T15:59:33Z

@colin-axner thank you for your feedback.

No issue, I can close this PR if it become unnecessary

Dumb question though, would it be possible to do post processing logic after a "SendTransfer" without this line change?
https://github.com/cosmos/ibc-go/pull/533/files#diff-ed533db5ed79787367690f88eacfb58bf5225e25a39cdebc40fc5eae26d7f1d6L180

I would requires to override or wrap the channel keeper to add additional logic but this does not seem clean

colin-axner · 2022-01-07T16:05:28Z

Dumb question though, would it be possible to do post processing logic after a "SendTransfer" without this line change?
https://github.com/cosmos/ibc-go/pull/533/files#diff-ed533db5ed79787367690f88eacfb58bf5225e25a39cdebc40fc5eae26d7f1d6L180

Not a dumb question. It is required. The ICS4Wrapper is the interface for middleware applications when we are doing logic which originates from the application and ends up at core IBC.

In IBC there are two flows:
app -> core
core -> app

app -> mw -> core utilizes ICS4Wrapper to achieve this (SendPacket/WriteAcknowledgement)
core -> mw -> app utilizes implementation of the 05-port IBC Module to achieve this (all On callbacks, OnRecv, OnAck etc)

When you hook up your middleware to ICS20, when the line for SendTransfer uses ics4Wrapper.SendPacket, then your function SendPacket will be called. Your function does its logic then call its ics4Wrapper (most likely the actual IBC channel Keeper). Does this make sense?

I think it makes sense to close the issue

The change from calling ChannelKeeper.SendPacket to ics4Wrapper.SendPacket will be included in v3 (its API breaking so we cannot backport)

thomas-nguy · 2022-01-07T16:13:23Z

Thanks for the explanation, yes it is clear.

If the change from calling ChannelKeeper.SendPacket to ics4Wrapper.SendPacket is already done in another PR then that would work for me 👌

I am closing this PR

colin-axner · 2022-01-07T16:17:15Z

yup #675 thanks again for starting this discussion

Add cost and api cost options

* WIP Provider interface * Add definitions to the txProvider and begin migration of cosmos specific logic to cosmos provider * get connection based msgs behind TxProvider * finish implementing TxProvider interface * WIP: implementing QueryProvider * finish implementing QueryProvider * Define and implement the KeyProvider interface * Merge PR cosmos#530: Config refactor to handle provider abstraction * WIP: refactor config for provider abstraction * bump gopkg.in/yaml from v2 to v3 * refactor config for provider abstraction * better var naming & doc tweaks * Merge PR cosmos#533: Refactor core relayer code to use provider interface * refactor cli based key management * refactor path cli based commands * testing new config * WIP: refactor chain cli based commands * delete dev and testnet cmds * Merge PR cosmos#534: State Based Relaying, Reenable tests, Add Osmosis to tests * Migrate https://github.com/strangelove-ventures/relayer/pull/35 to this PR * Merge PR cosmos#535: Working tests and Strategy removal * Add osmosis to supported chains for test env * Remove more stuff and add make test-short * Add build osmosis container make file * WIP: push everything behind provider interface * WIP: push everything behind provider interface pt 2 * WIP: swap out old function calls for new provider calls * IT'S ALIVE! (bug fix time) * Most tests working! 🎉🚀💯 * update filename for fetch tests Co-authored-by: Jack Zampolin <jack.zampolin@gmail.com> * Fix test race conditions * Add back makefile test targets Co-authored-by: jtieri <37750742+jtieri@users.noreply.github.com>

thomas-nguy requested review from AdityaSripal, colin-axner and fedekunze as code owners November 10, 2021 14:23

thomas-nguy mentioned this pull request Nov 10, 2021

Draft: support middleware in ICS20 #351

Closed

9 tasks

thomas-nguy force-pushed the thomas/add-middleware-support-to-ICS20 branch from b6873a1 to f060f30 Compare November 10, 2021 14:29

middleware support for ICS20

ae0629b

thomas-nguy force-pushed the thomas/add-middleware-support-to-ICS20 branch from f060f30 to ae0629b Compare November 10, 2021 14:32

thomas-nguy commented Nov 16, 2021

View reviewed changes

thomas-nguy requested review from charleenfei, crodriguezvega, damiannolan and seantking as code owners November 16, 2021 07:05

thomas-nguy force-pushed the thomas/add-middleware-support-to-ICS20 branch 2 times, most recently from 0aaede8 to 1edd2fa Compare November 16, 2021 07:22

update tests

9b4ac36

thomas-nguy force-pushed the thomas/add-middleware-support-to-ICS20 branch from 1edd2fa to 9b4ac36 Compare November 16, 2021 07:28

thomas-nguy changed the title ~~Draft: middleware support for ICS20~~ [WIP] middleware support for ICS20 Nov 16, 2021

thomas-nguy changed the title ~~[WIP] middleware support for ICS20~~ middleware support for ICS20 Nov 30, 2021

thomas-nguy changed the title ~~middleware support for ICS20~~ feat: middleware support for ICS20 Nov 30, 2021

Merge branch 'main' into thomas/add-middleware-support-to-ICS20

a019faf

fedekunze approved these changes Dec 28, 2021

View reviewed changes

modules/apps/transfer/ibc_module.go Show resolved Hide resolved

fedekunze and others added 4 commits December 29, 2021 15:59

fix and changelog

e18c29f

test fixes

5826f83

panic if middleware already set

13bb71e

fix

4d8f264

colin-axner reviewed Jan 3, 2022

View reviewed changes

AdityaSripal requested changes Jan 5, 2022

View reviewed changes

thomas-nguy closed this Jan 7, 2022

faddat pushed a commit to notional-labs/ibc-go that referenced this pull request Feb 23, 2022

Merge pull request cosmos#533 from CosmWasm/gas_525

e7526cc

Add cost and api cost options

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

feat: middleware support for ICS20 #533

feat: middleware support for ICS20 #533

thomas-nguy commented Nov 10, 2021 •

edited

Loading

lgtm-com bot commented Nov 10, 2021

thomas-nguy Nov 16, 2021

colin-axner Nov 30, 2021 •

edited

Loading

colin-axner Jan 3, 2022

thomas-nguy Jan 3, 2022 •

edited

Loading

thomas-nguy Jan 5, 2022

lgtm-com bot commented Nov 16, 2021

fedekunze commented Dec 28, 2021

fedekunze left a comment

lgtm-com bot commented Dec 28, 2021

codecov-commenter commented Jan 3, 2022

colin-axner commented Jan 3, 2022

colin-axner Jan 3, 2022

thomas-nguy Jan 3, 2022

colin-axner Jan 3, 2022

AdityaSripal left a comment

fedekunze commented Jan 6, 2022

colin-axner commented Jan 7, 2022

thomas-nguy commented Jan 7, 2022 •

edited

Loading

colin-axner commented Jan 7, 2022 •

edited

Loading

thomas-nguy commented Jan 7, 2022 •

edited

Loading

colin-axner commented Jan 7, 2022

feat: middleware support for ICS20 #533

feat: middleware support for ICS20 #533

Conversation

thomas-nguy commented Nov 10, 2021 • edited Loading

Description

lgtm-com bot commented Nov 10, 2021

thomas-nguy Nov 16, 2021

Choose a reason for hiding this comment

colin-axner Nov 30, 2021 • edited Loading

Choose a reason for hiding this comment

colin-axner Jan 3, 2022

Choose a reason for hiding this comment

thomas-nguy Jan 3, 2022 • edited Loading

Choose a reason for hiding this comment

thomas-nguy Jan 5, 2022

Choose a reason for hiding this comment

lgtm-com bot commented Nov 16, 2021

fedekunze commented Dec 28, 2021

fedekunze left a comment

Choose a reason for hiding this comment

lgtm-com bot commented Dec 28, 2021

codecov-commenter commented Jan 3, 2022

Codecov Report

colin-axner commented Jan 3, 2022

colin-axner Jan 3, 2022

Choose a reason for hiding this comment

thomas-nguy Jan 3, 2022

Choose a reason for hiding this comment

colin-axner Jan 3, 2022

Choose a reason for hiding this comment

AdityaSripal left a comment

Choose a reason for hiding this comment

fedekunze commented Jan 6, 2022

colin-axner commented Jan 7, 2022

thomas-nguy commented Jan 7, 2022 • edited Loading

colin-axner commented Jan 7, 2022 • edited Loading

thomas-nguy commented Jan 7, 2022 • edited Loading

colin-axner commented Jan 7, 2022

thomas-nguy commented Nov 10, 2021 •

edited

Loading

colin-axner Nov 30, 2021 •

edited

Loading

thomas-nguy Jan 3, 2022 •

edited

Loading

thomas-nguy commented Jan 7, 2022 •

edited

Loading

colin-axner commented Jan 7, 2022 •

edited

Loading

thomas-nguy commented Jan 7, 2022 •

edited

Loading