ICS28: Channel initialization should have a timeout

[mpoke]

Closes #832

[AdityaSripal]

I think this needs some more discussion. How do you prevent the TRY from succeeding after the timeout exceeds on INIT? How should the consumer chain react if this occurs?

[mpoke]

I think this needs some more discussion. How do you prevent the TRY from succeeding after the timeout exceeds on INIT?

The TRY will fail at the following line (see https://github.com/cosmos/ibc/blob/74444db64bbd4c3645f49e4780dca0a5cff843c5/spec/app/ics-028-cross-chain-validation/methods.md#ccv-pcf-cotry1):

// verify that the underlying client is the expected client of the consumer chain
abortTransactionUnless(chainToClient[clientState.chainId] == connectionEnd.clientIdentifier)

How should the consumer chain react if this occurs?

The consumer should eventually shut down. The handshake will not be successful.

[AdityaSripal]

It doesn't seem like it would?

Because there is a height for which the INIT is valid, so the TRY can be submitted with that height as the proof.

The INIT timeout is also measured against the initializing chain. So the timeout might occur without the TRY chain noticing.

Seems like a race exists, we designed packet timeout with the counterparty time to explicitly avoid this race

[mpoke]

It doesn’t seem like it would?

Do you refer to the TRY failing or the Consumer eventually shutting down?

Because there is a height for which the INIT is valid, so the TRY can be submitted with that height as the proof.

It’s not about the proof. TRY will fail after the channel initialization timeout because the chainId will be removed from chainToClient when the consumer chain will be stopped, see StopConsumerChain.

The INIT timeout is also measured against the initializing chain. So the timeout might occur without the TRY chain noticing.

Note that the channel initialization timeout of Interchain Security is not a timeout for the INIT part of the channel handshake. It's a timeout for the entire handshake. This timeout is on the provider side. The INIT is always on the consumer. Thus, the TRY chain will always be the provider, which for sure will notice a timeout occurring.

Seems like a race exists, we designed packet timeout with the counterparty time to explicitly avoid this race

Not sure that I follow.

[AdityaSripal]

Ahh ok, I misunderstood the proposal. One I mistook TRY for being executed on the consumer chain. Also it seems like you will remove the consumer chain if the full handshake is not complete by a certain time.

My remaining question is still what happens to the consumer chain in this case. What will happen if it is stuck on INIT or OPEN (after ACK) when the provider chain has removed the consumer chain

[mpoke]

My remaining question is still what happens to the consumer chain in this case. What will happen if it is stuck on INIT or OPEN (after ACK) when the provider chain has removed the consumer chain

It gets stuck. It needs social consensus to deal with it: either restart the process to be a consumer or start as a sovereign. I guess we could implement some sort of Interchain Query for the consumer to query the provider and see if it was kicked out. What do you think?

[AdityaSripal]

No let's not introduce a new application to handle this edge case. Social consensus is fine, I think there should be a note in the spec to mention this