In depth analysis on the Cosmos IBC; trustless bridging through light client verification

TLDR at the bottom

Current state of Interoperability

As it stands today, there is too much trust in cross blockchain transactions. Bridges act as one of he most vulnerable parts of blockchain and it’s a billion dollar issue.

The current model of blockchain bridging tends to operate like this:

Imagine you send a transaction from X chain, to Y chain. What happens under the hood is, you a wallet or multiple wallets, held on both chains, as well as smart contracts to initiate transactions between chains. When you send a tractions from one chain to another, these wallets will lock up the tokens on one end, which will initiate a minting nodule on the receiving chain to mint the newly bridged tokens.

How does the communication happen though? In reality, it’s about smart contracts initiating these lock and mint/burn modules. Oracles relay information to each chain, when a change in state and a lock up has been made on the starting chain, and should trigger a mint on the destination chain. In which case, the bridge contracts will act appropriately.

Risks in the current system

This type of bridging leaves a few levels of risk. You have smart contract risk, which likely includes multisig risk. So if enough ravage keys get compromised, or worse,a group of multisig key holders go malicious, then they could theoretically drain the bridge.

You also have third party oracle risk. So if an oracle receives incorrect information, or has sine sort of issue that halts important information for a period of time, the bridging system may not be operational.

Comparing this to the Inter Blockchain Communication Protocol (IBC)

This protocol allows sovereign blockchains that are hooked into it, to communicate freely through light client verification, without the need for multisigs or Oracles.

It goes like this:

Chain A and Chain B have a relayer, who agrees to run a light node, that will communicate between chain A and chain B. To initiate this relationship between the two chains however, there must be a “handshake agreement”, to obtain trust in each others ledger as they currently stand.

At a high level, each one of the chains will perform this step by communicating their algorithm and a snapshot of their consensus state, containing the root hash at the latest block height. The light client then can confirm that these chains are accurately communicating their state, and that they are both compatible for IBC communication, and then the handshake agreement is over and the chains now can communicate through the relayer.

Many validators opt to run relayers, alongside their validating nodes, however, their is no requirement where only a validator can run an IBC relayer.

IBC’s capabilities

In general, an IBC transaction can include, but is not limited to coin transfers. It can also transfer arbitrary data, and thanks to Interchain Accounts and Interchain Queries, it also includes cross chain smart contract deployment and execution.

These types of base layer communications are essential for ensuring trust, in this trustless bridging system. Relayers actually can’t “miscommunicate”. It’s essentially the chains directly communicating, and the relayer simply relays directly what the chain states, and and a relayer has to sign a direct order of communication from a chain. There is not trust necessary in a relayer, as they can’t change the way the protocol is set to form direct communication.

This sort of trustless bridging of both transactions and general information, with a direct link from each chain, is extremely important to be able to form seamless communication for cross chain smart contracts and collaborations. This type of bridging will also create a new paradigm to allow for cross chain abstraction, as multi hop IBC transactions will soon allow for any chain to connect to any chain, using the already connected relayers on each chain.

However, I will save multi hop IBC transactions for another day.

TLDR;

IBC differs greatly from the current state of blockchain bridges. It doesn’t rely on any smart contracts, oracles or multi sigs. Rather it relies on relayers, who can utilize a light client, to form a direct communication link between blockchains.

These relayers are able to communicate transactions, as well as arbitrary data, perform Interchain Queries and open up accounts across chains, allowing for easy execution of cross chain smart contracts. There are many different use cases coming from things such as multi hop IBC and ZK IBC, that will make even more efficient cross chain communication, and an even more abstracted IBC.