Dynamic capability & routing implementation

[fedekunze]

• Implement ADR03 - Dynamic capability store.
• Fix routing.
  Apparently we assume that ModuleName == PortName in MsgPacket, this is just wrong. Instead we need a routing table mapping port owners to module names.

[cwgoes]

@alexanderbez Are you interested in working on this 🙏 ?

[alexanderbez]

@cwgoes yes. WRT to routing, is it enough to pass a router to the IBC module that handles package/msg route to module message handler?

[cwgoes]

We could architect it that way, I don't have a strong preference. The important part is simply that IBC packets get routed to the module which owns the port to which the packet is addressed.

[cwgoes]

After #5828 the next step is to update x/ibc to use the dynamic capability keeper in accordance with the spec, and add a routing mechanism as described above - perhaps @AdityaSripal can help with that - I'll also try to clarify the spec a bit with respect to the ADR 3 API.

[cwgoes]

Basic routing mechanism:

• The SDK needs to implement channel handshake callbacks as per ICS 26 (and see usage example in ICS 20) that allow modules to run code during the handshake process, negotiate versions, and claim channel capabilities. Initial routing for ChanOpenInit and ChanOpenTry must be based on which module owns the port capability to which the channel is being opened, while routing for ChanOpenAck and ChanOpenConfirm must be based on which module owns the channel capability (which was created during one of the first two steps). Modules must store the channel capability under an appropriate name so that they can look it up automatically (e.g. based on the channel & port identifier) - if they do this, no user interaction should be required, the relayer should be able to send all the transactions as it does currently.
• The SDK needs to implement an IBC-specific router which will route packets to the module which owns the channel capability associated with the channel & port to which the packet is addressed. Technically, the way the spec is written, if multiple modules own a channel capability, they should all be able to send & receive packets on the channel, but we can safely assume that only one module will own the channel capability for now.

If we do want to implement support for multi-owner capability routing, either the call pattern has to be reversed (modules have to call into the IBC handler, rather than vice versa), or we need to implement some way for a module which is one (of many) owners of a capability to claim the "routing slot", which is singular. I don't think present use cases require this, though (dynamic IBC does not require this, at least not at the moment).

[alexanderbez]

Can we go with the simpler approach of routing to a single module while we design a cleaner approach for multi-owner/module routing?

[cwgoes]

Can we go with the simpler approach of routing to a single module while we design a cleaner approach for multi-owner/module routing?

I think that's fine for the time being.

[AdityaSripal]

The SDK needs to implement an IBC-specific router which will route packets to the module which owns the channel capability associated with the channel & port to which the packet is addressed. Technically, the way the spec is written, if multiple modules own a channel capability, they should all be able to send & receive packets on the channel, but we can safely assume that only one module will own the channel capability for now.

Currently because single owner ports can't be enforced at the capability level, unless we force modules to release after transfer. I am enforcing this property in the routing module. Even if port capabilities are owned by multiple modules. The router will only map portID to a single module name at any given point for now

[cwgoes]

Closed by #5888.