Async channel version negotiation?

[michaelfig]

Hi,

I'm asking here to gather ideas around how to enable channel version negotiation to be performed asynchronously.

In ibc-go v7.2.0's ibc-go/modules/core-keeper/msg_server.go's ChannelOpenTry function has the following synchronous calls to determine the version and return it to the submitter:

	// Perform application logic callback
	version, err := cbs.OnChanOpenTry(ctx, msg.Channel.Ordering, msg.Channel.ConnectionHops, msg.PortId, channelID, cap, msg.Channel.Counterparty, msg.CounterpartyVersion)
	if err != nil {
		return nil, sdkerrors.Wrapf(err, "channel open try callback failed for port ID: %s, channel ID: %s", msg.PortId, channelID)
	}

	// Write channel into state
	k.ChannelKeeper.WriteOpenTryChannel(ctx, msg.PortId, channelID, msg.Channel.Ordering, msg.Channel.ConnectionHops, msg.Channel.Counterparty, version)

	return &channeltypes.MsgChannelOpenTryResponse{
		Version: version,
	}, nil

For the Agoric chain, it is desirable to have the version negotiation initiated by cbs.OnChanOpenTry serviced by an async (possibly across several blocks) JS smart contract call, finally resulting in a separate k.ChannelKeeper.WriteOpenTryChannel. In the absence of this feature, I have to (hackishly) just assume that the msg.CounterpartyVersion is acceptable, return it to the tx submitter, and crash later if the JS contract would have negotiated something different.

Is there a way to make this part of the handshake implementable async, similar to how the k.ChannelKeeper.WriteAcknowledgement can be done in a later block than when the RecvPacket transaction is handled?

I don't have a clear suggestion for how to accomplish this without a relayer-breaking change.

Thanks for any advice you can offer!

[michaelfig]

@AdityaSripal, @colin-axner I'd appreciate your opinions on this.

[crodriguezvega]

@AdityaSripal and @colin-axner are on holidays right now. I will check with them when they're back. How urgent is this for you? Can you manage with the workaround for now?

[crodriguezvega]

This is the same as the problem you describe in this issue in the spec repo, right?

[michaelfig]

This is the same as the problem you describe...

Oh, yes! I had totally forgotten about that issue, and it seems rather stale, but does describe the problem very clearly. It would be great to have more discussion in it.

How urgent is this for you?

I'm not expecting immediate resolution, but it would be good to know that there is at least a plan in place for how to solve this, and to get it into a development cycle (whether as an Agoric PR, one of our partners' work, or via the core IBC team). It's currently a gap in our dIBC system, and I don't want to be caught off-guard when somebody tries to use dIBC in this way.

[michaelfig]

@crodriguezvega, the spec change is merged in cosmos/ibc#1019. Would it be possible to schedule the ibc-go changes to implement it?

[crodriguezvega]

Hi @michaelfig. Let me discuss this with the rest of the team and we will come back to you.

[michaelfig]

Is there any update on this?

[AdityaSripal]

Hi @michaelfig , the functions for the message state checks, the callbacks, and the state write are already split out into their individual functions.

So each handshake msg server takes the following form:

k.ChannelKeeper.ChanOpenInit(...)

version, err := cbs.OnChanOpenInit(...)

k.ChannelKeeper.WriteOpenInitChannel(...)

In the default msg_server provided in ibc-go these calls happen synchronously.

However, Agoric should be able to write its own custom message server that uses these subcomponents asynchronously as it already stands. Thus the Write call (and thus any event emission that a relayer will need) only happens once the callback asynchronously returns and triggers a write.

This would of course, require a different wiring of the subcomponents then what we have in ibc-go; but it shouldn't be impossible to write as-is for the Agoric architecture.

Have you tried writing a custom message server to handle this case?

The handshake msgServer should do something like:

k.ChannelKeeper.ChanOpenInit(...)

// this will run asynchronously and trigger a WriteChannel sometime later
cbs.OnChanOpenInit(...)

You should be able to call the handshake callback. Then when the contract is ready to return its version, it needs some endpoint on Agoric that it can call to write the channel

// after application finishes callback it must call some custom msg server endpoint that writes the channel
// if it is indeed the application that initially received the callback (use capabilities)
msgServer.WriteOpenInitChannel(version, capability)

This would require some custom implementation and wiring on your end, but I don't think you need to rely on assuming the counterparty version is the same or anything like this.

We could possibly provide a WriteChannel callback natively in ibc-go; similar to how we have WriteAcknowledgement and then change our message server to accept the channel handshake callbacks writing an empty string and wait for the Write to happen later.

However, this would get quite complicated with our current middleware flow and isn't really relevant for other users.

If this is something you can do by writing your own message server to wire up the ibc-go subcomponents asynchronously; I think that would be the best option. I can help with reviews. And once we simplify our own middleware architecture (it is next after ics20-v2); we can make this change on our msg_server more easily

[michaelfig]

Thanks for your reply, @AdityaSripal. The reason I have baulked at writing a custom message server is that our chain also uses the standard ibc-go message server for the Golang IBC modules we use alongside our JS IBC modules.

I don't understand the message server flow well enough to know if having two independent handshake message servers would cause problems, or if I'm better off forking ibc-go and implementing the "similar to how we have WriteAcknowledgement" feature until we can integrate a version of ibc-go that has your new middleware architecture.