Agoric Contract IBC Middleware

[sufyaankhan]

What is the Problem Being Solved?

Ordinary ICS-20 IBC transfers use connections on the transfer port; these connections are handled by an ibc module provided by the interchain stack. It's not straightforward (or possible?) for the swingset network API to take over such connections. So in order for contracts to receive such messages, we need some other solution.

Description of the Design

Expose IBC go's Transfer App inbound packets to JS Smart Contracts, as a form of IBC middleware.

There are 3 pieces of work (boxes in RED in the diagram) that need to be implemented.

1. Agoric Contract Middleware

• Agoric Contract Middleware is a wrapper for IBC Contract app Channels. It intercepts inbound and outbound transfer packets.

• If a packet contains conventional memo fields that indicates an Agoric contract target, then forward the packet details and target information to x/vtransfer.

2. x/vtransfer

• This module simply forwards messages to swingset over the bridge device.

3. Transfer Notification Service

• Maintains a table of target names mapped to publishers.
• When receiving message from x/vtransfer, lookup the target in the table and publish the packet to the target.

Security Considerations

• For Transfer Notification Service - Registering or removing targets are privileged operations. (accessible by core-eval)
• Contract middleware must be robust so transfer is not impeded

Scaling Considerations

• Transfer Notification Services target collections should be durable, so that they will scale over time.

Test Plan

• Unit Test + Manual E2E testing (automated)

Upgrade Considerations

• Upgradable Transfer Notification Services

[dckc]

Problem

We need to expose IBC go's Transfer App inbound packets to JS Smart Contracts.

@sufyaankhan @michaelfig could you elaborate on that? Why do we need to do that?

cc @schnetzlerjoe

[dckc]

based on discussion with @sufyaankhan and @michaelfig , I gather the problem we're addressing is this:

Ordinary ICS-20 IBC transfers use connections on the transfer port; these connections are handled by an ibc module provided by the interchain stack. It's not straightforward (or possible?) for the swingset network API to take over such connections. So in order for contracts to receive such messages, we need some other solution.

[schnetzlerjoe]

based on discussion with @sufyaankhan and @michaelfig , I gather the problem we're addressing is this:

Ordinary ICS-20 IBC transfers use connections on the transfer port; these connections are handled by an ibc module provided by the interchain stack. It's not straightforward (or possible?) for the swingset network API to take over such connections. So in order for contracts to receive such messages, we need some other solution.

This would be correct! We (Calypso) COULD get away for now probably without but the concern with engineering within is that over time the uncomposability with the transfer port especially with PFM would draw away teams like Skip or create stray asset issuances. I.e: I use skip API to route asset, ends up on another port not transfer. Now uncomposable with Calypso or any other protocol on Agoric.

[dckc]

does anybody have a user story sketch of how this works?
maybe even a sequence diagram?

[michaelfig]

maybe even a sequence diagram?

@raphdev and I are discussing this today. There will be artifacts.

[raphdev]

I don't have detailed sequence diagrams, mainly modified versions of @sufyaankhan's diagrams as an aid for documenting architecture:

What exists today (as far as code, not on-chain):

Addition of transfer middleware:

And a view outlining kernel/cosmos boundary:

[dckc]

TIL: IBC middleware pre-dates this issue.

[raphdev]

I believe what we call "Agoric Contract Middleware" is the custom IBC middleware. Originally, the custom middleware and x/transfer were separate components, but they ended up being merged.