转发信息：深入探讨IBC转发器的操作

Interchain GmbH 团队将很快发布 ICS-29——中继费用激励——用于 ibc-go 模块。这标志着 IBC（跨链通信）协议可扩展性路线图上的一个重要里程碑。

中继操作员是 IBC 基础设施的重要组成部分，但有时他们的存在被视为理所当然。在这篇博客文章中，我们将重点介绍中继功能，并考虑确保 IBC 启用（或有意启用）链的平稳和可靠的中继覆盖率的方法。以下内容和建议来源于我们与中继操作员进行的一系列访谈，启动了一项监测中继体验并规划额外支持的工作，希望第一轮访谈得出的结论对那些有兴趣开始中继、新链想要启用 IBC，或者对 IBC 及其运作方式有兴趣的任何人有所帮助。

阅读指南：本文旨在为多种听众提供信息。对总体情况感兴趣的链代表可能希望跳过关于 Relayer 软件 和 技术设置 的部分。另一方面，渴望成为中继操作员的人可能希望专注于这两个部分作为起点。

中继在 IBC 中的角色

让我们简单回顾一下什么是中继、为什么它很重要，以及它与跨链通信（IBC）的关系。IBC 为区块链提供了一种协议，使数据包的可靠、安全和无权限传输成为可能。该协议与数据无关，为应用开发者开发各种可能的跨链服务铺平了道路（可替代和不可替代的代币转账显然是一个候选者，同时也包括通过 跨链账户 或 跨链安全 的任意跨链消息传递）。

从高层次上看，这一过程的工作方式如下。源链上的一个模块希望将一个数据包发送到目标链。它向源链提交一条消息，该消息在链上存储了一个承诺证明，并记录了包含数据包信息的事件。凭借这些信息和证明，我们可以向目标链上的 IBC 客户端提交一条消息，后者将验证该证明，如果成功，将在链上存储收据，并允许接收模块根据数据包数据执行所需的操作。为了简化起见，我们将省略确认和超时功能，更多信息请参见 文档。

在这个流程中，有两个重要的考虑因素。首先，在接收链上，我们需要验证源链上的承诺证明。这就是为什么需要一个轻客户端来有效地跟踪对方链的状态。我们再次引用 文档 来了解更多信息。其次，区块链无法直接相互通信，那么证明确认和数据包信息是如何到达目标链以继续上述流程的呢？

这就是中继操作员发挥作用的地方，他们确保通过网络基础设施中继数据包。中继操作员可以访问源链和目标链的完整节点，在这些节点上他们可以查询和提交消息。他们在其中继的频道上监听需要发送 IBC 数据包的事件。他们运行中继软件，使他们能够重建数据包及其证明，并将其提交到目标链。在目标链上存储收据后，会进行类似的处理，促进确认消息发送到源链。

谁是中继操作员？

中继是无权限的。IBC 协议设计为即使在存在故障或恶意中继的情况下也能安全运行。中继的无权限性质，以及在 IBC 启用链上无权限创建客户端、连接和频道，是 IBC 在互操作性愿景中的关键价值主张。与大多数其他需要将受信任的验证器集作为代币转账桥梁中介的互操作性解决方案不同，IBC 信任的是链本身，而不是桥梁。这里的含义是，在扩展的跨链生态系统中，管理、安全和维护桥梁的任务不应被少数可信方所瓶颈。

无权限中继意味着任何人理论上都可以开始中继。然而，实际上，链间中继涉及重大的硬件要求和运行节点基础设施的知识。由于中继对节点施加了大量 RPC（远程过程调用）压力（有关详细信息，请参考下面的技术部分），建议中继操作员为他们希望中继的链运行自己的完整节点。因此，在 ICS-29 引入之前，中继主要由已经验证 IBC 启用链的团队进行（通常，中继操作员仅为他们没有验证的少数链提供服务）。我们将在后面重新讨论成本和激励的话题，以探索中继者如何获得回报或可能获得回报的方式。

然而，对于希望实现 IBC 并需要确保中继操作员支持的链而言，关键在于：与你自己验证者社区或希望连接的对方链群体接触。例如，目前所有顶级中继操作员大多数情况都是在一个大型链决定采用 IBC 时开始中继（如 Osmosis、Juno、Secret 等）。另一种选择是联系主要中继操作员，询问他们是否提供 中继即服务 的服务（查看 Osmosis IBC 中继器列表 以了解哪些团队提供该服务）。随着中继费用激励的变化，监测这一情况将变得极为有趣，但在撰写时，这仍然是最佳选择。

中继软件

一旦某人决定开始中继，就可以查看可用的不同中继软件实现。目前，这些有：

• Hermes 中继器。由 Informal Systems 使用 Rust 开发
• Golang 中继器。由 Strangelove Ventures 使用 Go 开发
• Typescript 中继器。由 Confio 使用 Typescript 开发

Hermes 和 Go 中继器都提供了一些诱人的功能，适合开始中继。Hermes 文档 非常全面，提供了各种功能的概述（请参考文档中的功能矩阵，了解当前支持的内容），但可能需要对 IBC 协议有更深入的了解。Go 中继器则专注于便于运行，因此可能是初学者更容易选择的选项。Hermes 和 Golang 中继器都提供可以在 2 个本地链上进行测试的教程。这使得在进入测试网和主网之前，可以对软件和配置文件进行实验。在中继操作员的访谈中对此提出增加激励测试网的需求，这在为新链实现 IBC 时也应考虑，以便引入新的或现有的中继器。

注意：Typescript 中继器目前并未积极维护，因此在生产中不应使用。然而，Ignite CLI 教程默认使用它，因此你可能会遇到。虽然不同的中继软件很容易进行插件和替换（只需确保配置文件设置正确，并运行所选择的中继器），但我们仍然想提到 Typescript 中继器，因为它在客户端中继方面具有潜力。作为 Javascript 的超集，适合网页的客户端语言，Typescript 中继器可以让用户实现无缝的 客户端中继，意味着最终用户可以从浏览器或移动设备中继他们自己的数据包，而不依赖于中继操作员提供的基础设施。不过，这在目前并不可用，并且相信未来将会出现客户端和服务器端混合中继的情况。

中继软件使用配置文件整合所有重要的配置参数，包括链参数（如 RPC、gRPC 和 websocket 端点）以及路径信息。对于 Hermes，你可以在 这里 找到不同参数的解释。Go 中继器具有从链注册表中获取配置数据的功能，你可以查看他们的 Github。你始终可以查看 Cosmos 链注册表 以获取 Interchain 链和资产的元数据。最近，已为 IBC 数据添加了数据模式，以改善中继器的用户体验。我们在不断努力改进可用数据，确保其更新。

我们与采访中大部分中继操作员交谈结果发现，他们要么全面运行 Hermes，要么主要运行 Hermes，并辅以 Golang 中继器作为备份或特定用例（例如当某个通道拥堵且数据包被阻塞时，发现 Golang 中继器在拥堵时能略好一些地清除通道）。对此设置引述的最多理由是生产环境中的性能。然而，与负责维护 Go 中继器的团队交谈时，他们正大力改善性能以及未来版本的日志记录和调试工具。此外，他们专注于为中继软件使用提供者接口，以便利与非 SDK 链的集成，这是一个重要特征，因为 IBC 协议在它起源的 Cosmos 生态系统外获得更多关注。

我们认为，对于发现两种应用并找出优缺点甚至尝试混合工作流程以优化设置，都是绝对值得的。例如，Notional 团队在 此处 提供了混合设置的概述（应当注意，这适用于 Golang 中继器 v1，因此在最终 v2 发布时应做修订）。

当需要支持以建立中继操作，或在此过程中有问题或困难时，你可以从经验丰富的中继器和中继软件开发团队中获得专家支持，交流在 IBC Gang Discord。此外，我们正在调查是否可以设置一个最佳实践资源库，以便运营商分享他们的设置信息。有关更多信息将会跟进。

我们还想提出一些额外的观点和常见的陷阱，包括：

• 同时强调并非每个中继操作员在开始中继特定路径时都需要初始化自己的通道。这是新手在开始中继时一个相当常见的误解。

截至目前，通过 ICS-20 的 IBC 代币转账是主要的 IBC 应用，仅需在链间打开一个规范通道。实际上，通过不同通道发送的代币将因 IBC номinals 的工作方式而变得不可替代，这是应该避免的。除非你在帮助链设置 IBC，否则很可能已经建立了一个规范通道。在不确定时，你可以通过 Map of Zones、Mintscan 或使用中继软件查询通道，检查是否已建立规范通道。最近为 IBC 数据添加了 新的数据模式到链注册表，并将在不久的将来扩展。这将提供有关规范通道的确切信息。

• 注意：随着越来越多的链实现跨链账户（目前每个跨链账户确实需要一个单独的通道），中继操作员设置通道将变得更加普遍，但仍建议在此之前做一些研究，看看是否存在规范通道。
• 中继数据包通常要求中继器在提交消息时支付费用（稍后会详细说明）。请记住，你需要设置一个已携带资金的钱包，以成功中继数据包。这适用于本地测试设置（可通过配置文件轻松授予地址资金）、公共测试网（可以通过水龙头获取测试网代币）和主网。

技术设置

在上一节中介绍了不同的中继软件实现，并将配置文件识别为配置参数的聚集地。在这一节中，我们引用一个更具体的技术设置示例并识别出当前最大的技术瓶颈。

作为 IBC 的大型用户，Osmosis 依赖于对所有连接链的良好中继覆盖。他们提供了一个 开始中继的指南，详细介绍了硬件需求、安装和配置设置，以开始中继。在查看指南时，你会注意到，为 RPC、gRPC 和 websocket 服务器配置端点的重要性，并确保中继器的配置（示例中是 Hermes）包含正确的端点。

Osmosis 中继器指南提到了一些清除数据包的命令，更详尽的列表可以在 Hermes 文档 中找到（对于 Go 中继器，你可以在 CLI 中运行 rly -h 查找命令列表）。这些命令包括建立新的客户端、连接和通道的命令（仅在未存在规范通道的情况下），包括握手消息、传递接收和确认消息的数据包消息、更新和升级客户端消息、清除数据包及若干查询。这些大多数根据需要在使用 hermes start 命令时自动执行，但也可以更加精细地使用。

如我们之前所述：中继器能够访问源链和目标链的完整节点，在这些节点上可以查询和提交消息。他们在中继的链上“监听”需要发送 IBC 数据包的事件，与他们所中继的通道相关（可以实现过滤以允许或过滤某些通道）。目前，中继器使用 Tendermint RPC 端点来查询所需的承诺证明，以验证对方链上的 IBC 交易。这些查询的数量可能为节点的 RPC 端点施加显著压力，这正是当前生产中的主要瓶颈。由于 Tendermint RPC 是单线程的，大量的中继查询可能会导致节点不同步，从而需要定期重置。这并不是中继软件的结果，而是节点架构造成的，随着 gRPC 支持工作的持续开展，这种情况可能会改善。

行动呼吁：负责维护中继软件的 Informal 和 Strangelove Ventures 团队希望邀请中继操作员提供反馈，如果存在问题或困难。他们会在 IBC Gang Discord 的相应 #hermes 和 #rly 频道中积极监控，并在需要时提供实时调试支持。两个团队都致力于改善软件设计，以满足中继操作员在生产中的需求。

成本与扩展

回顾上文，中继器捕捉事件并提交消息到对方链。这些消息的提交需要支付交易费用（除非链决定采用无费用的 IBC 消息，你需要向链社区确认），至今为止，没有任何链上费用激励的情况下，这意味着中继器需要自掏腰包支付这些费用。

现在，让我们考虑覆盖费用的当前解决方案的概述，并可能为中继器提供额外激励：

• 团队委派：团队委派是一种让中继者间接受益于他们提供的中继服务的办法，因为大多数中继操作员也是他们所中继链的验证者。
• 直接资助：链直接资助中继器的钱包
• 中继器（社区）资金池：一部分社区资金被聚集并分配给中继操作员。从一些经验来看，这并不总是容易以公平的方式执行。
• 费用授予：Cosmos SDK 链具有 费用授予 功能，允许一个账户为另一个账户支付费用。通过这种方式，链托管账户可以为中继器支付费用，例如借鉴这个 配置 文件，Omniflix团队使用的配置文件。然而，这一功能仅覆盖中继成本并不会提供额外的激励。
• 中继费用中间件（ICS-29）：费用中间件允许最终用户或链为中继器每一个数据包提供费用，更多信息请参见 这篇博客。

希望实施中继激励的链应调查上述解决方案——或混合——最适合他们的需求和愿景。例如，我们可以预见在全力以赴拥抱多链功能作为他们商业模式核心的链与将资产通过 IBC 转移视为额外功能的链之间会有不同的做法。他们可能对是否将中继成本转嫁给最终用户或自担费用有不同看法，例如通过使用社区资金池或其他链上账户来支付 ICS29 激励，作为 IBC 交易流的一个集成部分。

从访谈中得出的一个有趣观察是关于扩展的话题。许多中继操作员目前为大约 10-15 条链提供中继服务。原则上，向配置文件中添加更多链（通道）并在获得如何执行的知识后为这些路径提供中继是很简单的。然而，一旦接近这条链的数量，基础设施设置的复杂性以及管理它的工作量和工程能力也会增加。结果是，随着服务的链数量增加，总成本中用于运营成本的比例上升而非费用。对于许多团队而言，这可能成为一个瓶颈，因为他们通常只有少数几个人，找到能处理额外复杂性的 DevOps 技能与配置可能会证明困难。

随着成本和盈利考虑，以及在扩展时增加的复杂性，可能会自然限制中继操作员决定用于中继的链数量。监测随着时间的推移这一变化将非常有趣，随着跨链的扩展，我们会看到许多较小的中继操作员团队为数十条链提供中继，还是会看到少数主导者克服初期人力和技术设置限制，并为大多数可用链提供服务？

覆盖地图

为了使 IBC 一切正常，我们假设有中继操作员可用，从而提供数据包的中继。中继是无权限的，且可以激励。然而，无权限的性质并不应该掩盖对服务质量保证的需求。必须提供工具以确保 IBC 应用中所使用路径的充足覆盖。截至撰写时，已自发设立的倡议在社区中创建电子表格，跟踪运营商的覆盖或冗余情况。

例如，在 I BC Gang Discord 中，有固定的电子表格跟踪 Osmosis、Juno、Secret 的中继覆盖（欢迎添加此类其他资源）。此类解决方案提供了一些即时好处：设置相对简单，并能提供中继操作员正在服务的链和通道的初步印象。然而，这种方式也有缺点：所有中继操作员必须了解这些跟踪文件的存在，保证其随时间的准确性需要投入大量精力，并且随着跨链账户和使用 IBC 的 CosmWasm 合同的引入，每次都预计会显著增加可用通道数量。未来，我们可能会看到一个更动态的景观，中继器在更突出地使用通道过滤。到目前为止，IBC 交易仅限于代币转账，因此期望所有规范的 ICS-20 通道在为特定的链对提供中继时都会被接收。

此外，还有由 Imperator 团队最初开发的 ibc-status bot，现在已开源，社区可做改进。这个工具证明是社区广泛使用的一种受人喜爱的工具，显示待清除的挂起数据包，并允许中继操作员社区协调解决方案。例如，当较少覆盖路径上的中继操作员下线或客户端过期时，状态机器人能够帮助社区作出反应。然而，我们可以设想，额外的监控功能将揭示更多关于冗余的信息（如果中继器没有成功取走数据包，那么有多少额外的中继器本可以接管它）。

这些倡议为 IBC 的成功推出奠定了很好的基础（有关更新的交易量和成功率，请参见 Map of Zones）。然而，为确保实现跨链愿景，仍需进一步改善。Interchain GmbH 团队继续制定路线图，并开发将帮助 IBC 社区实现这一愿景的功能。此外，我们促进主要利益相关者之间的讨论，使他们了解中继领域中的不同策略和可用技术，并为社区提供教育材料。社区的未来发展和不同利益相关者之间的互动将决定确保覆盖的最合适解决方案，不论是在 IBC 启用链的层面，还是通过中继操作员（尤其是提供中继即服务的中继操作员）的监控仪表盘等更复杂的监控，甚至是链上的监控协议。

感谢

我们要感谢那些我们采访过的中继操作团队，他们为我们的合作和对中继体验的宝贵见解提供了支持：Lavender Five Nodes、CryptoCrew Validators、Cros-nest、Imperator、Notional 和 Cephalopod。同时感谢 Hermes 和 Go 中继团队向我们提供调研路线图的反馈：Informal Systems 的 Adi 和 Strangelove Ventures 的 Justin。

我们乐于与中继操作员进行更多访谈，并将联系各团队。如果你是中继操作员并希望与我们联系，可以通过 thomas@interchain.io 与我取得联系。

特别感谢 Charly Fei 在研究过程中对我的支持和提供的宝贵建设性反馈。也非常感谢 Alan、Carlos 和 Susannah 的审阅和反馈。

• 原文链接： medium.com/the-interchai...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～