Understanding the value proposition of Cosmos

A new, more complete version of this article has been published on the Cosmos website.

Cosmos is generally seen as an interoperability solution, something to connect blockchains together. While it is certainly a part of what we are trying to achieve, this conception of Cosmos leaves out many important pieces. Cosmos is much, much more than just an interoperability solution. To understand why, let us try to explain the vision behind Cosmos, starting from the beginning.

What is a blockchain?

In short, a blockchain is a deterministic state machine replicated on nodes that do not necessarily trust each other. There is a state, which can represent different things depending on the application (e.g. token balances for accounts), and transactions, that modify the state. From an architecture standpoint, blockchains can be divided into three conceptual layers:

• Networking: Responsible for the propagation of transactions.
• Consensus: Enables nodes to agree on the current state of the system.
• Application: Responsible for updating the state given a set of transactions, i.e. processing transactions

Simplified blockchain architecture

The networking layer makes sure that each node receives transactions. The consensus layer makes sure that each node agrees on the same transactions to modify their local state. As for the application layer, it processes transactions. Given a transaction and a state, the application will return a new state. In Bitcoin for example, the state is a list of balances for each account (in reality, it’s a list of UTXO, short for Unspent Transaction Output, but let’s call them balances for the sake of simplicity), and transactions modify the state by changing these balances. In the case of Ethereum, the application is a virtual machine. Each transaction goes through this virtual machine and modifies the state according to the specific smart contract that is called within it.

The birth of Tendermint

Before Tendermint, building a blockchain required building all three layers from the ground up. It was such a tedious task that most developers preferred forking the Bitcoin codebase, thereby being constrained by the limitations of the Bitcoin protocol. Then, Ethereum came in and greatly simplified the development of decentralised applications by providing a Virtual-Machine blockchain on which anyone could deploy custom logic in the form of Smart Contracts. But it did not simplify the development of blockchains themselves, as Go-Ethereum remained a very monolithic tech stack that is difficult to hard-fork from, much like Bitcoin. That is where Tendermint came in.

The goal of Tendermint is to provide the networking and consensus layers of a blockchain as a generic engine on which arbitrary applications can be built. With Tendermint, developers only have to worry about the application layer of their blockchain, thereby saving them hundreds of hours of development work. Note that Tendermint also designates the name of the byzantine fault tolerant consensus algorithm used within the Tendermint Core engine. For more on consensus protocols, you can check this cool podcast.

Tendermint ABCI architecture

The Tendermint Core engine is connected to the application by a socket protocol called the Application Blockchain Interface. This protocol can be wrapped in any language, so that developers can choose the programming language they prefer to build their application. But this is not all. The goal of Tendermint is to provide developers with a tool that is not only practical, but also highly performant. Here are the properties that make Tendermint a state-of-the-art blockchain engine:

• Public or private blockchain capable: Tendermint only handles networking and consensus for the blockchain, meaning that it helps nodes propagate transactions and validators agree on a set of transactions to append to the blockchain. It is the role of the application layer to define how the validator set is constituted. Developers can therefore build both public and private blockchains on top of the Tendermint engine. If the application defines that validators are elected based on how many coins have been bonded to them, then the blockchain can be characterised as Proof-Of-Stake. If however the application defines that only a restricted set of pre-authorized entities can be validators, then the blockchain can be characterised as permissionned, private or Proof-Of-Authority. Developers have all the freedom to customize the rules that define how the validator set of their blockchain changes.
• High Performance: Tendermint Core can have a block time on the order of 1 second and can handle thousands of transactions per second.
• Instant finality: A property of the Tendermint consensus algorithm is instant finality, meaning that forks are never created, as long as less than two thirds of the validators are malicious (byzantine). Users can be sure their transactions are finalized as soon as a block is created.
• Security: Tendermint consensus is not only fault tolerant, it’s optimally Byzantine fault-tolerant, with accountability. If the blockchain forks, there is a way to determine liability.

Another cool thing with Tendermint is that the ABCI is so modular that you can port existing blockchain codebases onto it. For example, you can take the Ethereum virtual machine codebase and plug it in on top of Tendermint. Indeed, we did that, it is called Ethermint. Ethermint works exactly like Ethereum, but also benefits from all the nice properties of Tendermint listed above. All the existing Ethereum tools (Truffle, Metamask, ..) are compatible with Ethermint, and you can port your smart contracts there without any additional work.

Bridging it all together — IBC

We now have our first building block: Tendermint. With it, developers can easily develop highly-performant blockchains without having to worry about the networking or consensus layers. These blockchains all have different application layers, but they share the same networking and consensus stack. Because of this, it becomes easy to connect them with each other.

The connection between Tendermint blockchains is achieved through a protocol called IBC, short for Inter-Blockchain Communication Protocol. IBC leverages the instant finality property of Tendermint to allow heterogenous chains to exchange value (i.e. tokens) with each other. Let us take a closer look at how IBC works, and how it enables the creation of Cosmos, a network of blockchains.

Heterogenous chains

First, we need to explain what we mean by heterogenous chains. Essentially, it comes down to two things:

• Different layers: Heterogenous chains can have different layers, meaning they can differ in how they implement the networking, consensus and application parts. This works with a few restrictions, the main one being that the consensus layer must have fast finality. Proof-Of-Work chains do not fall in this category, as they have probabilistic finality.
• Sovereignty: Every blockchain is maintained by a set of validators, whose job is to agree on the next block to commit to the blockchain. In Proof-Of-Work, validators are called miners. A sovereign blockchain is a blockchain with its own validator set. In many instances it is important for blockchains to be sovereign, as validators are ultimately responsible for modifying the state. In Ethereum, applications are all run by a common set of validators. Because of this, each application only has limited sovereignty.

IBC allows heterogenous chains to exchange tokens. This means that blockchains with different applications and validator sets are interoperable. This is a very important feat, as it gives maximum flexibility to each blockchain. For example, it allows public and private chains to exchange tokens with each other.

How IBC works

The principle behind IBC is fairly simple. Let’s take an example where an account on chain A wants to send 10 tokens X on chain B. First, these tokens are locked on chain A. Then, a proof that these 10 tokens X are locked is relayed from chain A to chain B. Chain B tracks the validator set of chain A. If the proof is signed by more than 2/3rd of chain A’s validators, then it is valid, and 10 tokens X are created on chain B.

Note that the tokens that have been created on chain B are not actually real tokens X, as token X only exists on chain A. They are a representation on B of tokens X from chain A, along with a proof that these tokens are frozen on chain A.

A similar mechanism is used to unlock tokens when they come back to their origin chain. For a more comprehensive description of the IBC protocol, you can look at this specification. It is worth mentioning that the IBC protocol we have described is for value transfer only, i.e. sending tokens from one chain to the other, but that it might later be extended to support logic transfer as well.

Cosmos — Hubs and Zones

Now that we have a protocol that allows two heterogenous chains to exchange tokens with each other, how do we create a network of blockchains?

One idea would be to connect each blockchain in the network with every other via a direct IBC connection. The main problem with this approach is that the number of connexion in the network grows exponentially with the number of blockchains. If there are 100 blockchains in the network and each of them needs to maintain an IBC connection with each other, that’s 4950 connections. This quickly gets out of hand.

So let’s not connect each blockchain with every other. A problem we then face is that the level of “trust” required between blockchain increases, and the risk of blockchains double spending each other gets higher. Indeed, when a blockchain receives a token from the chain that created it, only one level of trust is required. In this case, the receiving chain only has to trust the validator set of the origin chain not to unfreeze or double spend the tokens. But when a blockchain receives a token from a chain that did not create it, several levels of trust are involved. That’s because the receiving chain must not only trust that the origin chain did not unfreeze the token, but also that all the chains that received the token before did not double spend it. As the number of chains relaying the token grows, the number of chains the receiver needs to trust grows as well. This is not practical.

To solve this, Cosmos proposes a modular architecture with two classes of blockchain: Hubs and Zones. Zones are regular heterogenous blockchains, and Hubs are blockchains specifically used to connect Zones together. When a Zone creates an IBC connexion with a Hub, it can automatically access (i.e. send to and receive from) every other Zone that is connected to it. As a result, each Zone only needs to establish a limited number of connexions with a restricted sets of Hubs. Hubs also prevent double spend among Zones. This means that when a Zone receives a token from a Hub, it needs only trust the origin Zone of this token and the Hub.

Cosmos — Cosmos Hub and Zones

The first Hub to launch in the Cosmos Ecosystem will be the Cosmos Hub. The Cosmos Hub is a public Proof-Of-Stake blockchain whose native staking token is called Atom, and where transactions fees will be payable in multiple tokens including Atom and Photon. The launch of the Hub will also mark the launch of the Cosmos network.

Bridging non-Tendermint chains

In the architecture of Cosmos we have presented until now, only Tendermint-based chains can interoperate. But the Cosmos is not limited to Tendermint chains. In fact, any kind of blockchain can be connected to Cosmos.

We have two cases to distinguish: fast-finality chains and probabilistic-finality chains.

Fast-finality chains

Blockchains that use fast-finality consensus algorithms can connect with Cosmos by adapting IBC. For example, if Ethereum were to switch to Casper FFG (Friendly Finality Gadget), a direct connection could be established between it and the Cosmos Ecosystem by adapting IBC to work with Casper.

Probabilistic-finality chains

For blockchains that do not have fast-finality, like Proof-Of-Work chains, it gets a bit trickier. For these chains, we use a special kind of proxy-chain called Peg-Zone.

A Peg-Zone is a blockchain that tracks the state of another blockchain. The Peg-Zone itself has fast-finality and is therefore compatible with IBC. Its role is to establish finality for the blockchain that it bridges. Let us take an example to better understand.

We want to bridge the Proof-Of-Work Ethereum blockchain so that it is possible to send tokens back and forth between Ethereum and Cosmos. Because Proof-Of-Work Ethereum does not have fast-finality, we need to create a Peg-Zone to bridge it.

First, the Peg-Zone needs to decide on a finality threshold for the origin chain. For example, it can consider that a given state of the origin’s chain is final when 100 blocks have been added after it. On the main Ethereum blockchain, a contract is deployed. It is this specific contract that is tracked by the Peg-Zone. When users want to send tokens from Ethereum to Cosmos, they actually send tokens to this contract. Then, the contract freezes the assets and, 100 blocks after, a representation of these assets is released on the Peg-Zone. A similar mechanism is used to send assets back to the Ethereum chain. Interestingly enough, the Peg-Zone also allows us to send any token that lives on Cosmos to the Ethereum chain (the Cosmos tokens being represented as ERC20 on the Ethereum chain). The Tendermint team is currently working on a Peg-Zone implementation for the Ethereum chain called Peggy.

The problem with Peg-Zones is that they need to be customized for the particular chain they bridge. Building an Ethereum Peg-Zone is relatively simple because Ethereum is account-based and has smart-contracts, but building a Bitcoin Peg-Zone is a bit more challenging. Explaining how to build a Bitcoin-like Peg-Zone is out-of-scope for this article, but know that it is theoretically possible. If you want to learn more about Peg-Zones, you can take a look at this spec.

Connecting the Ethereum blockchain via a Peg-Zone

Cosmos-SDK

Up until now, we have presented a set of tools designed to:

1. Make it easy and fast to develop blockchains with Tendermint and the ABCI
2. Make these blockchains interoperable with IBC and Peg-Zones

But is it easy enough to develop blockchains yet? At this point, developers only have to work on the application layer of the blockchain thanks to Tendermint Core, which is already a big improvement in itself. But we can do better.

Developing a blockchain application is not a trivial task. This is why the Cosmos-SDK exists. The Cosmos-SDK is a generalized framework to build secure blockchain applications on top of Tendermint. It is based on two major principles:

• Composability: The goal of the Cosmos-SDK is to create an ecosystem of modules that allow developers to easily spin up sidechains without having to code every single functionality of their application. Anyone can create a module for the Cosmos-SDK, and using already-built modules in your blockchain is as simple as importing them into your application. For example, the Tendermint team is building a set of basic modules that are needed for the Cosmos Hub, like staking, IBC, and governance. These modules can be used by any developer who wants to develop the application layer of a Tendermint blockchain. As a developer, you only have to create the specialized modules required by your application that do not already exist. As the Cosmos network develops, we expect the module ecosystem to gracefully expand, making it easier and easier to develop complex blockchain applications. A tutorial explaining how to code a Cosmos-SDK module will be available soon.
• Capabilities based security: Capabilities constrain the security boundaries between modules, enabling developers to better reason about the composability of modules and limit the scope of malicious or unexpected interactions. For a deeper look at capabilities, you can read this cool article. We will also release an article detailing the use of capabilities based security in the SDK soon

Simplified architecture of a Cosmos-SDK based blockchain

The Cosmos-SDK also comes with a set of nice tools like Command-Line Interface, REST Server, as well as a bunch of useful libraries like HSM libraries.

What is the tradeoff? For now, the Cosmos-SDK only exists in Golang. This means you will have to code your application in Go if you want to use it. In the future, we expect that the SDK will be implemented in other programming languages. For now, if you don’t want to use Go, you will have to build an ABCI application from scratch. Note that if you want to use Javascript, we have a cool alternative framework called LotionJS.

One final remark: the Cosmos-SDK, like all Cosmos tools, was designed to be modular. Today, it allows developers to build on top of the Tendermint consensus engine. However, it can be used with other consensus engines. As time goes by, we expect multiple SDKs to emerge, built with different architecture models and compatible with multiple consensus engines. All within a single ecosystem: Cosmos.

Scalability

Now that we can easily create and connect blockchains, what is left? You probably guessed it from reading the section’s title: Scalability. Today’s blockchains don’t scale, and that has become one of the biggest pain points of the blockchain ecosystem, if not the biggest.

Cosmos leverages two types of scalability:

• Vertical scalability: This encompasses the methods for scaling the blockchain itself. By moving away from Proof-Of-Work and optimising its components, Tendermint Core can attain thousands of transactions per-second. The bottleneck factor really is the application itself. So, for example, an application like a Virtual Machine (e.g. the Ethereum Virtual Machine) will impose a much lower limit on the transaction throughput than an application where transaction types and state transition functions are directly embedded in it (e.g. a standard Cosmos-SDK application). This is one of the reasons why application-specific blockchains make sense (find out the other reasons here).
• Horizontal scalability: Even if the consensus engine and the application are highly optimised, at some point, the transaction throughput of a single chain inevitably hits a wall it can’t surpass. That’s the limit of vertical scaling. To go beyond it, we have to introduce multi-chains architectures. The idea is to have multiple parallel chains running the same application and operated by a common validator set, making blockchains theoretically indefinitely scalable. Details about horizontal scalability are fairly complex and out-of-scope for this article.

Cosmos will offer vertical scalability at launch, which will be a major scalability improvement in itself. Later, horizontal scalability solutions will be implemented.

At this point, some might be wondering: Why bother creating a blockchain when I can just deploy my decentralised application on top of an Virtual-Machine blockchain and make this underlying blockchain scale? This is a justified question, considering that most decentralised application today are developed on top of Virtual-Machine blockchains like Ethereum. We believe this is mainly due to the fact that up until now, blockchains were much more difficult to develop than Smart Contracts. But not anymore! Thanks to the Cosmos-SDK, you can easily deploy application-specific blockchains. To learn more about application-specific blockchains and why they make sense, you can read this post. Of course, if you don’t want to build your own blockchain, you can still make your Smart Contracts compatible with Cosmos by deploying them on Ethermint.

Cosmos in 3 points

We have covered most of the building blocks of Cosmos. Let us try to recap and summarise what Cosmos is about in three concise points:

1. Make blockchains powerful and easy to develop with Tendermint and the modularity of the Cosmos-SDK
2. Enable blockchains to transfer value with each other with IBC and Peg-Zones, while retaining their sovereignty
3. Make blockchain applications scalable with both horizontal and vertical scalability.

More than anything, Cosmos is not a product. It is an ecosystem built on a set of modular, adaptable and interchangeable tools. Developers are encouraged to join the effort to improve existing tools and create new ones to make the original promise of blockchain technology a reality. These tools are the foundation needed to create the decentralised internet and global financial system of tomorrow.

Back to Earth

Now that we have presented the Cosmos vision and given a sense of its potential, let us materialise it with a few concrete examples.

Fundraiser Zone

Let us say we want to build an ICO Zone on Cosmos. This Zone would be able to accept virtually any existing token while maintaining transparency and decentralised custody for backers. Also, it would scale and not run concurrently to other decentralised applications. In short, users would be able to participate in all ICOs from a single, highly-performant platform.

We want to ease our lives as developers and therefore choose to build on top of the Cosmos-SDK. Our ICO Zone is a public Proof-Of-Stake Zone, which means it needs the following modules:

• Staking: To handle Proof-Of-Stake
• Accounts and Bank: To keep track of each user’s coins
• Governance: To manage upgrades and contentious issues
• IBC: To send and receive tokens

We are lucky! These are already available, we don’t need to code them again. The only thing we need to do is to create an ICO module for our specific application. This shouldn’t be too hard! (A tutorial on how to code a SDK-module will be available soon).

And that is it! Coding a fully-fledged public, interoperable and scalable blockchain just boiled down to coding a simple module. Now we still have to develop the front-end for our blockchain application, but this is not the hardest part.

If we are nice, we can also open source and document our ICO module, so that other developers can import it in their application to support its functionalities.

Decentralised Exchange

A decentralised exchange is the holy grail of cryptocurrency exchanges. With such an exchange, users would always be in control of their funds, unlike current centralised exchanges where users entrust their funds with exchange operators.

Building a decentralised exchange on Cosmos is fairly simple. The blockchain part of the exchange will deal with funds custody and clearing. As for order matching, it will still be handled by centralised operators to allow for a satisfying user experience and deep order book (see this doc for more background on this model).

We want our decentralised exchange to support FIAT-token. The problem with FIAT-token is that they are submitted to regulations, and therefore can’t be emitted on public blockchains. As a result, our decentralised exchange will have a 2-chains infrastructure. One chain will be a private Proof-Of-Authority chain that handles FIAT-tokens, and the other will be a public Proof-Of-Stake chain for crypto-to-crypto trading, both running on top of Tendermint Core. These two chains will be connected together and to the Cosmos Hub via IBC connexions.

Now what do we need to do to build such a complex infrastructure? Not much, actually. The staking, governance, accounts, bank and IBC modules that we need already exist. What we need to code is:

• A Proof-Of-Authority module: To have private validator set for our FIAT-chain.
• A FIAT-token module: To handle emission and transfer of FIAT-tokens according to the regulations of my specific jurisdiction.
• A settlement module: To allow settlement of trades between tokens on both chains

With these three modules, we have the building blocks we need to deploy the base blockchain layer of our decentralised exchange architecture.

Local currencies

Let us say 7 US states want to launch their local currencies. In each state, a blockchain would be operated between cities to manage the local currency of the state. Building such a blockchain on Cosmos would be super easy. The modules account, bank and governance already exist. All that is left is to build a Proof-Of-Authority module to enable cities of a given state to run a private chain between each other.

Now let us say that these 7 states want to interoperate with each other. Easy! All they need to do is deploy a local Hub between them. We would now have 7 blockchains, one in each state, and one Hub that connects them all. All that each state-level blockchain would need to do is import the IBC module and establish a connexion with the Hub.

At this point, the 7 local currencies can flow between the 7 states. But what if these states now want to interoperate with public cryptocurrencies? Nothing complicated: The local Hub just needs to establish an IBC connexion with the Cosmos Hub, and that’s it. Once this connexion is established, public cryptocurrencies can flow through the local Hub to reach the 7 state blockchains. This design has one big advantage: if the Cosmos Hub went down for some reason, the local Hub would still be functioning. The blockchains of the 7 states would not be able to transfer tokens to blockchains connected via the Cosmos Hub, but they would still be able to transact between each other through their local Hub. That is the power of IBC, which allows blockchains to interoperate without losing their sovereignty.

Conclusion

These are but a few examples. The potential for Cosmos applications is virtually infinite. Cosmos is designed to be modular, adaptable and scalable. It exists to make the promise of blockchain a reality. Whatever your blockchain use case may be, you will find tools to easily build it on Cosmos. This is not a promise that may come true in a few years, this is available now.

Social Channels

If you have general questions, ask them on:

• Telegram: t.me/CosmosProject
• Reddit: reddit.com/r/CosmosNetwork

If you’re thinking about becoming a validator, visit:

• Discord: forum.cosmos.network

If you’re thinking about building an application-specific blockchain and have technical usage questions about the Cosmos-SDK, ask them on Riot:

• Riot: riot.cosmos.network

If you just want to be entertained or to absorb knowledge, your best resources are:

• YouTube: youtu.be/CosmosNetwork
• Twitter: twitter.com/cosmos