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.
Inter-Blockchain Communication (IBC) protocol is what 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).
IBC's architecture is comparable to the ubiquitous internet protocol, TCP/IP. First, in order to establish a connection between two distinct chains, a relationship between the two chains 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.
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:
- Tokens on Chain A are locked in escrow, and an outgoing data packet containing the sender, receiver, and amount is produced.
- The relayer receives and transfers the data packet.
- 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.
- Chain B’s IBC module produces an acknowledgment data packet confirming receipt of tokens.
- The relayer receives and transfers the packet.
- The confirmation packet is received on Chain A, and the transfer is complete.
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 establishes 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.
