Application Chain Theory: Why will the Cosmos ecosystem flourish?

Original: https://rainandcoffee.substack.com/p/the-application-specific-chain-thesis?utm_source=%2Fprofile%2F14239335-rainandcoffee&utm_medium=reader2

Author: RainandCoffee

The past few weeks have seen a revival in the broader Cosmos ecosystem, as applications and builders have either decided to build their own application-specific chains, or expressed interest in doing so. This follows the demise of the Terra ecosystem which also had some impact on the wider IBC ecosystem. However, we think it's important to note that the entire stack performs very well technically. It turns out that despite the very volatile transaction volume, it is capable of handling internal and external message and asset transfers across chains via IBC, as well as on internal chains via the Cosmos SDK with Tendermint, ABCI, and a custom VM. In this article, we aim to explain the arguments behind the rise of application-specific blockchains, and why the sovereignty, composability, and interoperability they bring are critical to building the next "killer app" and ecosystem in the coming cycle. Systems matter.

Before we delve into this topic, it is necessary to reach a consensus, so we will briefly introduce some unique technologies in the Cosmos ecosystem in an easy-to-digest way.

The overall architecture of a Tendermint-based chain using ABCI and the Cosmos SDK is as follows:

Cosmos SDK

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 interface with Tendermint via ABCI. In addition to being a framework that allows for the creation of application-specific blockchains, it also allows for various customization options such as protocol-agnostic governance, transaction and staking mechanisms, and more. The SDK handles most of the tasks required at the application logic layer, which means developers don't have to build it entirely from scratch. It processes transactions received from the Tendermint consensus engine through a router, which sends messages along with state changes to the appropriate processing modules.

ABCI

ABCI is an interface that connects the application part of the blockchain and the Tendermint state replication engine that provides consensus and network mechanisms. ABCI realizes the split of the blockchain stack, which means that the blockchain application part can be independent of the virtual machine, so any virtual machine and execution environment can be used for the application part of the stack. Examples include Junowasm, Cosmwasm, Agoric's Hardened Javascript, and even the Secret version of Cosmwasm (which allows the use of TEEs). Tendermint itself creates three ABCI connections to the application part, responsible for the verification of transactions when the mempool broadcasts, the connection between the application and the consensus engine, and the ability to use for block proposals and query the state of the application.

Tendermint

Tendermint Core is responsible for the consensus and network layer of the chain in the Cosmos ecosystem. The consensus layer is to ensure the validity and order of transactions through the consensus algorithm process among network participants. The network layer is responsible for facilitating point-to-point communication 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 achieves instant finality. The BFT process goes through three phases before the final commit phase of the proposed block. The three stages are:

• In the proposal phase, a block is designated at a specific height;
• In the pre-voting stage, 2/3 of the verifiers pre-vote on the proposed block;
• In the pre-commit step, 2/3 of the verifiers pre-commit the proposed block.

IBC

The core of Inter-Blockchain Communication(IBC) is a cross-chain information transfer protocol for homogeneous blockchains. This means it connects chains that share similar functionality, in this case instant finality provided by the Tendermint consensus algorithm and chains with light client capabilities. The way IBC works is that two chains interested in connecting to each other will propose governance on the target chain. This is usually through the Cosmos Hub or Osmosis (currently Osmosis connects 45, Cosmos has 40). This means that there is an agreement at the protocol level, therefore, there is no need to use a trusted third party in the external bridge.

Then, the two chains need a light client on each other's chain to cryptographically verify the consensus state between the two chains, and a repeater to pass information between the light clients on the two chains. Relays are required for activity - to be able to exchange information between nodes, and for nodes to successfully reach consensus. Let's explore the actual situation:

This means that the trust assumption is in the two validators connecting the blockchain, so the trust assumption is much less than other types of cross-chain bridges and messaging protocols. For example, with XCMP in the Polkadot ecosystem, the trust assumption lies only in the relay chain (Polkadot).

To show the compatibility and pervasiveness of IBC in the Cosmos ecosystem, and the number of chains it connects to - let's take a look at the current real-time connection scale:

ICS

ICS is an abbreviation for Interchain Standard, and uses the transaction setting parameters between chains that occur in IBC. ICS is basically a module specification for IBC transactions, and for two chains to use IBC, they need to have the same ICS.

One of the interesting and unique ICSs is ICS-27, also known as interchain accounts.

ICS-27

Interchain accounts enable composability, that is, interoperability. They allow people on chains to not only exchange data, but also write state from one smart contract on one chain to another. This means that instead of needing to move between various interfaces when assets or messages are transferred, users will be able to utilize a single interface on the source chain simply by specifying the endpoint of the transaction. ICS-27-enabled chains create accounts on other ICS-27-enabled chains and are able to control those accounts through IBC transactions. Interchain accounts retain all the functionality of regular accounts, but are operated by a separate chain or end-user via IBC, such that owners on the source chain maintain full control over any cross-chain accounts they enroll on the target chain.

The procedures after the IBC transaction are carried out in accordance with the ICS specifications that each chain must have. This means, it allows transactions to go from application-specific to application-independent, in other words - it enables true composability across a range of different networks.

Interchain security

Interchain security allows one chain or hub to produce blocks for other chains. Validators run two (or more) nodes, one on each chain, but only need to stake their native tokens on the main chain. This is enabled by cross-chain verification, an IBC-level protocol. Subchains use IBC to communicate with the mainchain to keep track of which validators are participating in interchain security using cross-chain validation. In this way, the security gained from the value locked on the main chain is shared with the child chains. Thus, consumers/subchains gain security from the mainchain without having to set up their own validators. This enables applications with light capital burdens to easily spin up their own chains while retaining the strong level of security of existing validators.

The main chain is responsible for generating blocks for a set of subchains, validators will receive staking rewards from the chain they are validating, and Slashing helps prevent validators from doing malicious things.

Summarize

Application-specific blockchains enable what we call a "repository" of block space. If you think of the blockchain stack as a supply chain, then the block space for each part of the stack is technically "purchased" by the application on the chain/layer it is on. This means that it joins countless different applications paying for the gas that resides in the same block space, causing it to be highly congested and competitive, thus driving fees up.

This spike in fees caused by a heavily congested monolithic chain inhabited by thousands of applications is then pushed onto users, who have to bear the heavy cost. A good example of this being Osmosis, where the application itself can better control the fees paid by the end user on a given application chain and give them the ability to keep it at a constant level.

Since such an application does not rely on chain X or Y as a warehouse, this would mean taking the risk of a higher average fee for the application, similar to a store's inventory risk. This means that the application itself, and by extension the community, can participate in and manage inventory risk. This leads to efficiencies in resource pricing, which in turn leads to better economics for applications.

Since the application is the owner of the chain it lives on, it allows self-management of the fee structure, which means you are no longer influenced by the chain you live on, you decide the cost of each resource on your chain.

In addition, the flexibility allowed by the underlying technology stack allows for optimization at the application layer while maintaining composability between chains in a larger ecosystem due to its native cross-chain information delivery system. Composability requires no third-party trust at all.

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