The idea of Cosmos came around in 2014, while the usable blockchain came into existence in 2019. What is Cosmos? Ethan Buchman defines Cosmos as the “internet of blockchains”, in fact everywhere you see Cosmos, see the phrase “internet of blockchain” addressed there somewhere. But how is it so? The Internet is a network of independent computers connecting to share data (whether to read, write, store, or all). In the same manner, the Cosmos connects independent blockchains. And as the internet uses HTTP networking protocol, Cosmos uses IBC protocol. So you see how the phrase makes sense. To put it simply, Cosmos creates an interconnected network of app-specific sovereign blockchains via IBC. So, imagine a mesh network (because it doesnt have a central authoritative point) connected with 1, more or all of the blockchains. In the case of Cosmos, we refer to these blockchains as Cosmos zones. Now, let's explore the architecture of Cosmos as an ecosystem. We already know that Cosmos zones are sovereign blockchains. We also know that IBC connects these blockchains, and now we know that for consensus, they use Tendermint. Let's dive into each of the Cosmos components. Tendermint is a BFT consensus mechanism that came into existence in 2014. We know that consensus algorithms make sure that after each transaction, the state of the blockchain is updated accordingly. So, what Tendermint does is deals with how nodes communicate to store the overall state of the blockchain. Tendermint is blockchain agnostic, meaning it doesnt depend on any specific blockchain. As a matter of fact, any blockchain can use it for its own consensus mechanism. Cosmos happens to be one of the many systems to use Tendermint. Let's peak on Tendermint a little. It uses two components Tendermint core and Tendermint application interface. The consensus engine, called Tendermint Core, ensures that the same transactions are recorded on every machine in the same order. The application interface, called the Application BlockChain Interface (ABCI), enables the transactions to be processed in any programming language. The state machine which Tendermint uses is defined in figure 1 The process starts with proposing a block by a designated proposer who is chosen deterministically in proportion to their voting power from the ordered list of validators, for a round. The rest of the flow goes according to figure 1. The Tendermint protocol doesnt have a fork choice for block creation. There is only one canonical chain, and once a transaction is included in a block, it reaches finality, unlike Nakamoto consensus, where you need to wait for probabilistic confirmations of 6 blocks. It requires a fixed number of validators, and 2/3rd of the validators prevote and pre-commit for the same block in the same round to add a block in the canonical chain. One more thing I’d like to mention while we talk about consensus is the light clients. Light clients are node that doesn't store all of the data of the blockchain, it uses just the block headers. So, light clients can get away with just snap sync, and it doesn't need to choose blocks between the fork choice because there exists only one canonical chain. Just like every blockchain, Cosmos too has a networking layer. It uses nodes, and these nodes communicate via gossip protocol. Tendermint core is responsible for this part. Nodes are responsible to share the transactions, update the mempool and create blocks. The application layer of Cosmos uses the Hub & Spoke model. Let's have a look at how the model works on Cosmos. On Cosmos, we have blockchains that we call zones which are mostly application specific. These zones are independent, and they connect with other zones via a Hub. Now, to connect both zones must accept the connection request to proceed. At the time of writing this, there are 51 zones; not all are active; only 48 are. To build Cosmos zones, the Cosmos SDK is used. Cosmos zones connect to others via Hub. The name hub is not how it sounds. One might think it can be a single point of connection, that is not the case. We can have as many hubs as we want on Cosmos, so it is designed to be decentralized as well as permissionless, as anyone can create a hub or a zone. You can think of Hub as a router used to route messages from zones. The topology formed here is a mesh, although it differs slightly from Mesh. Sunny Agarwal and Zaki Manian defined the topology by comparing it with fungus the mycelial networks, which will make sense once you have a look at Cosmos and the fungus side by side. The reason to mention topology here is to emphasize the fact that not all zones are connected together. They may or may not, depending upon the need. IBC, or inter-blockchain communication protocol, connects blockchains. In this case, it connects the Cosmos zones. When zones are connected to Hub via IBC, they automatically connect to the other zones which are connected to the hub. Hence you see how the hub and spoke model is used? This prevents every zone from connecting to another zone, making the system less complex. Now, let's dive into how IBC works. Imagine IBC as a message shipment service. To understand it more clearly, let’s say that IBC is a shipping container. Messages are in these containers, which are then shipped to the port of the other zone to which the container is meant to be delivered. Now you need someone to carry this container, right? This someone, in this case, is a relayer. Relayers have full access to nodes on both sides of the IBC. IBC also makes use of light clients for commitment-proof exchange. Before shipping the container for transferring messages, a commitment proof is sent by the source chain to receiving chain. This is verified by the receiving chain, and for this, light clients are used. This back-and-forth relaying of proofs is taken care of by the relayer. The route which connects the zone has some specific chain ID. Which is used when you want to send messages among zones. Hub reads the chainID and forwards the request accordingly. Figure 2 defines the package flow for the message, which is Just like Tendermint, IBC is also blockchain agnostic. Any blockchain can implement IBC. However, the ICS standard used should be of the same specifications. ICS is the interchain standard that sets parameters for transactions happening between the IBC chains. Cosmos introduced a new architecture in the paradigm of interoperability and composability. Blockchain, like ethereum and bitcoin, has a big market share but scaling them is quite a feat. Cosmos enables users to create blockchains that are compatible. Having app-specific chains remove the complexity from the system by a lot. In Ethereum as a monolithic chain, one change to the base ecosystem forces all dApps to recheck their compatibility and introduce upgrades accordingly. But since app chains don't have dApps on top of them as they are the dApps. The problem doesn’t exist here. Furthermore, it is possible to connect Cosmos with the already existing blockchains. You can do that by simply creating a peg-zone. You can imagine peg-zone as a bridge between the Cosmos hub and whatever existing blockchain you want to connect it to. Peg-zones are used with probabilistic chains, and it’s function is to track the state of these blockchains and establish finality for them so that they can be compatible with IBC. While the Gravity bridge is live and is still a work in progress, it faces certain issues. Axelar is another blockchain interoperability network built via Cosmos SDK. You can use their bridge, “Sattelite” to transfer assets between EVM and Cosmos-based chains. You can read more about how to use Sattelite at this link. Also read Fraud and Data Availability Proofs.
Architecture
Tendermint On Consensus Layer:
Networking Layer:
Application Layer:
Cosmos Zones As Spoke:
Cosmos Hub:
IBC:
Package flow:
Why Cosmos:
We develop cutting-edge products for the Web3 ecosystem supported by our extensive research on blockchain core and infrastructure.
