IBC Eureka

[womensrights]

Summary

Eureka 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

[yihuang]

this looks awesome.

1. how can we help?
2. Is it part of the plan to support connecting ethereum with ibc?
3. any ideas how to create light client for ethereum or rollups?

[womensrights]

Exactly that is the plan, we will connect ethereum with IBC, you can check out the solidity work and zk tendermint light client as well. We don't have light clients for rollups just yet, but in the future we will.

[yihuang]

@womensrights just curious, what do you guys think about eth rollups finality, I think we have to wait for L1 finality for security, but that duration could be very long, or we need to trust the L2 operator, or we'll make it optional for people to choose?

[womensrights]

@yihuang indeed to be able to verify an IBC packet commitment, you would need to wait for finality and this is problematic for optimistic rollups where that takes 7 days. Given that waiting 7 days is unacceptable for end users, I think it is best to have some kind of party, e.g. a solver take on the risk of finality (within what they see as acceptable) in exchange for a small fee to enable a reasonable waiting time for the user. However this is not super scalable given it requires fronting liquidity. This is less of a problem for zk rollups so I think this will be the dominant design long term, and you already see optimistic rollups looking into zk. You might be interested to take a look at this rollup guide on the specs repo for some more useful context