Technology

VALIDATORS

In classical Byzantine fault-tolerant (BFT) algorithms, each node has the same weight. In Tendermint, nodes have a non-negative amount of voting power, and nodes that have positive voting power are called validators. Validators participate in the consensus protocol by broadcasting cryptographic signatures, or votes, to agree upon the next block.

Validators’ voting powers are determined at genesis, or are changed deterministically by the blockchain, depending on the application. For example, in a proof-of-stake application such as the Cosmos Hub, the voting power may be determined by the amount of staking tokens bonded as collateral.

NOTE: Fractions like ⅔ and ⅓ refer to fractions of the total voting power, never the total number of validators, unless all the validators have equal weight. >⅔ means “more than ⅔”, ≥⅓ means “at least ⅓”.

CONSENSUS

Tendermint is a partially synchronous BFT consensus protocol derived from the DLS consensus algorithm. Tendermint is notable for its simplicity, performance, and fork-accountability. The protocol requires a fixed known set of validators, where each validator is identified by their public key. Validators attempt to come to consensus on one block at a time, where a block is a list of transactions. Voting for consensus on a block proceeds in rounds. Each round has a round-leader, or proposer, who proposes a block. The validators then vote, in stages, on whether to accept the proposed block or move on to the next round. The proposer for a round is chosen deterministically from the ordered list of validators, in proportion to their voting power.

The full details of the protocol are described here.

Tendermint’s security derives from its use of optimal Byzantine fault-tolerance via super-majority (>⅔) voting and a locking mechanism. Together, they ensure that:

≥⅓ voting power must be Byzantine to cause a violation of safety, where more than two values are committed.

if any set of validators ever succeeds in violating safety, or even attempts to do so, they can be identified by the protocol. This includes both voting for conflicting blocks and broadcasting unjustified votes.

Despite its strong guarantees, Tendermint provides exceptional performance. In benchmarks of 64 nodes distributed across 7 datacenters on 5 continents, on commodity cloud instances, Tendermint consensus can process thousands of transactions per second, with commit latencies on the order of one to two seconds. Notably, performance of well over a thousand transactions per second is maintained even in harsh adversarial conditions, with validators crashing or broadcasting maliciously crafted votes. See the figure below for details.

LIGHT CLIENTS

A major benefit of Tendermint’s consensus algorithm is simplified light client security, making it an ideal candidate for mobile and internet-of-things use cases. While a Bitcoin light client must sync chains of block headers and find the one with the most proof of work, Tendermint light clients need only to keep up with changes to the validator set, and then verify the >⅔ PreCommits in the latest block to determine the latest state.

Succinct light client proofs also enable inter-blockchain communication.

PREVENTING ATTACKS

Tendermint has protective measures for preventing certain notable attacks, like long-range-nothing-at-stake double spends and censorship.

ABCI

The Tendermint consensus algorithm is implemented in a program called Tendermint Core. Tendermint Core is an application-agnostic “consensus engine” that can turn any deterministic blackbox application into a distributedly replicated blockchain. Tendermint Core connects to blockchain applications via the Application Blockchain Interface (ABCI). ABCI is an interface that defines the boundary between the replication engine (the blockchain), and the state machine (the application). By using a socket protocol, we enable a consensus engine running in one process to manage an application state running in another. Thus, the ABCI allows for blockchain applications to be programmed in any language, not just the programming language that the consensus engine is written in. Additionally, the ABCI makes it possible to easily swap out the consensus layer of any existing blockchain stack.

We draw an analogy with the well-known cryptocurrency Bitcoin. Bitcoin is a cryptocurrency blockchain where each node maintains a fully audited Unspent Transaction Output (UTXO) database. If one wanted to create a Bitcoin-like system on top of ABCI, Tendermint Core would be responsible for

Sharing blocks and transactions between nodes

Establishing a canonical/immutable order of transactions (the blockchain)

Meanwhile, the ABCI application would be responsible for

Maintaining the UTXO database

Validating cryptographic signatures of transactions

Preventing transactions from spending non-existent funds

Allowing clients to query the UTXO database

Tendermint is able to decompose the blockchain design by offering a very simple API between the application process and consensus process.

Source.

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 SDK exists.

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.

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.

ETHERMINT

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.

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 application parts. 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.

Heterogeneous chains have different layers, meaning they can differ in how they implement the networking, consensus and application parts. 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.

Tracking

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.

Bonding

When the IBC transfer is initiated, the Atoms are locked up (bonded) on chain A.

Proof Relay

Then, a proof that the 10 Atoms are bonded is relayed from chain A to chain B.

Validation

The proof is verified on chain B against chain A’s header and, if it is valid, then 10 Atom-vouchers are created on chain B.

Note that the Atoms that have been created on chain B are not real Atoms, as Atoms only exist on chain A. They are a representation on B of Atoms from chain A, along with a proof that these Atoms are frozen on chain A.

A similar mechanism is used to unlock Atoms when they come back to their origin chain. For a more comprehensive description of the IBC protocol, you can look at this specification.

Designing the “Internet of Blockchains”

IBC is a protocol that allows two heterogeneous blockchains to transfer tokens to each other. From there, how do we create a network of blockchains?

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

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 designed to connect Zones together. When a Zone creates an IBC connection 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 connections with a restricted set of Hubs. Hubs also prevent double spending among Zones. This means that when a Zone receives a token from a Hub, it only needs to trust the origin Zone of this token and the Hub.

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

Bridging non-Tendermint chains

So far, the architecture of Cosmos we have presented shows how Tendermint-based chains can interoperate. But 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 any 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, things get a bit trickier. For these chains we use a special kind of proxy-chain called a 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 it bridges. Let us look at the following example.

Example: Ethereum Peg-Zone

We want to bridge the Proof-of-Work Ethereum blockchain to make it 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 act as a bridge between the two.

First, the Peg-Zone needs to decide on a finality threshold for the origin chain. For example, it can consider that a given block of the origin’s chain is final when 100 blocks have been added after it.

Second, a contract is deployed on the main Ethereum blockchain. When users want to send tokens from Ethereum to Cosmos, they start by sending tokens to this contract. Then the contract freezes the assets and after 100 blocks, 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 users to send any token that lives on Cosmos to the Ethereum chain (the Cosmos tokens would be represented as ERC20 on the Ethereum chain). The Tendermint team is currently working on a Peg-Zone implementation for the Ethereum chain called Peggy.

Peg-Zones will 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. However, building a Bitcoin Peg-Zone is a bit more challenging. If you want to learn more about Peg-Zones you can take a look at this spec.

Solving Scalability

Now that we can easily create and connect blockchains there is one final issue to tackle: Scalability. 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 optimizing its components, Tendermint Core can reach thousands of transactions per-second. The bottleneck factor is the application itself. 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 (read about more reasons here).

This encompasses the methods for scaling the blockchain itself. By moving away from Proof-of-Work and optimizing its components, Tendermint Core can reach thousands of transactions per-second. The bottleneck factor is the application itself. 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 (read about more reasons here). Horizontal scalability: Even if the consensus engine and the application are highly optimized, at some point the transaction throughput of a single chain inevitably hits a wall it cannot surpass. That is the limit of vertical scaling. To go beyond it, the solution is to move to multi-chain architectures. The idea is to have multiple parallel chains running the same application and operated by a common validator set, making blockchains theoretically infinitely scalable. Details about horizontal scalability are fairly complex and out-of-scope for this intro.

Cosmos will offer very good vertical scalability at launch, which will be a major improvement over current blockchain solutions in and of itself. Later, after the completion of the IBC module, horizontal scalability solutions will be implemented.

Source.