Cosmos-sdk: ICS03: Connection versioning for Handshake

Created on 20 Sep 2019  路  10Comments  路  Source: cosmos/cosmos-sdk

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
help wanted ibc

Most helpful comment

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

All 10 comments

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

@mossid What is the status of this?

The function just needs to be updated to increase it鈥檚 performance + add tests.

Is this still applicable? Seems like a small task.

This should be tested in conjunction with dynamic IBC, e.g. with CosmWASM, cc @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.

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 - https://github.com/cosmos/cosmos-sdk/issues/5846.

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

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

Yes.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

fedekunze picture fedekunze  路  3Comments

kevlubkcm picture kevlubkcm  路  3Comments

ValarDragon picture ValarDragon  路  3Comments

rigelrozanski picture rigelrozanski  路  3Comments

rigelrozanski picture rigelrozanski  路  3Comments