You are reading an excerpt from our free but shortened abridged report! While still packed with incredible research and data, for just $40/month you can upgrade to our FULL library of 60+ reports (including this one) and complete industry-leading analysis on the top crypto assets. 

Becoming a Premium member means enjoying all the perks of a Basic membership PLUS:

• Full-length CORE Reports: More technical, in-depth research, actionable insights, and potential market alpha for serious crypto users
• Early access to future CORE ratings: Being early is sometimes just as important as being right!
• Premium Member CORE+ Reports: Coverage on the top issues pertaining to crypto users like bridge security, layer two solutions, DeFi plays, and more
• CORE report Audio playback: Don’t want to read? No problem! Listen on the go.

Inter-Blockchain Communication (IBC)

In addition to relying on a PoS mechanism that isn’t encumbered by the nothing-at-stake problem, Cosmos aims to become “the internet of blockchains” via its internal Inter-Blockchain Communication (IBC) protocol. IBC allows users to send information between two IBC-connected sovereign chains by running a light client on each chain (see Map of Zones).  As a reminder, full nodes download and validate every transaction that has ever occurred on the chain since its genesis. Light nodes (typically) only check block headers. This means light clients are “light weight” nodes that require fewer computing resources than a full node. This makes them more egalitarian because they are cheaper and typically easier to run, helping to further decentralize the network. Once a zone creates an IBC connection with a Hub, it automatically has access to every other zone that’s connected to it.

Source

The Inter-Blockchain Communication (IBC) protocol is known as a "natively-verified" bridging/messaging protocol that connects the blockchains in the Cosmos ecosystem. As chains implement the IBC protocol, they bridge to one another, and the overall Cosmos ecosystem liquidity increases. Inter-Blockchain Communication (IBC) is fundamentally a cross-chain communications system for zones within the Cosmos ecosystem that utilize Tendermint consensus and have light clients deployed on each blockchain. Besides light clients, the IBC requires relayers to transport data packets (token transfers, smart contract calls, etc.) in specific formats as well as run the same consensus algorithm (discussed further below).

Within the Cosmos ecosystem, chains that implemented IBC have the Tendermint light client verifiers so they can consume and verify those receipts in their communication, thus removing external consensus to verify state. Because of the light clients, chains continuously verify and reach consensus on the state of other blockchains by verifying their block headers. Zones that are IBC-connected can communicate with no added trust assumption outside of their own validator sets.

This is in stark contrast to many bridging solutions that introduce third-parties or, as is the case with XCMP in the Polkadot ecosystem, where the trust assumption rests completely with the relay chain (Polkadot).

Source

IBC's architecture is comparable to the ubiquitous internet protocol TCP/IP. First, to establish a connection between two distinct chains, a relationship must be established via a series of initial transactions sent to each blockchain. Each transaction includes information and state proofs from the other chain. This enables each chain to authenticate the other's light clients in preparation for data exchange.

Source

Before the chains become interoperable, they also need to open channels involving more data exchange in the form of data packets.  Once any number of channels are formed, the chains can communicate, e.g., transfer tokens or a call to a smart contract. Each IBC connection could have various settings, such as timeout constraints or ordering guarantees, for each chain.

The token transfer process through IBC follows the following order:

1. Tokens on Chain A are locked in escrow, and an outgoing data packet containing the sender, receiver, and amount is produced.
2. The relayer receives and transfers the data packet.
3. The packet is received on Chain B and then verified. If successfully verified, new tokens of an equal amount are minted and transferred to the receiver on Chain B.
4. Chain B’s IBC module produces an acknowledgment data packet confirming receipt of tokens.
5. The relayer receives and transfers the packet.
6.  The confirmation packet is received on Chain A, and the transfer is complete.

Source: Galaxy Digital

Cosmos aims to scale horizontally with an asynchronous heterogeneous network model, where the app-chains have different VMs and can interoperate with other zones only when needed. The ability to launch  your project as a sovereign app-chain rather than a set of smart contracts on Ethereum has three fundamental advantages:

• Customizable validator rules and requirements for your chain's specific needs (e.g., public vs. private, privacy vs. transparent, etc.) 
• Performance isolation to ensure one dApp unrelated to your project doesn’t disrupt the chain a la Ape Coin on Ethereum in April 2022
• Predictable and customizable fees

IBC drawbacks

While the IBC model creates a very secure and trust-minimized bridge with reduced friction, this approach is harder to scale because establishing and maintaining light clients on hundreds of chains is cumbersome. As previously mentioned, IBC was designed to connect chains that utilize the same consensus algorithm. Tendermint chains have deterministic finality, making the bridge between them more straightforward, whereas others, like Ethereum, have probabilistic finality. Cosmos hubs can technically link to both types of chains, although bridging to probabilistic chains presents more challenges and tradeoffs. This is because hubs are incapable of maintaining the global state of probabilistic chains. This creates a double-spend attack vector that is not present in traditional IBC-connected zones.

As a solution, Cosmos employs "Peg Zones" to achieve interoperability with probabilistic chains. A Peg Zone is a separate blockchain created simply to monitor the state of a probabilistic blockchain and establish finality. Peg Zones will only interface with other IBC zones until enough time has elapsed so that the risk of a chain reorg is low.

Additionally, token transfers via the IBC are “path dependent,” reducing fungibility and creating friction in cross-chain composability. A token that is routed from, say, Secret Network to Osmosis to the Hub is not the same as a token routed from Secret Network to Axelar to the Hub even though they started and ended in the same places. 

Because of this, Cosmos employs the Hubs and Zones model to limit the number of connections required for a blockchain to benefit from being connected to the network.

Source

A solution to this path-dependence problem is in the works with the introduction of path unwinding. This method facilitates the return of tokens to their original chains prior to reaching their ultimate destination, introducing a layer of latency but markedly reducing the number of necessary hops for a token's journey. This is particularly advantageous in scenarios involving multiple transitions across various chains, where path unwinding streamlines the process by directly bridging tokens to their native blockchain and, subsequently, to their final destination. This method contrasts with the current path-dependent model, which often requires tokens to navigate a convoluted series of hops to maintain fungibility.

In parallel, the Packet Forward Middleware presents another innovative solution specifically designed for the Inter-Blockchain Communication (IBC) protocol. This middleware enables a blockchain to route incoming IBC packets from disparate chains through the originating chain first. This ensures uniformity in token denomination, thereby preserving fungibility across transactions. The advent of this middleware is timely, considering the rapid proliferation of blockchain networks, which escalates the demand for archival nodes and relayers to facilitate cross-chain transactions. By centralizing the routing process through the source chain, the Packet Forward Middleware simplifies multi-hop IBC transactions, transforming potentially complex multi-chain interactions into a singular, streamlined transaction.

This middleware solution not only addresses the issue of path dependency but also draws parallels with traditional internet data packet routing. By designating the native source chain as the primary router, it effectively consolidates various blockchain connections, leveraging the security and efficiency of the source chain's path. The Packet-Forward-Middleware, in essence, functions as a gateway, analogous to a router interface in a conventional network, facilitating the seamless flow of tokens across the blockchain ecosystem.