ICS-27-v2

[sangier]

Opening this Draft PR for early review purposes. The spec is still a WIP and can be significantly improved, so any feedback will be much appreciated.

The ICS-27 version 2 specification adheres to the requirements defined here.

What is missing:

• Message blacklist mechanism for the host chain.
• Encoding negotiation consideration in channel handshakes
• Extra TODOs in spec.

What can be added:

• Delete hostAccount mechanism for controller chain. (Should be easy to implement given the proposed hostAccountId management)

I would like to thank the community for participating in the discussions here and in the ICA-Working-Group, @womensrights for gathering the requirements, @AdityaSripal for the internal discussions and the Penumbra team for the inspirational proposal.

[AdityaSripal]

Thanks @sangier

A couple thoughts.

1. We can remove the channel handshake handlers here
2. Why does the controller account need to control multiple accounts on the host chain. Seems like we can simplify if there is a single host account per chain for a controller account
3. Can we just have a generateAddress helper on the host chain that we can rely on?
4. Perhaps we also should give the ability to register a specific account type during registerInterchainAccount

[womensrights]

2. Why does the controller account need to control multiple accounts on the host chain. Seems like we can simplify if there is a single host account per chain for a controller account

Some context, that for Stride, they have a single controller for 4 host accounts per ICA deployment

[sangier]

1. I definitely agree.

2. For 2 I can think of an extra reason:
   Imagine you're Bank X. Imagine your clients want to use services A,B,C,D on Bank Y. However as Bank X you offer two separate services: (A+B) and (C+D). So for n accounts you want only to use (A+B); while for m accounts you want to use (C+D). For Bank X would be convenient to setup a unique ica-account for all its n client that wants to subscribe to use (A+B) on Bank Y and another unique ica-account for the m clients that wants to subscribe to (C+D).
   So basically you would group your clients subscriptions to external services using different ica-controllers.
   Additionally, If you're a Bank, n/m can be really big numbers. Having a 1-1 relationship may be a limitation.

3. I see your point and agree we can do that.

4. Mmm, not sure how, but maybe the protocol could even be account type agnostic?