IBC v2

[womensrights]

Summary

IBC v2 simplifies and improves IBC retaining the positive elements - light client based security model, the packet life cycle, permissionless relay, whilst removing many of the negative elements - high complexity, poor extensibility and upgradability.

Problem Definition

Large Resource Requirements to bring IBC to a new ecosystem

Whilst IBC has successfully connected hundreds of ComeBFT (tendermint), and Cosmos-SDK based blockchains, it has been challenging to extend beyond these chains. The first IBC connection with a non-Cosmos based blockchain was introduced by Composable finance to connect to the Polkadot ecosystem which took close to 2 years of development time. Although possible, with such high resource requirements, it is practically unfeasible to further extend IBC's reach, and many chains interested in an IBC connection are deterred by this high resource requirement.

High Protocol Complexity

• Channel and connection abstractions add complexity for little benefit (more information detailed in this issue) and result in a lot of state to be written through the handshake processes before a useful action can be made by a user, e.g. send tokens.
• Many core types have to be parsed on chain, e.g. chainIDs associated with a given clientID, which is expensive in resource constrained environments
• High complexity generally makes it more difficult for new developers to onboard to IBC and use it

Difficult Upgradability

• To use new applications, e.g. ICS20v2 two chains need to coordinate and use channel upgradability. This requires governance and off-chain coordination. Additionally, the channel upgradability feature was complex and time-consuming to implement and increased the complexity of the protocol.
• Keeping the protocol backwards compatible with v1 hugely increases the maintenance burden and meant working around what was there, rather than designing for what makes the most sense. This slows down the speed of development to fit within such constraints.

Goals

• Reduction in development time to bring IBC to new ecosystems, including blockchains using an EVM
• Retain interoperability using a light client based security model
• Retain existing packet semantics (send, receive, acknowledge, timeout)
• Facilitate a migration that minimises disruption for existing IBC users

Proposal

A list of relevant resources are detailed:

• IBC Eureka Specification
• IBC Eureka alpha milestone

---

For Admin Use

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