IBC: Expanding Polkadot’s Interoperability

By James Lofgren

It’s been an exciting few weeks in the Polkadot ecosystem, as a critical component of internal interoperability called Horizontal Relay-routed Message Passing (HRMP) channels are being opened across the ecosystem. Although this is a big step forward, there is still work to be done to fully deliver on the promise of interoperability in Polkadot. This technical deep dive will explore how native solutions within Polkadot allow the Relay Chain to be a Layer 0 solution between parachains and how the flexibility of Polkadot's SDK, Substrate, is being used to implement two universal cross-chain messaging languages to connect Polkadot to a world of other blockchains: IBC, the DeFi standard in external operability, and XCM, Polkadot's own format.

And so, let’s dive in!

The following key protocols and formats enable interoperability within the Polkadot ecosystem:

With an interconnected framework, and a shared trust in a common Relay Chain, interoperability between parachains has been a strong selling point as protocol teams determine where to build their projects. This shared security model also provides a unique opportunity to optimize the communication methods between the participating parachains through the use of Horizontal Relay-routed Message Passing (HRMP, or often referred to as XCMP-Lite within the community) and Cross-Consensus Messaging (XCM), Polkadot’s universal messaging format for internal and external interoperability. In simple terms, HRMP is an internal transport protocol that deals with how messages are sent and received between parachains, while XCM is the format used to express meaning to the receiving chain. It is fairly common to hear this message passing capability referred to broadly as XCM, but it’s important to understand that the XCM format can be used regardless of which transport protocol carries the message.

The shared trust of Polkadot is enabled by the way that consensus is reached within the system’s architecture. Within the current framework of HRMP, all XCM between parachains are stored on the Relay Chain itself and the validity is confirmed. Due to this storage requirement, all HRMP channels require a small bonded deposit (currently set at 10 DOT) on the Relay Chain and opening a channel is approved by on-chain governance. This bond is also used to reduce message spam and unnecessary channels being opened and is subject to slashing.

It should be noted that HRMP is a stop-gap protocol being used until the release of XCMP (Cross-Consensus Messaging Protocol). Once XCMP is released, the use of HRMP will be deprecated and will allow messages to be passed between parachains without routing them through the Relay Chain, instead utilizing validity proofs and a queuing mechanism for collators to route XCM messages directly to the appropriate inbound and outbound parachains.

To understand interoperability within Polkadot and between blockchains outside of its ecosystem, it’s important to understand the current scope of HRMP, as a communication method between parachains. As with any process optimization, HRMP relies on a set of assumptions to take advantage of its design, such as the shared security of a common set of validators on the Relay Chain. This protocol also defines the scope of network topology between the sending and receiving chains, such as “Chain A and Chain B are both parachains who share a common Relay Chain.”

An important distinction is that although HRMP is used for internal communication, the XCM format can be used to convey meaning using any transport protocol, including HRMP, XCMP, bridges, relayers, postcards, carrier pigeons… literally anything! The XCM format exists outside of the method used to relay the message.

To learn more about the inner workings of XCM, I highly recommend this article written by Dr. Gavin Wood.

The design of this optimized messaging protocol provides parachain teams enormous benefits such as:

• Enables true programmability between parachains, where the apps, products, and functionality of other parachains can be fully integrated

• Allowing teams to focus on their unique value proposition rather than re-inventing communication primitives between parachains

• Teams can confidently rely on how messages should be sent

• Communication requires no new trust assumptions

The first HRMP channels were recently opened between parachains on Polkadot enabling use cases that were previously not possible such as transferring DOT and other assets between parachains natively, rather than relying on wrapped tokens through bridging. This has already been beneficial to holders of DOT who can now use it across DeFi applications on smart contract platforms such as Moonbeam. One of those applications is Moonwell, a lending protocol created by Coinbase Cloud alumnus Luke Youngblood, which was among the first to leverage xcDOT when Moonwell Artemis launched on June 22nd!

HRMP is deservedly receiving a lot of attention right now for advancing Polkadot’s “internal” interoperability. However, it is thanks to Substrate, the modular blockchain SDK that Polkadot and Kusama were built from, and its well-designed architecture that the ecosystem gears up to leverage IBC to extend this interoperability to other exciting ecosystems.

We’ll be discussing the following protocols used to enable external cross-chain communication beyond Polkadot:

It’s not by coincidence that teams focused on interoperability identified the modularity of Substrate as fertile ground to grow cross-chain applications.This modularity is what gives Polkadot a canvas to not only create chains with independent designs, but also the ability to leverage best practices and protocols from other networks. As a result Polkadot is home to some of the first teams outside of Cosmos working towards integration with IBC, an interchain communication protocol pioneered by the team at Interchain GmbH.

While conceptually the modular approach of both Polkadot and Cosmos are similar, their approach to shared security has been a key differentiator between them. Both Kusama and Polkadot implemented shared security before parachains were launched, which allowed projects to inherit the security of the entire network, but delayed the introduction of core functionality required for parachain interoperability. 

In contrast, the Cosmos ecosystem provided teams the tools to create independent blockchains, but left the security of the network as an implementation detail of the individual chains. It should be noted that Cosmos is actively working towards an Interchain Security model, but currently all Cosmos chains are effectively “external” to each other, making the need for trustless communication between external chains a critical priority from the very beginning.

In the absence of a shared security model within Cosmos, the Interchain GmbH worked with teams across the ecosystem to define a cross-chain messaging protocol, the Inter-Blockchain Communication (IBC) Protocol, which was released in April of 2021. Notably, the IBC protocol was designed to send arbitrary messages between chains without any assumptions of the underlying network topology or introducing additional trust requirements beyond trusting each chain itself. 

In order to enable trust-minimized communication between different chains, IBC messages are facilitated by permissionless relayers using IBC-TAO who monitor specific channels for outgoing messages in a queue from the sending chain and pass these messages to the receiving chain. Anyone is able to become a relayer, and it’s only required that a single relayer is available to pass messages in a channel.

The process of relaying can be completely trustless, because within IBC, a light client implementation of the opposite chain’s consensus mechanism is also required for the blockchains themselves to confirm the validity and inclusion of the messages coming from the relayer. This light client implementation is what allows the receiving chain to confirm the validity and inclusion of the message on the sending chain, without relying on the relayer to be honest. When using IBC, security always reduces to the security properties of the light client, and does not possess security guarantees of its own.

While homegrown solutions like HRMP and XCMP are foundational for Polkadot’s “internal” interoperability, the ability to integrate with IBC will also unlock “external” blockchain ecosystems for native interoperability with Polkadot.

Though the majority of connections using IBC have been between blockchains built using the Cosmos SDK, the IBC protocol can be implemented within any blockchain that achieves deterministic finality. This finality is an important requirement, as each chain must be certain that a transaction they have verified on the opposite chain will not be reverted. Within Substrate, this finality is achieved through a consensus mechanism pallet called Ghost-based Recursive ANcestor Deriving Prefix Agreement… or  GRANDPA for short. Though this finality gadget works well for validators within the Polkadot network, the use of only GRANDPA would not be well-suited as a light client implementation on IBC.

Knowing the requirements in IBC for light client consensus mechanisms and the limitations of GRANDPA alone, teams such as Octopus Network, Composable Finance, and Polymer Labs have been working with the Interchain Foundation to create light-client implementations of Parity’s Bridge Efficiency Enabling Finality Yielder (BEEFY) protocol intended to pair with Substrate’s GRANDPA finality mechanism to enable light client functionality on other chains. Using light client implementations of BEEFY and GRANDPA, the consensus mechanism of Polkadot can be implemented within an IBC module to confirm the validity and inclusion of messages from Substrate-based chains.

With a generic light client implementation of BEEFY, this opens the possibility of parachains and independent Substrate chains to interoperate with the Cosmos ecosystem in a trust-minimized and secure way using IBC. Having access to both XCMP and IBC will allow teams to optimize communications dependent on their destination, using out of the box parachain-to-parachain communication through XCMP, and IBC or XCM for any communication outside of the parachain / Relay Chain network.

When looking at the capabilities of XCM as a format, it can be used even with IBC as the transport layer, to become a standard in how chains can express meaning to each other. Through the expansion of definitions, these messages could be utilized not just for fungible asset transfers, but also use cases such as NFTs, passing Decentralized Identity credentials, executing staking operations, or participating in governance actions. As a “language” XCM maintains the ability to continually adapt.

Polkadot held their successful token sale in 2017 on the promise of shared security and easy, secure interoperability. As Coinbase Cloud, we’ve had a front row seat to their progress as we’ve proudly supported Kusama and Polkadot since day 1.

From its inception, Polkadot has been designed with an adaptable and flexible framework, capable of implementing innovations from throughout the industry while underpinned with a shared security that would be difficult for other ecosystems to replicate.

We take great pleasure in not only congratulating the community on the launch, but highlighting the incredible work by teams within the Polkadot ecosystem in building home-grown, and leveraging well-known, interoperability solutions to come as close as we’ve seen to “solving” interoperability!