Adaptive IBC: Extending IBC to All Blockchains

Octopus Network

Octopus Network is a multi-chain network built around NEAR Protocol. It was born to bootstrap and run appchains by providing developers with flexible leased security (LPoS), out-of-box interoperability, one-stop infrastructure, and a ready-to-be-engaged community to make it easier to innovate without the time-suck and labor involved in bootstrapping PoS security.

When designing Octopus, we were initially inspired by Cosmos’ interchain vision but took a different approach. We believe the Internet of Blockchains should be built around a public blockchain with a prosperous economy as the Hub. Appchains could share security from it and aggregate their trading liquidity into this Hub. This design philosophy was called the “Fat Hub Thesis,” and we chose NEAR Protocol as its home.

Because blockchain frameworks, such as Cosmos SDK and Substrate, provide an unprecedented colossal design space and tech-layer-depth agnostic optimization options, we focused our initial build on Substrate chains. We later released Octopus 2.0 to support Cosmos SDK chains.

From a high level, Octopus Network is quite a complex collection of smart contracts built on NEAR that facilitate shared security and interoperability among the appchains. From day one, any appchain launched on Octopus has interoperability with all NEAR apps and protocols. The v1 mainnet went live in Aug 2021, and v2 in Dec 2023.

NEAR IBC was a critical component for Octopus 2.0. Without NEAR-Cosmos trustless interoperability, implementing Octopus’ leased security protocol for appchains would be troublesome, if not impossible. Through developing a NEAR IBC, we came up with a design useful for connecting any heterogeneous chains — Adaptive IBC, which we discuss in more detail below. Adaptive IBC is our contribution to the interchain ecosystem. It’s called “adaptive” because it adapts to heterogeneous blockchains and the evolution of verification methods.

Why IBC?

The root reason for the recurrent security issues with cross-chain bridges is that any single team must resist the collective strength of attackers worldwide. With the collaborative effort of the open-source community, sustainable cross-chain security can only be achieved through the continuous enhancement of open protocols.

The IBC protocol invented for the interchain is the first open and general-purpose interoperability protocol for blockchain. Its layered architecture and open-source strategy allow IBC to support feature-rich, trustless cross-chain interoperability, making it the gold standard for cross-chain protocols.

In line with our philosophy of a more open, secure, and fair Internet, we adopted and built on IBC even before we initiated Octopus. In August 2020, the team, called cdot back then, received a grant from ICF to implement IBC on Substrate.

Our team proposed ICS10 of the Cosmos IBC specification and has been its maintainer since then. After that, we proposed ICS12, the NEAR Client, which is under review and will become part of the IBC protocol family if approved.

NEAR IBC

NEAR IBC is the basic implementation of the IBC protocol transport layer (IBC/TAO) based on the NEAR protocol. It also implements a fungible token cross-chain transfer (ICS20) to link the NEAR and Cosmos ecosystems and bring greater combinable space to the innovation of the blockchain Internet. NEAR IBC is based on ibc-rs, mainly implementing chain storage-related and protocol-level interfaces for on-chain data.

NEAR IBC allows any smart contract on NEAR to call IBC ports and set up channels with IBC-enabled chains such as Cosmos Hub, Osmosis, etc. Through these channels, users can send tokens. The Octopus team will implement more IBC application protocols, such as Interchain NFT and Interchain Account, on NEAR in the future.

In general, some of the characteristics and limitations of smart contract platforms make IBC implementation more challenging, requiring us to work on engineering solutions. Introducing all of the technical difficulties and specific solutions for implementing IBC/TAO and ICS20 on NEAR is beyond the scope of this article. A deeper article on implementing IBC with smart contracts can be found here. NEAR IBC addresses challenges like gas, sandbox limitations, and on-chain storage differences.

We adopted a design based on the NEAR sub-account mechanism for ICS20 asset management. In this design, sub-accounts are used to support cross-chain assets.

As depicted in the graphic below, the lower half of the diagram (highlighted green) represents the sub-accounts used to support cross-chain assets from NEAR to other chains. The upper half of the diagram (highlighted blue) represents assets from other chains to NEAR — with each asset assigned an Asset ID.

Adaptive IBC

After nearly four years of heterogeneous chain IBC development practice, while designing NEAR IBC, Octopus Network found a generic way to extend IBC to different blockchains.

Throughout the journey with IBC, we continued to encounter a conundrum: the unique characteristic of IBC that makes it trustless, the light client, also makes it challenging to extend IBC to non-Cosmos SDK blockchains.

In the IBC protocol transport layer (IBC/TAO), Chain A has a light client representing Chain B in its state machine, and Chain B also has a light client representing Chain A. The light client tracks the consensus state of the peer blockchain, verifying the block header and Merkle proof, confirming the legitimacy of cross-chain interactions.

Because Cosmos designed the Tendermint consensus (now CometBFT) with the light client in mind, there is a ready-to-use on-chain light client implementation for Cosmos SDK chains. However, other blockchains did not design their consensus with interoperability as a priority. Thus, no ready-to-use on-chain light client can run with IBC for other blockchains, such as NEAR Protocol.

Octopus set out to solve these challenges with NEAR IBC and has discovered a creative solution: Adaptive IBC. To illustrate the design, let’s consider the cross-chain interaction between NEAR and Cosmos chains.

Off-chain verification proxies and on-chain proxy clients replace on-chain light clients in the IBC stack. The Tendermint Verification Proxy maintains the consensus of the Cosmos chain, verifying all cross-chain messages and signing them with its key. The proxy client only needs to verify one signature on the NEAR side. The other direction follows the same practice.

We acknowledge that introducing verification proxies can be vulnerable in terms of security. That is why we built verification proxies on a public chain called the “proxy chain.” As long as the proxy chain’s security level is not lower than the security of the source and target chains, it doesn’t necessarily downgrade the overall system’s security.

Adaptive IBC is a vast improvement over multi-signature or other external verification cross-chain bridges. Those not entirely convinced by the Adaptive IBC design may argue that since verification proxies are needed, why bother with IBC? Why not simply build external verification cross-chain bridges?

Fair questions. Our response is that because IBC is an open, layered protocol, we can retain IBC interoperability while evolving the verification layer separately.

A living example is when we were about to finish the NEAR IBC testing, NEAR 4.0 SDK introduced the precompile of ED25519 signatures, which reduced the cost of Tendermint header verification by a few dozen times. So, we decided to replace the proxy client with a real Tendermint Client in Octopus 2.0, and it still went live on schedule.

In the future, once ZK consensus proof matures enough, the proxy client could be replaced by a ZK verifier. This type of upgrade will be fully transparent to upper-layer applications. Therefore, Adaptive IBC not only adapts to reality but also adapts to the future, always embracing the best technology available.

In Closing…

Octopus Network is not alone. Others, including Composable Finance, Data Chain, and Polymer, are working on heterogeneous IBC. We do not compete with each other. We have a similar vision and strive to contribute to the open protocol from different angles.

You are like us if you don’t expect one chain to fit all. You are among us if you don’t believe one chain should rule them all. Then, let’s work together to expand the interchain ecosystem and make the Internet of Blockchains a reality!

Suzanne Leigh is the Editor of Octopus Network. This article was written in collaboration with Louis Liu, CEO and Founder of Octopus Network.

Follow Octopus Network!

• Website: https://oct.network/
• Twitter: https://twitter.com/oct_network
• Discord: https://discord.gg/6GTJBkZA9Q
• Octopus DAO: https://forum.oct.network/
• Medium: https://medium.com/oct-network
• Telegram: https://t.me/octopusnetwork
• Youtube: https://www.youtube.com/@OctopusNetworkOfficial
• Github: https://github.com/octopus-network
• Docs: https://docs.oct.network/

Disclaimer: The information presented here is made available solely for general information purposes and is not investment advice nor a legal or financial recommendation of any sort. We do not warrant the accuracy, completeness, or usefulness of this information. Any reliance you place on such information is strictly at your own risk. We disclaim all liability and responsibility arising from any reliance placed on such materials by you or any other reader or by anyone who may be informed of any of its contents. By mentioning any specific project, business, or other organization in this information, the maintainers of this blog/channel/platform do not express endorsement unless explicitly stated.

Adaptive IBC: Extending IBC to All Blockchains was originally published in Interchain Ecosystem Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.