Cosmos: IBC and the Modular Blockchain

Imagine you want to create your own blockchain. On Ethereum you write a smart contract - and share resources with thousands of other applications, follow someone else's gas rules, someone else's validators, someone else's upgrades. What if you could get your own blockchain with your own rules in a matter of weeks - and it would not be an isolated island, but would freely communicate with 50+ other chains without bridge intermediaries? That is exactly what Cosmos promises, and today we will dig into how this architecture works from the inside.

• **dYdX v4** left StarkWare (ZK-rollup on Ethereum) for its own Cosmos chain - and gained ~2000 TPS with an in-memory orderbook and full control over MEV policy, impossible on any L2
• **Celestia** uses CometBFT for consensus in a modular data availability layer - the foundation for a new generation of rollup architectures where execution and data availability are separated
• **50+ chains** connected through IBC without a single bridge intermediary - unlike classic bridges (Ronin: -$625M, Wormhole: -$326M), IBC uses cryptographic verification through light clients

Предварительные знания

• Tendermint and Cosmos Consensus

Cosmos SDK: Modular Framework

In the Tendermint lesson we saw how ABCI separates consensus from business logic. But ABCI itself is just an interface: CheckTx, DeliverTx, BeginBlock, EndBlock. Writing a blockchain directly through ABCI is like writing a web app directly on sockets - possible, but why? **Cosmos SDK** is a framework that turns a set of ABCI calls into a full modular architecture with ready-made components.

**Cosmos SDK is written in Go** and follows a "batteries included" philosophy. Out of the box it includes modules: `bank` (token transfers), `staking` (delegation and validators), `gov` (on-chain voting), `auth` (accounts, signatures, fees), `distribution` (reward distribution), `slashing` (penalties for downtime and double signing). Developers combine the modules they need and add their own.

The central abstraction of the Cosmos SDK is the **Keeper**. Each module has its own Keeper that encapsulates access to storage (KV-store) and business logic. Keepers communicate through explicit dependencies: the `staking` module receives a reference to the `bank` Keeper to debit and credit tokens during delegation. This prevents chaotic dependencies - each module sees exactly what it needs.

**BeginBlocker** and **EndBlocker** are hooks that each module registers. The `slashing` module's BeginBlocker checks which validators missed a block signature and penalizes downtime. The `staking` module's EndBlocker updates the validator set - new delegations, unbonding, jailing. The order in which modules are called is set by the developer in `app.go` and is critically important: staking rewards cannot be distributed before the `distribution` module has calculated them.

**Ignite CLI** (formerly Starport) is a scaffolding tool that generates a working blockchain in minutes. The command `ignite scaffold chain mychain` creates a project with configured modules, protobuf definitions, REST/gRPC API, and CLI. `ignite scaffold module trading` adds a new module. `ignite scaffold message create-order pair price amount` generates a Message, Handler, Keeper method, and protobuf types. The developer only needs to fill in the business logic.

IBC: Inter-Blockchain Communication

An ecosystem of hundreds of blockchains is useless if they cannot communicate. Traditional bridges solve this problem through **trusted intermediaries**: multisig wallets, oracles, MPC groups. The result - dozens of hacks totaling billions of dollars: Ronin ($625M), Wormhole ($326M), Nomad ($190M). **IBC** solves the problem differently: no intermediaries, only cryptographic verification through light clients.

**IBC is not a bridge.** A bridge is a specific implementation with trusted operators. IBC is a **protocol** - a standardized set of rules by which chains verify each other's state. Each chain runs a light client of its partner chain and independently verifies Merkle proofs. No third party needs to be trusted.

The **light client** is the foundation of IBC security. Chain A stores a light client of chain B: the last confirmed header, the validator set, and their voting power. When a relayer brings a packet from B, chain A does not trust the relayer - it verifies the Merkle proof in the header signed by 2/3+ of chain B's validators. Tendermint's **instant finality** makes this possible: one header is sufficient, there's no need to wait for 6 confirmations as in Bitcoin.

A **relayer** is an off-chain process (Hermes, Go Relayer) that scans events on one chain and submits corresponding transactions to another. Critically: the relayer **is not a trusted party**. It cannot forge a packet - the receiving chain verifies the Merkle proof independently. The relayer is simply a "courier" delivering an envelope. If one relayer is malicious, any other relayer can deliver the same packet.

**ICS-27 (Interchain Accounts)** is an IBC extension that allows one chain to control an account on another. A user on Cosmos Hub can use ICA to open a position on Osmosis, vote on Juno, or stake tokens on Stride - without leaving the source chain. This is the foundation for **interchain composability**: protocols on different chains can interact programmatically, like smart contracts inside a single EVM.

CometBFT: Evolution of the Engine

In lesson bc-18 we covered Tendermint BFT as a consensus protocol. But since 2022, the ecosystem has gone through a rebranding and significant technical changes. **Tendermint Core** was renamed to **CometBFT** following the restructuring of Tendermint Inc. This is not just a name change - CometBFT received active development and important improvements that address problems in the original Tendermint.

**Why the rename?** Tendermint Inc. (later All in Bits) held the "Tendermint" trademark. Conflicts within the company led the Interchain Foundation (ICF) to fork the project under the name CometBFT to ensure independence from corporate decisions. Technically, CometBFT is a continuation of Tendermint Core with full backward compatibility.

The key improvement is **ABCI 2.0** (also ABCI++). The original ABCI had a limitation: the proposer built a block from the mempool without application involvement. The application only saw transactions during DeliverTx, after the block had already been proposed. ABCI 2.0 adds two new methods: **PrepareProposal** and **ProcessProposal**, allowing the application to control block content.

**Instant finality** is the foundation on which IBC is built. In Bitcoin, a transaction finalizes probabilistically: 6 confirmations (~60 minutes) for reasonable certainty. Ethereum after The Merge finalizes in 2 epochs (~13 minutes). In CometBFT, a block is **final at the moment of commit** - within 6-7 seconds. This is fundamental for IBC: a light client can safely accept a single header without waiting for additional confirmations. That is exactly why there is no "7-day waiting period" as in Optimistic Rollups.

**Alternative consensus engines** are gaining popularity in Cosmos. **Sei** developed **Twin-Turbo** - a CometBFT optimization with optimistic block processing and intelligent transaction proposals, reducing block time to 390 ms. **Berachain** is building Proof of Liquidity on top of CometBFT. **Dymension** developed its own implementation for hub rollups. The ABCI interface allows experimentation with consensus without rewriting the application layer - exactly the modularity Cosmos was built for.

App-Chains: The Sovereign Blockchain Thesis

Ethereum offers one model: all applications live on a single blockchain and share resources. A DeFi protocol competes for gas with an NFT mint; a GameFi project competes with memecoin traders. **Cosmos offers an alternative: every serious application gets its own blockchain.** This is not isolation, but **sovereignty**: its own validator set, its own governance, its own gas economy - while maintaining connectivity through IBC.

**App-chain sovereignty means full control:** - **Validators** - the project chooses who secures the network - **Governance** - custom voting rules and upgrade processes - **Tokenomics** - own gas token, fee model, inflation/deflation - **Execution** - custom virtual machine (EVM via Ethermint, CosmWasm, native Go) - **Throughput** - no sharing of bandwidth with unrelated dApps

The critical problem for app-chains is **security**. Each chain must attract its own validators and sufficient stake to protect against attacks. For a small project this is an insurmountable challenge: bootstrapping a validator set requires significant market capitalization of the token. Cosmos addresses this through **Interchain Security (ICS)** - a mechanism that allows chains to "rent" security from larger chains.

**Osmosis** is the largest DEX in the Cosmos ecosystem, a sovereign chain with a custom concentrated liquidity module. **Celestia** is a modular data availability layer using CometBFT for consensus, but reimagining execution: instead of executing transactions, Celestia only guarantees data availability for rollups. **Injective** is an orderbook-based DEX with sub-second finality. **Stride** is a liquid staking protocol operating as an ICS consumer chain, inheriting security from the Cosmos Hub.

Key Takeaways

• **Cosmos SDK** is a modular Go framework where the Keeper pattern isolates modules (bank, staking, gov), BeginBlocker/EndBlocker manage the block lifecycle, and Ignite CLI generates a blockchain skeleton in minutes
• **IBC** is an inter-network communication protocol without trusted intermediaries: light clients verify Merkle proofs, the relayer is just a courier, and CometBFT's instant finality allows accepting a single header without waiting for confirmations
• **CometBFT** (formerly Tendermint Core) added ABCI 2.0: PrepareProposal/ProcessProposal give the application control over block contents - critical for orderbook DEXes, oracle integration, and MEV protection
• **The app-chain thesis**: every serious application gets its own blockchain with sovereign validators, governance, and custom execution. Interchain Security solves the bootstrapping problem by allowing chains to "rent" Hub validators
• Remember the question about your own blockchain in a few weeks? Cosmos SDK + CometBFT + IBC is not a theoretical possibility but a working infrastructure: dYdX, Osmosis, Celestia, Injective, and dozens of other projects confirm that a modular sovereign blockchain is a viable alternative to the monolithic Ethereum approach

Related Topics

The Cosmos ecosystem sits at the intersection of several fundamental blockchain concepts:

• Tendermint and Cosmos Consensus — The foundation of Cosmos is Tendermint BFT, the ABCI interface, and instant finality on which Cosmos SDK and IBC are built
• Bridges and Cross-Chain — IBC is an alternative to bridge intermediaries: instead of trusting a multisig or MPC group, it uses cryptographic verification via light clients
• Solana: Proof of History and Parallelism — Solana and Cosmos represent two opposite approaches to scaling: a monolithic high-performance L1 vs an ecosystem of specialized app-chains
• Move: Resource Model — Move (Aptos, Sui) offers a third path - innovation at the language and execution level, while Cosmos innovates at the architecture and cross-network interaction level

Вопросы для размышления

• IBC is safer than bridges because it requires no trusted intermediaries. But what happens if the light client of one chain is not updated (connection expires)? How does this affect tokens locked in escrow?
• dYdX showed that an app-chain can be more efficient than an L2 for specific tasks. But if every DeFi protocol moves to its own chain - won't the atomic composability that made DeFi on Ethereum so powerful (flash loans, MEV-arbitrage between protocols) be lost?
• Interchain Security lets consumer chains "rent" security from the Cosmos Hub. But this creates a dependency: if the Hub halts (>1/3 of validators offline), all consumer chains halt too. How does this compare to the Ethereum rollup model, where L1 guarantees security but L2 can operate with some delay?

Связанные уроки

• dist-15-consistent-hashing