composite channel types / bundled packets

[hxrts]

Motivation: composite channels allow for atomic delivery of various IBC message types in a single packet, as well as unification of acknowledgments and callbacks. Composite channels also enable simultaneous delivery of multiple fungible token denoms.

A composite channel can be created from multiple base channel types, after a concrete channel of each type has been instantiated, eg. a specific ics-20 and ics-27 channel. Composite channels inherit the traits of constituent base channels, satisfying the least common constraint behavior, so composing an ordered channel with an unordered channel will result in an ordered composite channel (for this reason it’s important to relax the base ICA behavior to unordered to avoid over-constraint). Because composite channels can only further constrain behavior it is safe to establish a composite channel permissionlessly.

A composite channel does not break composability with the underlying channel types, rather it performs routing to those respective channels, requiring base channel routing information for each message, thus fungible tokens from an existing ics-20 channel could be sent through a composite channel that includes that channel id and remain fungible. A trivial composite channel can be established specifically to enforce further ordinal constraints eg. assuming the base behavior of ICA was unordered a composite channel could be created with a strict ordering condition if required for a given application.

Credit: ics-999 from @larry0x + conversations with @0xekez and @womensrights

Edit: changed title to reflect added discussion of bundled packets

[ValarDragon]

Why is this a property of a channel

This moreso fees like a definition problem. Define a packet as the minimum atomic unit on any channel. Then you just want a way to logically bundle multiple packets into a single packet.

Just make a new packet type bundled_packet, which is constituted by other IBC packets. The processing logic for bundled_packet is to for loop run full IBC processing logic for each constituent packet.

[hxrts]

enabling packets to abstract over multiple channels seems like a more radical change to the IBC spec, but I'm open to it. this would make IBC packets act more like sdk transactions that support multi-messages.

[womensrights]

I guess the desired behaviour is to have atomic execution of packets that have come from different application modules so if you had a bundled_packet, to reach the desired behaviour of transfer + action generically the packet would require packets from different application modules where the channel has different packet semantics. So the bundled_packet would solve the multiple denoms concern, as you could bundle a packet with the foo and a packet with the bar token, but this wouldn't cover the atomic transfer + action concern as it would be much harder to bundle packets from different channels.

[jackzampolin]

why not have an application protocol that allows for handling of multiple different type of application packets?

[hxrts]

@ValarDragon do you imagine ordering still being defined on the channel level with bundled_packet? I don't yet have a fully developed opinion about the best way to approach composition of ordering strategies because there is a real tradeoff between developer ergonomics and the expressivity of a blocking primitive.

[assafmo]

This sounds like a good idea. In my mind this is equivalent to a tx that has multiple messages, so maybe this should be an abstraction over a connection rather than a new channel type?