1. Advantages and Disadvantages of the Cosmos Ecosystem

Cosmos has emerged in the world with the aim of building an ecosystem where organic communication between blockchains is possible, advocating for an "Internet of Blockchains." Of course, there is the reality that it's hard to communicate unless the blockchain is built using the same Cosmos SDK, but there are also attempts to bring in assets from outside the Cosmos ecosystem using various interchain solutions like Axelar. What are the pros and cons of this Cosmos ecosystem?

1.1 Advantage: Building Application-Specific Blockchains

A significant advantage of the Cosmos ecosystem is that each blockchain can be designed to be application-specific. Before the advent of Cosmos, it was natural for various applications to be implemented on a single blockchain, but with the release of the Cosmos SDK, designing a Cosmos-based blockchain became easier. Consequently, developers who originally aimed to implement services on blockchains began to build application-specific chains in the Cosmos ecosystem.

The advantages of such application-specific chains can be summarized as follows: 1) Since it's their own chain, they can tailor the performance and functions of the blockchain to a single application. 2) They can construct an indepenent infrastructure that isn't dependent on anything else. 3) Since most chains only have a single application, network congestion is relatively low. Additionally, the ability to move assets organically between chains based on the same Cosmos SDK, in line with the claim of being an "Internet of Blockchains," is also a significant advantage.

1.2 Disadvantage: Imperfect Communication

However, the disadvantages are also clear. While they claim to have 'independent application-specific chains', and thus ensure independence, it's crucial whether a flexible communication method can be implemented between them, as each chain is essentially an application. Ultimately, users will want a similar or better experience than what they experienced on existing blockchains. If Cosmos shows unnatural connectivity between applications, users will not use Cosmos's applications.

Blockchains in the Cosmos ecosystem communicate with each other through a protocol called IBC (Inter-Block Communication). The problem with IBC is that while asset movement between chains(Cosmos SDK based chains) was very convenient, more complex communications, like executing smart contract between chains (enabling the execution of smart contracts from another chain), were previously impossible. Therefore, it can be seen that the "composability" between applications, a feature of traditional monolithic blockchains, was missing.

Moreover, since they have to build their own blockchain, it was challenging to successfully construct a layer-1 blockchain due to the burden of recruiting validators and providing them with rewards initially(This has caused massive inflation to almost every App-chain). This is because a blockchain is not a product that can be built alone.

2. New concepts to explore: ICA, ICQ, RS

Of course, the developers of the Cosmos ecosystem were clearly aware of these limitations, so they tried to make the communication between appchains more advanced, and the technologies that emerged from these efforts are Interchain Account (ICA), Interchain Queries (ICQ), and Replicated Security (RS).

2.1 Interchain Account

ICA is a feature that allows accounts on one chain (e.g., Stride) to communicate with and control accounts on another chain (Cosmos Hub). As long as the chains that want to communicate have upgraded their ICA, they can create accounts on each other's chains.

To understand ICA, you need to understand two concepts: “Controller Chain” and “Host Chain”. A controller chain is a chain that "controls" an account on another chain, and a host chain is a chain with a controlled account. So in my example (Stride<>Cosmos Hub), Stride would be the controller chain and Cosmos Hub would be the host chain.

Here's how ICA works:

1. The controller chain (Stride) sends IBC packets to the host chain (Cosmos Hub).

2. The relayer receives the packet and sends it to the IBC module in the host chain (Cosmos Hub).

3. The ICA on the host chain receives information about what to do with the IBC packet (it can be about staking, governance, or opening a CDP, etc.).

4. The ICA on the host chain performs its duties by issuing transactions as passed to it by the relayers.

Before ICA was enabled, different Interchain Standards were required for IBC transactions coming from different chains, but after ICA is enabled, the IBC module does not process incoming transactions, but only forwards them to the interchain account, and the processing of incoming transactions is performed by the chain's own logic (the interchain account performs the transaction as received).

With the addition of features like ICA, “an appchain dedicated to liquid staking only” can be created, because the liquid staking appchain will have access to other independent appchains through ICA. Using Stride as an example, the process of staking ATOM on Stride might look like this:

1. A user deposits ATOM to Stride (and receives a proof-of-stake token, stATOM, in return).

2. Stride forwards the ATOM via IBC to the Delegation ICA (ICA) in the Cosmos Hub.

3. The ICA at the hub verifies the message and stakes it by firing a transaction that stakes the ATOM (which also determines which validator it delegates to).

In addition to the staking liquidation just described, ICAs are also used to reinvest rewards accumulated in tokens that are already staked: In fact, every 6 hours(every epoch), Stride processes the rewards accumulated in staked tokens, sending 90% of the rewards to the Delegated ICA to be re-staked, and 10% to the Fee ICA to pay fees. In this way, Stride organically reinvests staking rewards by directly controlling the events that happen on Cosmos Hub.

While these technologies may seem complicated, they don't actually require users to do much, but rather allow users to stake/reinvest their tokens on the Cosmos Hub without having to access the Cosmos Hub directly through the ICA.

2.2 Interchain Queries

If ICA is about giving a controller chain access to exercise certain actions on a host chain, then Interchain queries (ICQ) is an interchain solution that allows you to retrieve data from other blockchains without relying on a third party. A blockchain is essentially a database that is independent of the environment outside of the blockchain. This means that it's hard to trust data outside of the blockchain unless it's produced by the blockchain itself. However, in order for a blockchain to become a more useful database, it must eventually be able to accept data from environments outside of its own chain (including other blockchains), as well as validate that data. Third-party services called oracle solutions (Chainlink, Pyth Network, Band Protocol, etc.) have traditionally done what blockchains can't do on their own. But in the end, relying on third-party services to bring data from outside the chain is risky, and hackers have been known to attack oracle solutions and steal funds, so oracle solutions have not been good alternatives so far.

So here we have ICQ. ICQ is a technology that can be implemented because the Cosmos ecosystem has already been using a protocol called IBC to communicate between chains based on the Cosmos SDK. The way the Cosmos ecosystem chains exchange data through ICQ is as follows:

1. In the figure above, the chain sending the data query is called the "home chain" and the chain receiving the query is called the "satellite chain." The node in the home chain configures the query values in the IBC packet and forwards the packet to the satellite chain through a relayer.
2. The satellite chain then receives the packets through the IBC module and forwards them to the appropriate modules.
3. The ICQ module checks the query values and forwards them to the application modules in the satellite chain where they are needed.
4. After using the received query value, the result is sent to the home chain through the ICQ module and IBC module.

(Please note that since ICQ is an open-source protocol, there are many variations and many different ways to get data, so consider this example to be just one of many ways to get data using ICQ).

After all, since Stride is the liquid staking chain of the Interchain ecosystem, we need to know how much staking rewards are being received by the assets staked through Stride. This is where ICQ can be used to read staking rewards. However, Stride doesn't rely on ICQ as much as other chains (especially QuickSilver, which it competes with).

2.3 Replicated Security (RS)

Another feature that is arguably as important component of Stride as ICA and ICQ is Replicated Security (RS or ICS), formerly known as Interchain Security. Along with Neutron, Stride will be one of the first chains to adopt RS. So, what is RS and how will it change the Cosmos ecosystem?

2.3.1. A PoS ecosystem where token value is security

First of all, all chains in the Cosmos ecosystem, including the Cosmos Hub, are inherently using PoS consensus. This means that the security of the chain itself is directly related to the value of the token. For example, if the native/governance token issued by an app chain has a market capitalization of $100, it would only take a little over $50 to buy the chain's majority tokens and attack the chain. Therefore, there are structural limitations that make newly launched PoS chains less secure than chains with high market capitalization, and RS is a concept that came up to resolve this problem.

2.3.2 Getting to know RS

To understand RS, you need to understand two concepts first: Provider-Chain and Consumer-Chain. A Provider Chain is literally a chain that provides security to a Consumer Chain, and a Consumer Chain rewards the Provider Chain with the Consumer Chain's native token in exchange for the security that provider chain provides. While many people understand RS as "Cosmos Hub sharing security with other App-chains," any App-chain can become a Provider Chain in the future. However, since Cosmos Hub has the highest value in the Cosmos ecosystem to date, it is likely that Cosmos Hub will be the leading provider chain and therefore the only provider chain for the time being (other Cosmos ecosystem appchains are already adopting different security sharing methods, so it is already clear that Cosmos Hub is not the only one sharing security).

Once you understand the provider and consumer chains, let's dive into how RS works. First, the provider chain passes its own set of validators to the consumer chain via the inter-block communication (IBC) protocol. The consumer chain then applies the provider chain's validator set to the consumer chain's validator set. In this way, the provider chain's validator set and the consumer chain's validator set can be configured identically. These validators will produce blocks and validate transactions for the consumer chain. The problem is that just because the same validators produce the consumer chain's blocks and validate transactions, it doesn't mean that the consumer chain has the same level of security as the provider chain. In the end, it's the connectivity of the consumer chain to the provider chain that matters, which is why when performing RS, the provider chain's validators also act as validators for the consumer chain, using the provider chain's native token (e.g. ATOM). Using the native token of the provider chain for RS means that if validators fail to validate and produce blocks for the consumer chain, they lose the token of the provider chain, not the token of the consumer chain, and because of this structure, they share the security level of the provider chain.

2.3.3 The Problems with RS

Indeed, RS is not without its problems. Recently, a research released by Chorus One, a famous validator in the Cosmos ecosystem, raised questions about the sustainability of RS itself. The report suggests that RS can be a significant financial burden for small validators. At a glance, RS might seem like a win-win technology for everyone (Cosmos Hub validators receive additional rewards, and consumer chains can enjoy security comparable to that of Cosmos Hub), but in reality, it can result in an additional operational burden for Hub validators, because they need to manage additional blockchains. As Chorus One pointed out, if situations continue to occur where only large validators constantly benefit from RS, the original intent of RS may be diluted. Consequently, the demand to launch blockchains through RS could decrease, posing a sustainability problem. Thus, a more in-depth discussion about the incentive structure of RS is necessary.

 

3. In Conclusion: The Evolving Ecosystem

Like all blockchain ecosystems, the Cosmos ecosystem also has various issues. However, there are also efforts to continually address these problems through new features such as ICA, ICQ, and RS. Although I believe there's still a long way to go for the Cosmos ecosystem to succeed, I think it's heading in the right direction. If the Cosmos ecosystem manages to maintain the neutrality of the Cosmos Hub while developing a system that can transmit value to the Cosmos Hub as the ecosystem grows, and if it continues to evolve its communication protocols so that application-specific chains can interact more organically, the Cosmos ecosystem could truly become the internet of blockchains.

Four Pillars — Website | Twitter(EN) | Twitter(KO) | Telegram

Four Pillars is a global crypto research firm based in Seoul, consisting of the most influential blockchain researchers in Korea. Through robust research and governance skills, it helps various market players easily onboard to the blockchain industry by offering high-quality research articles while supporting protocols in their expansion into Korean and global markets.

Writer: Steve Kim, Co-Founder and CEO at Four Pillars 
Reviewer: 100y, Co-Founder and Publication Lead at Four Pillars 

#Cosmos #Interchain #Multichain #Appchain #FourPillars