Rise of Lisk: Why the Cosmos Ecology Will Prosper

The vast Cosmos ecosystem has seen a renaissance over the past few weeks as applications and builders decide or intend to build their own specific Lisks. The previous demise of the Terra ecosystem also brought spillover effects to the wider IBC ecosystem. However, we think it’s worth noting that the entire stack is actually doing pretty well, and that’s not possible without sensible technical support. It has been proven that Cosmos can handle internal and external information and asset transfers across chains through IBC, and can also handle inter-chain transfers through the application of the Tendermint consensus mechanism, the ABCI interface and the Cosmos SDK for custom virtual machines.

This article aims to discuss the reasons behind the rise of application-specific blockchains, and why the resulting sovereignty, composability, and interoperability are critical to building the next “killer apps” and ecosystems in the next cycle important.

Before entering the discussion, it is very important that we reach a consensus “on the same frequency”. So, I will briefly outline in an easy-to-understand way a few different technical aspects that make the Cosmos ecosystem unique.

The overall architecture of the chain based on the Tendermint consensus mechanism using the ABCI interface and the Cosmos SDK is as follows:

7Yo22c37GOAqbufj7VqB7O1C4RIo8IjycN10xxzq.png

Cosmos SDK

The Cosmos SDK is a set of modular tools that allow blockchain developers to build application-layer logic in a VM-agnostic way. The Cosmos SDK is designed to connect to the Tendermint consensus via the ABCI interface. In addition to being a framework that allows the creation of application-specific blockchains, it supports a variety of customization options, including protocol-agnostic governance, transactions, staking mechanisms, and more. The SDK handles most of the tasks required by the application logic layer, meaning developers don’t need to build from scratch. It processes transactions received from the Tendermint consensus engine, routing information and state changes by the network to the appropriate processing modules.

ABCI

ABCI is an interface that connects blockchain applications with Tendermint, a state replication engine that provides consensus and network mechanisms. ABCI separates the blockchain stack, which means that blockchain applications can be independent of virtual machines, so that any virtual machine and execution environment can be used to support the application layer of the stack. Examples include Junowasm, Cosmwasm, Agoric’s Hardened Javascript, and the Secret version of Cosmwasm that supports TEE applications. Tendermint itself creates three ABCI connections to the application layer, namely: transaction validation broadcast in the mempool, connection between applications and consensus engines for block proposals, and the ability to query application status.

uWzFV8TCDc8eeL6g4wx0LMMBgz17BbGqpVUOq3hS.png

Tendermint

In the Cosmos ecosystem, Tendermint Core is responsible for the consensus and network layers of the chain. The consensus layer ensures the validity and order of transactions through the consensus algorithm process among network participants, and in the Tendermint use case is the set of proof-of-stake validators. The network layer is responsible for point-to-point communication between nodes in the system, enabling third-party applications and nodes to interact with the consensus layer.

Tendermint applies a Byzantine Fault Tolerant (BFT) consensus model for instant results. The BFT process goes through three stages before the proposed block reaches the final submission stage: the proposal stage (blocks are set to a specific height), the pre-voting stage (at least 2/3 of the validators pre-vote a proposed block) , Pre-commit stage (at least 2/3 of validators pre-commit a proposed block).

hUg3KfuIwgDjeaeEfsJFiSDTsxGcbXtwYfV4rWVJ.png Tendermints’ BFT process (Timeout delay: refers to the short waiting time required to receive a proposal or determine skip information)

 IBC

The core of Inter-Blockchain Communication (IBC) is a cross-chain messaging protocol for homogeneous blockchains. This means that it connects chains that share similar functionality, in this case, chains that share instant results from the Tendermint consensus algorithm and have light client functionality. The way IBC works is that two chains that are intentionally connected to each other will make governance proposals on the target chain. Usually starts either through the Cosmos Hub or through Osmosis (currently Osmosis has 45 chains and Cosmos has 40 chains). That is to say, a consensus agreement at the protocol level is reached, so that there is no need for a trusted third party from an external bridge.

Subsequently, the two chains need to run a light client on the other chain to encrypt and verify the consensus state between the two chains, and a repeater is needed to transmit information between the light clients on the two chains. Relays are required to be active and can exchange messages between nodes for nodes to successfully integrate into the consensus. Let’s see how it looks in action:

KBZpqMlfe5ALU6ga1aOqd30Ebt5G6nmf6pG9QDFE.png

(Chain A runs a light client towards chain B and vice versa.)

This means that the trust assumptions are located in the two validator sets of the interconnected blockchain, so there are many less trust assumptions relative to other types of bridge and message protocols. Taking XCMP of the Polkadot ecosystem as an example, the trust assumption only depends on the relay chain (Polkadot).

To demonstrate the compatibility and wide distribution of IBC in the Cosmos ecosystem, and how many chains it connects to – let’s take a look at the graph below for an overview of the current active connections.

YE3COjnLLW9AmlcCQQs445jPEPSjqhqdNbQVPqfg.png

ICS

ICS is the inter-chain standard, which sets the inter-chain transaction parameters for the application of IBC. ICS is basically a modular specification for IBC transactions. Both chains communicate using IBC and need to handle the same ICS specification parameters.

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

ICS-27

Interchain accounts support composability and interoperability. Allows data to be exchanged between chains, and can write the state of one on-chain smart contract into another on-chain contract. That is, in the transfer of assets or information, users do not need to operate across different interfaces, and users can use a single interface on the source chain until the terminal node of the transaction is determined.

An ICS-27 compliant chain can generate accounts on other ICS-27 compliant chains and control these accounts through IBC transactions. The inter-chain account retains all the functions of an ordinary account, but is operated by a separate chain or end user through IBC, and the account owner on the source chain can maintain full control of the inter-chain accounts on all target chains.

When initializing an interchain account transaction, use IBC to send a non-IBC transaction (non-IBC transaction within an IBC transaction) – an example often used to illustrate this is “a letter in an envelope in the mailbox”.

9kwXzcsxo5AJBwhDIpjwlpGjNLxOFJxEJFSwT4Pd.png

Inter-chain account transactions

The IBC post-trade procedure is carried out according to the ICS specification parameters that each chain needs to process. That is, transactions are allowed to transition from application-specific to application-independent. In other words – true support for composability across different networks.

Inter-chain security

Interchain security allows a chain or a 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. Cross-chain verification is an IBC-level protocol that makes this all possible. The sub-chain communicates with the main chain using IBC, recording which validators participate in inter-chain security using cross-chain verification. In this way, the security gained through the staked value locked on the main chain can be shared with the sub-chain. This way, consumers/subchains get security from the main chain and don’t need to start their own validator set. This allows some light capital applications to easily launch their own chains, while retaining the high level of security obtained from the existing validator set.

The main chain is responsible for producing blocks for the sub-chain set. Validators will receive staking rewards from the chain they validate. Reducing the workload helps to foster a situation where no validators are maliciously acting.

thesis

Application-specific blockchains support what we call “repositories” of the block space. If you look at a supply chain blockchain stack, the block space in different parts of the stack is technically “purchased” by applications on the chain/layer of the stack. That is, applications pay gas fees, but many different applications are crowded into the same block space, causing severe congestion and competition, which ultimately drives fees up. This spike in fees due to thousands of applications living on a heavily congested single chain puts pressure on end users to live with high fees. On a specific application chain, the application itself can better control the fee, the fee is paid by the end user, and the end user is allowed to set the fee to be constant and remain unchanged. Osmosis is a good example. It also supports fee subsidy for apps that want to get rid of the surge fee structure entirely. For example, an app could apply for an average fee subsidy for a specific time period without worrying about a surge in fees due to severe congestion.

That is, the application has its own repository, rather than relying on renting a pallet in some corner of the chain.

cvJtTTlTujFR0vksPcpoopIwML6XoUvhw0paJcQa.png Block space storage (the former is a specific application storage, the latter is a single chain storage)

Since the application does not rely on a certain chain as a warehouse, it seems to mean that the application bears the average cost risk, just like the store has the inventory risk. That is, the program itself and its extension—the community—can participate and implement inventory risk management. This contributes to resource pricing efficiency and enables better applied economic models.

Because the application is the owner of the chain on which it resides, the fee structure is allowed to be autonomous, which means that you are no longer tied to the blockchain you are on, and you can decide how much resources you spend on your chain.

In addition, the flexibility brought by the underlying technology stack allows application layer optimization while preserving the inter-chain composability within this broad ecosystem derived from native cross-chain information systems. This composability does not require a third-party trust assumption, allowing the validator sets of the two chains to communicate as a trust assumption.

Before Cosmos prevailed, there was a clear separation between applications and infrastructure (chains), and application-specific chains using IBC broke this barrier, allowing applications to become interconnected composable infrastructure.

Posted by:CoinYuppie,Reprinted with attribution to:https://coinyuppie.com/rise-of-lisk-why-the-cosmos-ecology-will-prosper/
Coinyuppie is an open information publishing platform, all information provided is not related to the views and positions of coinyuppie, and does not constitute any investment and financial advice. Users are expected to carefully screen and prevent risks.

Like (0)
Donate Buy me a coffee Buy me a coffee
Previous 2022-07-28 11:23
Next 2022-07-28 11:26

Related articles