Scalable version queries

[colin-axner]

Summary

Querying for an application version is currently unsupported (during handshakes). My initial thoughts indicate that there are two solutions:

• modifying the module interface to return the supported versions
• supporting gRPC routes for every application version

Both have their draw backs and (2) isn't scalable. I'd like to give this some more thought to determine if there's a way we could abstract it so that it can scale without introducing more constraints required for IBC execution

---

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged/assigned

[colin-axner]

To close this issue, we should modify the application module interface by adding another function. This function should perform application version negotiation and return the version to be used in the OpenTry step.

The relayer will choose the initial version in the OpenInit step, this will likely be chosen by the user controlling the relayer or by the application which triggers the OpenInit step (interchain accounts)

The version submitted in the OpenInit step will be submitted as an argument to the function being adding to the module interface. The function should look at the version selected in OpenInit and return the matching version to be used for OpenTry. Applications may choose to implement this in however fashion they choose.

ICS20 would simply return the "ics20-1" or perhaps an error if the counterparty version is unsupported. Assuming a second version of ICS20 eventually arises, we may expect this negotiation only to return a valid version if the counterparty version is supported. So if the counterparty used "ics20-1" in OpenInit, it returns "ics20-1". The same would be true if it used "ics20-2". If the counterparty used an unsupported version, say "ics20-5", then an error should be returned

ICS27 would have similar version negotiation. Assuming ICS27 also decides to interject the host chain account address into the version, then we would expect this function to generate interchain account adddress using the counterparty port ID and append this to the existing version (or use the associated protobuf version)

This function signature may look something like:

func NegotiateAppVersion(ctx sdk.Context, portID string, counterparty channeltypes.Counterparty, counterpartyVersion string) (version string, err error) 

The name may be different (I haven't given it to much thought atm). I left off channelID in the function signature since it may not be known in advance by a relayer, but the portID should be known. I'm unsure if we should include the connection hops as well

We should assume some applications may return versions based on current state and thus access to the context may be useful

We also want to add a gRPC to 05-port which specifies an standard gRPC relayers can use which routes the request to the appropriate module callback. This way each module does not need to define their own gRPC

[seantking]

wdyt about adding this to the interchain-accounts milestone?

[colin-axner]

wdyt about adding this to the interchain-accounts milestone?

No preference, but this change should be made to the main branch

[seantking]

@damiannolan the version string passed into OnChannelOpenTry will look like ics27-1-<interchain-account-address>

[damiannolan]

I'll include the ICS27 version negotiation as part of #378 targeted for the interchain-accounts branch