ICS 4: Channel & Packet Semantics

[cwgoes]

Primarily a port of the original IBC spec.

Will cover:

• Channel semantics
• Required data structures
• Standard encoding formats
• Pseudocode algorithms for packet handling

[cwgoes]

Connection specification split into #3. Packet specification split into #24.

[cwgoes]

To-do in spec:

• Define channel data structure which must be kept in state (probably needs to be provable)
• Define channel negotiation handshake
• Define possibilities for bidirectional-relay (four channels), unidirectional relay (two channels)
• Define difference between enabling/disabling receipts
• Enumerate security guarantees
• Reference connection primitives as defined in ICS 3

[cwgoes]

Datagram formats that need to be defined here (that I can think of so far):

Opening handshake:

• CHANOPENTRY - try to open a channel
• CHANOPENACK - acknowledge & finalize a channel

Closing handshake:

• CHANCLOSETRY - try to close a channel
• CHANCLOSEACK - acknowledge & finalize a channel close

[mossid]

• Channel data structure also needed to be generic, there are some merkle tree implementation, for example merkle patricia tree, that the user cannot specify the position of the packet to be stored
• I suggest to define a channel only from one side (like a pair of (PacketQueue, ReceiptQueue)) instead of all queues on both chains (like (PacketQueueA, PacketQueueB, ReceiptQueueA, ReceiptQueueB)). The channels are symmetric on both side so we can just define a channel as a pair of one-side channel...
• The channel on both side should have same configuration; such as receipt enabled, type of packets allowed, expiration time, logic goverening the channel, etc. We should contain that information in the handshake message.

[cwgoes]

Handshake:

• Originating module init
• Destination module try (open), (timeout => reset)
• Originating module ack (open), (timeout => reset)

[cwgoes]

Actually I think a three-way handshake is better so some data can be conveyed / agreed-upon easily.

[cwgoes]

Kinds of ordering:

• SEQUENTIAL (exactly-once, ordered queue, track with index)
• PARALLEL (exactly-once, unordered, track with accumulator)

[cwgoes]

Kinds of channel:

• BIDIRECTIONAL - shared reference string, one queue per chain, tx/rx on both chains
• UNIDIRECTIONAL - shared reference, one queue on sending chain, tx on A, rx on B

Bidirectional queues can only be created on bidirectional connections. Unidirectional queues can be created on (the right direction of) unidirectional connections or on bidirectional connections.

Queues are always owned by single modules.

[cwgoes]

I think we will avoid receipts in the core IBC spec for now, I do not think they are fundamental.

[cwgoes]

I think storing full packets or just commitments can be an option on the channel level.

[cwgoes]

Goals of channel handshake:

• Originating module
• Destination module
• Modules can negotiate some arbitrary data ("version") as part of handshake
• Safe to send packets once complete, will be processed (how to deal with possible timeout?)
  Maybe wait for first packet sent by originating module before allowing dest. module to send.
• 1-1 channel established once complete, no other modules can use
• Usual asynchrony assumptions

[cwgoes]

Questions

• increment sequence on packet timeout (require ordering there) too?
• worth doing unordered channels
• reverse mappings for client => connection, connection => channel (for safe closure)?
• is txrx / tx / rx worthwhile? could also do at module layer presumably
• clarify the module calling pattern

[cwgoes]

Ah, unordered channels are much better if you use an extra accumulator.

I think we can punt unidirectional channels until we have unidirectional or broadcast connections.