Digging into the Cosmos Stack

By Alex Ausmus

After discovering the functionality of application-specific blockchains (ASBCs), the next question is, “how are ASBCs made possible?” There are a handful of open-source frameworks useful for developing independent blockchains, one of which is the Cosmos stack –– made up of the Cosmos SDK, Tendermint Core, and the Inter-Blockchain Communication Protocol (IBC). Here we will dig a little deeper into the tech stack that the Cosmos ecosystem is built on.

Cosmos is an ecosystem of ASBCs, built using the Cosmos SDK, which are able to easily communicate via the IBC. By using the Cosmos stack, developers can more easily create their own blockchain dedicated to a specific application. These three softwares that make up the Cosmos stack allow for: 

1) the modular composition of ASBCs, 

2) the implementation of a battle-tested consensus engine, and 

3) the ability to communicate with other IBC-enabled blockchains. 

The vision of Cosmos is to be the ‘Internet of Blockchains,’ allowing for any independent blockchain to begin interacting with others that are IBC-enabled. This broader IBC-enabled ecosystem is referred to as The Interchain. 

For a refresher on ASBCs and the Cosmos ecosystem, read our post. 

The Cosmos SDK is an open-source software development kit for building proof of stake & proof of authority blockchains. The goal of the Cosmos SDK is to provide developers with generic and composible tooling for the creation of ASBCs. 

The building blocks provided by the Cosmos SDK are designed so that they can be forked, tweaked, and improved without losing compatibility within the ecosystem. Cosmos SDK-based blockchains are built using composable modules, most of which are open-source and available for any developer to use. SDK modules handle nearly all application-related processes and business logic, while Tendermint Core handles consensus, networking, and the lower-level wiring needed for module composability. 

There are a number of modules available within the Cosmos GitHub repository that address generic functionalities, such as accounts, staking, and token management. This allows application developers to focus on creating modules specifically for their needs rather than mulling over the basic requirements of a blockchain. With an ever-growing library of robust, open-source SDK modules, the Tendermint ecosystem is making it increasingly easier to build complex blockchain applications.

In an ecosystem built on a library of modules, the network needs to address the eventual issue of faulty or malicious modules. The Cosmos SDK is built in a way that makes it a capabilities-based system, allowing developers to better reason about the security interactions between modules. 

Capabilities-based security is a design concept that designates authority based on a possession of access key. In this type of system, modules hold a series of keys that grant permissions to interact with other modules. In contrast, the more traditional system for delegating authority is an access control list (ACL), a list that each module holds which correlates permissions with identification. The difference between these two systems is like that of giving each hotel visitor a unique key that only opens the rooms they need vs. giving each visitor a general key to the hotel and enforcing permission to enter at each door. 

The overall goal of capabilities-based systems is to reduce the risk of security issues occurring by designating the least authority to perform a task. This doesn't make complications impossible but limits the scope of unexpected interactions.

Tendermint Core is an application-agnostic consensus engine that can be used to handle the networking and consensus layers of a blockchain. The software is Byzantine Fault Tolerant (BFT), which means that  the network can still perform as expected if up to ⅓ of the network’s bonded stake goes offline or acts in a malicious manner. Because Tendermint-based blockchains favor correctness over liveness, if more than ⅓ of the network’s bonded stake goes offline for a significant period of time or acts malicious the network will halt and require manual intervention from the community to fork the chain and address the issue. 

Any Tendermint-based chain has a hard-coded limit of 10,000 validators, but most protocols elect to set their own limit at 100-300 active validators. While the number of validators on Tendermint-based chains is relatively low, this does not necessarily mean that they are less decentralized or secure than chains with a higher validator count.

Cardano’s stake pool saturation limit and Polkadot’s Nominated PoS mechanism increase the number of validators in the network but don’t necessarily increase the amount of independent node operators. In these networks, large stakeholders encounter a practical maximum stake per validator (in terms of potential rewards earned) and are encouraged to run multiple validators rather than just one. 

Tendermint’s consensus does not have such an incentive. Simply increasing the size of the active validator set does not directly improve security, as the long-tail of smaller validators add only marginal additional security due to their smaller stake. What is most important in Tendermint-based chains is encouraging the equitable distribution of stake amongst validators, and increasing the total amount staked overall, while gradually increasing the active validator set. Tendermint-based chains typically aim to help smaller validators bootstrap operationally before considering expanding the active set.

Rather than probabilistic finality, the finality method commonly seen in other chains (such as Bitcoin and Cardano) in which a block is considered final as more blocks are created after it, Tendermint provides absolute finality, meaning that a block is considered finalized once it is accepted by network peers. This requires a block to be accepted by enough validators to represent ⅔ of the bonded stake on the network. The process is continuous unless ⅓ or more of the network’s bonded stake become unresponsive — in which case the network is unable to finalize blocks, and consensus will halt until either validators controlling >⅔ of bonded stake are online or the chain is forked with the overall set of validators changed. The latter is what would need to happen to restart the chain in extreme circumstances. Tendermint makes the compromise of availability for consistency during emergency situations, making natural forking of the network impossible via absolute finality while requiring a hard fork in emergency situations.

In order to integrate the application logic with the consensus and P2P networking layers, Tendermint Core also contains the Application Blockchain Interface (ABCI). The role of the ABCI is to relay the necessary information between Tendermint Core and the application logic. Tendermint Core doesn’t need to understand what the state of the application means, or what’s in its transactions — it just needs to be able to validate the blockchain’s state transitions and update the state accordingly. In order to do this, the ABCI maintains four connections for handling different message types:

• Consensus connections communicate when a new block is committed and all info from the block

• Mempool connections are used to validate mempool transactions before broadcasting them or proposing blocks

• Info connections query the local state of the application without engaging in consensus (useful on start-up)

• State Sync connections offer application snapshots that help a node reach the head of the blockchain quicker

A powerful update, ABCI++, is bringing a number of changes to Tendermint Core’s consensus connection, giving applications more control over consensus. This initial ABCI design removes control of consensus and networking from the application logic. While this makes a more hardened connection, it limits interactions between the layers. 

By giving application logic more control over the consensus the application can add, remove, merge, and reorder transactions in a block in order to make them more efficient. This also makes front-running transactions from the mempool significantly more challenging. These are just a few examples of how applications using Tendermint Core will benefit from the technical improvements that ABCI++ offers. 

In order for an ecosystem of independent ASBCs to thrive, a reliable communication standard must be established and adopted.

The IBC is a module that provides reliable, ordered, and authenticated communication between IBC-enabled blockchains. The IBC doesn’t need to manage an entire chain’s data or verify new blocks, it just needs to verify that the state of a chain is accurately reflected in the data packet it communicates. In order to verify the information, the receiving blockchain’s IBC module uses a light client to authenticate the data before passing the information to the application.

Since a blockchain will need to implement a light client for each blockchain it connects to, a blockchain will likely have multiple IBC channels, each of which is a unique, independent connection between the two blockchains. You can learn more about how IBC sends data using channels in our post.

For a blockchain to reliably share data via IBC, instant finality, rather than probabilistic finality, is required. This is because if a sending blockchain finalizes a block with a transaction that sent a data packet to an invalid blockchain fork after locking up a token, there is no way to use the packet on the invalid blockchain fork to recover the funds on the sending blockchain.

Thus, instant finality is required to avoid situations like this that arise from the natural forking of probabilistic finality. While Tendermint Core provides instant finality, there are many blockchains and ecosystems which do not. IBC is not exclusive to Tendermint-based chains, but blockchains that use probabilistic finality can only interact with IBC-enabled chains using a bridge chain that escrows the tokens until probabilistic finality is reached. An example of such a bridge chain is the Gravity Bridge.  

Because IBC operates on a distributed network it is expected that data relayers will be faulty at times. Because of this the network must be able to handle a case of a data packet not reaching its final destination. Data packets must contain a timeout height or timestamp, after which the packet is no longer valid. A proof-of-packet timeout can be submitted to the sending chain if the timeout is reached. So, even if a faulty relayer becomes stuck when relaying data, the request will eventually timeout and roll back.

Chains that don’t want to use the Cosmos SDK can still participate in the IBC-enabled ecosystem dubbed “The Interchain,” thanks to the inter-chain standard (ICS) design documents. The ICS documentation is used to describe various protocols, standards, or features that are implemented in or proposed to the Cosmos ecosystem. The protocols that are required to participate in the IBC are located there so that any developer can adapt them to their unique blockchain.

The teams contributing to the Cosmos ecosystem have laid the foundation for a vast ASBC-based ecosystem by providing developers with open-source tooling with unique security and communication features. The effectiveness of this toolkit is just now being realized, as applications such as Terra and Osmosis have garnered significant traction. While the Cosmos stack has been around for quite some time, the ecosystem itself is only just beginning to take shape and is currently in a transitory stage: the goals laid out in the Cosmos whitepaper have been completed, and a new roadmap with fresh goals is currently being tackled. The developments planned in the roadmap aim to aid developers in creating more unique and powerful blockchain applications. 

Ultimately, this is the vision of Cosmos –– to aid developers in creating an internet of blockchains –– and it can only be approached by creating the tooling for developers to build, create, and grow their own ecosystems.