Application-specific blockchains and the Cosmos Ecosystem

By Alex Ausmus, Protocol Analyst at Coinbase Cloud

For blockchain application developers, there are a series of parameters that are typically beyond their control — those that have to do with the underlying blockchain architecture. Recent developments in blockchain tooling have provided developers with an easier route toward creating a blockchain with decentralized applications built-in, commonly referred to as an ‘application-specific blockchain.’

A handful of stable blockchain frameworks have been developed over the past few years. In this article, we will focus on the approach that Cosmos takes toward developing application-specific blockchains (ASBCs).

The Cosmos ecosystem encompasses all blockchains built using any version of the Cosmos software development kit (SDK). The Cosmos SDK is part of the ‘Cosmos Stack’ which is a software trio including: 

1. Tendermint Core, a pre-constructed consensus engine, 

2. Cosmos SDK, a software development kit, and

3. IBC, a network communication protocol.

Currently, the core Cosmos software is maintained and supported by three parties: Interchain GmbH, Informal Systems, and Regen Network. Initially, much of the software for the Cosmos ecosystem was built by the company Tendermint (aka All in Bit Inc.) which now focuses most of its efforts on the Gravity DEX and Starport.

Tendermint Core is the consensus engine that powers blockchains native to the Cosmos ecosystem. It also includes the P2P networking layer, Application Blockchain Interface (ABCI), and many other modules needed to build a blockchain. By providing this foundation for developers to easily generate their own consensus and networking layers, teams can turn their engineering focus to their applications. 

To help facilitate the development of applications built using Tendermint Core, the Cosmos SDK was developed. The Cosmos SDK is a development kit for building the application layer of a Tendermint-based blockchain, composed of a number of generic modules used for a blockchain’s most common functions such as creating accounts, staking, and token management.

Developers can use modules created by the supporting teams, those that have been created by other teams, and their own modules developed in-house, to compose a unique ASBC that suits their needs. Essential to these modules is their composable nature, which is achieved thanks to the way that Tendermint Core integrates modules. In this context, Tendermint Core acts like an old telephone switchboard — it is the backend service that connects and routes the information properly.

The third software in the stack is the Inter-Blockchain Communication Protocol (IBC), a module within the Cosmos SDK that allows for independent communication between sovereign blockchains. This protocol is different from the networking layer provided in Tendermint Core. The IBC allows sovereign blockchains to send and receive data/information from other independent blockchains, whereas the Tendermint Core networking layer is the P2P network that allows nodes within a blockchain to communicate and reach consensus. IBC standardizes the way in which a message should be sent to another blockchain. This is similar to how SMS messages have been standardized so that phones of various brands and operating systems can communicate with each other without much effort from the sender or receiver. To learn more about IBC, how it works, and why it’s important, read our article on IBC.

A blockchain can be thought of as having three layers: consensus, peer-to-peer (P2P) networking, and the application layer. For developers, building a new consensus and P2P networking layer in the pursuit of an ASBC is overburdening. The tooling found in the Cosmos Stack expedites development of ASBCs by providing an easy to use, composable framework — the Cosmos SDK. This framework allows developers to easily generate consensus and networking layers based on Tendermint Core, which they can then use as a platform to build their application on. 

By abstracting away production of the lower layers of an ASBC, development teams can focus more on the application itself and which consensus and networking parameters would best suit the application, instead of focusing resources on building the lower layers.

Source

There are two flavors of application layers that can be used on a blockchain. The traditional route makes use of a virtual machine (e.g. the Ethereum Virtual Machine, or EVM) for the creation of smart contracts which are then uploaded to a single blockchain. This route requires a generalized virtual machine which allows for the creation of vastly different applications. While having a generalized application layer is great for a variety of applications, the application developers are limited in what parameters they can change related to the consensus and networking layers.

Networks that embrace the ASBC design philosophy often provide teams the tooling needed to instead easily create their own blockchain dedicated to a specific application. Rather than having a virtual machine compiling applications for the blockchain, the application can be built into the core computational logic of an ASBC, and each application can have its own sovereign blockchain. 

Developer teams now have the choice between launching their application on an existing blockchain or creating their own blockchain to house their application. However, the decision is quite nuanced and requires consideration from multiple perspectives.

The main tradeoff between building on an existing blockchain and developing an ASBC can be distilled down to the simplicity of development vs. customizability of an application. 

• While the Cosmos Stack significantly simplifies the development of a blockchain, building a new blockchain is still very involved. 

• In contrast, building on an existing blockchain entails creating and deploying a number of smart contracts with little to no control over the underlying blockchain infrastructure. 

• When creating their own blockchain, the development team must not only consider the anatomy of the application but also the infrastructure and security considerations of launching and maintaining an independent blockchain.

Creating an ASBC also pushes into a less explored territory. On existing blockchains, such as Ethereum, there are plenty of examples of working products that developers can look to for inspiration. It’s even possible to fork an existing application and launch a new application in a very short amount of time. However, while it is convenient to develop on an existing blockchain, there are a number of improvements found in having a blockchain dedicated to a specific application. 

The most promising advantage that ASBCs have over a single blockchain ecosystem is sovereignty. Typically, the types of actions that an application can take are reliant on the underlying blockchain’s consensus participants’ ability to validate the actions. Since the application runs within a general-purpose virtual machine, it has little governance influence over the virtual machine running the application as it is dictated by the greater blockchain validator community. An application team can only make alterations to the smart contracts it uses; it is impossible to change the consensus and networking mechanics of the network overall unless the larger community agrees that it will benefit the entire network. 

If an application would benefit from having control over its underlying blockchain mechanics, an ASBC might be better suited. For example, on Ethereum today, it is possible to generate representative tokens for staked ETH (such as stETH), but there is no way to stake ETH tokens that have already been locked in DeFi applications. Osmosis, an ASBC-based decentralized exchange developed using the Cosmos-SDK, can do just that because it has control over consensus. Called superfluid staking, it will enable OSMO and other protocol tokens that are providing liquidity in the Osmosis AMM to also be staked to Osmosis validators, provide security to the blockchain, and earn staking rewards on top of their LP rewards. Developing such a unique utility is feasible because the application is closely integrated with, and has complete sovereignty over, its own consensus and networking layers. 

Source

By having a dedicated blockchain and set of validators for an application, the goals of the application and the underlying blockchain are aligned, and changes to the consensus and networking mechanics are more easily realized. Giving an application total control over its own blockchain provides a number of potential performance benefits. In an ecosystem of ASBCs, there is less competition for computation and storage resources, since each application has its own set of validators.

If these ASBCs are interoperable and can communicate with each other natively — as is the case in the Cosmos ecosystem — sovereign blockchains can run independently while still interacting with each other, creating an ecosystem. Cosmos, specifically, follows a hub-and-spoke model where different ASBCs (referred to in Cosmos as zones) are able to communicate with a central hub blockchain (the Cosmos Hub) which can route data and information to other zones. 

Blockchains in the Cosmos ecosystem tend to focus on building out their application while developing a strong, albeit small, validator set, which can be grown as it is needed. However, the small validator count can be reason for concern, especially in an environment of malicious validators. It is possible that if the top validators were to collude that they could control the network, as is the case with most PoS networks. 

Another consideration for the security of ASBCs is that the attack surface of each application is much smaller compared to an application built on a general-purpose blockchain. There is also the flexibility to use tailor-made cryptography, or well-audited libraries, rather than what is made available by the virtual machine.

The tradeoffs and advantages in choosing to develop an ASBC over working with an existing virtual machine-based blockchain are multifaceted. When making this decision it is important to look at the application and ecosystem from many different perspectives, and to consider all potential use cases before committing to development.

While Cosmos has been the focus of this article, there are many other frameworks for developing ASBCs. Polkadot is the most comparable ecosystem to Cosmos. Developers in the Polkadot ecosystem make use of the Substrate framework, which also allows the use of modules to compose applications, similar to the Cosmos SDK. 

Polkadot differs from Cosmos in a number of ways, but the main differences are in their approach to shared security, membership, governance, and consensus. Polkadot’s ASBCs, or parachains, outsource security and some resources to their main relay chain and, thus, are reliant on the relay chain for operation. Much like choosing between building on an ASBC or an established blockchain, differences in framework abilities determine what functionalities a blockchain within each ecosystem can have. This topic is worthy of an entire article itself and, as such, is outside of the scope of this article. 

Another provider of blockchain development tooling is Polygon, which is best known for their Ethereum scaling solutions, such as their EVM-compatible sidechain. Alongside their flagship PoS sidechain, Polygon also provides a number of Ethereum-compatible rollups (Polygon Hermez), a general-purpose data availability-focused blockchain (Polygon Avail), and a modular framework for building Ethereum-compatible blockchains (Polygon Edge). Thus, Polygon provides tooling for those interested in building their own dedicated blockchain architecture within the Ethereum ecosystem.

There are many other examples of platforms for ASBCs to be built on. It’s important to keep in mind that this is not likely a winner-takes-all kind of game; it is important to not only think about interoperability within a specific ASBC, but also between platforms, such as Cosmos, Polkadot, and Ethereum.

Choosing which ecosystem to launch an application in is one of a developer’s most important decisions. For example, Ethereum is the unofficial home of NFTs so it is important for NFT-based applications, such as Axie Infinity's Ronin sidechain or Immutable X’s rollup, to stay within the Ethereum ecosystem. However, as the Ethereum mainnet is not able to match the scalability needs of these two applications, they have decided to build the architecture that meets their needs while still being within the Ethereum ecosystem as a layer 2 network. These application teams saw benefits in having dedicated architecture but also needed to develop in an ecosystem that is best suited for their application.

Choosing which ecosystem to develop an application within requires a holistic approach, rather than making a decision purely on the tech involved, as the technical design details are much easier to sort out than the challenges of launching in an unfitting ecosystem.

It’s common to hear that ‘the future is multichain’ and with such technology coming to fruition, the path to that future is clearer than ever. With the development of tooling used to create independent blockchains readily available, ASBC ecosystems are much more practical today than even just a few years ago. While we are just now beginning to see ASBC ecosystems kick off, it is likely that ASBC ecosystems will be essential to an effective and efficient multichain future.