Strictly speaking, Cosmos is a decentralized network of independent parallel blockchains, each powered by BFT consensus algorithms like Tendermint consensus.
In other words, Cosmos is an ecosystem of blockchains that can scale and interoperate with each other. Before Cosmos, blockchains were siloed and unable to communicate with each other. They were hard to build and could only handle a small amount of transactions per second. Cosmos solves these problems with a new technical vision. In order to understand this vision we need to go back to the fundamentals of blockchain technology.
What is a Blockchain?
A blockchain can be described as a digital ledger maintained by a set of validators that remains correct even if some of the validators (less than a third) are malicious. Each party stores a copy of the ledger on their computer and updates it according to the rules defined by the protocol when they receive blocks of transactions. The goal of blockchain technology is to make sure the ledger is correctly replicated, meaning that each honest party sees the same version of the ledger at any given moment.
The main benefit of blockchain technology is the ability for parties to share a ledger without having to rely on a central authority. Blockchains are decentralized. The first and most famous application of blockchain technology today is Bitcoin, a decentralized currency.
Now that we have a better understanding of what a blockchain is from a high-level perspective, let us look at the definition of blockchain with a more technical angle. A blockchain is a deterministic state machine replicated on full-nodes that retains consensus safety as long as less than a third of its maintainers are Byzantine. Let’s break this down.
- A state machine is just a fancy word for a program that holds a state and modifies it when it receives inputs. There is a state, which can represent different things depending on the application (e.g. token balances for a cryptocurrency), and transactions, that modify the state (e.g. by subtracting balances from one account and adding them to another).
- Deterministic means that if you replay the same transactions from the same genesis state, you will always end up with the same resultant state.
- Consensus safety refers to the fact that every honest node on which the state machine is replicated should see the same state at the same time. When nodes receive blocks of transactions, they verify that it is valid, meaning that each transaction is valid and that the block itself was validated by more than two thirds of the maintainers, called validators. Safety will be guaranteed as long as less than a third of validators are Byzantine, i.e. malicious.
From an architecture standpoint, blockchains can be divided into three conceptual layers:
- Application: Responsible for updating the state given a set of transactions, i.e. processing transactions.
- Networking: Responsible for the propagation of transactions and consensus-related messages.
- Consensus: Enables nodes to agree on the current state of the system.
The state machine is the same as the application layer. It defines the state of the application and the state-transition functions. The other layers are responsible for replicating the state machine on all the nodes that connect to the network.
How does Cosmos fit in the broader blockchain ecosystem?
THE BITCOIN STORY (BLOCKCHAIN 1.0)
To understand how Cosmos fits in the blockchain ecosystem, we need to go back to the beginning of the blockchain story. The first blockchain was Bitcoin, a peer-to-peer digital currency created in 2008 that used a novel consensus mechanism known as Proof-of-Work (PoW). It was the first decentralized application on a blockchain. Soon, people started to realize the potential of decentralized applications and the desire to build new ones emerged in the community.
At the time, there were two options to develop decentralized applications: either fork the bitcoin codebase or build on top of it. However, the bitcoin codebase was very monolithic; all three layers—networking, consensus and application — were mixed together. Additionally, the Bitcoin scripting language was limited and not user-friendly. There was a need for better tools.
THE ETHEREUM STORY (BLOCKCHAIN 2.0)
In 2014, Ethereum came in with a new proposition for building decentralized applications. There would be a single blockchain where people would be able to deploy any kind of program. Ethereum achieved this by turning the Application layer into a virtual machine called the Ethereum Virtual Machine (EVM). This virtual machine was able to process programs called smart contracts that any developer could deploy to the Ethereum blockchain in a permissionless fashion. This new approach allowed thousands of developers to start building decentralized applications (dApps). However, limitations to this approach soon became apparent and still persist to this day.
Limitation #1: Scalability
The first limitation is scaling - decentralized applications built on top of Ethereum are inhibited by a shared rate of 15 transactions per second. This is due to the fact that Ethereum still uses Proof-of-Work and that Ethereum dApps compete for the limited resources of a single blockchain.
Limitation #2: Usability
The second limitation is the relatively low flexibility granted to developers. Because the EVM is a sandbox that needs to accommodate all use cases, it optimizes for the average use case. This means that developers have to make compromises on the design and efficiency of their application (for example, requiring use of the account model in a payments platform where a UTXO model may be preferred). Among other things, they are limited to a few programming languages and cannot implement automatic execution of code.
Limitation #3: Sovereignty
The third limitation is that each application is limited in sovereignty, because they all share the same underlying environment. Essentially, this creates two layers of governance: that of the application, and that of the underlying environment. The former is limited by the latter. If there is a bug in the application, nothing can be done about it without the approval of the governance of the Ethereum platform itself. If the application requires a new feature in the EVM, it again has to rely entirely on the governance of the Ethereum platform to accept it.
These limitations are not specific to Ethereum but to all blockchains trying to create a single platform that would fit all use cases. This is where Cosmos comes into play.
THE VISION OF COSMOS (BLOCKCHAIN 3.0)
The vision of Cosmos is to make it easy for developers to build blockchains and break the barriers between blockchains by allowing them to transact with each other. The end goal is to create an Internet of Blockchains, a network of blockchains able to communicate with each other in a decentralized way.With Cosmos, blockchains can maintain sovereignty, process transactions quickly and communicate with other blockchains in the ecosystem, making it optimal for a variety of use cases.
This vision is achieved through a set of open source tools like Tendermint, the Cosmos SDK and IBC designed to let people build custom, secure, scalable and interoperable blockchain applications quickly. Let us take a closer look at some of the most important tools in the ecosystem as well as the technical architecture of the Cosmos network. Note that Cosmos is an open source community project initially built by the Tendermint team. Everyone is welcome to build additional tools to enrich the greater developer ecosystem.
What is Tendermint Core and the ABCI
Until recently, building a blockchain required building all three layers (Networking, Consensus, and Application) from the ground up. Ethereum simplified the development of decentralized applications by providing a Virtual-Machine blockchain on which anyone could deploy custom logic in the form of Smart Contracts. However, it did not simplify the development of blockchains themselves. Much like Bitcoin, Go-Ethereum remains a monolithic tech stack that is difficult to fork from and customize. This is where Tendermint, created by Jae Kwon in 2014, came in.
Tendermint Core is a solution that packages the networking and consensus layers of a blockchain into a generic engine, allowing developers to focus on application development as opposed to the complex underlying protocol. As a result, Tendermint saves hundreds of hours of development time. Note that Tendermint also designates the name of the byzantine fault tolerant (BFT)consensus algorithm used within the Tendermint Core engine. For more on the history of consensus protocols and BFT you can check this cool podcast by Tendermint co-founder Ethan Buchman.
The Tendermint Core engine is connected to the application by a socket protocol called the Application Blockchain Interface(ABCI). This protocol can be wrapped in any programming language, making it possible for developers to choose a language that fits their needs.
But that is not all. Here are the properties that make Tendermint Core a state-of-the-art blockchain engine:
- Public or private blockchain ready: Tendermint Core only handles networking and consensus for a 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 Core engine. If the application defines that validators are elected based on how many tokens they have at stake, then the blockchain can be characterised as Proof-of-Stake (PoS). If however the application defines that only a restricted set of pre-authorized entities can be validators, then the blockchain can be characterised as permissioned or private. 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 handle up to thousands of transactions per second.
- Instant finality: A property of the Tendermint consensus algorithm is instant finality. This means that forks are never created as long as more than a third of the validators are honest (byzantine). Users can be sure their transactions are finalized as soon as a block is created (which is not the case in Proof-of-Work blockchains like Bitcoin and Ethereum).
- Security: Tendermint consensus is not only fault tolerant, it is also accountable. If the blockchain forks, there is a way to determine liability.
Cosmos SDK and other application layer frameworks
Tendermint Core reduces the development time of a blockchain from years to weeks, but building a secure ABCI-app from scratch remains a difficult task. This is why the Cosmos SDKexists.
The Cosmos SDK is a generalized framework that simplifies the process of building secure blockchain applications on top of Tendermint Core. It is based on two major principles:
- Modularity: The goal of the Cosmos SDK is to create an ecosystem of modules that allows developers to easily spin up application-specific blockchains without having to code each bit of functionality of their application from scratch. Anyone can create a module for the Cosmos SDK, and using ready 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. These modules can be used by any developer as they build their own application. Additionally, developers can create new modules to customize their application. As the Cosmos network develops, the ecosystem of SDK modules will expand, making it increasingly easier to develop complex blockchain applications.
- 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 click here.
The Cosmos SDK also comes with a set of useful developer tools for building command line interfaces (CLI), REST servers and a variety of other commonly used utility libraries.
One final remark: the Cosmos SDK, like all Cosmos tools, is designed to be modular. Today, it allows developers to build on top of Tendermint Core. However, it can be used with any other consensus engines that implements the ABCI. 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: the Cosmos Network.
To learn how to code applications on top of the SDK you can check out this tutorial.
The great thing about the Cosmos SDK is that its modularity allows developers to port virtually any existing blockchain codebase already in Golang on top of it. For example, Ethermint is a project that ports the Ethereum Virtual Machine into an SDK module. Ethermint works exactly like Ethereum but also benefits from all the properties of Tendermint Core. All the existing Ethereum tools (Truffle, Metamask, etc.) are compatible with Ethermint and you can port your smart contracts over without additional work.
Why bother creating a blockchain with the Cosmos SDK when I can just deploy my decentralized application on top of a Virtual Machine blockchain?
This question is justified, considering that most decentralized applications today are developed on top of Virtual Machine blockchains like Ethereum. First, it should be stated that the reason for this phenomenon is that up until now blockchains were much more difficult to develop than Smart Contracts. This is not the case anymore, thanks to the Cosmos SDK. Now, developers can easily develop entire application-specific blockchains, which have several advantages. Among others, they give more flexibility, security, performance and sovereignty. To learn more about application-specific blockchains 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.
Connecting Blockchains Together - IBC
Now that developers have a way to quickly build customized blockchains, let us see how to connect these blockchains together. The connection between blockchains is achieved through a protocol called Inter-Blockchain Communication protocol (IBC). IBC leverages the instant finality property of Tendermint consensus (although it can work with any “fast-finality” blockchain engine) to allow heterogeneous chains to transfer value (i.e. tokens) or data to each other.
WHAT ARE HETEROGENEOUS CHAINS?
Essentially it comes down to two things:
- Different layers: Heterogeneous chains have different layers, meaning they can differ in how they implement the networking, consensus and applicationparts. To be compatible with IBC, a blockchain needs only follow a few requirements, the main one being that the consensus layer must have fast finality. Proof-of-Work chains (like Bitcoin and Ethereum) 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 blockchains these 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 heterogeneous blockchains to transfer tokens and data to each other, meaning that blockchains with different applications and validator sets are interoperable. For example, it allows public and private blockchains to transfer tokens to each other. Currently, no other blockchain framework enables this level of interoperability.
HOW IBC WORKS
The principle behind IBC is fairly simple. Let us take an example where an account on chain A wants to send 10 tokens (let us call them Atoms) to chain B.
Continuously, chain B receives the headers of chain A, and vice versa. This allows each chain to track the validator set of the other. In essence, each chain runs a light-client of the other.