通道可升级性将如何提升跨链互操作性

在 IBC（跨区块链通信）协议 的传输层中，渠道（channels）是核心组成部分。渠道充当两条不同链上两个 应用模块（application modules） 之间传输数据包的导管—每个渠道与单个应用相关联。

渠道可升级性（Channel upgradability） 将成为 IBC 作为其重要特性发布的一部分。为什么会这样？什么是渠道可升级性？它有多重要？这篇博客文章将回答这些问题以及更多内容。

什么是渠道可升级性，为什么需要它？

渠道可升级性是一个 IBC 级别的协议，允许链利用新渠道功能，而无需创建新渠道或进行网络范围的升级。

截至目前，想要升级应用模块或添加中间件的 Cosmos 链，无法在维护现有渠道的同时进行。例如，为了更新转账模块以利用新功能，或者实施 费用中间件模块（fee middleware module）（用于链上对中继者的激励），需要进行协调的网络范围升级或重新谈判一个新渠道。其缺点是失去现有渠道的累积状态/流动性、代币可替代性以及网络效应。

随着渠道可升级性（计划于 2023 年第一季度发布）的推出，这不再是一个问题。应用将能够实现如 在可替代代币的数据包中包含备注字段、为代币添加 denom 元数据 或利用 费用中间件 的功能，同时维护当前操作的渠道。

设计概览

渠道升级将通过一系列类似于标准 连接/渠道打开握手（connection/channel opening handshake） 的握手过程来初始化。

成功的渠道升级握手过程如下：

1. 启动升级过程的链（链 A）通过 ChanUpgradeInit 函数将其 渠道状态（channel state） 从 OPEN 设置为 INITUPGRADE。
2. 随后，对方（链 B）通过 ChanUpgradeTry 将其渠道端状态从 OPEN 更改为 TRYUPGRADE。
3. 在上一步成功完成后，链 A 通过 ChanUpgradeAck 将其渠道状态设置为 OPEN。
4. 最后，链 B 通过 ChanUpgradeConfirm 将其渠道状态设置为 OPEN。

图 1：用于渠道升级的握手过程。蓝色箭头表示从核心 IBC 到应用的回调。

ChanUpgradeInit 函数由中继者或链在治理授权下触发（下面详细介绍访问控制）。链 A 上的核心 IBC 在传输层执行验证和排序检查。随后，链 A 的应用通过蓝色箭头指示的回调执行其自定义 INIT 逻辑。接下来，链 B 启动 ChanUpgradeTry。类似于链 A 的回调，链 B 中的应用将执行其自定义 TRY 逻辑。最后，由中继者发送 ChanUpgradeAck 和 ChanUpgradeConfirm。

图 2：失败的渠道升级握手。蓝色箭头表示从核心 IBC 到应用的回调。

请注意，升级过程是原子性的。因此，要么两个渠道端都升级到新版本，并根据升级后的逻辑处理数据包，要么升级失败，在这种情况下，两个渠道端都会返回到其先前版本（如图 2 所示）。这在一条链在握手中途取消过程时维持了一致性保证。

这也是渠道打开握手与升级握手之间的主要区别。在前者中，如果握手在任何一个渠道打开步骤（INIT、TRY 等）停滞，握手将失败，最终需要重新开始新的握手。但对于渠道升级，如果对方不同意提议的渠道端更新并在中途取消升级（或如果对方未在其端启用升级功能），该过程即被中止，并恢复到更新前的渠道版本。

访问控制

另一个需要注意的关键方面是，规范中并未提及谁应有权限启动渠道升级（ChanUpgradeInit）。这可以在有权限或无权限的方式下进行。

考虑任意两条链 A 和 B，有至少 3 种不同的情况可以调用 ChanUpgradeInit：

1. A 和 B 预先批准某些升级类型：链 A 上的技术委员会/DAO 由链治理选出，提出治理提案，声明其链 预先批准转账模块从 v1 到 v2 的所有渠道升级类型。如果该提案通过，并且链 B 也预先批准了这一类型的升级（从 v1 到 v2），则以有权限的、预先批准的方式执行渠道升级。在这种情况下，任何中继者都可以提交 ChanUpgradeInit 和 ChanUpgradeTry 消息。
2. 链 A 上的治理门控升级与链 B 上的预先批准升级类型：链 A 通过治理提案批准一次升级，并执行 ChanUpgradeInit。链 B 预先批准了该类型（在 A 上启动）的所有升级，因此任何中继者都可以在 B 上提交 ChanUpgradeTry 消息。
3. 链 A 和 B 上的治理门控升级：链 A 和链 B 都通过完整的链治理或通过组模块（groups module）的 DAO/技术委员会针对升级施加门控。链 A 调用 Init。在链 B 内，必须在 A 指定的超时窗口内调用 Try 函数。

请注意，在所有对方的升级都由治理控制的第三种情况中，源链上指定的渠道升级超时窗口必须考虑到这一信息，因为治理提案可能需要几天到几周的时间。

最后，无权限升级可以是链同意或预先批准一套升级类型，与对方默认同意。在这种情况下，任何中继者都可以向对方发送 ChanUpgradeTry。

旁注：我们目前正在与不同的链联系，并收集反馈，了解它们希望如何定制其链上的升级访问控制。以最佳方式指定访问控制非常重要，因为它直接影响最终用户体验。如果你对这方面有任何想法或问题，请随时在这里分享。

修改渠道端参数

重要的是要注意，渠道端结构内的任何内容（除标识符，即对方端口 ID 和渠道 ID）都可以更改—如版本、连接跳数和渠道排序。例如，费用中间件可以通过更新版本字符串如 这里所示 的方式添加到应用模块中。

只有当新排序是其先前排序的子集时，渠道排序才能升级。这意味着可从有序渠道升级到无序渠道，但其反向操作则不可以。

结论

渠道可升级性是链利用新应用功能的一项关键组件，以可扩展的方式。 费用中间件模块（fee middleware module） —提供 funding relayer operations 的链内解决方案—将能够使用渠道可升级性添加到现有渠道中。我们预计将来会推出更多以实用为驱动的渠道特性，尤其是针对 ICS-20（可替代代币转账）功能。

关于作者：

Adi Ravi Raj 在 Interchain GmbH 工作，是 IBC 团队的协议分析师。

特别感谢 Charly Fei , Susannah Evans, 和 Carlos Rodriguez 的反馈和审阅。

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