Motivation behind Cosmos 

You’re tired of high fees and latency and generally dislike the current form of the blockchain space. Nothing meets your requirements, and you think about creating something new and better - a new chain. Thus a powerful and dangerous idea is born. Yet, now you are plagued with questions of where to start, which ecosystem to choose - what is the best way of achieving this. Well, no one can tell you about the “best” way, but we can inform you about one possible way to build your chain - Cosmos (**cue the music**).

Intro

Since its inception, Ethereum has enabled smart contract functionality by introducing the Ethereum Virtual Machine (EVM). This has enabled the creation of many different types of Decentralized Applications (DApps) in the realm of Decentralized Finance (DeFi), Non-Fungible Tokens (NFTs), Gaming, etc.

Ethereum is a general-purpose public chain capable of supporting different DApps that compete for the network's resources. In times of congestion, transaction fees skyrocket, leading to a bad user experience both in terms of cost as well as latency.

Another problem of Ethereum, and similar Layer 1 chains, is that it has a "two-layer" governance system. This means that besides honoring its own rules, a DApp must honor the rules imposed by the protocol itself. It would be infeasible to alter the protocol each time new functionality is required by the DApp.

What Cosmos proposes is that instead of DApps competing for the resources of one chain, have each DApp on a separate, sovereign, parallel, and application-optimized chain. As they are separate, each of those individual chains can be upgraded/modified without affecting the other ones. Cosmos chains are able to communicate with each other and are even capable (under certain conditions) of communicating with chains that have a different Proof-of-Stake(PoS)/Proof-of-Work(PoW) consensus mechanisms than the one that Cosmos chains use.

Goals

This blog post provides a high-level introduction to Cosmos - ecosystem made with an intention of building application-specific blockchains easier than that was the case before. The post gives the idea and reasoning behind Cosmos, its non-monolithic, modular approach which eases the development process by defining a set of standards that need to be honored.

Discussion

Cosmos' Zones and Hubs

The functionality of any Cosmos blockchain (also referred to as a "Zone") can be broken down into three layers:

• Networking layer
• Consensus layer
• Application layer

Networking and Consensus layers handle the forming of a Peer-to-Peer (P2P) network, node discovery, and reaching an agreement between nodes about what is/will be the state of the chain. These layers are handled by the Tendermint Core, and using the Application Blockchain Interface (ABCI), they communicate with the Application layer.

The application layer defines the state of the chain and the transition to the next state. The developer's activity is mostly focused on tailoring this layer to address the application's needs.

Instead of each zone being connected with every other zone, zones can be connected to Hubs (Figure 1). Hubs are chains dedicated to managing the communication between zones, as well as their assets. Currently, there is, however, only one hub - Cosmos Hub, and it serves as the economic center of the whole ecosystem.

Figure 1 : Hub - Zone(s) Topology

Inter-Blockchain Communication (IBC) protocol 

Cross-chain communication is done by leveraging the IBC protocol. The whole realization of IBC is beyond the scope of this blog, but it is worth mentioning that there are no bridges involved. Rather, if we want to achieve communication between two chains (A and B), on each side, we will introduce light clients of the opposite chain and a concept of “relayers”. Relayers are off-chain processes responsible for relaying data between two chains by scanning the state of each chain, constructing appropriate datagrams, and executing them on the opposite chain as is allowed by the protocol.

In short, when chain A sends a message to chain B, it writes it in a special location which is monitored by the relayer. The relayer will carry the message to chain B, where the light client of chain A will verify if the message is valid.

Cosmos’ Tooling and Development Process

To provide you with the necessary information on how to get started, we give you the list of tools that are used. For the best learning experience, we recommend going through the Cosmos Academy tutorials that will give you a good basic knowledge (there’s even a fast track if you are impatient ;)).

Cosmos SDK and Ignite CLI

As was mentioned, most developers’ activity is done on the application layer. This is performed by using the Cosmos SDK - an opinionated Golang framework. The application layer is made up of modules - predefined and/or custom. Predefined modules are in charge of common functionality seen across different chains - i.e., the “bank” module handles the balances of accounts, transfers, etc., for the chain’s native tokens. Custom modules are meant to handle the unique functionality specific to the chain that is being developed.

The whole development process starts by defining “messages” that correspond to actions that users can make - i.e., the transfer of funds. Messages are wrapped and carried by a transaction (one transaction can have multiple messages).

Each individual message needs a “handler,” which will be called once the transaction is unwrapped and the message is passed to the corresponding module. Handlers have access to the current state of the chain and decide if the message is valid (it can alter the state) and, if that is the case, what will be the next state - rules for transitioning to it.

To view the current state without making changes, one needs to use “Queries” - functions that are called when a request for some piece of state’s information is made. Queries are implemented by the developer and automatically exposed through REST API.

All of this can be done via Cosmos SDK, though there’s an even better tool - Ignite CLI which scaffolds pieces of code and is especially useful for newcomers.

CosmJs

CosmJs is a Javascript/Typescript library that is used for building transactions and interacting with the wallet and thus with the chain itself. To be able to build a transaction, CosmJs needs to know about the types of messages that will be part of a transaction. The generation of those types is done manually via a terminal and is somewhat time-consuming (see Custom CosmJs interfaces for more information).

Next steps for the ecosystem

The roadmap for the project is available at the link. Take a special look at the v9-Lambda Upgrade (expected Q1 2023) entry. 

This upgrade brings Interchain Security to Cosmos - a feature that significantly lowers the barrier to launching a new chain. 

Taken from the blog post: Interchain Security is Coming to the Cosmos Hub 

“At a very high level, Interchain Security allows for a provider chain (like the Cosmos Hub), to be in charge of producing blocks for a consumer chain. It does this by sharing the set of validators who are in charge of producing blocks. The participating validators would run two nodes, one for the Cosmos Hub and one for the consumer chain, and receive fees and rewards on both chains.”

Conclusion 

This was a high-level overview of Cosmos’ idea, which has a completely different way of thinking about the scaling problem in the blockchain space and tremendously eases the development of new blockchains. 

In this text we covered:

• Main idea behind Cosmos ecosystem
• Tools currently available and a general process of development
• Further improvements that Cosmos will face

Overall, Cosmos’  ecosystem is good and mature in terms of tooling as well as developer resources and there are even courses being held by the Interchain Foundation, a Swiss non-profit that funds and advances the Cosmos Ecosystem.

I will be part of the September 2022 cohort and will be documenting my progress. Stay tuned.

In the meanwhile, let’s connect via Discord - We would love to hear from you.