The Multi-hop IBC upgrade will take IBC to Ethereum and beyond

The State of Interoperability is Broken

Blockchain interoperability is broken across the ecosystem. Protocol fragmentation, multi-sig bridging, and centralized oracles are all key issues that have yet to be effectively addressed. Since 2020 DeFi Summer, the industry has further fragmented and increased developer friction with an ever increasing number of competing standards and solutions.

Comparing interoperability solutions across all ecosystems, IBC is miles ahead of the competition in security and decentralization. Most believe that IBC can only serve the Cosmos, but Polymer envisions IBC across all chains as the de-facto interoperability standard.

The Future of IBC

Because of its rigorous security standards and specifications, IBC is not natively compatible with all major blockchains which has prevented industry-wide adoption. Below, we’ll discuss some key areas of improvement that Polymer is tackling to upgrade IBC functionality and expand the IBC network across the industry. We invite you to join us in this journey and provide feedback on how to improve IBC together as a community.

Inefficient → efficient connections

Gas costs for running IBC state and transport logic in the EVM are impractically expensive. Multi-hop IBC enables routing through optimized IBC router chains like Polymer which provide efficient connectivity via ZK-IBC connections to ecosystems such as Ethereum. Through ZK-IBC connections via Polymer, any IBC enabled module or smart contract connecting to a counterpart on Ethereum will become effectively the same as connecting to any counterpart on a Cosmos chain.

Dense → sparse network

IBC network topology has organically grown to be densely connected which results in redundant connections and poor scaling. Currently, IBC connections are 1:1 with IBC channels. With the Multi-hop upgrade, IBC connections can be 1:N with IBC channels. This change results in increased network efficiency, throughput, and capacity while still allowing all blockchains to directly communicate.

Dense versus sparse networks.

In mathematical terms, the blockchain topology changes from exponential O(N²) to linear O(N) growth in the number of connections. This dramatically reduces the cumulative overhead of maintaining connections across the entire network of chains.

Homogeneous → heterogeneous topology

IBC network topology has been homogeneous within Cosmos and has only supported one IBC connection type. Polymer is setting the foundation to shift IBC network topology from homogeneous to heterogeneous by bringing new chain types into the network. Additionally, modular blockchains such as Celestia will further diversify the number chain types by allowing for novel rollup designs. Polymer is adapting IBC’s design to make it thrive in this heterogeneous future.

Multi-hop Technical Summary

IBC currently requires direct chain <-> chain connections to establish channels for app messaging. The connectionHopsfield in the IBC channel definition is used to load connection ends. Currently, the allowed number of connection hops has been fixed to one, meaning chains must connect directly to each other to establish an IBC channel.

Multi-hop enabled IBC introduces the ability to define an IBC channel over pre-existing IBC connections. The benefit is that the effective channel connectivity of chains increases while reducing the number of required IBC connections. This allows connection aggregation and efficient routing paths within the Cosmos and efficient routing through Polymer to chains that may have expensive computation like Ethereum.

With multi-hop, IBC channels can be defined over Polymer as a middle connection hop, greatly reducing total connectivity costs while simultaneously connecting to any other connected chain. For example, one could set up an IBC channel over two hops such as Juno ←connection→ Polymer ←connection→ Ethereum.

In addition, increasing load on chains like Osmosis with a large number of inbound connections and channels is not scalable in perpetuity. Client state updates within a connection can crowd out compute space for other transactions at scale (e.g. a Cosmos where we have an ever growing number of chains). Multi-hop will help alleviate this scaling concern.

Technical Specification

At Polymer, we set out with a goal of designing a multi-hop protocol with the following properties:

• All IBC channel handshake and packet messages should be able to utilize pre-existing connections
• Relaying for a multi connection IBC channel should not require additional writes to intermediate hops
• No additional module or middleware requirements
• Minimal additional required state and changes to core and app IBC specs
• Retain desired properties of IBC connection, channel and packet definitions
• Retain backwards compatibility for messaging over a single connection hop
• Intermediate connected chains are not required to upgrade to multi-hop IBC

The high level intuition behind our approach is as follows:

• IBC connections already embed the consensus state of the counterparty chain
• A chain of IBC connections forms a doubly linked list of pointers to each other
• Relayers can prove a chain of IBC connections using a chain of merkle inclusion proofs
• Dapps can commit a message on the source chain and relayers can prove the commitment through a chain of proofs instead of making writes to intermediate connection hops

See below for a visual representation of how IBC connections form a multi-hop IBC channel path from a sending → receiving chain. Each consensus state holds a reference to the next chain in the channel path.

The chains in a channel path form a set of linked state roots by virtue of their IBC connections.

The relayer queries the sending chain (chain0) for a proof of packet commitment. It then queries each subsequent chain for proof of consensus and connection state to establish the relationship described in the figure above. In plain terms, relayers first prove the relationships between the chains starting from the destination to the sender. Lastly, on the sending chain, we prove a specific packet commitment.

Relayer multi-hop proof queries.

Multi-hop proof data and proving logic forms a recursive structure as seen below. There can be any number of connections in the middle step. The proving logic will remain the same but the amount of proof data will increase linearly.

Multi-hop proof verification logic.

An Ecosystem Collaboration

Polymer is currently collaborating with Aditya Sripal (Interchain) and Manuel Bravo (Informal Systems) on the review and acceptance of the spec. Jack Zampolin (Strangelove) is making the go relayer changes necessary to support querying for multi-hop proofs.

How to Contribute

We currently have an open spec PR and an open implementation branch. For those looking to contribute, we welcome comments and feedback on the spec and implementation! We envision a future where IBC is the de-facto open-source standard for interoperability and would love to work with those who share our vision. Check out our open roles here.

About Polymer

Polymer is the first modular IBC networking protocol. The Polymer chain will enable ZK-IBC connectivity across all integrated chains with a trust-minimized architecture based on light client state proof verification. Polymer believes in a multichain future connected primarily by one open-sourced, community-developed, and maintained industry standard, IBC x Polymer.

Follow our Twitter, visit our Website, and join our community on Discord!