The Geek Out: Cosmos Unchained
One of the things that distinguishes Cosmos is that it is a toolkit for building other blockchains, via the Cosmos SDK and Tendermint Core consensus engine. Their vision of an “Internet of Blockchains” is one of a multi-chain world, and to help make this happen they also developed a native protocol for blockchains to connect and communicate. Thanks to the IBC protocol, or Inter-Blockchain Communication Protocol, every blockchain built on Cosmos can in theory talk to every other Cosmos blockchain, making it much easier to transfer assets. Although there are many initiatives to build various forms of bridges, this excellent Medium post provides a good look at just how complicated it is to build a secure and scalable bridge. And anyone who has built financial systems knows that complexity can kill you: within those intricacies bugs could lurk that hackers could exploit to steal tokens or crash the system, and even if you manage the security side of things you may well fail to hit your performance targets. A standard bridging mechanism that’s built once and only once for every blockchain is thus very appealing.
Before we dive into a tour of the protocol itself, though, it’s probably worth taking a step back to acknowledge a deep assumption in this whole mechanism: that a multitude of blockchains is a good thing. This is an instance of a technical choice that is ideologically loaded. If you believe that there will be one and only one true blockchain one day spanning the world — and Bitcoin is most often positioned in this way — then to suggest that a technology to make it easier to have diverse blockchains connecting to one another is a good thing is to take sides in a highly-charged debate. That is not the goal here: I think both futures are still possible at this point. Bitcoin’s resilience over the course of years now makes for a credible argument for a single unified blockchain with a single scaling mechanism on top like Lightning. But if that’s not the outcome, multiple blockchains are going to have to learn to live together, and IBC is one possible way forward; it’s worth digging a bit into how.
Why Do We Care?
A number of blockchain projects are using grants from their foundations to support development of blockchain explorers, analysis tools, oracles, DeFi protocols, NFT marketplaces and more — understanding that the applications, the DApps, are what will drive adoption of their technologies. Unfortunately this has a cost: if you have a single AMM-based decentralized exchange or yield farm or NFT marketplace or what have you on every single chain, and there are dozens of them, you are fragmenting liquidity. Hedge funds and other arbitrageurs are of course delighted by this situation: fragmented liquidity leads to price dislocations, because one liquidity pool cannot take pricing signals from activity in another. This allows for risk-free trades: if you can spot the discrepancies and you can shift funds efficiently, you can make money by buying an asset where it’s underpriced and selling it where it’s more expensive. Risk-free does not mean free of course — you need to take into account not only transaction costs but also deploy capital in multiple locations at once, and coordinate it all too — but it’s possible.
Fragmented liquidity has another consequence: greater market impact from large trades. Because each chain’s DeFi protocols each host only a fraction of the liquidity on offer, a trade executed in one place is limited in size. Though smart order router protocols like 1Inch will help you stitch together liquidity from multiple venues, their job is made much, much harder when it’s not just a question of sourcing liquidity on two DeFi protocols on, say, Ethereum, but scooping it up across three Ethereum DEX’s, one Avalanche DEX, and one Polkadot DEX. This inefficiency raises costs for traders, and in some cases may make it outright impossible to enter or exit a sizable position in a timely fashion. If the market is moving quickly against you, this can be the difference between a successful trade and a failed one.
In the NFT world, you have all of the above problems if you are trading, but you add in complexities around validating your ownership of the NFT as well. If Twitter adds a feature to confirm to the world that your profile picture of a mutant ape is truly owned by you, today Twitter has to make a choice about which digital wallet it consults to make this assessment. If they choose Ethereum but you minted your NFT on, say, Algorand, well, good luck. The image may be shared with everyone on the IPFS global file system, and this may be common across different NFT marketplaces, but the NFT itself — the record that you and only you provably own, with its associated metadata — only lives on one blockchain.
So if you take as a given that multiple blockchains are not going away anytime soon, it’s clear that the ability to connect them is going to be important. This is where IBC may come in.
Philosophy
The IBC protocol takes its inspiration from TCP/IP. Like TCP/IP, it aims to provide a uniform communication layer that is agnostic about the application data being relayed and higher-level messaging. From the paper: “Just as TCP/IP provides reliable, ordered data transmission between processes, allowing a process on one host to reason about the state of a process on another, IBC provides reliable, ordered data transmission between modules, allowing a module on one ledger to reason about the state of a module on another.” These attributes, reliable and ordered, are of course essential to ensure each blockchain (zone) has a consistent view of state, just as higher-level protocols like HTTP rely on TCP/IP’s guarantees to ensure the data that gets delivered from a Web application your browser are not scrambled.
Zones vs. Shards
Explaining sharding architectures like Ethereum 2.0 is beyond the scope of this post, but it’s important to at least touch on it to understand the difference between the Cosmos approach to scaling vs. other blockchains, as IBC is a key part of it. In a sharded blockchain you get scaling by divide-and-conquer: multiple subsets of the distributed ledger can process transactions in parallel, and not every shard has to process every transaction (extending the database analogy, they are not replicas of each other). However, to achieve this there is a need for coordination. In Ethereum this point of coordination is called the Beacon chain: in Vitalik Buterin’s post on this from April 2021, he distinguishes between the Beacon Chain as a “Coordination Layer” vs. the Shard Chains as a “Data Layer.”
Cosmos zones are different: a zone is a sovereign ledger. Like sharding, having multiple zones break up the problem of processing all the world’s transactions into sections. Unlike sharding, the division of work is not generic or even. The fact that there is a spike in transactions on, say, the Akash network today is not going to be helped by having another Cosmos-based blockchain’s network take on some of the processing. But on the other hand, you will never have a situation where a mad rush to buy a new NFT on that other blockchain affects your ability to reserve decentralized compute on Akash.
The other difference, relevant for today’s topic, is sharded blockchains have an internal protocol to communicate between the shards and the Beacon chain. In Cosmos, this concept is generalized in the form of IBC: rather than having a segmented ledger with pieces that know how to intercommunicate and coordinate, zones operate independently and then use IBC to exchange data as needed, with Cosmos Hub aids coordination via tracking per-zone token balances. Importantly, this greater independence of the zones allows for greater diversity: zones can use different virtual machines for smart contracts, be public or support secret content, innovate with new features not available on other blockchains, etc., but they maintain the ability to interoperate.
Relayers
Relayers play a key role in IBC. They are independently-operated processes that take care of the hand-off between chains. There are currently three major implementations: the initial one was in Go, the newer Hermes implementation is in Rust and there is a third in TypeScript. Like validators, relayers can be operated by anyone with the capacity and technical knowledge to run the infrastructure. Unlike validator nodes in proof-of-stake, there is (currently — this will change) no economic incentive to support a well-run relayer; you are not going to get slashed just because your relayer is dropping packets all the time, and equally you won’t earn income from doing it. Functionally, a layer is dual-ported, listening to events on one blockchain and relaying messages to another blockchain, and vice versa.
What’s important to understand is that relayers are not teleportation devices. They do not truly move balances between ledgers in the sense that data is lifted off one blockchain and then written to another. Mechanically a relayer locks the token on the sending side and provides a cryptographic proof — a receipt — to the receiving side, giving the opposing blockchain confidence that a coordinated update can be performed. So what you are sending is not the token (or NFT, etc.) but the evidence of a valid transfer operation. What IBC specifies is the messaging protocol (things like sequence numbers, how to encode the proof exchange, etc.) which is what lets blockchains with potentially very different technical substrates to talk.
Note IBC’s relayer mechanism is still immature: packet relay sometimes fails due to timeouts, and as of a developer presentation in July 2021 they quoted an average fail rate of 5% on the network, which is quite high. The Cosmos developer was at pains to emphasize that this is about the communication channel and not integrity of the records on the blockchains. Although he may not like the analogy, it reminded me a bit of the two-phase commit protocol in SQL databases: if the two coordinating blockchains cannot complete the handshake, the transaction just rolls back like it never happened.
If you are bloody-minded like me, at this point you are probably wondering why exactly one blockchain should trust that a relayer is well-behaved. Why isn’t there a risk of a man-in-the-middle type attack? Could a relayer assert that it has locked up a token on one blockchain and then authorize materializing it on another and then execute a trade on a DeFi protocol? It would be the ultimate flash loan: a token comes from nowhere, and you can do a trade! This is where it becomes important that IBC messages are not relaying data, but rather proofs — specifically Merkle proofs, the exact same mechanism that Bitcoin lightweight clients use to validate transactions without having a copy of the entire blockchain. The relayer is simply listening for writes in a well-known location from the originating blockchain, and it’s the job of the originator to write the proof, and the receiver to verify the proof. If the relayer corrupts the proof, validation should fail, so a relayer can misbehave and send whatever assertion it wants over the wire, but a correctly-implemented IBC client on the receiving side would never allow the receiving blockchain to be updated.
Channels
A channel is a persistent; named; logical route between chains for a given purpose. Like a URL, the channel helps the relayer know where to send the data you want to relay between blockchains. Unlike a URL, there is no implied physical mapping for the address. You don’t specify a host and port here: you have a name like channel-xxx and only by inspecting the description of it can you know that it’s, say, for sending tokens between Cosmos and Akash. The other important point is that qualifier of “for a given purpose.” Technically the endpoints of a channel are not blockchains but modules, or components of a blockchain: this refers to the fundamental building blocks of the Cosmos SDK, which is a modular framework which you can use to build blockchains with various features.
Usage Trends
According to the Map of Zones explorer, there have been more than 1.5M IBC transfers in the last month; note they do not currently have these stats in notional value. The most active zone, about half of the activity, is the Osmosis DeFi protocol, with a lot of traffic on channels to the Cosmos Hub and the Terra blockchain.
The Way Forward
In a recent interview, the CEO of Tendermint, Peng Zhong, predicted that over the next year they will see 200 blockchains connected through IBC, up from 22 today. He has insights into the pipeline of projects that I do not have, so it’s hard to say if that is overly optimistic or not, but it’s clearly growing. What deserves closer scrutiny though is their progress in promoting IBC outside the Cosmos ecosystem. Right now Cosmos is the basis for multiple blockchains — I had a hard time finding a good source for how many; they quote 260 but this is inclusive of applications and related services, so ping me if you have a citation — but they don’t seem to have gotten as far in convincing other blockchains to adopt IBC as an open standard. That could be changing: Solana and Polkadot are apparently working on adopting it. If IBC truly takes off as an open standard like HTTP and other early Internet standards and if we do see a multi-blockchain future, IBC will be an important piece of it.
Learning More
- Explainer from the Cosmos team (basic): https://www.youtube.com/watch?v=dYuTYykRhH4
- Overview: https://docs.cosmos.network/master/ibc/overview.html
- Tutorial: https://cosmos-network.gitbooks.io/cosmos-academy/content/introduction-to-the-cosmos-ecosystem/cosmos/ibc-protocol.html
- Whitepaper: https://github.com/cosmos/ibc/raw/old/papers/2020-05/build/paper.pdf
- Specification: https://github.com/cosmos/ibc
- Cosmos FAQ (old): https://github.com/cosmos/cosmos/blob/master/FAQ.md
