ICS27 v2

[crodriguezvega]

Spec changes for ICS27 v2 and their implementation in ibc-go are in the roadmap of the Interchain team for 2024. One of the main features of v2 will be to enable multiplexed interchain accounts (i.e. to allow many controllers to control many host accounts through a single channel). Initially requirements written by @womensrights for this feature can be found in this PR.

There are multiple teams interested in improvements to ICS27 and discussions are happening in different communication channels. In order to streamline the conversation, let's use this discussion to share and discuss problems with the current design of ICS27, use cases that builders would like to see supported in a v2 design, and design ideas.

Note: we are working on centralising discussions in the Cosmos discussion board, so this discussion might move there when the new board layout is finalised.

[zmanian]

A collection of thoughts.

1. Semi ordered channels can be built at the application layer out of unordered channels. It would be great to have a semi ordered channels in IBC 1.x but we can proceed with ICA v2 without depending on improvements in the transport layer.

2. I want some of atomic fill and execute primitive in ICA. ie. The execution of a message should be able to conditionally wait until funds arrive to execute the message and ideally the funds can actually be atomically reverted if the messages fail.

3. I'd like the option of being able to speak an abstract operations language to Cosmos SDK chains with verbs like Stake, send, vote etc that aren't tied to the implementation of a specific Cosmos SDK version.

4. We should explicitly target EVM, SVM and non Cosmos SDK chain in ICA 2.0

[bpiv400]

Agreed with all of this except I don't think its essential in the fill&execute model if the funds can't be reverted if the messages fail.

For other messaging layers that don't have ack protocols, integrators and contracts need to handle what to do in these cases and can't easily revert funds -- since these protocols lack an ack.

ICA v2 can do better, but I wouldn't view it as a blocker for shipping something.

[blasrodri]

These are all features that we find very valuable. We are, and have been implementing models on top of IBC to fulfill certain cross-chain needs, and having robust + battle tested primitives like these would greatly help us.

Happy to start porting some of our designs to use this logic, and give feedback on the way.

[zmanian]

Adding a link to the semi ordered accounts issue.

#872

[womensrights]

One clarification for 3. - would this be in the sense that the controller doesn't have to be concerned with the state machine that the account is hosted on and the host chain deals with executing the correct message type for that specific action? So rather than having the message type constructed and encoded correctly for the host chain on the controller chain, there is some kind of mapping on the host chain for a generic action?

[ohadbachner]

About 3 @zmanian we are actually do it Nomos, talk with me if you want more info

[bpiv400]

This honestly looks really good and seems to reflect most of the pain points I've heard.

I think we should make sure the Composable, Landslide, and Union teams take a look at the requirements, since they're extending IBC to these other ecosystems that Zaki mentioned.

I'll share this with them and the other teams that I've heard with significant painpoints with V1 to see if they have any requirements to add.

[ohadbachner]

Hey all, it's Ohad from the Nomos team here. We recently facilitated the creation of over 220k Interchain accounts requested by Xion to Injective, and during this process, we encountered some issues that I'd like to share with you.

Quick background on us:
Nomos is dedicated to building Super accounts, essentially facilitating chain-to-chain abstractions. We empower users to seamlessly connect different dApps across various chains while managing tokens for gas and enabling them to stay on their preferred chains. Our approach involves utilizing technologies like IBC, ICA controller, and more, also building SDK for developers and Multisig for teams.

When we launched the campaign with Xion, we developed a simple proof of concept (POC) allowing users to mint NFT collections
Wrote by @kmchmk
on Injective with just one click, all without leaving Xion. The project consisted of three main steps:

1. User login: Users create a Xion wallet by logging in with their email.
2. ICA account creation on Injective: Utilizing the cw-ica-controller contract, a channel is initialized from Xion to Injective for each user.
3. NFT minting: Upon clicking the "Mint NFT" button, the packet is sent through the channel, relayed by the relayer, and users can view their NFTs on the frontend.

However, we encountered challenges due to the unexpectedly high number of users:

• We anticipated a few thousand users but received 220k account creations within 2-3 days.
• The relayers faced difficulties with channel handshakes, including race conditions and duplicated packets.
• The Hermes relayer prioritized channel handshakes over NFT minting transactions, resulting in only 6k+ successful NFT mintings out of 220k accounts.
• The process of scanning all 220k channels upon relayer startup caused significant delays.

Our suggestions moving forward include: work together on this with (@srdtrk ,@kmchmk, @rafaelChelo, @isakfm )

1. Opening multiple channels to create many ICAs from one channel.
2. Integrating ICQ and ICA into the same channel (already in progress).
3. Implementing queuing mechanisms for relayers to optimize packet selection.
4. Exploring solutions for crossing IBC to different chains that are not Cosmos SDK-based. (ready work with some team on that we are build a "like" ICA contract from the other side currently evm and encoding the messages, but if we want to work from EVM -> cosmos SDK we need to that ICA can create from non Cosmos sdk cw or EOA.)

We are already in discussions with Union, Landslide, Toki, and Picasso, keeping them updated on our progress. If you have any questions or would like to further explore these developments, please feel free to reach out to me on TG: ohadbachner.

[kostovster]

Hey @ohadbachner,

Pleasure to meet you. At Nolus, we utilize ICA in a similar manner—manage a high volume of accounts/channels and we've faced the same challenges you've described above.

For some issues, we might have temporary solutions that can be beneficial to all:

• Channel handshakes blocking the relayer queue can be an issue not only when opening a new one, but also after timeouts and channels need to be reopened. Since this issue does not heavily impact unordered ICA channels (presuming channels do not timeout), it did not make sense for us to report it. Instead, we made a simple "dirty" patch: a forked version of the relayer that appends a short sleep after executing messages involving opening new or timeout channels and prioritizing new messages that enter the queue.

• Channel scanning is something that we've also managed to resolve for the time being by running our own relayer infrastructure on bare metal. For comparison, we have roughly 100k channels that, in a normal situation, take 1+ hour to scan, whereas on bare metal, it takes less than 2 minutes.

[ohadbachner]

Hey there, it's great to reconnect! Yes, I believe we've crossed paths before. I appreciate your kind words about our work, thank you. Regarding your question, our solution is designed to handle high traffic volumes efficiently, even within short periods. We've implemented various strategies to ensure scalability and performance, so I'm confident that our solution can effectively manage spikes in traffic. If you'd like to explore more about how our solution addresses these challenges, I'd be happy to provide further details. Let me know if you're interested!

[clemensgg]

Hi all, CryptoCrew is working on this as a relayer operator. @kostovster this super interesting, can we possibly use these learnings to improve wide spread relayer software like hermes? Could you link your relayer fork repo pls?

[clemensgg]

A little more context from the operator's perspective can be found in this post mortem we created for the Nomos test

[kostovster]

Hey, @clemensgg .
Here is a link to the fork: https://github.com/nolus-protocol/hermes. Please bear in mind that it was a quick and dirty fix and is not documented. I'll loop you in a chat with our developers should you have any questions on the matter.

[iamnathanwindsor]

Thank you, @crodriguezvega and the Interchain team, for starting this important discussion on the evolution of ICS27. As the CEO of Landslide, the IBC connection between Avalanche and the IBC-enabled ecosystem, the proposed upgrades in ICS27 v2 are highly relevant and exciting for our work.

The multiplexed interchain accounts feature, allowing many controllers to manage many host accounts through a single channel, could be a game-changer for Landslide. Reducing the overhead of managing individual channels for each account would enable us to provide a more efficient, user-friendly, and scalable interop experience. We're stoked to explore how this can simplify account management, optimize transaction fees, and unlock new cross-chain application designs.

We built:
1.) a CosmWasm VM without Tendermint consensus
2.) an EVM VM

Both will be shared with the community as soon as possible, targeting June 2024.

The future of IBC on Avalanche
ICA will become really important as we integrate with the Avalanche "Vryx" VM, detailed here.

Vryx is a fortified decoupled state machine replication construction that provides a path to scale the throughput of each Avalanche HyperSDK blockchain instance to over 100,000 TPS.

This means that interchain Accounts (specifically AI agents) can control potentially thousands of accounts via a single key pair on any IBC-enabled chain.

So ideally, the expanded scope of ICS27 v2 to target EVM chains like Avalanche and Cosmos SDK chains, aligns perfectly with Landslide's mission and would greatly facilitate our integration. The proposed atomic fill and execute primitive is another promising enhancement that could enable more robust cross-chain transactions for our users.

We appreciate the call for Landslide, Composable, and Union (whom we are in touch with) to review the ICS27 v2 requirements. We're committed to actively participating in the design discussions to ensure the new spec supports our unique use case connecting Avalanche and the interchain. We also see great value in collaborating with other teams like @ohadbachner from Nomos, who are working on similar challenges at the intersection of IBC and non-Cosmos ecosystems. Learning from their experiences and technical suggestions will be crucial as we scale our own solutions.

While we recognize that multiplexed interchain accounts may have tradeoffs and challenges to address, such as increased complexity for relayers, the benefits around efficiency, user experience, and composability are well worth pursuing. We're excited to contribute to the ICS27 v2 design process and help shape this critical piece of IBC infrastructure.

Questions for the community:

1.) @crodriguezvega, @zmanian: is there some tokenized incentive structure to maintain these channels?

Landslide would happily pay relayers in SLIDE tokens to maintain these channels.

2.) @crodriguezvega, What requirements would you like to see Landslide fulfill?

3.) What Cosmos SDK version is required for these channels?

This is the only resource I know that shows which chains run which SDK version.

Landslide is fully aligned with the direction of ICS27 v2, and we look forward to working closely with the Interchain team and the broader IBC community to make these upgrades a reality.

LFG 🚀

[ohadbachner]

Agree happy to work on this together!

[kostovster]

At Nolus, a novel money market where users have access to the underlying leveraged assets, we utilize a high number of ICA channels/accounts (currently 100k+), and multiplexed interchain accounts will greatly improve the UX and maintenance for us. All feature requests outlined by @zmanian will be more than welcomed, but multiplexed accounts alongside casual ordering will have the highest impact in our usecase.

[wheresaddie]

Glad to hear tokenized incentives for channel maintenance is something that could potentially be supported in the future, even if not directly in the ICS27 v2 spec. .. Id think @iamnathanwindsor will def explore this more on the Landslide side.

Regarding the key requirements to support v2:

1 Updating integrations for the multiplexed account model: Absolutely, this will be a priority. We want to ensure we are fully leveraging the efficiencies and UX benefits this enables.
2 Compatibility testing: def will test against the v2 spec and ref implementation to ensure compatibility .

Active inputs: (from the pov of the Landslide ecosystem group) we are more than happy to to provide feedback throughout the dev process. If offering any enhancement ideas that could benefit the spec is helpful, we are always available to provide inputs and hot takes...

I also appreciate the info on the likely ibc-go version that will include the v2. ,,, we'll keep an eye out for those details and Ill make a note for the Cosmos SDK upgrades accordingly to support.