将中继激励转移到链上：费用中间件、费用补助和预算模块

中继者是跨区块链通信（IBC）的核心。它们通过实现将数据包从A点运输到B点的关键功能，确保协议的活跃性。鉴于它们在IBC领域的重要性，必须有效地激励中继者运营商，以适当扩展跨链。

到目前为止，运行验证者设置的团队出于无私或战略原因维护中继者基础设施。如今，大多数中继者都是在它们中继数据包所连接的链上进行验证的。团队（权益）委托、补助金和来自链或社区池的直接资金是当前中继者运营资金的重要来源。

在IBC交易量增加一个数量级或更多的阶段，单靠这些现有方法将不足以充分资助中继者。类似地，随着通道数量的增加和更多中继者进入生态系统，链下谈判也不会很好地扩展。因此，尽管当前的流程在短期内可行，但并不具可持续性。

本文旨在阐明三种替代的链上机制，这些机制可以作为长期解决方案来激励中继者。在后面的讨论中，我们提供了与这些机制相关的优缺点概述。

链上中继者激励机制

1. 一般中继者激励机制（费用中间件模块）

跨链标准（ICS）29 一般中继者激励机制（以下简称“费用中间件”或“费用模块”）是一种IBC应用层标准，它规定了一种可以由任何应用模块实现为中间件的设计。它用于在每个通道基础上激励中继者。

费用中间件指定了关于费用分配的所有信息，包括源链的信息。 给定两个链，A和B，数据包流的费用中间件功能工作如下：

1. 中继者A在目标链的费用中间件上注册它们的目标地址到源地址映射。
2. 用户在源链上提交发送数据包，同时给费用中间件模块发送一些代币和如何分配这些代币的费用信息。用户可以指明3种不同费用的支付金额：接收费用（ReceiveFee）、确认费用（AckFee）和超时费用（TimeoutFee）。费用代币均由费用模块保管。
3. 中继者A在目标链上提交MsgRecvPacket。
4. 目标费用中间件将根据步骤1注册的映射，检索给定中继者的目标地址的源地址，并将其包含在确认中。
5. 中继者B提交MsgAcknowledgePacket，提供反向的信息，包含源链上的中继者地址，以及嵌入在确认中的前向中继者的源地址。
6. 源链上的费用中间件可以将步骤2中保管的代币分配给前向和反向中继者，还可以将剩余代币退还给原始费用支付者。

为了简单起见，在超时情况下的数据包流在这里没有展示。要了解更多关于此的内容以及费用中间件如何工作的详细解释，请参阅此博客文章。

费用中间件模块v1已包含在最近的ibc-go v4.0.0版本中，并可以由新通道选择使用。随着通道可升级性的发布，中间件也可以在现有通道上实施。

2. 费用补助模块

费用补助是一个Cosmos SDK模块，允许一个账户（补助者）为另一个账户（受益者）提供Gas费的补助。

该模块可以实例化以指定最大补助金额、补助到期时间、定期补充补助的间隔，并且还可以指定为仅可用于某些类型的消息执行。

对最终用户而言，创建一个新钱包并为其资金提供Gas费用的代币可能会变得繁琐，或者成为某些平台的进入壁垒。这是费用补助模块所解决的主要问题。

OmniFlix是一个很好的费用补助模块在实际应用中使用的示例。该链利用此模块来支付新用户产生的Gas费用，以及为中继者支付的链上费用。即使它们的原生代币尚未发行，使用费用补助模块也使OmniFlix能够推出其产品。

3. 预算模块

预算模块，可在Cosmos SDK中实现，可以通过治理进行实施，允许将通货膨胀奖励和Gas费用从源地址分配到目标地址。

预算金额、源地址和目标地址可以作为治理参数进行指定。该金额可以根据区块逐步分配（或根据治理达成的任何其他时间间隔进行分配）。

这些方法的优缺点是什么？

费用中间件/模块 — 优点

1. 可扩展且可持续

费用中间件的开发旨在实现可扩展性和可持续性。

它消除了对链下实体的需求，手动跟踪中继者活动并相应资助它们（或任何其他形式的链下资助机制）。希望激励其中继者的任何应用都可以选择使用费用模块，并根据确切的中继数据包数量在链上进行资助。

决定是否由最终用户或链本身承担数据包中继费用的决定留给选择采用费用模块的链。

由最终用户支付费用的场景创建了一个根本上可持续的系统，将激励与公共利益和价值分配的协调与价值创造对齐。这也要求前端应用程序和钱包集成费用中间件，以便最终用户可以指明其费用偏好。或者，链本身可以选择直接或通过社区池和其他无私机制资助中继者，从而通过吸引更多用户到其平台上，以支持IBC交易量的启动。

需要注意的重要一点是，费用中间件的设计尽可能通用，没有偏向于谁负责中继者的资助。实施中间件的链可以选择不同的方法。因此，开发人员在自定义模块方面具有很高的灵活性。这将引导我们进入下一个要点。

2. 灵活性

虽然费用中间件为所有选择实施模块的应用创建了标准化接口，但费用处理逻辑本身可以自定义。这可以被实现为IBC中间件（ICS-30），它作为应用模块和传输层（核心IBC）之间的中介来执行自定义逻辑。

通过使用IBC中间件（ICS-30）设计自定义费用处理/分配逻辑，费用模块（ICS-29）能够插入到IBC数据包流设计中，而无需将其代码放入核心IBC或应用模块中。

3. 颗粒度

使用费用中间件的另一个好处是它提供了颗粒度。使用该模块可以在每个通道基础上激励。例如，在任何两个区域之间进行Token转移的通道可以得到激励，而无需激励ICA通道。或者，它可以用于鼓励在中继数据包较少的通道上进行中继。

4. 无权限

与费用补助和预算模块不同，使用费用中间件资助中继者运营商是完全无权限的。只要某个通道得到了激励，任何将数据包运送到或从该通道的中继者都会按每个数据包获得资助。无需对中继者进行白名单处理。

5. 对中继者的透明度

费用中间件暴露以下查询：GetReceiveFee、GetAckFee和GetTimeoutFee。中继者可以调用这些函数以了解其在中继RecvPacket、AcknowledgePacket和TimeoutPacket时预期的费用。

这可能会产生有趣的动态，中继者通过自定义自己的软件实现，选择根据预期费用优先中继某些数据包。结果可能形成一个自然的IBC中继费用市场。

6. 覆盖完整的数据包流

通过使用费用中间件，尽管费用的分配是在源链上进行的，但通道的两边都可以得到激励。这与只能激励发送到源链的费用补助或预算模块形成鲜明对比。

费用中间件/模块 — 缺点

1. 通道可升级性

目前，费用中间件只能在新的IBC通道上实施。因此，通过新的激励通道发送的代币将与通过现有非激励通道发送的相同代币不可互换。这导致流动性碎片化，并损失在已经存在的通道上积累的网络效应。然而，随着通道可升级性的发布，现有通道也可以被激励（计划在2022年第四季度实施）。

2. 需要在两个链上进行更新

为了使通道得到激励，通道的两端都需要进行升级（然而，只需要一侧提供激励，因为所有费用处理逻辑都在源链上进行）。

3. 收入仅归给最快的中继者

对于使用费用中间件激励的通道，只有那些成功传递数据包的中继者才能获得资金。那些没有成功传递数据包的将不会收到任何款项，尽管它们在线。

这造成了一个情境，即最快的中继者（通常是设备最好且地理位置占优的）获得大多数收入。这是提议链下资助方法作为更好替代方案的主要原因。然而，这些方法也会受到参与的社会动态造成的相同中心化问题的影响。此外，随着区域数量的增加和更多通道的开启，链下谈判的扩展也变得繁琐。

附注：解决收入归于最快中继者问题的一个潜在解决方案是实施一种投票机制，通过该机制小部分中继者在特定时间间隔内被选中以在某一通道上传递数据包。通过在不同的子集之间持续轮换，每个中继者都有机会发送数据包。

费用补助模块 — 优点

1. 灵活性

使用费用补助模块为补助者提供了很高的灵活性和自定义性，具体体现在以下几个方面：

• 补助可设定为特定时间段的最高额度
• 补助可按指定时间间隔进行补充
• 补助可设定为无限额且没有到期日
• 补助可实例化以适用于特定类型的消息

或许使用费用补助模块的最重要优势在于它显著简化了用户体验（UX）。因此，从灵活性的角度来看，它不仅可以用于激励中继者，还可以用来支付最终用户产生的Gas费用。正如我们看到的OmniFlix的例子，这在吸引新用户到你的平台方面有很大帮助。

2. 实施简便

与费用中间件相比，费用补助模块只需要在通道的一侧实施即可资助中继者（但是，在这种情况下，只有对被中继到模块实施的区块链上的数据包进行激励是可能的）。

3. 控制

费用补助模块的一个关键特性是，用于补助的资金始终保持在补助者的控制之下。这为补助者提供了强有力的安全保障。

4. 用户体验（UX）

使用费用补助模块，IBC用户无需担心为中继者支付费用。

尽量减少与IBC级别接口的用户交互有助于抽象出IBC的概念。这提高了组合性和用户体验。

费用补助模块 — 缺点

1. 手动流程

尽管费用补助模块确实提供了创建永久有效的无限补助额度的选项，但在某些情况下，这种设计可能不适用。

相反，在某些情况下，补助者可能希望设置授予补助的上限，并设定补助到期日。在这种情况下，每次补助被耗尽后，可能需要手动处理补助的补充。

2. 仅补偿链上费用

中继者运营的相关费用包括中继数据包的链上费用，以及维护节点基础设施的运营费用。使用费用补助模块只能补偿链上费用。这个模块不能提供额外的激励。

3. 需要权限

由于使用费用补助模块的链指定了哪些中继者获得运营资助，这创建了一个权限系统，只有白名单中的中继者才能收到支付。

预算模块 — 优点

1. 灵活性

预算模块提供了相当高的灵活性。任何人都可以创建治理提案，将资金从源地址分配给目标地址。分配资金的时间间隔可以作为治理的一部分进行指定。

一旦提案得到投票通过，预算计划就会自动按照指定的内容开始执行。

2. 不直接影响最终用户的经济

由于最终用户不为数据包中继支付交易费用，因此该方法对他们没有直接影响。与费用补助模块类似，这有助于抽象出IBC的概念。

尽管如此，最终用户将以间接方式遭受费用，因为他们在质押上的收益将减少。

预算模块 — 缺点

1. 扩展性和可持续性有限

区块奖励和交易手续费是链的收入来源。将这些资金用于激励中继者有效上是一种对验证者（以及用户）的间接税收。此外，大多数链上的通胀调度随着时间的推移而减小，在某些链上到达一定节点之后没有通胀。

因此，这种方法在长期内是否可持续值得怀疑。尚未量化交易费用是否足以资助中继者运营，尤其是当IBC使用量增加一个或两个数量级时。

2. 修改预算计划可能是一个缓慢的过程

由于预算计划通过治理执行，因此实施新的参数或修改现有参数可能是一个相对缓慢的过程。

权衡总结

结论

为中继者提供全面的激励解决方案对IBC的长期增长至关重要。费用中间件、费用补助和预算模块提供了三种不同的实现方式，每种模块都有其自身的权衡。不同的链可以选择实施其中一种或其组合。

目标是为中继者创造一种可持续的收入模式，以回报他们所提供的重要服务。通链激励机制能带来获利（或至少是盈亏平衡）的中继者运营，这对整个生态系统都是有利的，并有助于推动跨链愿景。

如果你是链开发者，希望建立自己的IBC轻客户端，并对上述内容有任何问题、意见或反馈，请随时与我们联系 在这里 。

关于作者:

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

感谢Charly Fei、 Susannah Evans, Thomas Dekeyser和Carlos Rodriguez的反馈和审阅。

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