v0.54 Release Notes

​

概览

此版本在网络稳定性和吞吐量方面带来了数量级的提升。在测试中，我们能够在多种网络配置下支持稳定的 1K TPS，同时区块时间不会出现下降；而此前一旦超过 200+ TPS，出块通常几乎会立刻变慢或停滞。 这得益于两项面向不同栈层的关键性能改进：

• 并行交易（BlockSTM）：当应用于包含可完全并行化交易的区块时，Block STM 在执行时间上可实现 5 到 10 倍的提升，具体取决于可用 CPU、区块大小以及运行的交易类型。我们已经修改了 Cosmos bank 转账和 EVM 原生转账的底层实现，以确保它们可以并行化，因此你可以立即从这些交易类型的加速中受益。对其他常见的 Cosmos 交易类型（例如治理、质押、auth）也可以采用相同方式，但我们目前尚未对它们进行优化。自定义交易类型和 EVM 智能合约同样可能需要调整实现，才能从并行化中受益。更多信息请参阅这里的指南。
• 增强网络（LibP2P）： 基于 lib-p2p 的 reactor 实现，在多种工作负载下的延迟基准测试中均优于 Comet 现有的 p2p 实现，在某些场景下可将 p99 延迟指标降低 100 倍，甚至最高达 1000 倍。libp2p 是点对点数据交换领域的行业标准。其底层依赖 QUIC，这是一种现代的、基于 UDP 的低延迟通信协议。目前，lib-p2p 主要面向集中管理的 Cosmos 网络使用，因为尚未支持节点对等发现，以及从 comet 网络栈迁移升级。如果你有兴趣在 devnet 或 testnet 环境中测试 libp2p，并可能为这些改进作出贡献，请联系我们。我们希望与各团队紧密合作以收集反馈。更多信息请参阅LibP2P 指南。

​

附加功能

1. AdaptiveSync 通过让共识和 blocksync 同时工作，帮助节点在落后时更快追赶。在流量高峰或区块时间较短时，这可以让节点在保持正常共识安全性和最终性行为的同时，持续跟上网络进度。对 RPC 负载较高的节点尤其有价值。更多信息请参阅区块同步指南。
2. Log/v2 支持 Cosmos SDK 的可观测性向 OpenTelemetry 迁移，从而实现所有日志输出的自动 trace 关联（如果 ctx 中存在 span，则会通过记录的键 trace_id、span_id 和 trace_flags 显示）。这由 Logger 接口上四个新的必需上下文化日志方法提供支持（InfoContext、WarnContext 等）。此外，新的 MultiLogger 支持同时分发到多个日志后端；当配置 OpenTelemetry 后，服务器现在会自动使用它。更多信息请参阅日志指南和遥测指南。
3. IBC General Message Passing (GMP)：IBC 中的通用消息传递支持在远程网络上调用任意智能合约。与 Interchain Accounts 不同，调用方无需在目标链上拥有账户（尽管它也足够通用，能够支持这种用法）。相反，GMP 会直接调用目标链上的合约。这使它特别适合实现 mint/burn 桥接（更多细节见下文）

​

企业功能

以下功能作为 Cosmos Enterprise 的一部分发布：

1. Groups 模块 为任意账户集合提供链上多签和集体决策能力。Groups 由带权重的成员组成，并可配置一个或多个决策策略，用于定义提案如何通过。成员可以提交包含任意 SDK 消息的提案、进行投票，并且在提案被接受后，任何账户都可以触发执行。内置提供两种决策策略：threshold（绝对加权票数）和 percentage（YES 票占比），二者都支持配置投票期和最短执行期。该决策策略接口支持自定义扩展。更多信息请参阅Groups 模块文档。
2. POA 模块 提供一个由管理员管理的验证者集合，可作为 staking、distribution 和 slashing 模块的直接替代。它专为由已知运营方运行的机构级部署而构建，提供简化的验证者生命周期，并且不需要原生代币。它开箱即用地支持向验证者分配费用，并完全兼容治理功能。更多信息请参阅POA 模块文档。

​

即将推出的功能（很快会在次版本中提供）

1. Krakatoa mempool（仅限 Cosmos EVM）：这个 mempool 通过让 comet mempool 无状态化，并为交易处理引入两个新的并发 ABCI 方法（reapTxs 和 insertTx），显著提升了交易吞吐量和网络稳定性。其结果是交易处理更高并发、更轻量，从而带来性能和稳定性收益。该功能将在 4 月底面向 Cosmos EVM 链提供。
2. Interchain Fungible Token Standard (IFT)： 与 ICS20 相比，这是一种更现代、更灵活的 IBC 代币转移方式，支持基于 mint/burn 的桥接。IFT 将铸造代币的合约或模块与 IBC 通道解耦。重要的是，这使代币发行方能够在其选择的任意网络上建立规范化、由自身拥有的代币部署，并使用 IBC 管理跨链 mint/burn，而不必使用自己无法控制的“wrapped”代币。它还允许单一代币在多条 IBC 路径上保持可替代性，并可在后台升级或更换 IBC 连接，而无需担心“token path”发生变化。该功能即将登陆 ibc-go、ibc-solidity 和 ibc-sol。
3. 为任意 EVM 网络提供 IBC 支持： IBC 功能将以一组实现 IBC Eureka 的 Solidity 合约形式，直接扩展到任意 EVM 网络。这将实现无需对 EVM 链做任何修改的直接 IBC 连接。这意味着 Ethereum、Base、Arbitrum、Optimism 以及其他 EVM 网络都可以直接参与 IBC 转账。结合 IFT，代币发行方可以基于单一事实源，在 Cosmos 和任意数量的 EVM 链之间管理规范化的代币部署。
4. 为 Solana 提供 IBC 支持： 与 EVM 支持类似，IBC 连接能力将通过原生程序实现扩展到 Solana。这将使 Solana 能够直接参与与 Cosmos 和 EVM 链之间的 IBC 转账，实现无需 wrapped 代币或中间链的跨生态代币流转。
5. IBC v2 relayer： 面向 IBC v2 协议的独立、可用于生产环境、请求驱动的 relayer 服务。该 relayer 将支持 Cosmos 系链与主流 EVM 网络（Ethereum、Base、Optimism、Arbitrum、Polygon 等）之间的互操作。运营者提交源交易哈希后，可以实时跟踪每个数据包的状态，从提交到中继完成的全过程；完整的重试和故障恢复将自动处理。

​

移除项

以下功能已从该发布系列中移除：

• ibc-apps/async-icq： 我们从未对 ibc-apps/async-icq middleware 提供过官方支持。这里仅是明确说明这一点。我们不会在本次发布中更新它，未来也不会继续更新。我们也不会测试它与 IBC-go v11.0.0 的兼容性。
• ibc-apps/pfm（packet forwarding middleware）： 我们从未对 PFM 提供过官方支持，但在历史上，我们确实会更新它，并尽最大努力在此前的发布周期中确保其与 IBC 兼容。我们不会在本次发布中继续这样做，未来也不会。相反，我们正在将 PFM 上游合入 IBC-Go，以简化我们的支持方式。我们将在这次迁移中保证等效的功能和 API。上游版本将在 IBC-go v11.1.0 中提供，供你迁移使用；我们计划在 2026 年 4 月底发布该版本。
• ibc-apps/rate-limits： 我们从未对 ibc-apps/rate-limits middleware 提供过官方支持，但在历史上，我们确实会更新它，并尽最大努力在此前的发布周期中确保其与 IBC 兼容。我们不会在本次发布中继续这样做，未来也不会。相反，我们正在将 PFM 上游合入 IBC-Go，以简化我们的支持方式。我们将在这次迁移中保证等效的功能和 API。上游版本将在 IBC-go v11.2.0 中提供，供你迁移使用；我们计划在 2026 年 5 月的前几周发布该版本。
• ibc-apps/ibc-hooks： 我们从未对 ibc-apps/ibc-hooks middleware 提供过官方支持，但在历史上，我们确实会更新它，并尽最大努力在此前的发布周期中确保其与 IBC 兼容。我们不会在本次发布中继续这样做，未来也不会。相反，我们正在引入并将维护一个新的 callbacks middleware，它支持在处理 ICS20 数据包时调用 Cosmwasm 合约（类似 ibc-hooks），以及 Cosmos 模块和 EVM 合约。我们正在努力确保即将发布的 wasmd 版本能够让 Cosmwasm 合约在不改变合约接口的情况下采用这一能力。

---

​

Overview

This release introduces order of magnitude improvements to network stability and throughput. In testing, we are able to support sustained 1K TPS on a variety of network configurations with no degradation in block time, whereas previously block production would have slowed / halted almost immediately after 200+ TPS. This is made possible through 2 critical performance improvements targeting different layers of the stack:

• Parallel transactions (BlockSTM): When applied to blocks containing fully parallelizable transactions, Block STM shows between 5-10x improvements in execution time depending on the available CPUs, size of the blocks, and types of transactions being run. We have modified the underlying implementations of Cosmos bank sends and EVM native sends to ensure they are parallelizable, so you will benefit from speed ups of these transactions immediately. It is possible to do the same for other common kinds of Cosmos transactions (e.g. governance, staking, auth), but we haven’t optimized them yet. Custom transaction types and EVM smart contracts may similarly require implementation modifications to benefit from parallelization. See our guide here for more information.
• Enhanced Networking (LibP2P): The lib-p2p based reactor implementation outperforms Comet’s existing p2p implementation on latency benchmarks across a variety of workloads, reducing p99 latency metrics by a factor of 100 and up to 1000 in some cases. libp2p is industry-standard in peer-to-peer data exchange. Under the hood, it leverages QUIC, a modern low-latency UDP-based communication protocol. At this time, lib-p2p is meant for usage in centrally managed Cosmos networks, as peer exchange and upgradeability from comet’s networking stack are not supported yet. Please reach out if you are interested in testing libp2p in devnet or testnet environments and potentially contributing these improvements. We want to work closely with teams to gather feedback. See the LibP2P guide for more information.

​

Additional Features

1. AdaptiveSync helps nodes catchup when they fall behind by letting consensus and blocksync work simultaneously. During traffic spikes or short block times, this keeps nodes progressing with the network while preserving normal consensus safety and finality behavior. Especially valuable for RPC-heavy nodes. See the block sync guide for more information.
2. Log/v2 supports the transition of the Cosmos SDK’s observability to OpenTelemetry, enabling automatic trace correlation across all log output (show via the logged keys trace_id, span_id, and trace_flags, if a span is present in the ctx). This is powered by four new required contextual logging methods on the Logger interface (InfoContext, WarnContext, etc). Additionally, a new MultiLogger allows fanning out to multiple logging backends simultaneously, which the server now uses automatically when OpenTelemetry is configured. See the logging guide and telemetry guide for more information.
3. IBC General Message Passing (GMP): General Message Passing in IBC enables calling arbitrary smart contracts on remote networks. Unlike Interchain Accounts, the caller does not need to own an account on the destination chain (though it is general enough to support this usage pattern). Instead, GMP directly calls contracts on the destination chain. This makes it especially useful for implementing mint/burn bridges (See below for more details)

​

Enterprise Features

The following features are released as part of Cosmos Enterprise:

1. The Groups module enables on-chain multisig and collective decision-making for any set of accounts. Groups are formed with weighted members and one or more configurable decision policies that define how proposals pass. Members submit proposals containing arbitrary SDK messages, vote, and any account can trigger execution once a proposal is accepted. Two built-in decision policies are included: threshold (absolute weighted vote count) and percentage (proportion of YES votes), each with configurable voting and minimum execution periods. The decision policy interface supports custom extensions. See the Groups module docs for more information.
2. The POA module provides an admin-managed validator set as a drop-in replacement for the staking, distribution, and slashing modules. Purpose-built for institutional deployments run by a known set of operators, it offers a streamlined validator lifecycle with no native token required. Fee distribution to validators and full governance compatibility are included out of the box. See the POA module docs for more information.

​

Upcoming Features (Available soon in Minor Releases)

1. Krakatoa mempool (Cosmos EVM only): This mempool significantly improves transaction throughput and network stability by making the comet mempool stateless and introducing two new concurrent ABCI methods for transaction processing (reapTxs and insertTx). The upshot is that transaction processing is more concurrent and more lightweight, resulting in performance and stability gains. This will be available for Cosmos EVM chains at the end of April.
2. Interchain Fungible Token Standard (IFT): This is a more modern and flexible approach to token transfers in IBC compared to ICS20 that enables mint/burn based bridging. IFT decouples the contract or module that mints a token from the IBC channel. Importantly, this allows token issuers to establish canonical, owned deployments of their tokens on any networks they choose and manage cross-chain mints/burns with IBC, rather than using “wrapped” tokens that they cannot control. It also allows a single token to support fungibility over multiple IBC paths and to upgrade/change the IBC connection in the background without worrying about the “token path” changing. This is coming shortly to ibc-go, ibc-solidity, and ibc-sol.
3. IBC support for any EVM network: IBC functionality will extend directly to any EVM network as a collection of Solidity contracts that implement IBC Eureka. This will enable direct IBC connectivity without requiring any modifications to the EVM chain. This means Ethereum, Base, Arbitrum, Optimism, and other EVM networks can participate directly in IBC transfers. Combined with IFT, token issuers can manage canonical token deployments across Cosmos and any number of EVM chains from a single source of truth.
4. IBC support for Solana: Similar to EVM support, IBC connectivity will extend to Solana with a native program implementation. This will allow Solana to participate directly in IBC transfers with Cosmos and EVM chains, enabling cross-ecosystem token movement without wrapped tokens or intermediary chains.
5. IBC v2 relayer: A standalone, production-ready, request-driven relayer service for the IBC v2 protocol. This relayer will support interoperating between a Cosmos-based chain and major EVM networks (Ethereum, Base, Optimism, Arbitrum, Polygon, and more). Operators submit a source transaction hash and can track each packet’s status in real time, from submission through relay completion, with full retry and failure recovery handled automatically.

​

Removals

The following features have been removed from this release family:

• ibc-apps/async-icq: We have never had official support for ibc-apps/async-icq middleware. This is us just stating this explicitly. We will not be updating it as a part of this release or going forward. We will not be testing its compatibility with IBC-go v11.0.0
• ibc-apps/pfm (packet forwarding middleware): We have never had official support for PFM , but historically, we did update it and make a best effort to ensure compatibility with IBC in during previous release cycles. We will not be doing that as a part of this release or going forward. Instead, we are upstreaming PFM into IBC-Go to streamline our support. We will guarantee equivalent functionality and APIs as part of this migration. The upstreamed version will be available for you to migrate to in IBC-go v11.1.0, which we are planning to release towards the end of April 2026.
• ibc-apps/rate-limits: We have never had official support for ibc-apps/rate-limits middleware, but historically, we did update it and make a best effort to ensure compatibility with IBC in during previous release cycles. We will not be doing that as a part of this release or going forward. Instead, we are upstreaming PFM into IBC-Go to streamline our support. We will guarantee equivalent functionality and APIs as part of this migration. The upstreamed version will be available for you to migrate to in IBC-go v11.2.0, which we are planning to release in the first weeks of May 2026.
• ibc-apps/ibc-hooks: We have never had official support for ibc-apps/ibc-hooks middleware, but historically, we did update it and make a best effort to ensure compatibility with IBC in during previous release cycles. We will not be doing that as a part of this release or going forward. Instead, we are introducing and will maintain a new callbacks middleware that enables calling Cosmwasm contracts (like ibc-hooks) as well as Cosmos modules and EVM contracts when processing ICS20 packets. We are working to ensure the upcoming wasmd release will enable Cosmwasm contracts to adopt this without changing contract interfaces.