Written by: Babywhale, Foresight News

The series of technical solutions launched by the Cosmos development team have always been popular with the Web3 development team. Whether it is the Cosmos SDK or IBC, many of these solutions 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, at last year’s Cosmoverse conference, the release of the Cosmos 2.0 white paper brought additional value to ATOM, including providing security for the “consumption chain” to collect fees and capture MEV revenue. Simply put, if Cosmos 2.0 is fully realized, ATOM will also benefit from the continuous expansion of the Cosmos ecosystem, so the remaining problem now is to realize the development of Cosmos 2.0 as soon as possible and further expand the Cosmos ecosystem.

Last month, the Interchain Foundation, which aims to promote the development of the Cosmos ecosystem, publicly released the development plan for the Interchain stack in 2024. The roadmap aims to achieve four strategic goals:

  1. Increase modularity by generalizing software to more easily adapt to specific use cases;

  2. Improve the developer experience to make it easier to build with the Interchain Stack;

  3. Pay off technical debt so you can make progress faster;

  4. Drive user adoption.

There are many plans in this that may change your judgment on the development prospects of Cosmos and ATOM.

CometBFT

CometBFT is the replication engine of the Interchain state machine to ensure that the network's validators agree on the generation of blocks, thereby ensuring the security and consistency of the blockchain network.

The Interchain Foundation says its goal is to grow Interchain by expanding the reach and applicability of CometBFT to help build sovereign interoperable applications. Additionally, cross-chain public goods stacks, including CometBFT, will need to reach new levels of flexibility and modularity to accommodate the increasing differentiation of applications in the interchain, provide institutional-grade services, and compete in multiple ways.

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

The Interchain Foundation plans to release v0.39, which is in preparation before the end of 2023. Its updates include efficiency improvements (reducing bandwidth and storage consumption), the Data Companion API that will eventually include indexers and RPC subsystems, etc., and is expected to be released in 2024 Released at the beginning of the year, this version may also be called v1.

As for what ABCI++ is, let’s start with ABCI. ABCI is the interface between applications and consensus. Its main function is to execute blocks determined by consensus. With ABCI, applications only interact with the consensus for decision-making and have little control over which transactions are picked from the mempool. ABCI++ adds programmability to every step of consensus, allowing applications to reorder, modify, abandon, delay, or add transactions, as well as reduce block production time by introducing the ability to optimize block production.

Sei uses ABCI++ to achieve optimized block production, intelligent block broadcasting and order parallel execution, thereby improving the processing efficiency of on-chain transactions.

To sum up, CometBFT provides a very customized block construction function for chains based on this consensus mechanism. Different chains can develop blocks and transaction sorting and execution methods according to their own needs, which greatly improves chain-level optimization. imagination. In addition, the Interchain Foundation has a very ambitious idea: allowing applications to leverage the capabilities of IBC directly through the ABCI interface, regardless of the virtual machine, framework or module stack used in their development. In this way, the goal of making IBC a cross-chain interoperability standard between on-chain applications developed based on Cosmos SDK, OP Stack, Celestia, etc. can be achieved.

Cosmos SDK

Speaking of Cosmos SDK, I believe most people are familiar with it. Cosmos SDK is a toolkit for developing blockchain or rollup. It is used as the core tool for development by many newly launched blockchains. In addition to many application chains in the Cosmos ecosystem, it also includes Fairblock, dYdX V4, Berachain, etc.

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

First of all, in terms of the "technical debt" owed, Cosmos will continue to complete the unfinished optimization work in the core layer including storage, ABCI, and the layer including modules, staking, etc., including:

Storage: performance, scalability.

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

Modules: easy to prove in various virtual machines; reduce the total number of lines of code; modular (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.

The second is modularity. The Interchain Foundation believes that the word "modularity" has been overused in the blockchain field, and its focus is on the modularity level of software. The Interchain Foundation stated that it will make the Cosmos SDK more modular at the core level in the second half of this year and continue to work until 2024, including:

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

Storage: Allows switching of original structures; allows different structures to be used between modules; parallelization of reading and writing.

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

There is not much content worthy of attention in the third maintenance aspect. In terms of the fourth future plan, the Interchain Foundation plans to launch the following updates:

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

Upgrades: Separate business logic of modules and VMS from core/node upgrades; enable seamless upgrades (upgrades deployed before target block height); enable synchronization from genesis state.

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

CosmJS

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

The Interchain Foundation plans to add new coders to the CosmJS library to improve the efficiency of the library, reduce code bloat, and provide users with a streamlined and more professional development experience. These updates are designed to add native visualization, optimize bundle sizes, automate the encoding process, enable multi-network adaptability, and create a more streamlined and scalable client.

Additionally, a key aspect of this work is leveraging Telescope's codegen feature to replace and automate certain goals, such as making the library more streamlined, removing hard-coded helper methods, and allowing developers to use modules and helper methods of their own choice to customize their client.

Most of the update plans for CosmJS involve lower-level technical aspects. Readers who want to know the specific details can read the original article by themselves. In summary, it mainly includes "Proto Visual" encoding of information, keeping CosmJS and Cosmos SDK updated in sync, more streamlined package and code optimization, updating the Amino encoder and adding modules, using multiple network adapters with different keys and signatures, and more streamlined , extensible Telescope and Helpers clients.

CosmWasm

CosmWasm is a smart contract framework built for the Cosmos SDK. On the 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 number of validator upgrades, thereby reducing the cost of blockchain. Blockchain operating costs.

The Interchain Foundation stated that thanks to the application chain model using CometBFT, the Cosmos SDK and the near-native execution speed of the Wasm contract, Cosmos solves the scalability problem and reduces transaction fees to a few cents, but it also results in L1 being available The block space is far more than needed. Therefore, CosmWasm needs to be optimized so that more applications can be developed more conveniently to improve block utilization, with the focus including IBC adoption and account intelligence.

The Interchain Foundation says that CosmWasm 2.0 will be delivered and deployed on most chains by early 2024. This will lay the foundation for feature additions in versions 2.1, 2.2 and 2.3 to be released during 2024, which will include:

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

  • Define application interfaces and find appropriate implementation methods;

  • Provide a full-stack sample application to show how to use the API in the contract;

  • Develop a baseline and set gas costs.

Further upgrade IBC functionality. Advanced use cases have emerged that are not possible with IBC and will be the focus of IBC updates:

  • Full support for ADR-8, allowing contracts to react to timeouts and acknowledgments of sent packages;

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

  • Creates optional delayed acknowledgments, allowing implementation of Packet Forward Middleware and ICQ long polling in the contract.

Other updates that favor the underlying technology or are of low importance include maintaining the current software stack, improving storage access efficiency, enhancing authz, creating IBC applications, hosting hackathon AwesomWasm II in the spring of 2025, CosmWasm documentation for DApp developers, running CosmWasm testnet to facilitate developer testing.

IBC Agreement

The Inter-Blockchain Communication (IBC) protocol is a blockchain interoperability solution that allows arbitrary data transfer between blockchains, as well as between blockchains, applications, and smart contracts in a secure, permissionless manner. Seamlessly send and receive data across chains. From January 2022 to February 2023, ibc-go facilitated 52 million transfers worth $29 billion. There are currently more than 100 chains connected to the IBC network.

The IBC ecology is very rich. In addition to applications developed by ICF-funded teams, other protocols include Osmosis for cross-chain transactions; Stride and Neutron making extensive use of middleware, ICA, and queries; DAO DAO created Polytone; and Evmos built an IBC precompiler for EVM Transmission; Injective established the oracle data flow module.

The Interchain Foundation said that IBC will be updated in 2024 around two themes: scalability and availability.

Scalability

IBC currently faces many challenges. To date, only the Cosmos SDK and the CometBFT chain using ibc-go can actually use the IBC protocol. Additionally, it took nearly two years to establish the first connection to a non-Cosmos chain. If every integration takes this long, it is simply impossible to achieve the IBC vision.

Additionally, the maintenance overhead associated with implementing local IBCs and repeaters is significant. In addition to the maintenance costs of IBC transmission and application implementation, each connection to a new blockchain architecture creates an associated relay and incurs maintenance and development costs. Relayers currently have no sustainable cash flow and must pay gas fees and infrastructure fees for the services they provide, including off-chain agreements to pay for infrastructure fees, foundation licensing, or use of the Cosmos SDK fee grant module.

Accordingly, specific updates required in terms of scalability include:

  • Minimize development time required for IBC integration;

  • Reduce maintenance costs for IBC integration;

  • Build the IBC connection framework of Layer1 and Rollup.

Availability

ICS-20 (Token Transfer) was the first application module launched by IBC-go in March 2021 and has been the most used application ever since. As applications become more complex, it becomes clear that simply sending tokens is not enough to meet interoperability needs. Therefore, the memo field is added to the ICS-20 data packet to send other data while sending tokens. Combined with middleware, more complex workflows can be implemented, such as cross-chain transactions and one-click liquidity staking. However, the middleware design patterns specified in ICS-30 are often used in conjunction with memo fields, which raises common concerns about key collisions. Additionally, stacking multiple middlewares poses challenges in properly formatting the memo fields, and the middlewares must be in the correct order for the workflow.

IBC denomination is another difficulty encountered by developers because the user interface needs to display the denomination in a human-readable format, which requires a registry maintained by each project to achieve this. Since the circulation path of a token determines the resulting IBC denomination, tokens arriving at their destination through different chains or channels will not be fungible. Some existing applications leverage packet forwarding middleware to solve this problem, but these solutions rely on off-chain configuration to determine the channel ID from the token origin to the destination. Long-term solutions should utilize on-chain registration.

ICS-27, the Interchain Account (ICA), launched in March 2022, currently has only 8 chains adopting the controller function. The original design required building a custom authentication middleware to use the feature, which created an immediate barrier to wider adoption of the feature. Refactoring in ibc-go v6 removes this need, however, ICA still suffers from a number of pain points that alternative solutions such as ics-999 and polytone attempt to address: lack of cross-channel ordering, atomicity in multi-channel workflows, and There is no error handling required for atomicity.

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

In view of the many existing problems mentioned above, the points that urgently need to be improved in terms of usability of IBC include:

  • Improve the development experience of IBC users - the convenience of deploying applications on a single chain should be closer to deploying cross-chain applications;

  • In addition to ICS-20 (token transfer), feature-rich applications can be used on IBC;

  • Applications developed using IBC should differ significantly from using other protocols.

Strangelove’s support for the Interchain stack

In addition to the Interchain Foundation, crypto development company Strangelove, which has played a major role in the promotion and adoption of IBC, has also proposed a plan to support the Interchain stack. Among them, IBC’s adoption and marketing plan is particularly worthy of attention, including:

  • An Avalanche Subnet supports IBC;

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

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

  • In addition to Composable, another Polkadot parachain is directly connected to IBC;

  • Add IBC support for NEAR;

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

  • 8 blockchains support IBC-App and middleware;

  • 4 chains support ICS-721 format NFT cross-chain through IBC.