A Comparative Analysis on Interoperability: Subnets, Parachains, Zones

36 min readJan 26, 2023

On December 22, 2022, Avalanche reached an important milestone. After much anticipation, it finally introduced Avalanche Warp Message (AWM), a native communication protocol that allows Subnets to communicate. Experts are projecting that this new release will increase the competitiveness of becoming the number one interoperable blockchain.

Yet, just what is the mechanism behind AWM? What does AWM do, and how does it compare with the interoperability mechanism between Polkadot’s Parachains and Cosmos’ Zones?

This article will attempt to answer these questions by conducting a comparative analysis of the interoperability system between these emerging blockchain ecosystems: Avalanche’s Subnets, Polkadot’s Parachains, and Cosmos’ Zones. We will dive deep into each of their mechanics to examine how they function and assess their unique traits and limitations.

Parachains

Overview

Polkadot is a heterogeneous, Layer-0 network that connects multiple specialized blockchains into one unified network1. It achieves scalability through a sharding infrastructure, whereby blockchains are partitioned so that each validator node no longer has to process the entire network’s transactional load, and each validator only maintains information to its specific partition or shard. Technically speaking, this allows multiple blockchains to run parallel, called Parachains, that connect to a central chain called the Relay Chain.

(Source: https://wiki.polkadot.network/docs/getting-started)

Parachains are Layer-1 application-specific data structures that are globally coherent and validated by the validators of the Relay Chain2.

(Source:https://wiki.polkadot.network/docs/learn-parachains)

Polkadot is a shared or pooled security ecosystem where all Parachains connect and derive their security from the Relay Chain. The main takeaway is that all projects building on a Parachain would benefit from the economic security provided by the Relay Chain3. Since the Relay Chain acts as the de facto consensus mechanism for the Polkadot ecosystem, Parachains do not have to worry about maintaining their own nodes and consensus mechanism. Hence, all time and resources can instead be directed at building the project’s leading products and services.

Interoperability

Polkadot’s interoperability is very complex, but it can be divided between its Cross-Consensus Message (XCM) format, the Cross-Consensus Virtual Machine (XCVM), and Bridging Methods.

Cross-Consensus Message (XCM)

Parachains can communicate through Polkadot’s Cross-Consensus Messaging format or XCM. It is a generic format and aims to be the standard communication format for developers to define the data and origins between Parachains and different consensus mechanisms that their chains can send and receive from4.

(Source:https://polkadot.network/blog/xcm-the-cross-consensus-message-format/#-reserves)

XCM is not a protocol and does not send messages between Parachains. Alternatively, it is a format for how message transfers should be performed. Also, it is crucial to note that XCMP is not the same as XCM, which stands for Cross-Consensus Message Passing5. Whereas XCM is what gets delivered, XCMP is a delivery mechanism. XCM can be used between Parachains, smart contracts, pallets, bridges, and sharded enclaves6.

Polkadot has not one but three cross-chain protocols that utilize XCM messages between chains: UMP, DMP, and XCMP7.

UMP (Upward Message Passing) allows Parachains to send messages to the Relay Chain.
DMP (Downward Message Passing) allows the Relay Chain to pass messages down to one of their Parachains.
XCMP (Cross-Consensus Message Passing) allows Parachains to send messages between themselves.

Simply, XCM can be used to express a message’s meaning over any of these three communication channels.

XCMv3 is a significant upgrade and is expected to be deployed very soon. Once initiated, Parachians will benefit from additional functionalities, including support for bridging ( e.g., external networks), improved fee payments for operations, NFTs, and APIs for querying and invoking pallets on other chains8.

Cross-Consensus Virtual Machine (XCVM)

If XCM is what gets delivered, the Cross-Consensus Virtual Machine (XCVM) is a domain-specific virtual machine that provides a set of instructions by which XCM messages are composed9.

Put simply, a “message” in XCM is a program that runs on the XCVM. It is one or other XCM instructions. It includes several registers, as well as access to the overall state of the consensus system which is hosting it.

Interestingly, the XCM executor that follows the XCVM specification can be customized by developers or even ignored altogether and create their own construct that follows the XCVM specification10.

Bridges

Bridges are ways for two economically sovereign and technologically diverse chains to communicate with each other, and they can vary from centralized and trusted to decentralized and trustless protocols. While Polkadot tends to favor the latter, there is nothing impeding developers from building the former.

For a bridge to be compatible and function within the entire Polkadot ecosystem while still connecting to other blockchains (e.g., Ethereum), it will need to integrate the XCM message format.

This integration is a bridge with one of the following methods11.

Bridge Pallets

Bridge pallets are used for sending/receiving messages between Substrate-based chains12. A prime example is between Polkadot and Kusama, but this can extend to Parachains that use the Substrate programming language. Under this method, tokens can be natively transferred between them.

2. Smart Contracts

When sending/receiving tokens between a Substrate-based chain and a non-Substrate-based chain, for example, an Ethereum Virtual Machine (EVM) based chain, smart contracts will need to be deployed13.

3. Higher-order Protocols

This third method is for chains that do not support smart contracts, such as Bitcoin. Specifically, the XCLAIM protocol can be used to swap, but it would require the swappable asset to be backed by a collateral higher in value than the said asset14.

Advantages and Disadvantages

To summarize, Polkadot’s interoperability system is composed of three parts:

Cross-consensus Message (XCM) format — a delivery format that allows the creation of communication protocols between Parachains (XCMP) and the Relay Chain (UMP & DMP).
Cross-consensus Virtual Machine (XCVM) — a VM that provides specific instructions on how XCM messages are composed
Three bridging methods — protocols that transfer data and cryptos between various chains (either between Parachains or external blockchain ecosystems such as Ethereum, Avalanche, and others)

The XCM format has four distinct communication properties15:

Asynchronous: XCM messages in no way assume that the sender will be blocking on its completion.
Absolute: XCM messages are guaranteed to be delivered and interpreted accurately, in order, and in a timely fashion.
Asymmetric: XCM messages out of the box do not have results that let the sender know that the message was received. Any results must be separately communicated to the sender with an additional message.
Agnostic: XCM makes no assumptions about the nature of the consensus systems between which the messages are being passed.

This enables certain real use-cases16:

Request for specific operations such as governance voting.
Enables single use-case chains.
The option to include payment of fees (gas fees) on a target network for requested operation (more below).
Provide methods for three asset transfer models:
Remote Transfers: Control an account on a remote chain, allowing the local chain to have an address on the remote chain for receiving funds and to eventually transfer those funds it controls into other accounts in that same remote chain.

(Source:https://polkadot.network/blog/xcm-the-cross-consensus-message-format/#-reserves)

Asset Teleportation: Teleporting an asset happens by destroying it on the original chain and creating a clone on the destination chain (ie, Burn and Mint).

(Source:https://polkadot.network/blog/xcm-the-cross-consensus-message-format/#-reserves)

Reserve Asset Transfer: There may be two chains that want to nominate a third chain, where it can safely store a native asset that can be used as a reserve for that asset. Then, a derivative form of the asset on each of those chains would be fully backed (by the third chain), allowing the derivative asset to be exchanged for the underlying asset on the reserve chain backing it.

(Source:https://polkadot.network/blog/xcm-the-cross-consensus-message-format/#-reserves)

Given what we now know, what does all of this mean?

Firstly, given that the aim for XCM is for it to be customizable and utilized throughout the Polkadot ecosystem by design, XCM is an intentionally robust, abstract and general format. Developers can integrate it with minimal barriers to allow their Parachain to communicate and send/receive tokens with other Parachains. As previously mentioned, even the execution of the XCM format can be customized or built on an entirely new one, making it much more robust.

XCM is not just used for sending messages between chains. It can also be used for transacting with a chain whose transaction format you don’t necessarily know well in advance. This enhances the flow of communication within the Polkadot ecosystem.

Concerning the actual flow of communication, Polkadot’s interoperability system offers a variety of options for developers. While XCM provides a format for how messages and transfers of data are composed and received, the three Asset Transfer Methods and Bridging Methods described above provide a rich combination of communication options. Developers on a Parachain can combine either method as they see fit. For example, a Substrate-based Parachain can use the Bridge Pallet method to communicate and transfer crypto assets natively with another Substrate-based blockchain while using the Smart Contract Bridge Method to transfer tokens with non-Substrate-based blockchains in the form of wrapped versions. Moreover, it can integrate either of the three asset transfer methods into the two bridging methods.

To further demonstrate their robustness, while the Smart Contract Bridge method was designed for communication between a Substrate based and non-Substrate based blockchain, it is very well possible for developers to use the said bridge method to connect between Substrate-based blockchains, so long as both chains support smart contracts. The same can be said for the Reserve-based Transfer method. Although designed for the transfer of wrapped tokens, Parachains can utilize a third chain to hold in reserve the native token asset while its wrapped version is held or traded between users in different parachain ecosystems.

However, at present, only between Substrate based-Parachains can the transfer of token assets be done natively. Wrapped tokens are still being used between Substrate based and non-Substrate back blockchains.

Fortunately, attempts to address this are being made. The Moonbeam Network is one such example with a unique response. Although built on a Parachain, it has an Ethereum Virtual Machine (EVM). As such, users can interact with other EVM-compatible blockchains (via bridges) and Ethereum tools, and popular wallets such as Metamask. This is possible due to having an Ethereum-style address (H160 format) which is matched with a private key that is used to sign transactions on the Ethereum side17. Additionally, this address is mapped into a storage slot inside the Substrate Balance pallet to a Substrate-style address (H256 format). This means that users not only have an EVM wallet address but a Substrate address as well!

However, there is a catch. Because a user’s private keys are only attached to their EVM wallet address, they are not connected to their 256 Substrate address18. Thus, they are unable to sign transactions on the Substrate side. They would need a Substrate-style private key in order to sign transactions and participate on the Substrate side of the chain. Although possible, this divides a user’s account into two incompatible sections, which only fragments a user’s experience.

Moonbeam’s answer to this is their Unified Account feature. By standardizing this account to conform with the Ethereum H160 address and Substrate H356 address standards, users would only need a single H160 address and its single corresponding private keys to sign transactions and participate in dApps on both the Ethereum and Substrate chains.

This was made possible because Moonbeam developers created compatibility between a substrate-based token standard and an ERC-20 token standard; the XC-20 token standard. This standard is not a wrapped token per se, but are Substrate-native tokens that are made to look like and act as ERC-20 tokens on Moonbeam. This way, a user would not need to have two separate accounts, but can just add the Moonbeam network on their Metamask wallet for example, just like any EVM compatible blockchain, transfer any tokens such as DOT from the Polkadot network to Moonbeam via the XCM format as an XC-20 token, and can interact with any dApp on Moonbeam. Essentially, Moonbeam’s Unified Account bypasses the need for a bridge between Parachains.

Yet despite all of these advantages, Polkadot’s interoperability system does have its limits. Firstly, the XCM format was not designed for every system that supports XCM to be able to interpret any possible XCM message19. Some messages will not have reasonable interpretations under certain systems. Others might be reasonable, but are still intentionally unsupported by the interpreter either due to resource constraints or because the same content can be expressed differently. Hence, it is inevitable that it only supports certain possible messages. Furthermore, heavily resource-constrained systems (like smart contracts) may support only a very limited version of it.

Secondly, because of its abstract nature, XCM does not automatically include a gas fee structure. Should a payment fee structure be needed, developers will need to build and integrate it into the XCM format. This is not a serious hindrance, but it is an inconvenient step that needs to be overcome.

Thirdly, Polkadot’s interoperability is still under development. Apart from the aforementioned XCMv3 upgrade that is yet to be deployed, there are features/tools that Polkadot’s interoperability still does not support. For instance, in a somewhat recent debate thread on Polkadot’s Forum, it was mentioned (several times) for the network to be able to support BLS signatures20.

A BLS Signature is a cryptographic signature scheme that was created by Boneh, Lynn and Shacham that allows a user to verify if a signature is authentic21. The idea behind a BLS Multi-Signature scheme is that it aggregates many BLS signatures to a common message, or transaction. As such, it permits a diverse array of signature aggregation options far beyond any other known signature scheme, including Polkadot’s GRANDPA signature scheme.

To be fair, the network does have plans to incorporate this scheme in the future22.

Fourthly, interoperability within Polkadot is tied to the success and security of the Relay Chain. Since it has a shared security infrastructure, this means that much (but not all) of the activity going on, including the transfer of tokens/messages between Parachains relies on the Relay Chain for validating and securing transactions and messages. While this can allow Parachains to leverage the security of the Relay Chain, were it ever to shut down or suffer an exploit/hack, it could cause the whole ecosystem to cease activities, making this a potential single point of failure.

Finally, Polkadot’s interoperability is limited to the ecosystem’s inability to expand any further. At present, both Polkadot and its sister chain Kusama are only able to support 200 Parachains each. This limits the ecosystem’s interoperability to only around those Parachains. This is in stark contrast to Avalanche that can support an unlimited amount of Subnets, making interoperability between them have no limits.

Nevertheless, Polkadot has made great improvements to its interoperability system in the last year. Their final 2022 Roundup Blog outlines all of their achievements23. So long as they continue to further improve, Polkadot is well on its way to becoming one of the most interconnected ecosystems.

Zones

Overview

Cosmos is a heterogeneous network of independent parallel blockchains, each able to be powered by the classical Byzantine Fault Tolerance (BFT) consensus algorithm like Tendermint (now branded to Ignite). This structure allows the network to interoperate with each other and scale. The Cosmos network is divided between two classes of blockchains; Hubs and Zones.

(Source:https://tutorials.cosmos.network/academy/1-what-is-cosmos/2-cosmos-ecosystem.html)

A Hub is a blockchain whose purpose is to connect Zones while limiting the number of connections and preventing double-spend attacks among them1. The Cosmos Hub is the primary example. It was the first blockchain to be launched and is the intermediary between all other Zones that connect to it2. The Cosmos Hub provides crucial services to the blockchains connected to it, including the largest interchain token exchange, shared security through interchain security, bridges to Ethereum (ETH) and Bitcoin (BTC), and secure custodianship of digital assets. The Cosmos Hub’s primary token is the ATOM3.

Zones are application-specific blockchains (more on them later on) in the Cosmos Network. By connecting to Hubs via the Inter-Blockchain Communication Protocol (IBC), they can communicate with each other and initiate the transfer of tokens and data4.

Interoperability

To understand Cosmos’ interoperability we need to examine its three components: the Inter-Blockchain Protocol Communication (IBC), the Cosmos Software Development Kit (SDK) and its Zones.

Inter-Blockchain Communication Protocol (IBC)

The Inter-Blockchain Communication protocol (IBC) is a permissionless, interoperable protocol that handles authentication and the transportation of data between blockchains5. The IBC is flexible, in that it can be used in a wide variety of blockchains and state machines. As such, it plays a crucial role for application-specific blockchains as it provides them with a common protocol and framework for implementing standardized inter-blockchain communication6.

The principle behind IBC is straightword. Below is an example of how IBC works7:

An account on chain A wants to transfer tokens, let us say 10 ATOM tokens, to chain B.

Chain B receives the headers of chain A, and vice versa. This allows each chain to track the validator set of the other.

When the IBC transfer is initiated, the ATOMs are locked up (bonded) on chain A.

(Source:https://v1.cosmos.network/intro)

A proof that the 10 ATOM are bonded is relayed from chain A to chain B.

(Source:https://v1.cosmos.network/intro)

The proof is verified on chain B against chain A’s header and, if it is valid, then 10 ATOM-vouchers are created on chain B.

(Source:https://v1.cosmos.network/intro)

These ATOM-vouchers are not native to chain B, meaning they are wrapped/synthetic tokens. The real ATOM tokens are locked up on chain A.

Should the user decide to transfer those 10 wrapped ATOM tokens back to the source chain; chain A, then the wrapped tokens will be burned and after verifying, chain A will unlock the 10 ATOM tokens on it, releasing them to the user.

Up to this point, the Cosmos architecture has shown the connection between Tendermint based blockchains. However, Cosmos is not limited to just that. Either by customizing IBC or through Peg Zones, Cosmos can establish connections with other blockchains, such Bitcoin or Ethereum8.

IBC is itself composed of two properties: the transport layer and the application layer. The transport layer (TAO) is what provides the necessary infrastructure to establish secure connections and authenticate data packets between chains. The application layer is on top of the transport layer and defines exactly how data packets should be packaged and interpreted by the sending and receiving chains9. The application layer is where applications or dApps can be built.

It should be noted that IBC does not allow blockchains to directly pass messages to each other. In order to communicate, blockchains commit to a precisely defined path reserved for a specific message type and a specific counterparty10. Relayers monitor for updates on these paths and relay messages by submitting the data stored under the path along with proof of that data to the counterparty chain.

(Source:https://tutorials.cosmos.network/academy/3-ibc/1-what-is-ibc.html)

When it comes to security, IBC was designed around three main principles11. The first is the placement of trust on the chain’s ability to be secured by its nodes, not on the bridge itself. The second is the implementation of fault isolation mechanisms, so as to limit any damage done should these chains be subject to malicious behavior. The third is its utilization of light clients.

Light clients are blockchain clients that download only the headers of the blocks. Instead of utilizing full-nodes, by verifying the result of its queries against these headers, light clients give users a lightweight alternative with good security guarantees12. More importantly, they are able to track and efficiently verify the relevant state of the counterparty blockchain, check commitment proofs for the sending and receiving of packets on the source and destination chains respectively. In this way, IBC does not depend on any third party to verify the validity of cross-chain transactions.

Cosmos Software Development Kit (SDK)

The Cosmos SDK is a modular or generalized framework that eases the process of building secure blockchain applications on top of the Tendermint Byzantine-Fault Tolerance (BFT) consensus algorithm13. The application layer, which is situated above the networking and consensus layers, was created using the Cosmos SDK. It can be used to build blockchains regardless of its consensus algorithm.

The goal of the Cosmos SDK is for developers to create application-specific blockchains or Appchains without having to build everything from scratch. To accomplish this, the SDK has ready made specific modules or subsets that developers can easily just import into their application. You can think of them as certain LEGO pieces, such a door or wall made of red pieces that developers can use. Developers can also create their own modules14. An Appchain built using the Cosmos SDK is usually an aggregation of modules.

Additionally, the Cosmos SDK has built-in capability-based security measures, safeguarding the security between modules by limiting the scope of potential malicious interactions.

What the Cosmos SDK essentially brings to the ecosystem is customization without sacrificing interoperability.

Zones & Application-Specific Blockchains (Appchains)

As previously mentioned, Zones are independent application-specific blockchains (Appchains), built and customized by its developers to meet certain requirements and needs. A Zone contains one Appchain, but it can house multiple dApps. Hence both names can be used interchangeably. In this subsection, we will call them Zones.

What makes a Zone an Appchain is due to having two key components: its ability to be customized in however way developers want their application to be, all while maintaining its sovereignty.

Developers have a range of tools and resources to build their Appchains, but when it comes to interoperability with a chain with a non-Tendermint consensus mechanism, all that is needed is to adopt the IBC to connect with a Tendermint-based one.

Yet, the real joy is that none of these tools and adaptation methods will hinder a Zone’s sovereignty. When building a dApp over a general-purpose virtual machine blockchain such as Ethereum, stakeholders have limited control and say over their application, which makes them vulnerable to the governing decisions from the underlying blockchain. Stakeholders also have to accept the architecture of the underlying blockchain by default15.

Appchains are designed to address these issues. They can allow developers to choose a proven programming language , or just their own, or they can use their own custom cryptography while relying on well-audited crypto libraries16. When using an SDK module, developers and users also do not have to worry about potential bugs or exploitable mechanisms in the underlying blockchain since these are mere pieces for a larger project, which mitigates risks. Additionally, application-specific blockchains can choose to be interoperable (public) or remain isolated blockchains (private).

Another crucial advantage is the reduction in network traffic as transactions on Zones are only validated by its own validator nodes in parallel with other Zones, independent of the Cosmos Hub. This not only allows the network to scale, but makes it cost efficient and is less prone to congestion during high traffic transaction time.

Advantages and Disadvantages

To summarize, Cosmos’ interoperability system is comprised of three parts:

Inter-Blockchain Communication Protocol (IBC) — A permissionless, interoperable protocol that handles authentication and the transportation of data between blockchains.
Cosmos Software Development Kit (SDK) — A generalized framework tool that allows developers to build customized blockchains without having to build everything from scratch.
Zones & Appchains: Zones or Appchains are one and the same thing. They are single-purposed, customized blockchains with a relatively better performance whose creators and stakeholders have full sovereignty over. Zones can be interoperable or isolated, public or private blockchains.

Taking all of this together, the Cosmos ecosystem is a decentralized, yet interconnected, application-specific set of blockchains. Each Appchain or Zone not only has its own unique components and architecture, but they are also sovereign ecosystems in their own right.

Unlike Polkadot, Cosmos does not have a shared security system. Each blockchain is required to set up its own validator set and trust assumptions. Now with the launch of Interchain Security, it is now possible and more efficient for these blockchains to leverage the security of the Cosmos Hub by setting up its validators to secure their own network, if they so choose17. This way, projects with less capital and resources will not have to spin up their own validator set and Cosmos’ Hub validators and delegators can earn additional rewards in the form of that chain’s native governance token. This helps reinforce the security of the Cosmos ecosystem.

For interoperability, Cosmos offers developers a standard set of tools, consensus mechanism structure and infrastructure on which to build on. These standard components are critical in providing a standard method from which blockchains can communicate with each other. This facilitates the flow of data and transfer of tokens between chains, making it not only more secure, but cost efficient and far less time consuming.

However, this is not only what Cosmos’ interoperability can offer. Similar to Polkadot’s Remote Transfer system, Cosmos has Interchain Accounts (ICAs). These allow users to control an account on a host chain from a controller chain by sending IBC packets18.

What we have in the end are blockchains that can be as interoperable and public, or as isolated and private as they need to be.

Yet despite all of these advantages, Cosmos’ interoperability does have its disadvantages. First and foremost, the tokens being transferred between Zones are not native, but a wrapped version of the original token. This means if users want the original back, they would need to bridge back to the original chain where the token natively resides. Another issue that can arise is inequivalent value. Although the wrapped token is supposed to represent the original token in both value and price, due to high market volatility, there is the risk of the price of the wrapped token depegging, albeit often temporarily. This is in stark contrast to both Parachains and Subnets that allow tokens to be natively transferred between chains, thereby mitigating price volatility or even manipulation risk for such tokens.

Secondly, by default the Cosmos SDK is tied to the Tendermints proof-of-stake consensus mechanism. Transactions are passed to the application layer through the Application Blockchain Interface (ABCI)19. However, ABCI also divides the work of processing transactions between the two components20. While enabling the creation of unique blockchains, this also makes the application layer dependent on Tendermint, restricting developers to use other, more advanced forms of consensus mechanisms when using the Cosmos SDK. To be fair, there are attempts at being able to replace Tendermint with other consensus, such as with the Narwhal and Bullshark consensus algorithms21. However these consensus are not only relatively new and untested, but are a form of BFT consensus mechanisms, not all that different from Tendermint.

In conclusion, there is no denying that Cosmos is well suited to being a leader in the drive to achieve interoperability. It has a standard, yet flexible method for communication and cross-chain transfers, coupled with a software development kit to build customized blockchain networks. Although its interoperability system does face certain restrictions, there is no denying this network’s potential.

Subnets

Overview

Avalanche is another Layer-1/0, open-source, smart-contract capable platform for launching decentralized applications and enterprise blockchain deployments in one interoperable, highly scalable ecosystem1.

A distinct difference between Avalanche and other decentralized networks is the consensus protocol. The Avalanche protocol employs a novel approach to consensus called Snowman to achieve its strong safety guarantees, quick finality, and high-throughput without compromising decentralization2.

Additionally, with Avalanche, users can create an unlimited number of customized and interoperable blockchains called Subnets.

Subnets are sovereign networks with their own defined rules, tokenomics, consensus mechanism and membership3. Their networks are secured via a dynamic group of validators functioning to achieve consensus on the state of one or more blockchains. Within a Subnet, Avalanche allows anyone to create their own custom-made application specific blockchain, supporting multiple custom virtual machines such as EVM and WebAssembly (WASM) and written in popular computer programming languages like Go rather than just Solidity. This virtual machine can then be deployed on a custom blockchain network, a Subnet, where complex rulesets can be configured.

(Source:https://docs.avax.network/Subnets)

The inherent nature of Subnets creates the potential for a powerful technical tool within web3. This model allows for reductions in network traffic as transactions on Subnet blockchains are only validated by the validator nodes within that Subnet. This also decreases the resources validators need, as they do not validate transactions on other chains besides the Primary Network and the specific Subnets they are interested in. Subnets can also hold specific properties, allowing for considerable customizability, including making them private or requiring validators to be in a specific jurisdiction, just to name a few.

Interoperability

Unlike Polkadot and Cosmos, Subnet’s interoperability is based on only two components: Cross-chain Bridges and the recent Avalanche Warp Message (AWM) Communication Protocol.

Bridges

As Subnets are their own sovereign network, and they are responsible for establishing their own connections to other Subnets and the C-chain. This means Subnet projects are responsible for building their own bridge infrastructure or utilizing a 3rd party bridging solution.

However, Avalanche does provide some assistance by providing a tutorial demo on how to build a cross-chain EVM-EVM bridge4. Yet, this is only a demo for only EVM compatibility and is not intended for actual production use.

Up until recently, building or using a typical cross-chain bridge was the way to go. Projects have the option to use three types of mechanisms5:

Lock and mint — A user locks tokens in a smart contract on chain A, then a wrapped version of that locked token is minted on the destination chain. In the reverse direction, the wrapped token on the destination chain is burned to unlock the original coins on the source chain.
Burn and mint — A user burns tokens on the source chain, then the same native tokens are re-issued (minted) on the destination chain.
Lock and unlock — A user locks tokens on the chain A, then unlocks the same native tokens from a liquidity pool on the destination chain. These types of cross-chain bridges usually attract liquidity on both sides of the bridge through economic incentives such as liquidity mining or revenue sharing.

In addition, Subnet projects have the option to either build their own automated-market maker (AMM) or leverage an existing DEX with an already built liquidity pool.

Projects that are connected with other blockchains, but vary in terms of token type and architecture may even have to use more than one bridge. The Swimmer Network for example uses its own native bridge for its NFTs, but has partnered up and is leveraging LayerZero’s and cBridge’s bridging services for its utility tokens6.

Speaking of LayerZero, this communication protocol has taken strides in expanding its service to the Subnet ecosystem7. As mentioned, it has already partnered with Swimmer Network and is looking for further integration.

Although projects building on a Subnet have multiple options to connect to other blockchains, having a native interoperable system for Subnet-Subnet communication has proven elusive. That is, until the arrival of the Avalanche Warp Message (AWM) Protocol.

Avalanche Warp Message (AWM) Protocol

Subnet-to-Subnet communication within Avalanche is a relatively latecomer when compared to other networks who already built an internal interoperable system. However, this has not hindered the growth of the Subnet ecosystem, which currently has six launched Subnet networks8, with dozens more being developed and tested on the Fuji Testnet9.

Then on December 22, 2022, Ava Labs announced the release of the first native Subnet-to-Subnet communication protocol called Avalanche Warp Message10. It is the fifth — and final — Banff upgrade and it allows two blockchains running on different Subnets to send/verify arbitrary messages to/from each other. A major component of AWM is that there are no additional or third party intermediaries between Subnet-to-Subnet communication, like those with cross-chain bridges that act as a third party intermediary.

Before we can discuss how AWM works, we need to first examine two components that play a crucial role in its function; Avalanche’s P-Chain and BLS Multi-Signature.

P-Chain

(Source: https://docs.avax.network/overview/getting-started/avalanche-platform#platform-chain-p-chain)

The Platform Chain or P-Chain is a metadata blockchain on Avalanche where coordination between validators takes place, enables the creation of Subnets and keeps track of them11. Crucially, it is also where the network’s Snowman consensus protocol is processed.

When it comes to messaging, the P-Chain is the heartbeat of AWM. Given its architecture, at any point in time it has records of all the stakes of all the Subnets and all BLS keys registered by any validator12. As such, a Subnet can know the validators of another Subnet in order to be able to authenticate the message that came directly from that Subnet. With no additional per-connection overhead, any Subnet can reach out or look at another Subnet’s database, ask the validator on that database to ‘ask’ or verify information such as the stake weight of a Subnet, who is participating in it, what BLS keys are registered with it, etc. That Subnet can then quickly and efficiently verify a BLS multi-signature that was signed by a certain percentage of stake (more on this later).

In a Twitter Space with Avalanche, the reason why they chose this approach was that, considering that Subnets allow a diverse array of customized virtual machines (VM) to be implemented, an ‘any-to-any’ messaging system became necessary13. Hence, it became critical that the ability for tracking and verifying messages from Subnets and their ability to transfer and validate information was decoupled in order to develop a high throughput messaging protocol.

BLS Multi-Signature

A BLS Signature is a cryptographic signature scheme that allows a user to verify if a signature is authentic14.

The idea behind a BLS Multi-Signature scheme is that it aggregates many BLS signatures into one transaction. To achieve this, one would need to shrink the size of a block by reducing the size of the signature and then compress multiple individual signatures into a single, shorter one, thereby giving more space for more transactions to be included in that block15. This is done by the system supporting a public key aggregation, where the verification algorithm only uses a short aggregated public key16. The original public keys are not needed for verifying the multi-signature. All of this makes the verification for the short multi-signatures not only very easy to use, but also scalable.

This was only one reason why Avalanche chose to integrate BLS multi-signature scheme into AWM. A second reason why it was chosen over other signature schemes such as the Threshold Signature Schemes (TSS) was because the BLS Multi-Signature scheme allows for validity to be determined by the stake weights from validators that participate in a Subnet17. If a Subnet chooses to process another Subnet’s message, it looks up both the BLS Public Keys and the stake weight from the P-Chain of validators from the original Subnet.

“Stake” refers to the Subnet’s own native token and not the amount of AVAX validators have staked on the P-Chain. “Weight” is the weight or how much of a Subnet’s native token has been staked by its validators.

A third benefit is attributable signing. This essentially allows a Subnet to require a specific set of participants to verify the validity of a message18. Other schemes such as TSS do not possess such a feature.

How Does it Work?

Thus far, AWM sounds complicated. However, the process is fairly simple and can be broken down into just 5 simple steps19.

(source: https://typefully.com/_patrickogrady/bo39clG)

Step 1

Any Avalanche validator that wishes to generate BLS signatures must first register their BLS Public Key and BLS Proof-of-Possession on the P-Chain when starting their staking period. This BLS key is recorded on the P-Chain database so that any VM can quickly query its value.

Next, validators must either create or join an already existing Subnet or Elastic Subnet. AWM can work on both types of Subnets.

Step 2

The VM running on the Subnet can at any time trigger the generation of a BLS signature over an arbitrary payload. It is up to the VM to determine both the fee on the blockchain for triggering a generation and for determining what to put in this payload.

Step 3

Once each validator has generated a BLS signature over the payload, any other Subnet wishing to broadcast the message to another Subnet can collect the validator signatures, form a BLS Multi-Signature and process it.

Bear in mind that AWM communications are not recorded on the Primary Network. The only way for someone to view communication between Subnets is to join either Subnet network with their own validator node.

Step 4

Should a Subnet choose to process another Subnet’s message, as stated previously, it will need to look up both the BLS Public Keys and stake weight of the original Subnet from the P-Chain. As there is no “per connection” overhead in order to maintain communication between Subnets, this is very practical.

Step 5

Each Subnet defines its own AWM security level. As such, it is up to each Subnet network to determine if it wants to accept messages from another Subnet and, if so, determine the threshold of a validator’s weight of stake in order for the message that it had signed to be considered valid and/or safe. For example, Subnet A accepts messages from Subnet B that are signed by at least 70% of stake but does not accept messages from Subnet C.

For a Subnet to broadcast data to any Subnet willing to listen, it sends an “Anycast Message”. This enables an “oracle” Subnet to emit a periodic heartbeat that can be utilized by any other Subnet without the need to send a direct message to every other Subnet.

It is up to the Subnet and their users to determine how they want to ferry data from source to destination and what sort of guarantees they want to provide around the transferring of data.

What results from this are resources being communally utilized, fostering strong cooperation between Subnets, thereby establishing strong, literal communications and bonds within the Subnet ecosystem.

At heart, AWM is a rather primitive way for Subnet networks to communicate with each other. However, this also makes it very flexible for developers to use it how they see fit. They get to determine what messages look like and how their VM will interact with those messages. You can even overlay messaging formats from other teams on top of AWM if they work with your VM.

At this point, one might begin to think that, with AWM, cross-chain bridges are no longer necessary. It is important to note that AWM is only a messaging protocol. That means it is solely responsible for validating and sending/receiving arbitrary message data (transfer info., contract data, price, etc.)20. It is not involved in the security of the message itself. That responsibility falls down to each Subnet to refine their own AWM security level. Secondly, it does not involve itself in the actual transfer of crypto, NFTs or any digital asset between Subnets. For this to happen, a cross-chain bridge would be needed because it either provides liquidity between single or paired tokens or routes the transaction to another protocol that provides liquidity between chains, such as two DEXs21.

Therefore, the AWM protocol does not necessarily replace cross-chain bridges, as much as complement it. Bridges are needed for the user-friendly interface and liquidity for the cross-chain transfer of tokens. The AWM is needed for its simplistic, and thus more secure, messaging system22. Thus the entire goal is to make the actual implementation of the bridge as simple and as easy to use as possible. Therefore, it is being recommended that bridges should be deployed using AWM to maintain full security.

Advantages and Disadvantages

To summarize, Avalanche’s Subnet interoperability system is composed by two parts:

Cross-chain Bridges — It is an infrastructure that enables data and tokens to be transferred from one blockchain network to another. Bridges have three types of mechanisms:

Lock and mint
Burn and mint
Lock and unlock

2. Avalanche Warp Message (AWM) Protocol — It is Avalanche’s native Subnet-Subnet communication protocol. It is made up of two key parts:

Platform Chain (P-Chain) — Avalanche’s metadata blockchain on Avalanche where validators can coordinate, Subnets are created and tracked and where the network’s Snowman consensus protocol is processed.
BLS Multi-Signature — A cryptographic signature scheme that compiles multiple validator signatures into one transaction and allows other validators to verify if that signature is authentic.

For Subnets, building or relying on a 3rd party cross-chain bridge for interoperability is an immediate, albeit short-term and solely local solution. Firstly, not only is it expensive for a project, especially a start-up one, to build its own bridge infrastructure, it would divert much needed funds away from developing the project’s main product/service. Secondly, the subnet project would be solely responsible for the security of its bridge. Although partnering up with an already established bridge is more cost efficient, this is only possible if the project’s VM and architecture is compatible with the bridge, thereby making it dependent on a 3rd party for security. Given how unreliable bridges have demonstrated to be in 2022 alone, this can put a Subnet network at risk of loss in liquidity and user funds23.

Moreover, bridges have only managed to make EVM-compatible Subnets interoperable with Avalanche’s C-Chain or other EVM blockchain ecosystems such as Harmony. This renders Subnets with their own customized non-Ethereum VMs incompatible and thus isolated or were compelled to divert funds away to build their own bridge infrastructure. What we get as a result is an inefficient, costly, and largely disconnected Subnet ecosystem with incompatible bridges.

This is why cross-chain bridges on their own are a limited solution. What is needed is a basic communication protocol that can be agnostic and compatible regardless of the VM being used, or the architecture of a network. This is what AWM provides for bridges and for the Subnet ecosystem as a whole. Moreover, it can be easily implemented and customized on a bridge, whether that be a 3rd party or a project’s own natively built bridge.

As stated previously, AWM and cross-chain bridges can complement each other. AWM provides the communication infrastructure or gateway from which data and messaging can take place between Subnets with diverse VMs. A bridge in turn provides the liquidity needed for the actual transfer of tokens to take place, not to mention it can provide its own security mechanism, which can further strengthen the ecosystem’s interoperability.

But the AWM and bridges are not the only ones that can add security value. Subnets will also be responsible for coming up with their own AWM security level, via determining the threshold of a validator’s weight of stake. So then combining all of this together, the AWM-bridge union can potentially provide Subnet-Subnet interoperability with three layers of security.

When it comes to supported tokens, since bridges usually support both native and wrapped versions, that means that Subnets should be able to also support both types.

Having said this, AWM does have a few limitations. Firstly, AMW only supports the Goland and Rust VM SDK. It is currently unavailable for EVM-Subnets, although it is expected that it will support it in the coming weeks. This unavailability extends to the C-Chain as well. Secondly, having only just come out and despite rigorous testing, its practical usage is somewhat vague with any potential security issues/vulnerability being unknown.

Subnets vs Zones vs Parachains

Now that we have examined all three ecosystem’s interoperability systems, how does the interoperability of Subnets compare with those of Zones and Parachains?

Let us start with security. As mentioned, the Cosmos Hub uses the Tendermint consensus mechanism for its security. However, other Hubs and Zones in the ecosystem do not depend on it for their own security. Every Zone and Hub has their own validator set and different trust assumptions. This thereby not only mitigates any security issues that could affect the whole ecosystem, but also doesn’t limit its expansion. To strengthen this, Cosmos will be launching its Interchain Security, where projects on their own Appchain have the option to leverage Cosmos’ own security Hub by leasing its validators to validate and secure their own network. This way, projects with less capital and resources will not have to spin up their own validator set and Cosmos’ Hub validators and delegators can earn additional rewards in the form of that chain’s native governance token.

Alternatively, for Polkadot, shared Security is mandatory. Polkadot uses a shared state infrastructure between the Relay Chain and all of the connected parachains. Every Parachain makes the same trust assumptions, and as such the Relay Chain validates state transition and enables seamless interoperability between them. In return, projects wanting to build on top of a Parachain have to purchase DOT, and win an auction for one of the available parachain slots.

However, Parachains don’t just rely on the Relay Chain for their security. Parachains must also implement censorship resistance measures and utilize some type of consensus mechanism (PoW/PoS) for each Parachain. Hence, they cannot simply rely on the security of the Relay Chain. While these requirements enhance the security of the protocol, they can also be technically and financially expensive, requiring expertise and capital to implement correctly. This can therefore be quite prohibitive to smaller, less well-funded organizations, individuals, or entrepreneurs. Despite this, this does not make Parachains’ security fully independent.

Subnets on the other hand can validate a single or many blockchains within a single validator set. To secure their network on a Subnet, projects must be able to incentivize Avalanche’s validators through a reward system (e.g. robust tokenomics, gas fees paid to validators, help validators validate more blocks by delegating AVAX to them). Moreover, only validators who staked AVAX on Avalanche’s Primary Network can participate in securing a subnet’s network, ensuring the simultaneous shared safety of the whole network as well as individual subnets in which the validator participates. However, that being said, a Subnet’s security is not dependent on the Primary Network’s security. Subnets are completely sovereign networks, with their own consensus mechanism and validating transactions outside of the Primary Network. This is great because it means subnets do not have to depend on Avalanche’s own consensus for security. It gives sovereign security to each Subnet. This is on par with Cosmos’ Zones, but projects on Parachains do not have that option and rely on the Relay Chain to enforce validities. Additionally, although Cosmos is building their Interchain Security, it only pre-released its version 1 which is not yet available for full adoption.

When it comes to ‘implementation ease’ there are a few distinctions. For starters, Polkadot’s Parachain-Parachain communication involves several components to coordinate, namely between the XCM, XCMP, XCVM and the type of bridge method (Pallet, smart contracts & Higher-order protocols), with the possibility of the Relay Chain being involved (UMP/DMP). By contrast, Avalanche’s subnet-subnet communication only involves the coordination between the AWM, a cross-chain bridge and the P-Chain, whilst still offering much of the same security, benefits and features.

From this perspective, Avalanche’s interoperability system is simpler to implement given that it involves less components to integrate and coordinate. The AWM itself only requires just an array of bytes, an index of who participated in the BLS Multi-Signature, and the BLS Multi-Signature to get it set up. This is crucial because there are no limits to how many Subnet networks can be launched, in contrast to Polkadot who can only support a maximum of 200 Parachains.

The case is somewhat similar when comparing it with Cosmos’s Zones. When it comes to the guarantee of security, both IBC and AWM are very much similar24. However, because there is no ‘P-Chain’ on Cosmos, validators have to spend more time verifying and updating headers of other validators. With AWM, it sets up a ‘global ledger’ for everyone, so instead of verifying headers of every chain, you can just keep track of them on the P-Chain, thus keeping up to date on all the validator sets and using that information to then communicate. Basically, the P-Chain on Avalanche just makes the communication process more efficient.

The AWM’s other distinct advantage is that it does not discriminate between native and wrapped tokens. By comparison, Cosmos’ IBC is only able to send out to the destination chain wrapped/synthetic versions of the original tokens. With XCM, only between Substrate-based Parachains can the transfer of token assets be done natively. Wrapped tokens need to be used between Substrate-based and non-Substrate back blockchains. However, the decision whether or not to be able to send tokens native or as wrapped seems to fall within the cross-chain bridge and a subnet’s capacity and willingness.

Now despite this, given that Polkadot’s and Cosmos’ XCM and IBC respectively have been out for some time, they are well ahead in development and integration. IBC for example, after some prior development, can be adopted by chains that were not built with the Cosmos SDK, nor even use Tendermint as their consensus mechanism25. As previously mentioned, the AWM protocol does not even support subnet-C-Chain communication, let alone whether it can be adopted by other non-subnet blockchains.

Another difference lies in the area of strict guarantees. AWM implementation is on a lower level compared to IBC. Meaning that IBC enforces stricter guarantees with regards to how messages between chains are processed. With AWM it is less strict and as mentioned before, it is up to each Subnet to introduce different rules on how strict they want to be with messages. In other words, there is a certain enforced level of strict guarantee of cross-chain communication that all Zones, by default, have to abide by when using IBC. However, such a standard is non-existent with AWM, but distributed to each Subnet to enforce its own level of guarantee security.

Depending on one’s perspective, AWM can be seen as more flexible. On the other hand, IBC provides an already built-in security guarantee standard. This means less time and work is needed when integrating IBC than with AWM. Developers on a Subnet will not only need to calculate their network’s own security threshold, but must ensure the security threshold is sufficient. However, this also provides subnet developers, much like with XCM, the flexibility to implement stricter security guarantees than what IBC can provide. But again on the other hand, having different security levels can potentially impede interoperability between Subnets, as this can isolate certain Subnets who for one reason or another, have cross-chain communication security threshold that is not up to par for other Subnets to accept.

Another area of potential disadvantage for Subnets lies in Zones and Parachains having the ability to have an account on a remote chain, allowing the original chain to have an address on the remote chain for receiving funds and to eventually transfer those funds it controls into other accounts in that same remote chain. It is not yet known whether AWM can also provide this same service.

Overall, while there are differences, each of the three interoperability systems has unique features and advantages. It all comes down to a project’s needs, requirements and priorities. Nevertheless, from what has been gathered in this analysis, the only true advantage Polkadot’s and Cosmos’ interoperability had over Avalanche was that the latter had no communication protocol for its Subnets to communicate. However, the AWM communication protocol launch has almost closed that disadvantage. Yes, the XCM and IBC systems are more mature and further developed than AWM, but Avalanche has consistently proven, especially during its Banff upgrades, not only its resilience but its ability to produce top-quality products and services for its growing ecosystem. The proof can be seen in the growth the Subnet ecosystem had experienced prior to the launch of AWM. Now with a native communication protocol at the helm, Parachains and Zones will have their work cut out for them.

Work Cited for Parachains

Work Cited for Zones

Work Cited for Subnets

Other notes:

https://www.youtube.com/watch?v=LUAFkRxMA8E

Space about IBC and AWM — by landslide

https://twitter.com/CosmosAVAX/status/1611451678708097024

A Comparative Analysis on Interoperability: Subnets, Parachains, Zones

Parachains

Overview

Interoperability

Cross-Consensus Message (XCM)

Bridges

Advantages and Disadvantages

Zones

Overview

Interoperability

Advantages and Disadvantages

Subnets

Overview

Interoperability

Bridges

Avalanche Warp Message (AWM) Protocol

Advantages and Disadvantages

Subnets vs Zones vs Parachains

Work Cited for Parachains

Work Cited for Zones

Work Cited for Subnets

Written by GoGoPool