IBC v2 Relayer 是一项面向企业的 IBC v2 中继服务,用于在 Cosmos、EVM 和 Solana 环境之间实现通用中继。 它专为高性能、具备策略感知能力的跨链操作而构建,覆盖 Cosmos 到 Cosmos、Cosmos 到 EVM、EVM 到 EVM、Solana 到 Cosmos 以及 Solana 到 EVM 的连接。 该中继器采用请求驱动模型。客户端通过中继器 API 提交源交易哈希,中继器随后负责在整个中继生命周期内完成数据包传递。 该中继器面向有以下需求的组织而设计:
  1. 高性能中继控制,提供请求驱动 API,并支持可配置的批处理、并发度和最终性设置。
  2. 生产就绪的签名能力,支持本地密钥或外部 gRPC 签名器。
  3. 运维安全控制,包括针对 EVM 中继请求内置的 OFAC 发送方检查。
  4. 生产级可观测性,包括 Prometheus 指标、/health、交易跟踪以及可选的 gas 成本跟踪。
  5. 对 recv、ack 和 timeout 流程提供完整生命周期支持,并在整个中继流水线中提供重试处理。

扩展的连接能力与特性

企业版中继器方案强调跨链操作的三项优势:
  1. 通用覆盖,围绕新的网络连接能力提供支持,包括 Solana、Hyperledger Besu、Ethereum、Base、Arbitrum 以及其他 EVM 网络。
  2. 完整生命周期支持,覆盖跨链工作流中的数据包中继、证明与证明声明构建、费用管理以及实时跟踪。
  3. 基于策略的数据包选择,支持在中继层进行面向合规的数据包过滤与优先级排序。

关键能力

  • 多链 EVM 支持,兼容 Ethereum、Base、Optimism、Arbitrum、Polygon 以及其他 EVM 兼容网络。
  • 请求驱动中继,当客户端通过中继器 API 提交交易哈希时,数据包会按需中继。
  • 自动重试,recv、ack 和 timeout 交易在整个中继流水线中都包含重试处理。
  • 交易跟踪 API,客户端可使用交易哈希轮询 Status API,以跟踪数据包在中继生命周期中的进度。
  • 远程签名,中继器可将交易签名委托给外部 gRPC 签名服务,从而使私钥保留在中继器进程之外。
  • 批处理,recv、ack 和 timeout 数据包可累积后批量提交,并支持可配置的批大小、超时和并发设置。
  • 地址黑名单,当交易发送方命中内置 OFAC 黑名单时,可拒绝 EVM 中继请求。
  • Gas 成本跟踪,可按链跟踪交易成本,并通过 Prometheus 指标暴露。

通用 IBC 中继的最佳可用方案

特性替代方案IBC v2 Relayer
Solana 支持✗✓
Ethereum 支持✗✓
Base、Arbitrum 和 EVM L2 支持✗✓
Hyperledger Besu 支持✗✓
基于策略的数据包选择✗✓
实时跟踪✗✓
费用管理✗✓
纳入 Cosmos 漏洞赏金计划✗✓
由 Cosmos 核心开发者持续开发和维护✗✓

架构

该中继器作为独立服务运行,包含三个主要组件:gRPC API 服务器、Postgres 数据库和中继调度器。当客户端提交中继请求时,中继器会验证源交易、提取数据包数据、将传输状态存储到 Postgres、通过 Proof API 请求中继交易数据,然后通过其处理流水线提交所需的 recv、ack 或 timeout 交易。 如需查看完整的端到端架构,请参阅 Deployment Overview。如需了解证明构建和证明声明细节,请参阅 Proof API 和 Attestor 文档。

源代码

源代码可在 cosmos/ibc-relayer 仓库中获取。

可用文档

可用性

IBC v2 Relayer 仓库以 Source Available Evaluation License 发布。生产或商业用途需要从 Cosmos Labs 获取企业许可证。 详情请参阅 license file。如需企业许可,请联系 Cosmos Labs。
The IBC v2 Relayer is an enterprise-ready IBC v2 relaying service for universal relaying across Cosmos, EVM, and Solana environments. It is built for high-performance, policy-aware cross-chain operations, including Cosmos-to-Cosmos, Cosmos-to-EVM, EVM-to-EVM, Solana-to-Cosmos, and Solana-to-EVM connectivity. The relayer uses a request-driven model. Clients submit a source transaction hash through the relayer API, and the relayer handles packet delivery across the relay lifecycle. The relayer is designed for organizations that require:
  1. High-performance relay control, with request-driven APIs and configurable batching, concurrency, and finality settings.
  2. Production-ready signing, with support for local keys or an external gRPC signer.
  3. Operational safety controls, including built-in OFAC sender checks for EVM relay requests.
  4. Production observability, including Prometheus metrics, /health, transaction tracking, and optional gas cost tracking.
  5. Full lifecycle support for recv, ack, and timeout flows, with retry handling across the relay pipeline.

Expanded connectivity and features

The Enterprise relayer offering emphasizes three advantages for cross-chain operations:
  1. Universal coverage, with support positioned around new network connectivity including Solana, Hyperledger Besu, Ethereum, Base, Arbitrum, and other EVM networks.
  2. Full lifecycle support, covering cross-chain workflows including packet relaying, proof and attestation construction, fee management, and real-time tracking.
  3. Policy-based packet selection, enabling compliance-oriented packet filtering and prioritization at the relay layer.

Key capabilities

  • Multi-chain EVM support, compatible with Ethereum, Base, Optimism, Arbitrum, Polygon, and other EVM-compatible networks.
  • Request-driven relaying, packets are relayed on demand when a client submits a transaction hash through the relayer API.
  • Automatic retry, recv, ack, and timeout transactions include retry handling across the relay pipeline.
  • Transaction Tracking API, clients can poll the Status API with a transaction hash to follow packet progress through the relay lifecycle.
  • Remote signing, the relayer can delegate transaction signing to an external gRPC signer service so private keys are kept outside the relayer process.
  • Batching, recv, ack, and timeout packets can be accumulated and submitted in batches with configurable size, timeout, and concurrency settings.
  • Address blacklisting, EVM relay requests can be rejected when the transaction sender is on the built-in OFAC blacklist.
  • Gas cost tracking, transaction costs can be tracked per chain and exposed through Prometheus metrics.

The best available option for universal IBC relaying

CharacteristicAlternativesIBC v2 Relayer
Solana support✗✓
Ethereum support✗✓
Base, Arbitrum, and EVM L2 support✗✓
Hyperledger Besu support✗✓
Policy-based packet selection✗✓
Real-time tracking✗✓
Fee management✗✓
Included in Cosmos bug bounty program✗✓
Ongoing development and maintenance by Cosmos core developers✗✓

Architecture

The relayer runs as a standalone service with three main components: a gRPC API server, a Postgres database, and a relay dispatcher. When a client submits a relay request, the relayer verifies the source transaction, extracts packet data, stores transfer state in Postgres, requests relay transaction data from the Proof API, and then submits the necessary recv, ack, or timeout transactions through its processing pipeline. For a full end-to-end architecture view, see the Deployment Overview. For proof construction and attestation details, see the Proof API and Attestor documentation.

Source Code

The source code is available in the cosmos/ibc-relayer repository.

Available Documentation

Availability

The IBC v2 Relayer repository is published under a Source Available Evaluation License. Production or commercial use requires an Enterprise License from Cosmos Labs. See the license file for details. Please contact Cosmos Labs for enterprise licensing.