Detailed Explanation of Adaptive IBC Heterogeneous Chain Cross-Chain Technology Route

Author: MiX

The IBC protocol proposed by Cosmos uses on-chain native light clients to verify cross-chain messages, meaning both parties in the cross-chain interaction maintain a native light client for the other side's chain on their own chain, thereby maximizing the security of cross-chain data.

The Cosmos SDK provides a Tendermint light client implementation for all blockchains based on the Tendermint consensus, so the cross-chain experience between Cosmos chains is smooth. However, for blockchains that do not use the Tendermint consensus, known as "heterogeneous chains," the journey of extending IBC to these chains is fraught with difficulties due to the lack of corresponding light client implementations.

On December 17, 2023, the second heterogeneous chain IBC developed by Octopus Network ------ NEAR-IBC was officially launched. The entire process, from project initiation and development to third-party auditing and official launch, took less than a year,and the key contributor behind this is the Adaptive IBC heterogeneous chain cross-chain technology route proposed by the Octopus Network team: Through innovations in the IBC technical architecture, it addresses the shortcomings of the IBC protocol in heterogeneous chain cross-chain interactions, greatly expanding the adaptability of the IBC protocol:

1. Various blockchains with different consensus mechanisms can adopt the Adaptive IBC technology route, such as Ethereum, NEAR Protocol, and Polkadot, etc.
2. It significantly reduces cross-chain costs, solving the biggest problem of extending the IBC protocol to heterogeneous chains.
3. It can adapt to advancements in various verification technologies; for example, once ZK technology matures, it can easily upgrade the proxy client to a ZK verifier.

For details on the milestones in the evolution of Adaptive IBC technology, see the appendix at the end.

|Basic Principles and Advantages of the IBC Protocol

The IBC (Inter-Blockchain Communication) protocol proposed by the Cosmos team is a completely open-source, general-purpose blockchain cross-chain interoperability protocol.

The key to cross-chain technology solutions lies in their "interoperability" and "security." The "layered architecture" and "open-source strategy" of the IBC protocol enable it to support feature-rich, trustless cross-chain interoperability, making it the gold standard for cross-chain protocols.

1. Layered Architecture:

IBC splits cross-chain interactions into "Application Layer" and "Communication Layer," with its simplicity and flexibility likened to the TCP/IP protocol of blockchain, as stated on the IBC official website: IBC draws inspiration from the foundational protocol TCP/IP that built the internet.
Figure 1: IBC is the TCP/IP protocol of blockchain

• The application layer is the cross-chain interoperability interface for end-users: it includes multiple independent application protocols such as token transfers, inter-chain accounts, and inter-chain queries. These application protocols are composable, and as the number of application protocols increases, cross-chain capabilities can improve exponentially.
• The communication layer defines the sending and receiving of data across chains, including transmission, verification, and ordering, while the content of the transmitted data remains opaque. The light client within the state machine of the source chain is key to the communication layer and becomes the essence of IBC.

Figure 2: IBC Technical Architecture

Chain A has a light client representing Chain B within its state machine, and Chain B also has a light client for Chain A. The light clients track each other's blockchain consensus data by verifying block headers and Merkle proofs, thereby validating the legality of cross-chain interactions.

There is a Relayer between the two cross-chain parties, responsible for monitoring Events generated by both blockchains. Once an IBC Event is received, it converts it into an actual IBC message and transmits it to the opposite chain.

In simple terms, the IBC protocol first establishes a secure channel between two blockchains, then transmits data packets, with the light client verifying the consensus information of the other blockchain, ensuring the consistency and security of the transfer. Therefore, as long as the communication layer is established, the entire IBC cross-chain interaction is secure.

2. Open Source Technology

Anyone can use the IBC protocol and contribute to it; there are no fees or hidden costs within the IBC protocol.

The frequent security issues with cross-chain bridges ultimately stem from the inability of a single team's security capabilities to withstand the entire hacker community. Only by using a common open cross-chain protocol and leveraging the collective power of an open community for continuous iteration and upgrades can the cross-chain security capabilities of the entire industry evolve. Louis, Founder of Octopus Network

Figure 3: IBC Cross-Chain Data
Data Source: mapofzones.com

As of January 15, 2024, the IBC protocol has been launched on 107 blockchains, with a total transaction volume of over $4 billion in the past 30 days and over 8 million secure cross-chain interactions. Of course, the vast majority of cross-chain interactions currently occur between Cosmos SDK blockchains.

Meanwhile, many teams are working hard to extend the IBC protocol to other ecosystems, hoping to achieve cross-chain interactions with heterogeneous chains through IBC, including Ethereum, Polkadot, NEAR Protocol, Avalanche, Solana, and Celestia rollups.

|Challenges of Extending IBC to Heterogeneous Chains

The architecture of the IBC protocol is based on light clients, so there is no need to introduce third-party verification services, achieving trustless cross-chain interactions. It has achieved an excellent balance of security, cost, and speed between Cosmos chains, but many teams have made visibly slow progress when extending to heterogeneous chains.

IBC and the Tendermint consensus mechanism were both proposed by the Cosmos team, so the Cosmos SDK has provided very good support for light clients since its design inception.

To implement the IBC protocol between Cosmos chains and non-Cosmos chains, it is necessary to implement a light client for the non-Cosmos chain on the Cosmos chain and a Tendermint light client on the non-Cosmos chain. Due to the differences in consensus mechanisms of heterogeneous chains, a significant amount of compatibility work is required during implementation, introducing corresponding technical risks.

This also means that heterogeneous chain IBC faces many technical challenges during implementation:

First, the verification of cross-chain messages on heterogeneous chains is costly and may have computational resource limitations/gas limitations:

Verifying cross-chain messages with IBC requires first verifying block headers, which usually involves verifying dozens or hundreds of signatures. Performing these calculations on-chain using smart contracts is very costly. On the other hand, whether it is Ethereum, NEAR, or other blockchains, there are limits and regulations on the available computational resources for smart contracts. This makes it easy for IBC to encounter issues with insufficient gas for verifying signatures.

The recently emerging zero-knowledge proof cross-chain technology converts many signatures into a single ZK proof, where verifying the ZK proof is equivalent to verifying all signatures of the block header, thus saving verification costs.

Second, the on-chain asset management mechanisms differ

The Cosmos SDK can register and operate on-chain assets through protocols, but this is not possible on smart contract blockchains, where fungible token data is managed by separate smart contracts.

Third, sandbox limitations of virtual machines

Current smart contract blockchains are based on virtual machines, which have limited capabilities to access the host chain in a controlled environment. For example, smart contracts cannot access the on-chain consensus state, and NEAR is an asynchronous chain where consensus state changes may occur across multiple blocks during smart contract calls, making it more complex.

Fourth, the rules for on-chain storage data differ

The IBC protocol requires strict storage key-value rules/path rules, and then retrieves cryptographic proofs based on the rules generated storage key-values from the chain.

These challenges and many more differences require development teams to perform additional engineering work, which will inevitably increase complexity and the risk of bugs.

|Principles and Advantages of Adaptive IBC

The key to the Adaptive IBC heterogeneous chain cross-chain technology route lies in innovating the layered architecture of the IBC protocol by further splitting out a "verification layer," introducing a "Verification Proxy" deployed on the proxy chain ( ICP ), so that both cross-chain parties only need to verify the proof generated by the "Verification Proxy," without needing to directly verify the block headers and all signatures of the other chain.

Figure 4: NEAR-IBC Architecture Based on Adaptive IBC

Taking NEAR-IBC as an example: Verification proxies for Cosmos and NEAR are deployed on the proxy chain, maintaining the consensus of the corresponding chains, and then a proxy client for the consensus mechanism of the other party is deployed on both cross-chain parties, replacing the original light client of IBC.

For example, when Cosmos sends a message to NEAR, the Cosmos verification proxy/Tendermint Verification Proxy on the proxy chain verifies the cross-chain message, signs it, and generates a proof. Then, the Cosmos proxy client/Tendermint Proxy Client on the NEAR side only needs to verify this proof to complete the cross-chain verification.

Figure 5: Security and Scalability of Cross-Chain Technology

In terms of security, although the introduced verification proxy belongs to an external verification scheme, theoretically, its security is slightly lower than that of native light client verification, it is worth noting that compared to native light client verification, the overall security does not significantly decrease.

This is because Adaptive IBC recommends deploying the verification proxy on public chains; for example, NEAR-IBC is deployed on the public chain ICP, ensuring both decentralization and public verifiability, as well as the security of the verification proxy and the entire cross-chain system. Figure 6: Two Perspectives on Cross-Chain Security

As long as the attacking cost of one of the cross-chain parties is lower than that of the public chain ICP, the introduction of the verification proxy will not compromise security due to the expansion of the trust set. Compared to multi-signature or other various external verification cross-chain bridges, the security level is much higher.

Thus, it can be seen that the verification proxy architecture of Adaptive IBC compensates for the shortcomings of the IBC protocol in heterogeneous chain cross-chain scenarios and greatly expands the adaptability of the IBC protocol from three aspects:

1. Significantly reduces cross-chain costs: From verifying dozens or hundreds of signatures of the other chain's block header to verifying just one signature of the verification proxy, it addresses the biggest pain point of IBC heterogeneous chain cross-chain interactions, namely "high verification costs and potential computational resource limitations."

2. Compatible with various consensus mechanisms: The verification proxy architecture does not impose dependencies on either cross-chain party and can be adopted by blockchains with various consensus mechanisms, such as Ethereum, NEAR Protocol, and Polkadot, making it a truly heterogeneous chain cross-chain technology solution.

3. Adaptable to advancements in verification technology: Adaptive IBC further splits the "verification layer" from the communication layer and evolves into a verification proxy scheme. One of the advantages of a layered architecture is to reduce interdependencies within the entire system, so Adaptive IBC can adapt to advancements in various verification technologies.

• If Cosmos can support aggregated signatures, or if NEAR supports ED25519 signature precompiles, it will significantly reduce the cost of direct verification on NEAR Protocol, allowing the proxy client to be upgraded to a truly usable light client.

• Once ZK cross-chain technology matures, the verification proxy can be replaced with a ZK prover, upgrading the proxy client to a ZK verifier. This can be seamlessly switched through community governance voting, without affecting the use of the application layer and the evolution of technology.

Adaptive IBC builds on the shoulders of giants, further promoting the advantages of the "layered architecture," designing a three-layer architecture of application layer, communication layer, and verification layer, allowing the verification layer to evolve independently, not only adapting to more blockchain consensus mechanisms but also embracing the best available technologies as verification technologies develop, adapting to future gradual evolution.

|Appendix

1. In 2020, the predecessor of Octopus Network, the Cdot team, received a grant from the Interchain Foundation to develop Substrate-IBC, i.e., ICS10.
2. In 2022, Substrate-IBC was completed, becoming the first team in the world to implement IBC on a non-Cosmos blockchain.
3. In October 2022, the Adaptive IBC heterogeneous chain cross-chain technology route was proposed, and the development of NEAR-IBC was initiated.
4. In October 2023, NEAR-IBC was completed and audited by the third-party security team Blocksec.
5. In December 2023, the Cosmos SDK blockchain Ottochain adopted the $NEAR Rstaking shared security service and officially launched. NEAR-IBC, as a key technology, validated the feasibility and scientific nature of the Adaptive IBC heterogeneous chain cross-chain technology route.
6. In the first quarter of 2024, the privacy protocol Secret Network will use the NEAR-IBC based on Adaptive IBC to achieve asset cross-chain interactions with NEAR Protocol. Subsequently, Octopus Network will continue to explore message cross-chain technology with Secret Network, allowing NEAR's smart contracts to directly utilize Secret Network's privacy computing capabilities.
7. In 2024, plans will be initiated to develop ETH-IBC based on Adaptive IBC, aiming to become the first team to provide users with an affordable IBC cross-chain experience between Ethereum and other IBC-supported blockchains.

|References

“The IBC Protocol 2023 Year in Review” Mary McGilvray
“Adaptive IBC: The Disruptor of Heterogeneous Chain Interoperability”Louis
“NEAR-IBC Introduction | How to Use Smart Contracts to Implement the IBC Protocol””Yang Zhen
“NEAR will be a Cosmos zone SOON”Louis