In September 2022, The Interchain Foundation released a revised concept for the Cosmos Hub, ATOM token, and the basis for the future roadmap. The biggest changes center around Interchain Security (ICS), new ATOM tokenomics and the inclusion of protocol-level liquid staking, and new protocol entities entitled the " Interchain Allocator" and "Interchain Scheduler." So, with all the new changes, how does it fit in with the current version of the protocol? Let's first work through the various components that make Cosmos what it is today before finally dissecting the good and bad of the proposed changes.

Consensus Mechanism

In order for a decentralized network of nodes/computers to function properly, the independent participants in the network need to reach an agreement over a shared state (e.g., who owns what on a blockchain). And while doing this, the network should remain fault tolerant with valid consensus despite imperfect information or malicious actors (Byzantine Fault Tolerance). Different blockchains implement different methods of doing so, but all are attempting to create a “consensus algorithm” that best fits their chain.

Consensus algorithms are used in public blockchain/distributed computer design in order to convince nodes in a decentralized system to agree on the next valid state. Within the context of public blockchains like Bitcoin and Ethereum, this signals that at least 51 percent of network nodes agree on the network's global state. In addition, a consensus algorithm often gives a guarantee (probabilistic or deterministic) that network nodes can reach consensus on the next valid state even if a minimum number of nodes in the system are adversarial.

Nakamoto’s consensus requires waiting for the creation of several additional blocks to ensure transactions cannot be reverted. As a result, Nakamoto chains have high uptime (they do not go down or stall) but low transaction speed due to their probabilistic finalization guarantee. This is because Nakamoto Consensus requires waiting for “enough” blocks to be mined on top of the block that includes the user’s transaction that reorganizing or reverting the blockchain becomes economically impractical, ensuring some “economic certainty” but never theoretic/deterministic certainty.

One issue with allowing anyone to participate in the consensus of an open network is that one malicious actor can create endless nodes, thereby creating multiple identities, as seen by the blockchain. If one person could create enough nodes, they could theoretically control the network, known as a Sybil attack. For this reason, blockchains also need a Sybil Resistance mechanism in addition to its Consensus algorithm.

A Sybil resistance mechanism, on the other hand, is the process through which a decentralized system deters Sybil attacks. A Sybil assault occurs when a single node can flood the network with several identities and utilize them to obtain an outsized amount of power.

Ideally, each node in a decentralized system would represent one vote. If a node can impersonate multiple other nodes and get 100, 1,000, or more than 10,000 votes instead of one, then the system is vulnerable to assault. Sybil attacks are often deterred by requiring nodes to show proof of a difficult-to-fake resource (unlike online identities, which are easy to forge).

Proof of Work - Hash power (e.g., Bitcoin)

Proof of Stake - Tokens (e.g., Cosmos, Polkadot, Tezos)

Proof of Space-Time - disk space (e.g., Chia, Filecoin, etc.)

Proof-of-Authority - (e.g., Algorand)

Tendermint

The Cosmos network uses Tendermint Core, a language-agnostic consensus algorithm that enables developers to replicate dapps in whatever programming language they wish. Tendermint Core is a Byzantine Fault Tolerant (BFT) consensus mechanism for distributed systems; this means that even if as much as one-third of the machines in the network arbitrarily fail, the network still reliably reaches the same version of events and executes the same state.

Tendermint Core achieves Byzantine Fault Tolerance via validators that stake ATOM and "vote" on blocks of transactions in rounds. Validators confirm transactions and broadcast cryptographic signatures to "vote" on the validity of state changes in the network. Validators cannot sign invalid or duplicate transactions or else they will have their staked ATOM "slashed" (i.e., taken from them).

consensus mechanism comparison table kraken — Source: Kraken

Tendermint BFT has three blockchain layers:

Application layer - Code that creates some type of functionality.
Networking layer - Broadcasts the transactions and consensus-related messages.
Consensus layer - Allows nodes (computers) to agree on the current state of the system.

Application Blockchain Interface (ABCI)

The problem with these layers is you have to build them from the ground up when creating a blockchain. Tendermint BFT connects to the application layer via the Application Blockchain Interface (ABCI). It's a protocol that allows developers to use any programming language they want, saving them lots of time and allowing them to focus solely on their application layer.

The other component of Tendermint that comprises Tendermint software, in addition to Tendermint Core, is the Application Blockchain Interface (ABCI). The ABCI, along with a Socket Protocol that manages the peer-to-peer element of the network, helps those building applications on Tendermint by isolating the transaction data (and similar) from the consensus mechanism. Additionally, the ABCI allows transactions to be processed and interacted with via any programming language; one isn’t wedded to the language used to implement the state. Ultimately, 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.

Conversely, Bitcoin, Ethereum, and their variants use Satoshi Nakamoto’s consensus, which requires waiting for the creation of several blocks to ensure transactions cannot be reverted. As a result, Nakamoto chains have high availability but low transaction speed due to their probabilistic finalization guarantee, which requires waiting for the chain to be long enough. To achieve faster finality, Cosmos (and others) use the classical Practical Byzantine Fault Tolerance (PBFT) consensus, which improves TPS but limits the possible number of validators in the network.

PBFT requires all nodes in the network to communicate with one another constantly so that the network may reach consensus with absolute certainty. It has low latency and quick finality, but it can’t scale to many participants in a global open network because the load on each validator node increases exponentially as the validation work increases. A block is considered to be finalized by the network after 2/3 of validators have broadcast their commits.

Cosmos Tendermint stack — Image credit: Cosmos blog

The Cosmos whitepaper describes the protocol as a "partially synchronous BFT consensus protocol derived from the DLS consensus algorithm." DLS is short for “Dwork, Lynch, and Stockmeyer,” the authors of the 1988 paper entitled “Consensus in the Presence of Partial Synchrony.” The whitepaper lays out a case for how Cosmos provides strong security guarantees while scaling to the order of thousands of transactions per second (under sub-optimal conditions, such as when validators are crashing or behaving maliciously by sending false votes); additionally, Cosmos hopes to prevent long-range-nothing-at-stake double spend attacks and censorship.

Proof-of-Stake (with Something at Stake)

Tendermint was the first project to demonstrate a conceptual solution to the nothing-at-stake problem that plagued early PoS blockchains. Essentially, Tendermint’s consensus mechanism involves a security deposit element to the “stake,” which users stand to lose if they behave maliciously or ineffectively. This is in contrast with earlier permutations of PoS systems whereby users just had to have tokens in a wallet in order to participate in the network’s consensus. In Cosmos, it can be said that validators have “something at stake” instead of “nothing-at-stake,” as malicious activities are punished by having some of their staked ATOM slashed or burned. Prior to PoS systems that required validators to have capital at risk (in virtue of it being staked), it wasn’t clear how double-spend attacks could be prevented by those with even 1% of the network's tokens (as opposed to 51% of the computational capacity).

Validators required for 33% attack Aug 2022 — Source: Kraken

PoS is sometimes considered to have several benefits over PoW, such as shorter time to transaction finality (sufficient confirmations and commitment to the ledger), improved capacity for transaction throughput in addition to volume, all in addition to massive improvements in energy efficiency. Of course, there’s an implied trade-off with regards to the scalability trilemma here: the security element is essentially moved to a different form, rather than computational power, it’s some agent’s willingness to stake their capital. Early permutations on alternative blockchain consensus mechanisms, in addition to PoS-based networks, included the Proof of Authority (PoA) Network, where the network is maintained by a trusted set of validators who are all U.S. notaries. Rather than trusting hash algorithms and cryptographic complexity, one trusts their interpretation of agents' motivations and their relationships to their capital (PoS) or their identity (PoA).

Cosmos originally launched in March 2019 with 100 validators and has ~200 validators as of Q3 2022, with a total of ~300 planned. Cosmos Hub validators can accept any token as a fee for processing a transaction. Block times are seven seconds, and the network can theoretically handle over 1,000 transactions per second. The upper limit has never been tested, and thus, any claims beyond current usage remain theoretical.

L1 smart contract table — Source: CryptoEQ

In PoS systems, validators serve as consensus nodes. In Cosmos, stakers (sometimes called delegators) assign their stakes to validators. A validator’s voting power is determined by the proportional amount of stakes allotted to it. In Cosmos, validators are chosen to propose the next block by their voting power—i.e., a validator that holds 15% of the voting power will get to propose the next block 15% of the time.

Such a system allows stakers or delegators to contribute to the project without needing substantial computing power of their own. For example, someone with an average laptop or even a smartphone can choose to stake their ATOM and start earning rewards, which is covered more in Economics.

Staking is not risk-free, as delegated ATOM can be slashed if a validator acts maliciously or against consensus. Slashing refers to when staked tokens are burned, and the user/validator can’t get them back. Validators can be slashed if they’re offline for long periods of time (minor offense and small stake slashed) or have ~5% slashed if they sign two different blocks (malicious activity).

Inter-Blockchain Communication (IBC)

In addition to relying on a PoS mechanism that isn’t encumbered by the nothing-at-stake problem, Cosmos aims to become “the internet of blockchains” via its internal Inter-Blockchain Communication (IBC) protocol. IBC allows users to send information between two IBC-connected sovereign chains by running a light client on each chain (see Map of Zones). As a reminder, full nodes download and validate every transaction that has ever occurred on the chain since its genesis. Light nodes (typically) only check block headers. This means light clients are “light weight” nodes that require fewer computing resources than a full node. This makes them more egalitarian because they are cheaper and typically easier to run, helping to further decentralize the network. Once a zone creates an IBC connection with a Hub, it automatically has access to every other zone that’s connected to it.

The Inter-Blockchain Communication (IBC) protocol is what is known as a "natively-verified" bridging/messaging protocol that connects the blockchains in the Cosmos ecosystem. As chains implement the IBC protocol, they bridge to one another, and the overall Cosmos ecosystem liquidity increases. Within the Cosmos ecosystem, chains that implemented IBC have the Tendermint light client verifiers so they can consume and verify those receipts in their communication, thus removing external consensus to verify state. Because of the light clients, chains continuously verify and reach consensus on the state of other blockchains by verifying their block headers. Besides light clients, the IBC requires relayers to transport data packets (token transfers, smart contract calls, etc.) in specific format as well as run the same consensus algorithm (discussed further below).

IBC's architecture is comparable to the ubiquitous internet protocol, TCP/IP. First, in order to establish a connection between two distinct chains, a relationship between the two chains must be established via a series of initial transactions sent to each blockchain. Each transaction includes information and state proofs from the other chain. This enables each chain to authenticate the other's light clients in preparation for data exchange.

Before the chains become interoperable, they also need to open channels involving more data exchange in the form of data packets. Once any number of channels are formed, the chains can communicate, e.g., transfer tokens or a call to a smart contract. Each IBC connection could have various settings, such as timeout constraints or ordering guarantees, for each chain.

The token transfer process through IBC follows the following order:

Tokens on Chain A are locked in escrow, and an outgoing data packet containing the sender, receiver, and amount is produced.
The relayer receives and transfers the data packet.
The packet is received on Chain B and then verified. If successfully verified, new tokens of an equal amount are minted and transferred to the receiver on Chain B.
Chain B’s IBC module produces an acknowledgment data packet confirming receipt of tokens.
The relayer receives and transfers the packet.
The confirmation packet is received on Chain A, and the transfer is complete.

Cosmos aims to scale horizontally with an asynchronous heterogeneous network model, where the app-chains have different VMs and can interoperate with other zones only when needed. The ability to launch your project as a sovereign app-chain rather than a set of smart contracts on Ethereum has three fundamental advantages:

Customizable validator rules and requirements for your chain's specific needs (e.g., public vs. private, privacy vs. transparent, etc.)
Performance isolation to ensure one dApp unrelated to your project doesn’t disrupt the chain a la Ape Coin on Ethereum in April 2022
Predictable and customizable fees

IBC drawbacks

While the IBC model creates a very secure and trust-minimized bridge with reduced friction, this approach is harder to scale because establishing and maintaining light clients on hundreds of chains is cumbersome. As previously mentioned, IBC was designed to connect chains that utilize the same consensus algorithm. Tendermint chains have deterministic finality, making the bridge between them more straightforward, whereas others, like Ethereum, have probabilistic finality. Cosmos hubs can technically link to both types of chains, although bridging to probabilistic chains presents more challenges and tradeoffs. This is because hubs are incapable of maintaining the global state of probabilistic chains. This creates a double-spend attack vector that is not present in traditional IBC-connected zones.

As a solution, Cosmos employs "Peg Zones" to achieve interoperability with probabilistic chains. A Peg Zone is a separate blockchain created simply to monitor the state of a probabilistic blockchain and establishes finality. Peg Zones will only interface with other IBC zones until enough time has elapsed so that the risk of a chain reorg is low.

Additionally, token transfers via the IBC are “path dependent,” reducing fungibility and creating friction in cross-chain composability. A token that is routed from, say, Secret Network to Osmosis to the Hub is not the same as a token routed from Secret Network to Axelar to the Hub even though they started and ended in the same places.

Cosmos IBC path dependency — Source: Delphi Digital

Because of this, Cosmos employs the Hubs and Zones model to limit the number of connections required for a blockchain to benefit from being connected to the network.

Hubs vs. Zones

The Cosmos Hub is a PoS chain that serves as the primary hub for routing transactions and data between Cosmos blockchains called zones. Hubs are the largest, most liquid zones in the ecosystem. Zones are application-specific chains built using Cosmos SDK. Using the hub and zone model, any zone can send information to a connected hub, and then that hub can send the information to any of the other connected zones. Because hubs act as routers or middlemen between zones, they are also responsible for maintaining the global state (token balances) across all Zones.

Cosmos hub and zone structure — Image credit: Cosmos website

Zones plug into hubs, which route and validate the transactions passed between different zones in exchange for fees. They connect to a Hub via a two-way peg, similar to Ethereum and side chains like Polygon. When a valid cross-chain transaction is submitted on the IBC, the token on the original chain is (essentially) frozen/burned while the receiving chain mints the equivalent amount on new tokens.

Cosmos hub and zone — Image credit: Cosmos blog

For example, if a user wants to transfer 50 ATOM from one chain to another, those 50 ATOM are bonded or locked on the native chain, then proof of the bonding is relayed to the other chain, and the proof is verified against the native chain’s header, and then vouchers for that 50 ATOM are created on the other chain. So, one could say the ATOM on the other chain is not “real,” but they do provide proof the ATOM they represent on the native chain is frozen.

Cosmos token transfer — Image credit: Cosmos website

The primary limitation in Cosmos’ architecture is this lack of shared security, making zones vulnerable. For example, a token pegged from one app-chain to another via IBC can be stolen by a malicious majority of source-chain validators. This issue aims to be addressed with the introduction of Interchain Security (discussed later) sometime in 2022/2023.

Cosmos' protocol architecture prioritizes app-chain sovereignty and purposely diminishes the role and power of the Cosmos Hub. With this design, the Cosmos ecosystem ensures continuity across all chains and removes a single point of failure. With several hubs, the failure of one would not be sufficient to bring down the entire system. This is different than the Binance Smart Chain sidechain and Avalanche subnet models, as illustrated in the table below.

subnets vs cosmos chart — Source: Galaxy Digital

Cosmos SDK

The Cosmos ecosystem, unlike Ethereum, is not a single blockchain that facilitates state and transaction transfers but rather a decentralized network of chains built using the shared Cosmos SDK toolkit. The Cosmos SDK allows new developers to choose from a selection of pre-built modules based on their specific needs when designing a new blockchain. One example is Binance Smart Chain which uses Ethermint. Ethermint took the Ethereum codebase, removed PoW, and added the EVM on top of Tendermint. This allowed Binance to build faster and immediately attract existing Ethereum users. However, because BNB Chain did not implement the IBC module, it is not connected to the Cosmos network.

Stargate, the name of the upgrade which launched IBC, was implemented in February 2021. With it, 150+ Tendermint-based blockchains are now interoperable, as well as allowing Cosmos SDK blockchains to communicate with other blockchain protocols. With IBC live, previously siloed blockchains can now send tokens from/to one another. Blockchains that have onboarded and are now interoperable include Osmosis, Terra, and the Secret Network.

Cosmos zone growth 2022 — Growth of Cosmos zones per quarter. Source:Delphi Digital

CosmWASM

CosmWASM is software that interacts with the Cosmos SDK to make developers’ lives easier when writing code in various languages and having it executed in Virtual Machines. WebAssembly standards act as a sort of intermediary language which takes the user inputs and reliably executes state transitions in the Cosmos SDK. For more information, look here. However, proceed with caution, as on April 6, 2022, an exploit was uncovered by Halborn, which affected 20+ blockchains in which an attacker could bypass validity checks or break storage keys under certain conditions.

Cosmos' 2022 Updated Whitepaper and ATOM 2.0

Stepping back just a bit, the Theta upgrade was released in April 2022 and featured Interchain Accounts (ICA). ICAs allow any account on any Cosmos zone to open and control an account on another zone. This removes the previous limitations inherent to the IBC in which only certain transactions that conformed to certain standards could be executed.

Where the IBC on Cosmos enables network participants to easily share tokens between accounts on different chains, the Theta upgrade includes the ability to interact with other accounts (similarly to how Ethereum users interact with smart contracts) in other hubs. Interchain accounts are a key step towards interchain security, in addition to having other major impacts on the Cosmos network. IA enables developers to leverage existing functionality regardless of the hub on which it exists.
Technically speaking, ICAs permit an IBC-connected chain to open ICA channels with new, pre-defined messaging standards. This fact is important because ICA transactions do not adhere to the typical IBC standards. Instead, they are bundled transactions wrapped into an IBC-conforming transaction. The receiving zone gets the IBC wrapper, processes the transactions inside based on the newly established ICA messaging standards, and then updates its state.
The main benefits of Interchain Accounts are a more seamless user experience with less friction for moving between zones and increased composability. With Interchain Accounts enabled, users can yield farm in DeFi, stake in the Cosmos Hub, vote in governance, and participate in DAOs across all connected zones, all from one account on the Cosmos Hub. Current IBC-chains will become more composable with one another, enabling a transition from their native, single-chain business model to interchain native business models.

Interchain Security (ICS)

V1 of Interchain Security will see the Cosmos Hub acting as a ‘provider’ chain to various ‘consumer’ chains, whereby smaller blockchains benefit from the Hub’s security for a fee. A new Cosmos zone (consumer chain) may "rent" current validators on the Cosmos Hub. In exchange, a 'consumer chain' pays a renters fee to the Hub via some of its transaction fees and token issuance. The participating validators would run two nodes: one for Cosmos and one for the alternate chain. The Cosmos Hub would then be able to oversee the block production for the alternate chain

At present, app-chains like Secret and Kava have had to create their own node networks and establish their own consensus security without support. Interchain Security fixes this by enabling projects with less capital available to launch on the ecosystem with security support from the Hub chain, helping bootstrap their economies. This is important because many app-chains are woefully insecure. For instance, in a chain utilizing Tendermint consensus, if a group of validators obtains/controls>33% of the network stake, they can stop finality and effectively censor the network. Consequently, it may be advantageous for a Cosmos app-chain to utilize the security of Cosmos Hub, which now has ~$1.8B in stake protecting it. Additionally, the consumer chain's tokenomics will benefit because they will no longer need to offer highly inflationary token rewards in order to incentivize new stakers and validators.

In the initial version of ICS, all consumer chains must be secured by all provider chain validators. In a future upgrade (2023+), an Interchain Security v2 is planned. With this upgrade, consumer chains will be able to use both their own validator set and the provider chain’s validator sets. This is important because one drawback of this model is if a large number of new chains begin renting from one provider chain, that provider chain's validator requirements will increase. Essentially, too much adoption could lead to only a few highly-specialized, resource-intensive provider chains controlling most of the chain.

One advantageous aspect of Interchain Security is that it allows teams to create their own "custom consumer chain" or "contract consumer chain." In customer consumer chains, teams have the option to modify the binary in order to experiment with other transaction costs and transaction assembly. Contract consumer chains do not have this flexibility. Here is a comparison between Cosmos Hub interchain security and other alternatives.

Cosmos interchain security chart — Source

The more consumer chains that launch and the more activity they drive, the greater the gas payments paid back to the Hub. This is a new value driver for the ATOM token. This also leads to Interchain Staking, in which ATOM stakers will provide security for the Cosmos Hub and smaller blockchains connected through IBC just by staking ATOM on the Hub. Newer, smaller chains will benefit from an enhanced security set and get their tokens to a wider audience sooner. While good for security, it also means stakers will also receive rewards in each of the respective native tokens of each chain (double staking rewards).

Changes to ATOM and Staking

A major change to the ATOM token in the new whitepaper is the addition of liquid staking at the protocol level. Liquid Staking allows users to continue transacting with their staked ATOM rather than having it locked up. Currently, the Lido team, which implemented ETH's wildly successful and popular Liquid Staking procedures, has suggested a proposal for Cosmos’ future development that builds on the limited V1 functionality of Liquid Staking. The V1 implementation generates representations of ATOM, which are associated with a specific delegator/validator. However, in the new version of Cosmos, liquid staking would not be handled by a third-party like Lido but, instead, be inherent to the protocol. Without the burden on locking up staked ATOM, more users should be willing to stake, driving up the overall proportion of staked ATOM. This increases security but also drives down token inflation.

Additionally, the whitepaper proposes a new two-phase monetary policy:
• Phase 1/Transition Phase - The Transition Phase will commence with a high ATOM issuance (10M ATOM each month) and run for three years. This phase is intended to gradually "sunset" the security subsidy while pouring capital into the newly established Treasury Pool to fund the Interchain Allocator's development. The goal is to provide enough time for more chains to join Interchain Security and build a substantial treasury.

Phase 2/Steady State: After three years, the monetary policy transitions to a continuous monthly issuance of 300,000 ATOM. Under this new phase, the inflation rate will eventually fall below 1%, and a certain percentage will be allocated to the Cosmos Hub Treasury. The Treasury funding will be utilized to launch Cosmos applications (as detailed in the Interchain Allocator Section).

Interchain Scheduler (IS)

Currently, Cosmos and the IBC enable frictionless token transfer across its zones, creating enormous cross-chain Maximum Extractable Value (MEV) opportunities. However, most of this MEV is extracted by a select few happening off-chain. The IS brings this activity back on-chain and plans to distribute the rewards across the users and Cosmos zones.

The Interchain Scheduler offers a secure market for all block space spanning all IBC chains. This is accomplished through the use of a market for the execution, clearance, and settlement of interchain block space. The Interchain Scheduler will distribute MEV rewards equitably among Cosmos users and the other blockchains. Additionally, Cosmos Hub will levy a matching fee that will be deposited into the Hub's Treasury.

Interchain Allocator (IA)

Using a percentage of the money made from the Interchain Scheduler, the Interchain Allocator reinvests the revenue into Cosmos-based projects, serving as a formal long-term incentive program for Cosmos dapps. Specifically, the (IA) consists of two arms: the Covenant and a Rebalancer. The Covenant will create multi-lateral agreements with IBC-enabled zones, while the Rebalancer will automatically manage the portfolios/public liquidity. All of it together will create the new Cosmos stack (image below).

Cosmos new tech stack — New proposed Cosmos tech stack. Source

Loading...