将中继器激励转移至链上:费用中间件、费用代付与预算模块

将中继器激励转移至链上:费用中间件、费用代付与预算模块

简介
中继器是 IBC 跨链通信协议的心跳。他们执行将数据包从 A 点传送到 B 点的关键功能,以此来确保协议的活力。鉴于中继器在 IBC 领域中的重要性,有必要有效激励中继运营商以充分扩展跨链生态。
目前为止,运行验证人节点的团队出于利他性或战略目标原因会参与维护中继器基础设施,大多数中继器也在他们所中继数据包的链上进行验证。团队(权益)委托、激励和来自链上或社区基金池的直接资助是目前中继器运营资金来源的重要部分。
在 IBC 体量以一个或多个数量级增长的阶段,仅通过现有方法不足以给中继器提供足够的支持。同样,随着 channel(通道)数量的增加和更多的中继器进入生态,链下协商也无法得到很好的扩展。因此,虽然目前的中继流程在短期内可行,但却是不可持续的。
本文旨在介绍三种可供选择的链上机制,它们可以作为激励中继器的长期解决方案。在下文的讨论中,我们概述了这些机制各自的优缺点。
链上中继器激励方式
1. 通用中继器激励机制(费用中间件模块)
跨链标准(ICS)29 「通用中继器激励机制」(下文简称为「费用中间件」或「费用模块」)是 IBC 应用层标准,它规定了可以由任何应用程序模块作为中间件实现的设计,可用于按每个 channel 来激励中继器。
跨链标准(ICS)29:
https://github.com/cosmos/ibc/tree/master/spec/app/ics-029-fee-payment
将中继器激励转移至链上:费用中间件、费用代付与预算模块
费用中间件指定有关源链上费用分配的所有信息。给定两条链 A 和 B,数据包流的费用中间件功能工作流程如下:
  1. 中继器 A 在目标链的费用中间件上注册其目标链地址到源链地址的映射。
  2. 用户在源链上提交一个发送数据包,同时向费用中间件模块发送一条消息,其中包含一些 Token 和有关如何分发这些 Token 的费用信息。用户可以为 3 类不同费用指定支付金额,分别是 ReceiveFee(接收费用)、AckFee(确认费用)和 TimeoutFee(超时费用)。费用 Token 全部由费用模块托管。
  3. 中继器 A 在目标链上提交 MsgRecvPacket。
  4. 目标链上的费用中间件将获取中继器目标地址对应的源地址(根据步骤 1 中注册的映射)并将其添加到确认信息中。
  5. 中继器 B 提交 MsgAcknowledgePacket,提供源链上的反向中继器地址,以及嵌入在确认信息中的前向中继器的源链地址。
  6. 源链上的费用中间件可以将步骤 2 中托管的 Token 分发给前向和反向中继器,并将剩余的 Token 退还给原始费用支付者。
为了简单起见,此处不介绍超时情况下的数据包流。要了解更多相关信息,以及有关费用中间件工作原理的深入说明,请参阅《IBC 中继即服务:解读协议内激励机制》
费用中间件模块 v1 包含在近期的 ibc-go v4.0.0 版本中,可以在新 channel 上选择将其加入。随着 channel 可升级性的发布,中间件也可以在现有 channel 上实现。
ibc-go v4.0.0 版本:
https://github.com/cosmos/ibc-go/releases/tag/v4.0.0
channel 可升级性:
https://github.com/cosmos/ibc/blob/main/spec/core/ics-004-channel-and-packet-semantics/UPGRADES.md
2. 费用代付模块
Fee grant 费用代付模块是一个 Cosmos SDK 模块,它允许一个账户(代付者)向另一个账户(款项接收者)提供 gas 费用补贴。
Fee grant 模块:
https://blog.cosmos.network/secret-powers-what-are-the-authz-and-fee-grant-modules-c57d0e808794
Cosmos SDK 模块:
https://docs.cosmos.network/v0.46/modules/
该模块可以被实例化,以指定最大补贴额度、补贴到期时间、定期补充补贴的间隔时间,甚至可以指定补贴资金只能用于特定类型的消息执行。
对于终端用户来说,创建一个新钱包并充值 Token 作为 gas 费用可能很繁琐,甚至会成为进入某些平台的障碍。这正是费用代付模块解决的首要问题。
OmniFlix 是灵活使用费用代付模块的一个很好的例子。它利用该模块支付新用户产生的 gas 费用,以及中继器支付的链上费用。尽管 OmniFlix 尚未有原生 Token,但使用费用代付模块可以允许其推出自己的产品。
相关推文:
https://twitter.com/OmniFlixNetwork/status/1501462693915422721
3. 预算模块
Cosmos SDK 中提供的预算模块可以通过治理方式来实现,它允许将通胀奖励和 gas 费用从源地址分配到目标链地址。
预算模块:
https://github.com/tendermint/budget/blob/main/x/budget/spec/01_concepts.md
这些激励方式的优缺点是什么?
费用中间件/模块——优点
1. 可扩展和可持续
费用中间件的开发考虑了可扩展性和可持续性的特定目标。
费用中间件消除了由链下实体手动跟踪中继活动,并相应地为其提供补贴(或任何其他形式的链下补贴机制)的需要。任何希望激励其中继器的应用程序都可以选择使用费用模块,并且根据所中继的数据包的确切数量在链上为它们提供支持。
选择采用费用模块的链可以决定终端用户或链本身是否必须承担数据包中继的成本。
终端用户支付费用的场景创建了一个基本可持续的系统,其中激励措施用于协调公共利益,价值分配与价值创造保持一致。这还要求前端应用程序和钱包集成费用中间件,以便终端用户表明他们的费用偏好。
或者,区块链本身可以选择直接或通过社区基金池和其他利他机制为中继器提供支持,从而吸引更多用户进入其平台,进一步提升 IBC 事务量。
需要注意的重要一点是,费用中间件的设计强调通用性,而不指定任何一方承担支持中继器的成本。关于这一点,实现中间件的链可能会有采取不同的方法。因此,开发人员在定制模块方面具有高度灵活性。这就引出了费用中间件的下一个优点。
2. 灵活性
虽然费用中间件为选择实现该模块的所有应用程序创建了一个标准化接口,但费用处理逻辑本身是可定制的。具体实现方式可以是 IBC 中间件 (ICS-30),它充当应用程序模块和传输层(核心 IBC)之间的中介,以执行自定义逻辑。
IBC 中间件(ICS-30):
https://github.com/cosmos/ibc/tree/master/spec/app/ics-030-middleware
通过使用 IBC 中间件(ICS-30)设计自定义费用处理/分配逻辑,费用模块(ICS-29)可以插入到 IBC 数据包流的设计中,而无需将其代码放置在核心 IBC 或应用模块中。
3. 颗粒度
使用费用中间件的另一个好处是颗粒度。使用此模块能够以 channel 为单位对中继器进行激励。例如,可以选择只激励任意两个 IBC 链之间的转移 channel,而不激励 ICA(跨链账户)channel。或者,该模块可用于鼓励中继器在中继数据包最少的 channel 上开展中继。
4. 无需许可
与费用代付和预算模块不同,通过费用中间件激励中继器运营商是无需许可的。一旦 channel 受到激励,任何在该 channel 上中继数据包的中继器都会以数据包为单位得到激励,而无需将一组中继器加入白名单。
5. 对中继器透明
费用中间件开放以下查询:GetReceiveFee、GetAckFee 和 GetTimeoutFee。中继器可以调用这些函数,以分别获取他们在中继 RecvPacket、AcknowledgePacket 和 TimeoutPacket 数据包时的预期费用。
这种特性可能会产生一个有趣的动态——通过自定义其软件实现,中继器会根据预期费用选择优先中继某些数据包。因此可能会形成 IBC 中继的自然费用市场。
6. 覆盖所有数据包流
即使费用支付是在源链上执行的,使用费用中间件可以激励 channel 两端链上的中继器。这与费用代付或预算模块形成了对比,后两者只能激励发送到源链的数据包。
费用中间件/模块——缺点
1. 可升级性
目前,费用中间件只能在新的 IBC channel 上实现。因此,通过新的激励 channel 发送的 Token 与通过现有非激励 channel 发送的相同 Token 是相互不可替代的。这导致了流动性分散以及现有 channel 上积累的网络效应丧失。但是,随着 channel 可升级性推出(定于 2022 年第四季度),现有 channel 也可以被纳入激励范围。
Channel 可升级性:
https://github.com/cosmos/ibc/blob/master/spec/core/ics-004-channel-and-packet-semantics/UPGRADES.md
2. 需要两条链同时进行升级
为了激励某一个 channel,其两端的链都需要升级。但是,由于所有费用处理逻辑都在源链上执行,因此仅需由某一端的链提供激励。
3. 最快的中继器获得大部分收入
对于使用费用中间件激励的 channel,只有成功传递数据包的中继器才会获得资金支持。那些未能成功传递数据包的中继器,尽管一直在线,也无法获得任何支持。
这会导致中继数据包最快的中继器获得大部分收入,这些中继器往往拥有最好的设备和地理优势。正因如此,有人提出以链下方法作为更好的替代性激励方案。然而,考虑到正在发挥作用的动态机制,这些链下方案也遭遇了相同的中心化问题。此外,随着区块链数量的增加和更多 channel 的开放,扩展链下协商变得很麻烦。
旁注:对于这个问题的一个潜在解决方案是实施一种投票机制,以指定的时间间隔选择一小部分中继器在特定 channel 上传递数据包。通过持续交替不同的子集,每个中继器都有机会发送数据包。
费用代付模块——优点
1. 灵活性
费用代付模块通过以下方式为代付者提供了高度的灵活性和可定制性:
  • 可将补贴设置为特定时间段内的最高金额
  • 可根据指定的时间间隔补充补贴
  • 补贴额度可设置为无限制,且无到期日
  • 可对补贴进行实例化,以适用于特定消息类型
使用费用代付模块最重要的优势可能是大大简化了用户交互操作。因此,在灵活性方面,它不仅可以用来激励中继器,还可以用来支付终端用户产生的 gas 费用。正如我们在 OmniFlix 示例中看到的那样,这对平台吸引新用户大有帮助。
2. 易于实现
与费用中间件相反,费用代付模块只需在 channel 一端的链实现,以便为中继器提供支持。但在这种情况下,只能激励被中继到该链的数据包。
3. 资金可控
费用代付模块的一个关键特点是,资金始终处于代付者的控制下。这为代付者提供了强有力的安全保证。
4. 用户体验
通过使用费用代付模块,IBC 用户无需担心为中继器支付费用。
与 IBC 级界面进行尽可能少的用户交互有助于抽象出 IBC 的概念,从而提高可组合性和用户体验。
费用代付模块——缺点
1. 手动流程
尽管费用代付模块确实能够提供创建永不过期的无限额补贴的选项,但某些情况下可能不适合使用这一设计。
与此相反,代付者有时可能希望设置补贴金额上限以及到期日。在这种情况下,每次补贴额度耗尽时都需要手动补充余额。
2. 只报销链上成本
与中继器运行相关的成本包括中继数据包的链上成本,以及维护节点基础设施的运营成本。使用费用代付模块仅可报销链上成本,无法提供额外奖励。
3. 需要许可
由于使用费用代付模块的链指定了为哪些中继器提供运营支持,因此它创建了一个许可系统,只有白名单中的中继器才能接收补贴款项。
预算模块——优点
1. 灵活性
预算模块提供了相当程度的灵活性。任何人都可以创建一个治理提案,将资金从源链地址分配到目标链地址。资金分配的时间间隔可以通过治理确定。一旦提案投票通过,预算计划就会自动执行。
2. 对终端用户没有直接经济影响
鉴于终端用户不为数据包中继服务支付成本,因此这种方法不会对他们产生直接影响。与费用代付模块类似,这有助于抽象出 IBC 的概念。
然而,终端用户将以间接的形式承担成本,因为他们的委托收益会有所降低。
预算模块——缺点
1. 可扩展性和可持续性有限
区块奖励和事务费用是链的收入来源。使用这些资金来激励中继器实际上是一种对验证人(以及用户)间接征税的形式。此外,大多数链上的通胀计划水平会随着时间的推移逐渐减少,一些链的通胀率在某时间节点后会完全归零。
因此,从长远来看,这种方法的可持续性存疑。仅通过事务费用是否足以为中继器运营提供资金?这一问题仍有待量化,特别是当 IBC 事务量增加一至两个数量级时。
2. 对预算计划的更改可能是一个缓慢的过程
鉴于预算计划是通过治理实施的,实施新参数或更改现有参数可能是一个相对缓慢的过程。
权衡总结
将中继器激励转移至链上:费用中间件、费用代付与预算模块
 结语
采用综合性解决方案激励中继器对于 IBC 的长期增长非常重要。为实现这一目的, 费用中间件、费用代付和预算模块提供了三种不同的方式,每个模块都有自己的权衡。不同的链可以选择实现其中一种或多种模块。
激励方案的目标是为中继器创建一个可持续的收入模式,以换取他们所提供的重要服务。让中继器运营实现盈利(或至少是收支平衡)的链上激励计划有利于整个生态,并有助于进一步实现跨链愿景。

本文由用户:麦妖榜 发布,不代表网站的立场,转转请注明出处:http://www.maiyaotop.com/tech/125462.html

发表评论

登录后才能评论