[go: up one dir, main page]

Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ICS-27-v2 #1122

Draft
wants to merge 33 commits into
base: main
Choose a base branch
from
Draft

ICS-27-v2 #1122

wants to merge 33 commits into from

Conversation

sangier
Copy link
Contributor
@sangier sangier commented Jul 4, 2024

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.

Copy link
Member
@AdityaSripal AdityaSripal left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Contributor
  1. 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
Copy link
Contributor Author
sangier commented Aug 19, 2024
  1. I definitely agree.

  2. For 2 I can think of an extra reason.. but maybe my thinking goes too much in an ideal world:
    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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants