Inter Blockchain Communication Review
A high-level comparing IBC, XCMP, and AWM
A look at IBC, XCMP, and AWM
Introduction
We live in a multi-blockchain world. Many projects have proven their worth and have developed new technologies and communities around them. Ten years ago, Bitcoin was the only game in town. That is no longer the case. Examples of such successful projects include Polkadot, Polygon, Solana, Cosmos, Avalanche, and the entire Ethereum L2 ecosystem.
The question becomes how to connect these blockchains – generally they are all running as independent entities with their own internal state machine. But connectivity is desirable – see the growth of the Internet as an example of what happens when different communities can be interconnected. In the 90s there were many different protocols on the Network and Transport layers in the OSI model. The internet was rather fragmented. But TCP/IP and HTTP both became the clear leaders, and so the success of the modern day Internet is largely based on adopting these technologies.
Will the same thing happen to blockchains in a multi-chain world? Since each chain is fundamentally different it remains to be seen. But there is an overarching desire to connect blockchains together. Let’s look at three different technologies that enable cross-blockchain communication that are live today: IBC (Inter-Blockchain Communications Protocol), XCMP (Cross-Consensus Message Passing), and AWM (Avalanche Warp Messaging).
IBC
IBC is a protocol for connecting two different chains together, and is modeled after TCP/IP. It provides primitives to pass messages between two chains in an ordered, exactly-once, way. IBC comes from the Cosmos ecosystem, but is entirely generic and can be used to connect any two blockchains together.
IBC is a stateful protocol – establishing connections, and sending/receiving messages impact’s each chain's state. A relayer, in effect acting as a proxy, is responsible for relaying messages between two chains interested in communicating. Light clients are used on both communicating chains to verify the state of the other chain, to ensure message integrity. Because blockchains are decentralized networks, messages include proofs to validate that a particular message was validated by a certain subset of the network. For example two-thirds of the network must agree on the message before it is considered valid.
At a high-level, here is how message passing through IBC works, between two separate chains A and B, where chain A sends a message to chain B:
Chain A establishes a connection to Chain B (through light clients and a relayer)
Chain A originates a message to open a connection to chain B which is then accepted. This message can be from a smart contract.
The light client on Chain B must update its state to include the message transaction originated from Chain A.
Chain B then verifies the merkle proof of the message using its own light client’s state. Since this is a decentralized and open environment, messages must be validated before accepting them.
An acknowledgement from chain B is sent back to chain A, in the same way as above, which confirms the connection.
After opening the connection successfully, a specific channel is set up between smart contracts on the two chains. Channels can be both ordered and unordered, and IBC ensures that messages are sent exactly once. Ensuring that messages are ordered and are sent exactly once is a very desirable behavior that TCP provides as well.
Data is then transmitted on this channel between these two blockchains in the form of smart contract data. For example, one smart contract could lock-up tokens on its own chain, and send proof to another chain to mint another token on that chain (effectively a cross-chain atomic swap).
That’s IBC in a nutshell – I will include several sources for those interested in more details.
XCMP
TODO!