What are the latest technological advancements in Cosmos? An interpretation of the Interchain stack 2024 roadmap

Written by: Babywhale, Foresight News

The series of technical solutions launched by the Cosmos development team has always been well-received by Web3 development teams, whether it is the Cosmos SDK or IBC, many of which have helped developers solve the problem of reinventing the wheel.

Although Cosmos has brought many products to Web3, its core ATOM token has not benefited from the expansion of the Cosmos ecosystem. However, the release of the Cosmos 2.0 white paper at last year's Cosmoverse conference brought additional value to ATOM, including providing security for the "consumer chain" to collect fees and capture MEV revenue. In simple terms, if Cosmos 2.0 is fully realized, ATOM will also benefit from the continuous expansion of the Cosmos ecosystem, so the remaining question is to expedite the development of Cosmos 2.0 and further expand the Cosmos ecosystem.

Last month, the Interchain Foundation, aimed at promoting the development of the Cosmos ecosystem, publicly released the development plan for the 2024 Interchain stack, which aims to achieve four strategic goals:

• Improve modularity through generalized software to better adapt to specific use cases;
• Enhance developer experience to make it easier to build with the Interchain Stack;
• Pay off technical debt to enable faster progress;
• Drive user adoption.

Many of these plans may change your judgment on the development prospects of Cosmos and ATOM.

CometBFT

CometBFT is the replication engine for the Interchain state machine, ensuring that the network's validators reach consensus on block generation, thereby ensuring the security and consistency of the blockchain network.

The Interchain Foundation stated that its goal is to develop the Interchain by expanding the coverage and applicability of CometBFT, helping to establish sovereign interoperable applications. Additionally, the cross-chain public goods stack, including CometBFT, needs to achieve new levels of flexibility and modularity to accommodate the increasingly differentiated applications in the Interchain, provide institutional-level services, and compete in various ways.

The Interchain Foundation released CometBFT v0.34 in February 2023, followed by v0.37 in March, which included the first part of ABCI++. At the end of March, the v0.38 candidate version was released, which is the final part of ABCI++. Before the final version is released, the Interchain Foundation will integrate it into Cosmos SDK and IBC-go.

The Interchain Foundation plans to release the upcoming v0.39 before the end of 2023, with updates including efficiency improvements (reducing bandwidth and storage consumption), and the Data Companion API, which will eventually include an indexer and RPC subsystem, expected to be released in early 2024. This version may also be referred to as v1.

As for what ABCI++ is, it starts with ABCI. ABCI is the interface between applications and consensus, primarily serving to execute blocks determined by consensus. With ABCI, applications only interact with consensus during decision-making and have almost no control over which transactions are selected from the mempool. ABCI++ adds programmability to every step of consensus, allowing applications to reorder, modify, abandon, delay, or add transactions, as well as shorten block production time by introducing optimizations that produce blocks.

Sei has adopted ABCI++ to optimize block production, smart block broadcasting, and order parallel execution, thereby improving the processing efficiency of on-chain transactions.

In summary, CometBFT provides highly customizable block building capabilities for chains based on this consensus mechanism, allowing different chains to define their own methods for block and transaction ordering and execution according to their needs, greatly enhancing the imagination for optimization at the chain level. Furthermore, the Interchain Foundation has proposed a grand vision: to allow applications to directly utilize IBC's functionalities through the ABCI interface, regardless of the virtual machine, framework, or module stack used in their development. This way, the goal of making IBC the cross-chain interoperability standard for on-chain applications developed with Cosmos SDK, OP Stack, Celestia, etc., can be achieved.

Cosmos SDK

When it comes to Cosmos SDK, most people are likely familiar with it. Cosmos SDK is a toolkit for developing blockchains or Rollups, used as a core tool by many newly launched blockchains, including numerous application chains in the Cosmos ecosystem, as well as Fairblock, dYdX V4, and Berachain.

In the development plan for Cosmos SDK, the Interchain Foundation stated that the focus for the new year will be on modularity and the introduction of new features.

First, regarding the outstanding "technical debt," Cosmos will continue to complete unfinished optimization work in the core layer, including storage, ABCI, and a layer that includes modules, staking, etc. Specifically, this includes:

Storage: Performance, scalability.

Core: Modularity (using different consensus engines: Rollkit, Dymint, etc.); switchable (easily switch components: storage, different module loaders (Wasm, FFI, gRPC, and local), clients, etc.).

Modules: Easy to prove in various virtual machines; reduce total lines of code; modularity (allow application developers to modify business logic); rewrite traditional modules (Auth, Bank, Staking, Distribution, Mint, Slash, etc.).

Cryptography: Rewrite key handling to make it more modular, allowing others to use custom HSMs; introduce new cryptographic primitives.

Second, regarding modularity, the Interchain Foundation believes that the term "modularity" has been overused in the blockchain field, with a focus on the level of software modularity. The Interchain Foundation stated that it will make Cosmos SDK more modular at the core level in the second half of this year and continue efforts into 2024, specifically including:

Consensus Modularity: Modularity (using different consensus engines: Rollkit, Dymint, etc.); switchable (easily switch components: storage, different module loaders (Wasm, FFI, gRPC, and local), clients, etc.).

Storage: Allow switching of existing structures; allow different structures between modules; read-write parallelization.

Module Composability: Allow users to fork or insert custom logic (depending on user feedback).

Third, there is not much to highlight in terms of maintenance, and fourth, regarding future plans, the Interchain Foundation plans to introduce the following updates:

Cross-language: Module loaders (WASM, FFI, GRPC); possibly closer integration with CosmWasm.

Upgrades: Separate the business logic of modules and VMs from core/node upgrades; achieve seamless upgrades (deploy upgrades before the target block height); achieve synchronization from the genesis state.

Research: ZK circuits for proving modules; fraud and validity proofs.

CosmJS

CosmJS is a library that helps developers integrate JavaScript-based clients with Cosmos SDK blockchains.

The Interchain Foundation plans to add new encoders to the CosmJS library to improve the library's efficiency, reduce code bloat, and provide users with a more streamlined and professional development experience. These updates aim to add native visualization, optimize package size, automate the encoding process, achieve multi-network adaptability, and create a more streamlined and scalable client.

Additionally, a key aspect of this work is to leverage Telescope's codegen capabilities to replace certain targets and automate them, such as making the library more streamlined, removing hard-coded helper methods, and allowing developers to customize their clients using modules and helper methods of their choice.

The update plans for CosmJS mostly involve lower-level technical aspects, and readers who want to understand the specific details can refer to the original text. In summary, it mainly includes "Proto Visual" encoding of information, keeping CosmJS synchronized with Cosmos SDK updates, more streamlined packages and code optimization, updating the Amino encoder and adding modules, using different keys and signatures for multi-network adapters, and creating more streamlined and scalable Telescope and Helpers clients.

CosmWasm

CosmWasm is a smart contract framework built for Cosmos SDK. On one hand, it allows users to deploy decentralized applications in a permissionless manner; on the other hand, blockchain developers can separate their product development cycles from blockchain development, reducing the frequency of validator upgrades and thus lowering the operational costs of the blockchain.

The Interchain Foundation stated that thanks to the application chain model using CometBFT, Cosmos SDK, and the near-native execution speed of Wasm contracts, Cosmos has solved the scalability issue, reducing transaction fees to a few cents, but this has also led to the available block space in L1 far exceeding the needs. Therefore, it is necessary to optimize CosmWasm to facilitate the development of more applications and improve block utilization, with a focus on IBC adoption and account intelligence.

The Interchain Foundation stated that by early 2024, CosmWasm 2.0 will be delivered and deployed on most chains. This will lay the groundwork for the features of versions 2.1, 2.2, and 2.3 released during 2024, which will include:

Zero-knowledge proof verification. By verifying zero-knowledge proofs in contracts, secure off-chain computation and various privacy applications can be achieved. By adding pairing-friendly elliptic curve cryptography to the application interface, CosmWasm is already prepared to serve these applications:

• Define application programming interfaces and find suitable implementation methods;

• Provide full-stack example applications demonstrating how to use the APIs in contracts;

• Set benchmarks and establish Gas costs.

Further upgrade IBC functionality. Advanced use cases that IBC currently cannot implement have emerged, which will be the focus of IBC updates:

• Comprehensive support for ADR-8, allowing contracts to respond to timeouts and confirmations of sent packets;

• Support for IBC fees, allowing contracts to pay fees for their own data packets;

• Create optional delayed confirmations, allowing the implementation of Packet Forward Middleware and ICQ long polling in contracts.

Other updates that lean towards lower-level technology or are of lesser importance include maintaining the current software stack, improving storage access efficiency, enhancing authz, creating IBC applications, hosting the AwesomWasm II hackathon in spring 2025, providing CosmWasm documentation for DApp developers, and running a CosmWasm testnet to facilitate developer testing.

IBC Protocol

The Inter-Blockchain Communication (IBC) protocol is a blockchain interoperability solution that allows for arbitrary data transfer between blockchains in a secure, permissionless manner, as well as seamless cross-chain sending and receiving of data between blockchains, applications, and smart contracts. From January 2022 to February 2023, ibc-go facilitated 52 million transfers, amounting to $29 billion. Currently, over 100 chains are connected to the IBC network.

The IBC ecosystem is very rich. In addition to applications developed by teams funded by ICF, other protocols include cross-chain transactions on Osmosis; Stride and Neutron widely using middleware, ICA, and queries; DAO DAO creating Polytone; Evmos establishing an IBC pre-compiler for transfers via EVM; and Injective establishing an oracle data stream module.

The Interchain Foundation stated that IBC will focus on two themes for updates in 2024: scalability and usability.

Scalability

IBC currently faces many challenges. So far, only Cosmos SDK and CometBFT chains using ibc-go can actually use the IBC protocol. Additionally, establishing the first connection with a non-Cosmos chain took nearly two years. If every integration takes this long, achieving the vision of IBC is fundamentally impossible.

Moreover, the maintenance overhead brought by implementing native IBC and relayers is enormous. In addition to the maintenance costs of IBC transmission and application implementation, each new blockchain architecture connected incurs a related relayer, resulting in maintenance and development costs. Relayers currently do not have a sustainable cash flow and must pay Gas fees and infrastructure costs for the services they provide, including off-chain protocols to pay for infrastructure costs, foundation grants, or using the Cosmos SDK fee grant module.

Accordingly, the specific updates needed for scalability include:

• Minimizing the development time required for IBC integration;

• Reducing the maintenance costs of IBC integration;

• Building an IBC connection framework for Layer1 and Rollup.

Usability

ICS-20 (token transfer) was the first application module launched by IBC-go in March 2021 and has since been the most widely used application. As applications become increasingly complex, simply sending tokens is clearly insufficient to meet interoperability needs. Therefore, the memo field was added to the ICS-20 packet to send additional data alongside token transfers, enabling more complex workflows such as cross-chain transactions and one-click liquidity staking when combined with middleware. However, the middleware design pattern specified in ICS-30 is often used in conjunction with the memo field, raising widespread concerns about key collisions. Additionally, stacking multiple middleware presents challenges for correctly formatting the memo field, and middleware must be executed in the correct order according to the workflow.

IBC denomination is another challenge developers face, as user interfaces need to display denominations in a human-readable format, which requires a registry maintained by each project. Since the circulation path of tokens determines the resulting IBC denomination, tokens arriving at their destination through different chains or channels will be non-fungible. Some existing applications have addressed this issue using packet forwarding middleware, but these solutions rely on off-chain configurations to determine the channel ID from the token origin to the destination. Long-term solutions should leverage on-chain registries.

Launched in March 2022, ICS-27, or Inter-Chain Accounts (ICA), has only been adopted by 8 chains for controller functionality. The initial design required building a custom authentication middleware to use this feature, which posed a direct barrier to broader adoption. The restructuring in ibc-go v6 eliminated this requirement; however, ICA still has many pain points, and alternative solutions like ics-999 and Polytone are attempting to address these pain points: lack of cross-channel ordering, atomicity in multi-channel workflows, and error handling required without atomicity.

Overall, all components of IBC are not easy for application or chain developers to learn and fully understand. This is reflected in the design decisions of trusted packet senders, which may lead to attacks due to claiming airdrops or trusting middleware through IBC. Additionally, upgrading to the latest ibc-go version is often not a priority, with about 60% of chains using unsupported versions.

Given the many existing issues mentioned above, the points where IBC urgently needs improvement in usability include:

• Improving the development experience for IBC users -- the convenience of deploying applications on a single chain should approach that of deploying cross-chain applications;

• Enabling the use of feature-rich applications on IBC beyond ICS-20 (token transfer);

• Applications developed using IBC should be significantly different from those using other protocols.

Strangelove's Support for the Interchain Stack

In addition to the Interchain Foundation, the crypto development company Strangelove, which has made significant contributions to the promotion and adoption of IBC, has also proposed a plan to support the Interchain stack. Among them, the adoption and marketing plan for IBC is particularly noteworthy, which includes:

• An Avalanche Subnet supporting IBC;

• 8 chains, including non-Cosmos SDK chains, supporting WASM light clients;

• 8 chains beginning to apply contract-to-contract IBC connections;

• Another Polkadot parachain, aside from Composable, directly connecting to IBC;

• Adding IBC support for NEAR;

• IBC cross-chain between Ethereum and Cosmos via cometBLS/ZK;

• 8 blockchains supporting IBC-App and middleware;

• 4 chains supporting ICS-721 format NFTs across chains via IBC.