Expanding the Interchain — taking IBC beyond Cosmos appchains
As some of you might not know, IBC (Inter-Blockchain Communication) is not limited to just blockchains built with Cosmos SDK; IBC is a blockchain-agnostic interoperability protocol, and it can be used with a wide range of blockchains worldwide.
IBC offers a unique and powerful framework for trust-minimized interoperability. And the impressive growth since its genesis is a testament to its security, composability, and extensibility.
Since IBC was originally developed within Cosmos, the majority of blockchains currently connected with IBC are Cosmos appchains. However, we are about to enter a world where many more blockchain ecosystems are connected with IBC, as a secure, fault-tolerant, universal interoperability protocol.
In fact, engineering work to expand the Interchain is well underway — with IBC connectivity being developed for Hyperledger Fabric, Hyperledger Besu, Corda, Near Protocol, Polkadot and Kusama chains.
This post covers these recent implementations and efforts to expand the use of IBC, the challenges we are facing and the potential solutions to those challenges.
How to make IBC available outside of Cosmos appchains
IBC provides a permissionless way for relaying data packets between blockchains to enable interoperability among them.
Unlike trusted bridging technologies, which require users to trust the third-party developers and/or operators of bridges, IBC operates as a trustless protocol — leveraging the security of the two chains it is connecting, with no third-party reliance, as it doesn’t depend on an intermediary to verify the validity of cross-chain transactions. That’s why IBC is recognized as one of the most secure ways of blockchain interoperability.
Unfortunately, the IBC protocol right now is a little complicated to expand to non-Cosmos appchains. To put it shortly, it requires two components below to make it possible to communicate via IBC between blockchains.
1. Core IBC implementations in the specific languages
IBC was initially written in Golang (ibc-go) as a Cosmos SDK module. The ibc-go makes it possible for blockchains built with Cosmos SDK to communicate with each other, but can’t make it for other blockchains, especially those which require implementing contracts and modules in other languages such as Solidity, Rust, etc. Those blockchains require IBC implementation in the respective languages.
2. Light client implementations to verify the consensus state of the blockchain
The verification of the other blockchain’s consensus state is provided by the light client in IBC. The light client can track and efficiently verify the state of the counterparty blockchain. As you might have already noticed, we need light clients for each consensus algorithm to verify the consensus of each blockchain. ICS (Interchain Standards) defines Tendermint Client, which allows us to verify the correctness of the Tendermint-based blockchains, but it is required to implement various light clients to support a variety of consensus algorithms each blockchain has.
IBC Core Logic
First, in terms of the IBC core logic, in addition to ibc-go, there are IBC implementations in other languages: the IBC implementation in Solidity (IBC-Solidity) and the IBC implementation in Rust (ibc-rs).
IBC-Solidity (IBC Implementation in Solidity)
IBC-Solidity is the IBC implementation in Solidity. With funding from Interchain Foundation, Datachain has been working on the implementation to enable trustless interoperability between the Cosmos-SDK blockchains and EVM blockchains. Datachain has contributed the code to Hyperledger Foundation as one of the primary software in a project called “YUI.” IBC-Solidity allows communication with EVM-based blockchains, including Ethereum, through IBC.
ibc-rs (IBC Implementation in Rust)
ibc-rs is the IBC implementation in Rust, mainly contributed by the Informal Systems team and the Composable Finance team. There is an increasing number of blockchains written in Rust, but for now, most use cases using ibc-rs are about connecting the Interchain and the DodSama ecosystem. For example, Centauri, contributed by the Composable Finance team, is a trustless bridging hub powered by IBC. Centauri initially started to connect the Picasso parachain and the Cosmos appchains, and they unveiled a demo of the cross-chain swap between those blockchains at Cosmoverse 2022. Also, they are in the process of expanding its ecosystem to Near. Brainjar, the Founder and CEO of Composable Finance, said that the first use case for Centauri will be the first trustless Kusama <> Polkadot bridge.
IBC Light Clients
As you can see on ibcprotocol.dev/lightclients/, there are various light clients for blockchains or consensus algorithms. I will show you below the major Light Client implementations, ecosystem by ecosystem.
Ethereum / EVM
As for Ethereum and EVM, tendermint-sol, which enables Tendermint consensus verification on EVM-based blockchains although it’s experimental, and ibc-harmony-client, which enables Harmony verification on Cosmos SDK-based blockchains, have been implemented. You can see a demo code to communicate between Cosmos appchainsand Harmony using IBC here. In addition, after the Merge, as Ethereum is now a PoS blockchain, the design of a light client for Ethereum is undergoing. The light client for Ethereum based on the IBC’s security model will be released not too far ahead. However, as some of you might know, the verification cost on Ethereum and EVM blockchains is one of the most significant problems connecting to those blockchains through IBC, so we need to fix the problem to realize it in the mainnet.
DotSama (Polkadot and Kusama) Ecosystem
With the ibc-rs implementation, bridges between the DotSama (Polkadot and Kusama) ecosystem and Cosmos appchains using IBC are also in progress. For example, Composable Finance is implementing BEEFY light client and GRANDPA light client, which enable verification of parachains in the Cosmos blockchains. The Composable Finance team has also implemented Pallet IBC, a module allowing IBC in Substrate-based blockchains. For the same purpose, Octopus Network is implementing Substrate IBC Pallet as well.
Enterprise (Consortium) Blockchains
As I previously explained in the post on the Cosmos Blog, IBC is also beneficial in the enterprise space because of its trust-minimized way of interoperability. For now, there are light clients for Hyperledger Fabric, Hyperledger Besu (IBFT 2.0 consensus) and Corda, which account for a large percentage of blockchains used in the enterprise space. Datachain is a core contributor to those light clients and teamed up with Mitsubishi UFJ Trust and Bank, one of the largest banks in Japan, to realize interoperability between Quorum and Corda using IBC.
Challenges IBC is facing and efforts to solve them
As described above, there are increasing numbers of IBC and light client implementations that could expand IBC to other networks. On the other hand, there are also some challenges that we need to solve to expand the IBC ecosystem: They are “verification cost” and “extensibility.”
The verification cost depends on the consensus algorithm for each blockchain and the availability of support for the cryptographic primitives required for verification. For example, when you attempt to connect Tendermint-based blockchains to EVM-based chains in which the Ed25519 pre-compiles are unavailable using IBC, the high execution cost (gas cost) is often a considerable problem. Especially for Ethereum, the gas cost would be impractically high.
The extensibility problem is, as explained previously, that it takes so much time to expand its network because it is required to implement various light clients on each chain to support a variety of consensus algorithms each counterparty blockchain has. It would be acceptable to connect just two blockchains; the number of light clients you need to implement is just two. It must be a massive problem if you want to connect more and more blockchains with each other; In this case, you need to implement hundreds of light clients.
However, there are ongoing projects and research work that will solve this high verification cost problem in IBC. LCP (Light Client Proxy) is one of the examples to solve this problem. LCP is a proxy middleware for light client verification. It adopts a “Proxy Method” that performs light client verification on behalf of a verifying chain and verifies its validity on the verifying chain. Someone feels it would add trust to the proxy system, but this is achieved by TEE (Trusted Execution Environment) to perform Light Client verification in the enclave, so it’s still a trust-minimized way of interoperability. The initial implementation of LCP uses Intel SGX, one of the most representative and tested TEEs.
Also, there is one more remarkable work to solve the problem: ZK-IBC. The central concept of ZK-IBC is that it constructs a zk-proof of Ed25519 signature validity and verifies the proof on EVM chains to reduce the verification cost. Both Electron Labs and Polymer Labs are working on ZK-IBC. It’s still in the PoC phase, and there are some practical issues, such as proving cost and the trade-off between verification cost and latency, but it will possibly be a breakthrough in the future.
Final thoughts
As seen in this post, there are lots of efforts and research that try to extend IBC to various blockchain ecosystems. According to Map of Zones, over 50 Cosmos appchains are connected by IBC as of November 2022 — an exponential growth since IBC was launched less than two years ago.
The Interchain will grow exponentially still when it becomes possible to communicate using IBC with EVM chains and the Dotsama ecosystem.
While verification costs and extensibility are challenging when applying IBC to some blockchains, they are now being solved through multiple efforts, such as LCP and ZK-IBC. Let’s move forward to create a world of interconnected blockchains by extending the Interchain.
Twitter: https://twitter.com/datachain_en
E-mail: contact[at]datachain.jp
