The Application-Specific Chain Thesis

The wider Cosmos ecosystem has seen a renaissance in the past few weeks as both applications and builders have either made the decision to build their own application-specific chain or expressed interest in doing so. This comes after the demise of the Terra ecosystem, which also had some spill-over into the wider IBC ecosystem. However, what we think is important to note, is the fact that the entire stack, tech-wise, held up extremely well. It proved that despite incredibly volatile volume action that it was able to handle both internal and external transfers of messages and assets both through IBC cross-chain, but also on chains internally through the Cosmos SDK with Tendermint, ABCI and customized VMs. In this article, we aim to explain the thesis behind the rise of application-specific blockchains and why the sovereignty, composability and interoperability they bring are vital to building out the next “killer apps” and ecosystem(s) in the coming cycle.

Before we dive into the thesis itself, it’s very important that we’re on the same page, and as such, we’ll briefly be covering some of the various technical aspects that make the Cosmos ecosystem unique in an easily digestible way.

The overall architecture in Tendermint-based chains that use ABCI and the Cosmos SDK looks like this:

The Cosmos SDK is a set of modular tools that allow blockchain developers to build their application layer logic in a VM agnostic manner. The Cosmos SDK is designed to connect to Tendermint through ABCI. Beyond being the framework that allows for creating application-specific blockchains, it also allows for various customization options such as protocol-agnostic governance, transaction and staking mechanisms and much more. The SDK handles most of the tasks that are required on the application logic layer which means that developers aren’t required to build things completely from scratch. It handles transactions received from the Tendermint consensus engine via a router that sends messages to the appropriate processing modules alongside the state changes.

ABCI is the interface that connects the application part of the blockchain to the Tendermint state replication engine which provides the consensus and networking mechanisms. ABCI enables the splitting up of the blockchain stack, which means the application part of the blockchain can be virtual machine agnostic, and as such, any virtual machine and execution environment can be used for the application part of the stack. Examples of this are Junowasm, Cosmwasm, Agoric’s Hardened Javascript and even Secret’s version of Cosmwasm which allows for the usage of TEE. Tendermint itself creates three ABCI connections to the application part. These are the validation of transactions when broadcasted in the mempool, the connection between the application and the consensus engine for block proposals and the ability to query the application’s state.

The functionality of ABCI

Tendermint Core is what takes care of the consensus and network layer of chains in the Cosmos ecosystem. The consensus layer is what guarantees the validity and order of transactions through a consensus algorithm process between network participants, in Tendermint’s case - validators in a proof of stake setting. The network layer is responsible for facilitating peer-to-peer communications between nodes in the system and enabling third-party applications and nodes to interact with the consensus layer.

Tendermint uses a byzantine fault tolerant (BFT) consensus model and enables instant finality. The BFT process goes through three phases before the final commitment phase of the proposed blocks. These are the propose phase where a block is specified at a specific height, the prevote phase where 2/3rds of validators prevote for a proposed block and the pre-commit step where 2/3rds of validators pre-commit for the proposed block.

Tendermints’ BFT Process (Timeout: Small wait time to receive a proposal, or establish skip)

Inter-Blockchain Communication(IBC) is at its core a cross-chain messaging protocol for homogenous blockchains. This means that it connects chains that share similar functionalities, in this case, instant finality provided by the Tendermint consensus algorithm and ones that have light client functionality. The way IBC works is that two chains that are interested in having a connection with one another will put up a governance proposal on the destination chain. This is usually, to begin with, either through the Cosmos Hub or Osmosis (Currently Osmosis has 45 peers, and Cosmos 40). This means that there’s an agreement on a protocol level, and as such, there is no need for a trusted third party in an external bridge.

These two chains then require a light client on each other’s chain to cryptographically verify consensus state between the two chains, as well as a relayer to relay information between the light clients on the two chains. The relayers are required for liveness - the ability to be able to exchange messages among nodes, with the nodes successfully coming to a consensus. Let’s explore how this looks in practice:

This means that the trust assumption lies within the two validator sets of the connected blockchains, as such there are much fewer trust assumptions than other types of bridges and messaging protocols. For example, with XCMP in the Polkadot ecosystem, the trust assumption lies solely with the relay chain (Polkadot).

To show just how compatible and widespread IBC has become in the Cosmos ecosystem, and how many chains it connects - let’s take a look at a map of the current live connections.

Source: mapofzones.com

ICS stands for Interchain Standard and sets parameters for transactions happening between chains using IBC. ICSs are basically module specifications for IBC transactions. For two chains two communicate using IBC they’re required to possess the same ICS specifications.

One of the more interesting and unique ICSs is ICS-27, also known as Interchain Accounts.

Interchain Accounts enable composability as opposed to interoperability. They allow for chains to exchange not only data but also write state from one smart contract on one chain to another. This means that instead of requiring a user to move across various interfaces as an asset or message moves, he or she will be able to utilise a single interface on the source chain, as long as the transaction’s endpoint is specified.

ICS-27-enabled chains create accounts on other ICS-27-enabled chains and are able to control these accounts via IBC transactions. Interchain accounts keep all of the abilities of a normal account but are instead operated by a separate chain or end-user through IBC such that the owner on the source chain maintains complete control over any interchain accounts it enlists on destination chains.

When initialising an Interchain Account transaction you make use of IBC to send a non-IBC transaction (non-IBC transactions within an IBC transaction) - An example often given to illustrate this, is the concept of "a letter inside of an envelope inside of a box”

Interchain Accounts Transactions

The procedure after the IBC transaction happens in accordance with the ICS specifications that each chain is required to possess. This means that it allows transactions to go from being application-specific to being application-agnostic, in other words - it enables true composability across a range of different networks.

Interchain Security allows a Chain or Hub to produce blocks for other chains. Validators run two(or more) nodes, one on each chain, but only have to stake their native token on the main chain. This is enabled by Cross Chain Validation, which is an IBC-level protocol. The child chain uses IBC to communicate with the main chain to keep track of which validators are participating in Interchain Security using Cross Chain Validation. In this way, the security gained from the value of the stake locked on the main chain is shared with the child chain. As such, the consumer/child chain receives security from the main chain and doesn’t have to spin up its own validator set. This enables less capital-heavy applications to easily bootstrap their own chain while retaining a strong level of security from an existing validator set.

The main chain is in charge of producing blocks for a set of child chains. The validators will receive staking rewards from the chain(s) they’re validating. Slashing works to facilitate that no validator behaves maliciously.

Application-specific blockchains enable what we’d like to call “warehousing” of blockspace. If you view a blockchain stack as a supply chain, then the blockspace on various parts of the stack are technically being “bought” by the application(s) on the chain/layer that it inhabits. This means that it pays for gas alongside a myriad of different applications all inhabiting the same blockspace, which causes it to be highly congested and competitive and as such drives fees up. This fee spike caused by the heavily congested monolithic chain inhabited by thousands of applications is then pushed onto the end-users, which have to bear the heavy cost. On an application-specific chain, the application itself is able to better control the fees that are paid by the end-user and give them the ability to keep it at a constant. A great example of this is Osmosis. It also allows for easier subsidising of fees for applications that want to remove spiking fee structures completely. For example, one application could subsidise the average fees for a certain time period without having to worry about fee spikes as a result of heavy congestion.

This means that the application owns its own warehousing instead of being reliant on renting out one pallet in a corner of one.

Warehousing of blockspace

As such applications don’t rely on x or y chain as a warehouse which would mean taking on the risk of average fees being loftier for the application, similar to how a store has inventory risk. This means the application itself and as an extension of this, its community, can participate in and carry out inventory risk management. This causes resource pricing efficiency which in turn leads to a better economic model for the application(s).

As a result of the application being the owner of the chain it inhabits it allows for self-governance of fee structures, which means you’re no longer at the whim of the chain that you inhabit, you decide what each resource on your chain costs.

Beyond this, the flexibility allowed by the underlying tech stack allows for optimisation on the application layer while retaining composability between chains in the wider ecosystem as a result of its native cross-chain messaging system. This composability doesn’t require trust assumptions with third parties but instead allows for the validator sets of the two chains communicating to be the trust assumption.

Before the prevalence of Cosmos, there was a clear divide between applications and infrastructure (chains), application-specific chains with IBC break down this barrier and allow applications to become connected and composable infrastructure.