Allow Unordered ICA Channels

[srdtrk]

Summary

Currently, ICA only allows ordered channels. This causes the channel to close if a timeout occurs, forcing the user to reopen it.

Problem Definition

ICA only allows ordered channels because if ordering is not enforced, then the relayer could try malicious attacks by reordering/censoring some of the ica-controller's transactions. However, this requirement can be dropped because the ica-controller can choose not to send any new transactions until it receives an acknowledgement or a timeout packet.

Proposal

Tasks

Beta Give feedback

1. Remove the channel type = ordered checks from both host and controller #5522
   27-interchain-accounts +1
   
2. When a channel reopens the ordering and metadata must not change #5523
   27-interchain-accounts +1
   
3. Update ICA upgrade callbacks to remove ordering restriction #5524
   27-interchain-accounts +1
   
4. Check active channel is CLOSED when reopening an ICA channel #5580
   27-interchain-accounts +1
   
5. ICA host: check active channel is CLOSED when reopening an ICA channel #5629
   27-interchain-accounts +1
   
6. Allow specifying order in MsgRegisterInterchainAccount #5602
   27-interchain-accounts +1
   
7. Allow channel version to change in icahost #5605
   27-interchain-accounts state machine breaking +2
   
8. Write e2e test where unordered channel is used with ICA #5525
   27-interchain-accounts e2e +2
   
9. Write e2e test when an ordered ICA channel is upgraded to unordered #5534
   27-interchain-accounts e2e +2
   
10. Update ICA documentation with support for unordered channels #5526
    27-interchain-accounts docs +2
    

---

For Admin Use

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

[migueldingli1997]

This would be very helpful for our use-case as well. We are using ICA round the clock with low timeout values for the transactions (because we want them to pass in a narrow time range, or not pass). If there is any event that causes this timeout then we're suddenly stuck with a closed channel that has to be re-opened.

We're already keeping track of tx sequences anyways so switching to an unordered channel would be a breeze.

[womensrights]

Great to hear you are using ICA! Could you tell us a bit more about your precise use case if you are happy for it to be public? We had heard that ordered channels for ICA was a pain point for a few users but when we looked in more detail at the number of channel closures happening is actually really small. For example on Stride, the number of ICA timeouts has been 40/ 35,261 which is 0.11% of transactions since genesis and for Quicksilver it was 68 of 312,565 ICA txs since Jan. so approx 0.02% therefore the change would be a relatively small improvement it seems but would like to hear more about your own experience

[hxrts]

approx 0.02% therefore the change would be a relatively small improvement it seems

I think this may be due to survivorship bias. I know most relayers don't want to run ICAs because it's too error prone and complex. Devs have a much harder time building applications because ICA relay channels are harder to come by. You should speak to some of the devs from the recent Dora hackathon within the Neutron track at Cosmoverse. The challenge required devs to use ICA and most people gave up because it was too difficult.

[joe-bowman]

Quicksilver it was 68 of 312,565 ICA txs since Jan. so approx 0.02% therefore the change would be a relatively small improvement

'Small improvement' in percentage of overall terms, but the wasted hours of finding, fixing and working around channel closures has been an expensive past time :)

'Big improvement' in DevX.

[womensrights]

I'm not trying to disregard the pain of debugging the problem at all and certainly it is a DevX improvement, I just put the numbers there for context and I think its interesting to see. The changes to the spec required have already been merged, and the implementation work will be done sometime next year

[joe-bowman]

Apologies; it was not my intention to suggest so :) great to see the spec is merged, I’m looking forward to it!