You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
To be clear about the original solution: This was a proposal intended to allow a more complex version negotiation for ICA with minimal disruption to core IBC. NegotiateAppVersion was a helper function added to the Application interface that relayers could optionally use to determine the correct versions to place into the handshake messages. It was not a necessary part of the application semantics, but made the handshake process smoother for automated relayers. Thanks to @damiannolan for his work on this.
But as @ethanfrey points out, if we are willing to make more substantial changes to core IBC; we can still simplify the process for relayers and remove this helper function NegotiateAppVersion from the required interface for application developers.
Taking the feedback into account we propose the following changes:
Deprecate Version from the ChannelOpenTry message. If the relayer is going to specify a particular version, it should be the INIT relayer choice that determines the ultimate version; not a combination of INIT relayer choice and TRY relayer choice. Note: we will not remove the field as this is a breaking change, we will simply ignore the inputted value.
Change OnChanOpenTry to return version string, err error. Core IBC will then set the channel struct with the version chosen by OnChanOpenTry
This makes NegotiateAppVersion unnecessary for the ICA workflow. We plan to make the above changes before the final release of ICA to ensure that we can remove NegotiateAppVersion from the interface before it gets real world usage. This will minimize the technical debt, as we can remove it immediately without going through deprecation.
Another set of changes can be added to further simplify the process but can be added at a later time:
Change OnChanOpenInit to return version string, err error. If the relayer passes in a non-empty version string, then INIT callback should return error if that version is not supported. If the relayer passes in an empty string, then INIT callback should return the default version string signifying all of the versions that it can support. If there is no "default version" for a particular application, the application should return an error.
Currently relayers hardcode the versions that they pass in for apps like ICS20. As the number of applications on-chain increase, this is unsustainable. Relayers will want to open channels for a particular port, without even understanding what application that port corresponds to and what version string they should be passing in. Passing in an empty string is effectively an "unopinionated" relayer opening a channel. The channel version may simply be negotiated from the set of versions INIT chain supports and the set of versions the TRY chain supports.
This still leaves the option of "opinionated" relayers choosing a specific version(s) by providing a non-empty version string.
This change requires some more thought and is not immediately relevant; so we plan to consider and implement this change after ICA release.
The text was updated successfully, but these errors were encountered:
My change doesn't modify core ibc in the sense of the protocol itself, but just makes full use of the fields. I do agree this is a minor breaking change to ibc-go applications.
I very much like the idea of "" version on channel init and letting the app decide. This allows a lot more flexible usage of this field.
Thanks to @ethanfrey for his feedback here: CosmWasm/wasmvm#269
To be clear about the original solution: This was a proposal intended to allow a more complex version negotiation for ICA with minimal disruption to core IBC.
NegotiateAppVersion
was a helper function added to the Application interface that relayers could optionally use to determine the correct versions to place into the handshake messages. It was not a necessary part of the application semantics, but made the handshake process smoother for automated relayers. Thanks to @damiannolan for his work on this.But as @ethanfrey points out, if we are willing to make more substantial changes to core IBC; we can still simplify the process for relayers and remove this helper function
NegotiateAppVersion
from the required interface for application developers.Taking the feedback into account we propose the following changes:
Version
from theChannelOpenTry
message. If the relayer is going to specify a particular version, it should be the INIT relayer choice that determines the ultimate version; not a combination of INIT relayer choice and TRY relayer choice. Note: we will not remove the field as this is a breaking change, we will simply ignore the inputted value.OnChanOpenTry
to returnversion string, err error
. Core IBC will then set the channel struct with the version chosen byOnChanOpenTry
This makes
NegotiateAppVersion
unnecessary for the ICA workflow. We plan to make the above changes before the final release of ICA to ensure that we can removeNegotiateAppVersion
from the interface before it gets real world usage. This will minimize the technical debt, as we can remove it immediately without going through deprecation.Another set of changes can be added to further simplify the process but can be added at a later time:
OnChanOpenInit
to returnversion string, err error
. If the relayer passes in a non-empty version string, then INIT callback should return error if that version is not supported. If the relayer passes in an empty string, then INIT callback should return the default version string signifying all of the versions that it can support. If there is no "default version" for a particular application, the application should return an error.Currently relayers hardcode the versions that they pass in for apps like ICS20. As the number of applications on-chain increase, this is unsustainable. Relayers will want to open channels for a particular port, without even understanding what application that port corresponds to and what version string they should be passing in. Passing in an empty string is effectively an "unopinionated" relayer opening a channel. The channel version may simply be negotiated from the set of versions INIT chain supports and the set of versions the TRY chain supports.
This still leaves the option of "opinionated" relayers choosing a specific version(s) by providing a non-empty version string.
This change requires some more thought and is not immediately relevant; so we plan to consider and implement this change after ICA release.
The text was updated successfully, but these errors were encountered: