ICS03: Connection versioning for Handshake

[mossid]

getCompatibleVersion and pickVersion are defined under Versioning in ICS03. The current implementation includes version information in the datagram but lacks version negotiation. Both functions need to be implemented as a hardcoded function and called by the handshake functions.

TODO:

• Performance issues

[fedekunze]

@mossid (cc: @cwgoes) How would each hardcoded function look like?

[cwgoes]

@mossid What is the status of this?

[fedekunze]

The function just needs to be updated to increase it’s performance + add tests.

[jackzampolin]

Is this still applicable? Seems like a small task.

[cwgoes]

This should be tested in conjunction with dynamic IBC, e.g. with CosmWASM, cc @ethanfrey.

[ethanfrey]

Is version:
(1) version of IBC or (eg. 1.0)
(2) protocol name and version ( eg. ICS20-1)

Since this is done on a Connection level, not a Channel level, I assume it is (1). This has no effect on CosmWasm. If we have a similar discussion on the Channel level, that is very interesting. I can easily imagine for example, one contract that supports both ICS20 and some other custom protocol, and needs to know which one is intended when opening a channel.

[cwgoes]

Ah yes, you are completely correct - this particular issue is for connection-level versioning, but we should also ensure that our implementation of channel-level versioning is up to snuff - #5846.

[cwgoes]

Specifically, what we probably want is:

• Handshake initiating chain supplies list of compatible versions
• Handshake receiving chain chooses version from list (or set of versions / features)
• Handshake initiation chain agrees

Then both chains agree on version string ~ featureset.

Also, we should

• Pick a fixed version string for 1.0
• Perhaps add channel types (ordered, unordered) for features

[colin-axner]

should an error be returned in OpenTry if the chain decides it cannot support any of the provided versions from the counterparty list?

[cwgoes]

Yes.