如何使跨链代币重新具备可替代性:第二部分 - ERC-7281

本文探讨了ERC-7281标准如何解决跨链代币的不可替代性问题,提出了一种更有效的代币桥接机制,以提升安全性、流动性和用户体验。ERC-7281的设计允许代币发行者在不割舍控制权的情况下,实现跨链代币的创建和管理,同时通过增强的限额功能改善对区块链桥的风险管理。

如果你还没有阅读《如何让跨链代币重新具备可替代性》(How To Make Cross-Chain Tokens Fungible Again) 系列的第一部分,你可能想先 查看一下它——它详细讲解了为何桥接代币失去可替代性及其带来的挑战。在第二部分中,我们将探索 ERC-7281,这一新标准简化了跨链代币转移,增强了可靠性,并赋予发行者更大的控制权。

需要更好方法的原因

到目前为止,我们已经探讨了各种解决方案,以使桥接代币可替代,并解决与流动性碎片化和非标准代表的原生代币在非本地区块链上流通时导致的用户体验不佳等问题:

  • 通过标准Rollup/侧链桥在远程链上铸造代币的标准表示
  • 通过第三方桥接服务在远程链上铸造代币的标准表示
  • 通过由代币发行人操作的标准桥接服务在远程链上铸造代币的标准表示

这些方法各有权衡,因此 ERC-7281 提出的创建可替代桥接代币的提案尝试汲取每种方法的优点,以便为希望在不牺牲安全性、主权或用户体验的情况下跨链部署代币的协议创造一种更全面、高效和可及的解决方案。

ERC-7281:主权桥接代币 是一个提案,使得可以创建与许多不同桥接铸造的表示兼容且可替代的代币的标准表示。 ERC-7281 通过扩展 ERC-20 接口来实现以下功能:

  • 允许铸造和销毁标准 ERC-20 代币的功能;
  • 代币所有者能够

1) 指定桥接操作员在跨链时铸造和销毁代币;

2) 为每个批准的桥接操作员限制铸造和销毁代币的数量——例如,针对中心化桥设置较小的限制,而对更安全的协议设置较高的限制。

鉴于 ERC-7281 和 ERC-20 代币之间的细微差别,EIP 的作者将前者称为“xERC-20”。对于需要了解 ERC-20 代币概述的读者,OpenZeppelin 有一篇很好的 指南

本质上,每个 ERC-20 代币合约都实现了定义全局代币供应并存储哪些地址拥有代币及其拥有量的信息的 ERC-20 接口。ERC-20 还包括用于管理用户代币访问权(通过批准)和检索有关某一代币的信息(如总流通量和特定地址的余额)的有用功能。

ERC-7281 为 ERC-20 规范添加的一个额外特性是可选的 Lockbox,它充当包装合约(类似于 WETH (Wrapped Ether) 合约)。Lockbox 合约通过熟悉的铸造和销毁机制将 ERC-20 代币包装成 xERC-20 代币,使其与缺乏销毁/铸造接口且不可升级的现有 ERC-20 代币合约兼容。

利用上一篇文章中介绍的框架,我们可以将 ERC-7281 分类为一种“信任代币发行人 + 信任(授权的)桥接提供者”的跨链代币铸造方法。跨多个链部署的 ERC-7281 代币由其中的发行人控制(与通常需要放弃主权的替代跨链代币设计不同)。虽然发行人仍面临经过批准的桥接发生安全事件的风险,但他们通过手动选择和限制授权的桥接提供者来管理该风险。

我们将在本报告中探讨的最大区别是,代币发行人可以通过对特定桥接操作员施加动态限制,来调整对桥接攻击和漏洞的暴露程度。 ERC-7281 还允许代币发行人为多个桥接提供者白名单,使他们能够跨链铸造相同的标准代币,从而减少对单一提供者进行跨链桥接操作的依赖。

这两个特性,使得 ERC-7281 相对于传统的促进协议代币跨链桥接的方法有了显著改善,并对用户、互操作性基础设施提供者(特别是汇聚服务)和应用程序开发者产生了积极的二次效应。在接下来的部分中讨论规范后,我们将回顾实施 ERC-7281 的优缺点。

ERC-7281 概述:主权桥接代币

为用户铸造和销毁代币

在规范中,一个项目部署一个新兼容 ERC20 的代币合约,实施 IXERC20 接口。桥接操作员在接收链上为用户铸造代币,前提是先在源链上销毁押金。铸造过程检查代币数量是否超过了桥的限制,成功后更新代币的总供应量和桥的铸造限制。

对于已经存在的 ERC-20 代币,应用“lockbox”逻辑:桥提供商将用户存入的 ERC-20 代币包装为 xERC-20 代币,通过将其转移到 Lockbox 合约中。Lockbox 然后批准桥接铸造等量 xERC-20 代币。

在目标链上由桥接铸造的 xERC-20 代币会使用 burn() 函数在源链上销毁。这个过程确保代币数量不超过桥的销毁限制,增加其数量并减少 xERC-20 代币的总供应量。桥接的运输层将销毁消息转发到目标链。目标侧的桥接合约验证该消息并在该链上向用户地址铸造等量的 xERC-20 代币。此铸造过程减少了代币的总供应量和桥接的铸造限制。

为了将代币桥接回主链,桥接操作员在远程链上销毁 xERC-20 代币,提供用户地址和代币数量。运输层将销毁凭证传递回主链。如果销毁消息被验证,桥接操作员将在主链上为用户铸造并销毁新的 xERC-20 代币。在代币合约验证销毁凭证后,桥接操作员将存入的 ERC-20 代币释放给用户。在主链上销毁 xERC-20 代币减少了代币的总供应量和桥的销毁限制。

一个重要的点是:xERC-20 合约在技术上可以在不通过桥接验证证明的情况下铸造代币。我们描述了标准(即:预期)的操作方法,但未实现任何消息验证或实现新型跨链消息验证机制的桥接可以被列入白名单,以铸造和销毁 xERC-20 代币。这完全取决于代币发行人可以接受什么。

代币铸造和销毁的速率限制

函数 setBridgeLimits 是一个受保护的函数,只能由代币合约所有者调用。该函数允许设置桥接合约的地址,并为桥接可以铸造(mintingLimit)和销毁(burningLimit)用户的代币指定最大数量。所有者可以更新这些限制,从而根据需要调整桥的能力。例如,如果发现某个桥提供商的基础设施存在安全问题,可以减少 mintingLimit,以降低风险。相反,安全性改进可能会导致铸造限制的提高。

xERC-20 规范还包括检查被批准处理代币的桥接的销毁和铸造限制的功能。“mintingMaxLimitOf” 返回一个桥接可以铸造的最大代币数量,相应地,“burningMaxLimit” 返回一个桥接在特定时间内可以销毁的最大代币数量。此外,这些函数显示桥接在达到预设限制之前可以销毁和铸造的剩余代币。

这些查看函数对需要了解不同桥接提供商可用限制的桥接汇聚器非常重要,以便在路由交易之前确保桥接没有达到铸造和销毁限制,因此允许进行一定数量的兑换。

速率限制参数

xERC-20 代币接口规范包含一个“Bridge”结构,其中包含“burningParams”和“mintingParams”(xERC-20 代币在规定时间内测速率限制功能的参数,控制桥可以在指定时间内销毁和铸造的代币数量)。“maxLimit” 定义了代币铸造和销毁的最大限制,并以预定速率“ratePerSecond” 每秒增加。

这里提出一个可能的混淆点:“maxLimit”(设置于销毁和铸造限制)听起来像是对特定时间的铸造和销毁操作的限制——而不是在预设时间窗口内根据预定义阈值限制铸造和销毁的速率限制。“currentLimit” 定义了一个桥可以铸造或销毁的数量,以预定速率增加。相对而言,“maxLimit” 定义了一个桥每天能够铸造或销毁的数量。

铸造和销毁参数主要与代币所有者(以及桥接操作员在较小程度上)相关。然而,最大和当前限制参数对用户和桥接操作员非常重要。例如,当前限制可能会影响用户在跨链协议中能够自信地桥接多少代币,而不会在接收 xERC-20代币时遇到延迟。

xERC-20 Lockbox

原始 ERC-20 代币没有指定增加和减少代币供应的功能(当时“代币经济学”意味着生成固定数量的代币,并告知用户代币的价值,因其将在几年发掘将会稀缺)。因此,并非所有 ERC-20 代币都有铸造和销毁功能。由于 ERC-7281 使用了今天大多数(如果不是全部)桥接所青睐的铸造和销毁机制,传统或不可升级的 ERC-20 代币无法直接与 ERC-7281 搭配使用。

Lockbox 合约提供了一种解决方案,允许与现有代币的向后兼容。在原始规范中(即项目部署一个新的代币合约,实施 IXERC20 接口),桥接操作员只需调用 mint() 即可为目的地链的用户铸造代币(在锁定押金于源链后)。

Lockbox 合约大量借鉴了 WETH 包装合约的设计。它实现了 deposit() 函数以在 Lockbox 中存入相应的 ERC-20 代币,以及一个 withdraw() 函数用于桥接操作员在远程域销毁包装代币后解锁 ERC-20 代币。

在规范中突出的前两种错误类型(“IXERC-20Lockbox_NotNative” 和 “IXERC-20Lockbox_Native”)发生在用户尝试在错误的 Lockbox 合约中存入代币时。Lockbox 可以是本地的或非本地的,具体取决于其支持的代币类型。

本地 Lockbox 托管原生代币——即,用于向验证者支付Gas费用的代币。具有本地 Lockbox 的代币之一是 ETH:将 ETH 包装成 xERC-20 代币需要调用 Lockbox 的 depositNative() 函数并存入 ETH 以获取与 ERC7281 兼容的 ETH 表示。

常规(非本地)Lockbox 托管诸如 USDC, DAI, WETH, USDT 等 ERC-20 代币。例如,要将 USDC 铸造为 xERC-20 代币,用户需要在锁定 USDC 后,调用 Lockbox 合约上的 deposit()。

通过 ETH 调用 deposit() 将使这些资金永远被锁定,因为常规的 Lockbox 合约只能包装和解包 ERC-20 代币。使用 ERC-20 代币调用 depositNative() 将产生类似的结果,因为本地 Lockbox 合约是用于处理原生代币的,而不是 ERC-20 代币。

通过将标准 ERC-20 代币包装成带有铸造和销毁支持的 xERC-20 代币,Lockbox 为这一标准提供了一层重要的兼容性。然而,在某些情况下,例如将其他桥接解决方案集成到 xERC-20 中,仅依靠 Lockbox 和返回包装代币并不可行。因此,项目可能会实现适配器合约。

适配器合约

在桥接协议未能识别与 xERC-20 代币相关的操作(铸造/销毁、相应的日志记录等)的情况下,应用程序可以构建适配器合约。这些合约充当自动包装和解包器——有效地将标准 ERC-20 批准 + 调用行为转换为 xERC-20 所需的更微妙的铸造/销毁计划。

这是必要的,因为许多桥接协议(例如 Chainlink 的 CCIP)仍然优化为传统的 ERC-20 行为。适配器合约可以通过嵌入这种逻辑,弥补这种兼容性差距:它将代币存入 Lockbox,以便在源链上生成 xERC-20 表示,然后在目标链收到消息时触发提取机制,以恢复为标准资产。

这个流程确保用户最终获得一个一致的、标准的代币——不会受到基于 xERC-20 的包装机制的影响。这样,适配器可以让协议与不兼容 xERC-20 的桥接无缝集成,并增加他们所支持的互操作解决方案的范围。

为什么是 ERC-7281?主权桥接代币标准的案例

高层次上,ERC-7281 有四个广泛目标:

  1. 可替代性:用户将代币从本地链桥接到另一条(L1/L2)链时,应该始终在目标链上收到桥接代币的标准表示。在非本地链上流传的多个非可替代版本的同一代币会带来问题,如前所述(例如,流动性碎片化和代币组合性差)。

创建 ERC-20 规范的初始愿景是确保可替代性和无缝互操作应用程序通过以太坊及其基础设施之间的代币。然而,在采用以Rollup为中心的扩展路线图之后,原本缺乏原子组合性的这一问题凸显出来,许多不同的域的创建削弱了那些可替代性的特性。xERC-20 允许将各种跨Rollup桥的流动性汇聚到统一的多Rollup代币中,从而恢复以太坊的初衷。

  1. 安全性:为了降低对手风险,代币发行人应能根据对安全基础设施的评估选择不同的桥接提供商。此外,代币发行人应对影响合作桥接提供商的安全事件的后果有合理的保护——对一或两个桥接服务的孤立攻击不应拖累整个总锁仓(TVL)。

  2. 无流动性的跨链代币引导:协议 DAO 不应该被迫在为桥接代币引导流动性时去花费大量(经济)资源作为多链扩展计划的一部分。基于流动性的桥接不仅体验糟糕,而且伴随着流动性提供激励的支出,在区块链数量未来增加的情况下,项目团队可能将变得不可行。

  3. 代币发行人的主权:代币发行人应保持对在非本地链上铸造的协议代币的标准表示的控制。解决非可替代桥接代币的问题不应需要将项目的桥接代币控制权交给第三方桥接尤其是如控制总供应量和配置铸造和销毁机制等管理方面。

我们可以进一步扩展这些目标,以看到 ERC-7281 为协议和社区提供的好处。

分析 ERC-7281 的好处

改善用户体验并消除流动性碎片化

ERC-7281 解决了引言中描述的路径依赖问题的多种版本。

路径依赖可以是链特定的(例如,从以太坊→Arbitrum→Optimism 桥接的 ETH 与以太坊→Optimism→Arbitrum 桥接的 ETH 不同),也可以是桥接特定的(例如,通过 Celer 从以太坊桥接到 Optimism 的 ETH 与通过 Connext 从以太坊桥接到 Optimism 的 ETH 不同)。

路径依赖是一个有价值的安全特性,但它也可能对桥接用户体验和跨链组合性造成不利影响。例如,用户无法通过编程向在 Optimism 和 Arbitrum 上运行的跨链 DEX 提供流动性,因为应用程序必须接受 opETH 或 arbETH。

ERC-7281 通过引入 xERC-20 代币来消除这一问题,无论用户跨链多少次或使用何种桥接提供商,代币都保持可替代性。假设用户希望将包裹的 USDT 从 Arbitrum 转移至 Optimism,而不首先提取到以太坊;则桥接提供商可以在 Arbitrum 上销毁 xERC-20 代币,并在 Optimism 上铸造 xERC-20 代币——在 Optimism 上铸造的代币价值仍与存入 Lockbox 的代币相固定,并重新映射以维护其 1:1 支持。

重要的是,ERC-7281 提供了许多 Circle 的 CCTP (Cross-Chain Transfer Protocol) 的好处,这样可即使协议不具有限的桥接代币代管权限,比如流动性主要围绕项目代币的标准表示集中,从而提高代币在 DeFi 应用中的效用,并减少为相同资产的不同版本创建不同市场的开销。

强化代币发行人的主权

xERC-20 被称为“主权桥接代币”,因为代币发行人不被局限于使用特定选项来铸造代币的标准表示,并且保留控制跨部署的桥接代币的设计和管理。 ERC-7281 是“通过第三方桥铸造标准代币”和“通过代币发行人控制的桥铸造标准代币”的混合,结合了主权、用户体验和去中心化于一体。

跨链部署使用 ERC-7281 代币的项目可以通过多个桥铸造原生代币的标准表示,而不必面临多个非可替代版本的相同代币带来的用户体验中断。这样的项目也能够对 token 进行类似的跨链部署控制,就像代币发行人通过自建基础设施来管理标准代币在多个域之间的转移一样,因为 xERC-20 代币合约和 Lockbox——桥接用来为用户锁定、铸造和销毁代币的——都是由项目部署和控制的。

这个低调的功能在高知名度项目的原生代币发行的情况上尤其有用,因为来自其他生态的用户希望以不同的理由接触到这些代币,而不必持有它们在本地链上。

然而,由于项目没有能力或愿望在每条链上运行自建的桥接基础设施以确保桥接代币的 1:1 兼容性——也不想将其代币的控制权交给一个不一定与协议及其社区一致的第三方。这种情况下,与以桥接代币投票且投票在本地链进行管理的跨链治理相结合的考量当中,不 align 的桥接提供商控制的桥接代币便成了协议治理的瓶颈。

Beefy,一个收益农业协议,也出于这个原因采用了 xERC-20。正如该项目的桥接文档所述,ERC-7281 为该项目提供了更多桥接代币的选项——这在一个主要桥接合作方遭遇黑客攻击后变得非常必要(这是一个对加密原生者来说正迅速成为耳熟能详的主题)——并提供了更细致的桥接机制设计控制。就 Beefy 而言,ERC-7281 的白名单功能使得该协议可以选择不同的桥接合作方,并在桥接 mooBIFI 代币时为用户提供不同选项,使之在速度、去中心化、成本和安全性之间进行优化。

激励再对齐,提升开放竞争和安全性

基于流动性的桥接通常更有利于那些有财力支出的项目,因为代币发行人想尽可能少地花费流动性提供者激励并提供优越的桥接用户体验,因此流动性成为使用通用 L1/L2 桥接的协议中的关键因素。这也扩展到桥接聚合器选择桥接提供商,从某种程度上来说,阻碍新的桥接服务(即使它们的基础设施安全性高)与更成熟的桥接协议竞争。

ERC-7281 通过消除流动性桥接的需求修复了这一问题。无需铸造和交换非标准代币与标准代币之间的桥接,任意规模的桥接都可以被批准在远端域铸造项目的代币。由于代币发行人希望将桥接失效的风险降到最低,因此更多的协议很可能开始更关注跨链桥的安全设计,而不是首先关注流动性。

这激励了开放竞争,因为这变成了“让最安全的桥赢”,而不是“让流动性最高的桥赢”,这种开放竞争还可以表现在桥接在超过流动性/安全性之外提供更多特性(如:费用、APIs/SDKs、应用程序集成等)。这些特性可谓相对简单,因为它们主要依靠开发团队的专业知识;相比之下,流动性和桥接交易量更复杂,要求结合业务拓展、资金、行业联系、市场营销等等。

为代币发行人提供更好的风险管理

ERC-7281 引入了对代币的铸造和销毁的可配置速率限制,大大改善了与第三方桥接一起正常工作时协议的风险特征。如果一位合作桥接提供商被黑或者妥协,攻击者能造成的最大损失等于分配给受影响桥接的限制。如果代币发行人仔细选择限速参数,桥接出现孤立攻击对协议的偿付能力影响可降至最低。

按桥配置的速率限制还可以改善协议 DAO 的风险评估过程。目前,由于从第三方桥接受到攻击带来的潜在巨大影响,桥接风险评估可能需要数月才能完成;协议希望确保做出可信的决定,致使安全审查针对所选桥的进行全面审查,以给社区更强的安全保障。除了不必要的浪费时间和精力,持续 Marathon 的桥接安全分析仍不保证选定的桥免受零日攻击。

采用 ERC-7281 使得风险评估更具动态性。项目仍然需要对桥接提供商进行尽职调查,以选择合适的速率限制属性;然而,风险评估的时间框架可以缩短,以反映出这些协议不再处于一刀切的局面。不再需要花数月时间分析多个桥接以选择一个选项,项目可以用一半的时间初步选择多个桥接提供商,并根据安全评估设置不同的铸造限制。然后代币发行人可以进行安全审查,以决定是否提升或降低特定桥接合作方的铸造限制,或从桥接方撤回铸造权(例如,当面临黑客攻击或漏洞披露时)。

ERC-7281 还降低了想要采用前沿桥接安全技术的项目的门槛,尽管它们在技术没有经过彻底检验和社区检验之前并不愿意全面采用(即创新者的困境)。如果某个桥接提供商提议的新基础设施声称大大提高安全保证,协议可以通过将有限的铸造权赋予该桥来“试水”,并逐步提高该桥的铸造限制,随着对提议系统设计的信心提高。

就像消除了与流动性相关的担忧,移除此协议需要在完全信任桥的技术堆栈之前再赋予铸造权,为新进入市场与旧玩家之间创造了平等竞争——老玩家有动力不断改进其安全方法,因为代币发行人现在有灵活性可以随时抽回铸造权并重新青睐另一个项目,只因后者更高地承诺给予安全性与去中心化。这还消除了另一个与第三方桥接工作相关的风险因素:所选的桥接提供者由于执行复杂性的原因,可以降低对桥接的某一技术堆栈的信任而停止继续创新;这是因为其知道 token 发行人往往无法执行惩罚性措施(例如迁移到另一个桥提供者)。

提高生态系统间组合性

构建复杂的应用程序工作流,需要在任意数量的链上路由代币,如今变得困难,这主要是由于流动性基础桥接定价的不确定性。例如,桥接聚合器从以太坊 → Linea → Base 桥接其中有两个选项:

  1. 设定滑点容忍参数,并基于用户在每条链可能收到的最少代币数量来执行跨链路由的定价(具体取决于桥接信息到达各层时的流动性情况)。
  2. 不设定滑点容忍参数;相反,创建逻辑以从链上流动性来源(例如,利用去中心化交易所)来保证如果在一条或多条链上收到的代币数量少于预期数量,则重新获取流动性。

相比之下,桥接聚合器可以通过添加 mintingLimit 和 burningLimit,在进行跨链交易时提前了解期望在每个相关领域标识上预计的代币数量。诚然,桥接在广播交易时可能会达到 maxLimit——这意味着用户可能无法在目标链上收到标准代币。然而,ERC-7281 在这方面仍是一次改善,原因如下:

  1. 如果桥接操作员在交易过程中达到 mintingLimit,则桥接交易将暂停,并会在速率限制参数调整时重新尝试。用户不会按照今天流动性的桥接类型收到专有的包装标准代币。
  2. 桥接聚合器对桥接交易的执行时间以及期望的代币数量具有更高的可预测性。由于 mintingLimit 和 burningLimit 被配置为使用区块作为时间指标(如“速率限制参数”部分所展示),很容易计算出桥何时重新开始铸造和销毁代币;相反,预测某桥的流动性何时增加就如同玩俄罗斯轮盘赌一般。

流动性价格波动的不确定性流动性在重新桥接交易中产生不确定性价格假如桥接聚合器(或其他应用)根据桥接流动性池当前代币对价格提供跨链交换报价(基于总流动性) ,但因流动性骤降停止了交易的执行。假如交易在重新尝试后保留,此时应用程序开发者便无法知道上次的报价是否仍然准确,以及流动性是否能达到用户首次提交交易时的同一水平。

由于桥接 xERC-20 代币与流动性波动无关,用户可以确信,在跨链交易中不会有滑点发生——即使它们未立即执行。

桥接聚合器并不是唯一从这一改善中获益的;任何跨链应用都可以利用 xERC-20 代币的可替代性来创建更有趣的应用程序。如今更加困难的是由于路径依赖的问题。假设开发者希望将以太坊的 ETH 桥接, 在 Arbitrum DEX 上开设一个借款头寸,然后用于在 Optimism 上购买 NFT,然后再将其桥接回以太坊。在这里,开发者必须确保与这些链上的桥梁提供商进行整合因为你不能轻易地互换产品,这种情况在项目的桥接代币在采纳 xERC-20 后将不复存在。

这种工作流程类似于早前描述的代币发行人的桥接。让我们以 Circle CCTP 为例:

Circle 的跨链转移协议允许用户对其 USDC 代币拥有统一的,标准的版本,而不必被限制于它们的链生态。所有跨链转移都是通过其协议使用铸造和销毁方案进行处理。

然而,尽管 CCTP 是一个中心化协议,因为 Circle 的运营者是唯一可以创作和销毁其 USDC 代币的实体,但 xERC-20 通过允许多个具有不同安全机制的实体进行跨链转移来消除了信托风险。

支持以太坊的汇聚未来愿景

ERC-7281 可以通过给予项目信心在可能缺乏已建立 L2 链强安全能力的新 EVM L2 上部署代币,从而加速以太坊的汇聚中心化路线图。例如,阶段 0 汇聚的标准桥不够安全,因为以太坊 L1 不保证该桥的安全性。一个代币项目可以逐步向该链扩展,通过将有限的铸造权授予标准桥,随着汇聚变为第一阶段,则逐步增加铸造限制。

该流程可以继续,直到 L2 达到第二阶段(汇聚的去中心化和安全的最高阶段)。让协议可以在新推出的链上以风险最小化的方式展开的机制,能便于以太坊生态系统,因为它使新 L2 更容易为代币提供流动性和应用程序的引导,同时鼓励更多的创新,推动汇聚的设计空间发展。

实施 ERC-7281 的潜在缺点

DAO 项目管理团队的开销增加

尽管 ERC-7281 对协议非常有吸引力,但由于 DAO 项目团队必须为管理 xERC-20 代币在共有多条部署上的重大运营开销而犹豫采用。

Gerard Persoon 的 在大量链上管理桥接代币 提出了迁移从 ERC-20 到 xERC-20 后协议必须执行一次性和定期任务的非详尽清单:

这是一项非常长的任务清单

提出的解决方案是让 DAOs 将一些与管理跨链 xERC-20 代币相关的管理任务外包给第三方服务,但这只是将一道权衡(人力资源成本)替换为另一道(雇佣服务的成本)。

假如一个协议之前使用内部基础设施(例如在每条链上部署一个独立的代币合约并控制铸造和销毁)来管理跨链代币,那么实施 ERC-7281 看起来就未必会有显著的变化。然而,对那些习惯于将核心桥接基础设施的管理外包给桥接开发团队的项目,则会感到额外负担关切。

例如,Lido 核心团队成员明确说明(对于 Lido 在所有部署中将 wstETH 部署为 xERC-20 代币的提案的回应)与互操作基础设施团队有关的 PM 团队的当前职责,并与相同团队成员在 Lido DAO 投票将所有域 wstETH 迁移至 xERC-20 版本时所需承担的职责进行了对比。

正如以上讨论所表明的,管理 xERC-20 代币对协议和社区成员施加了非可忽略的行政开销。例如,桥接限制需要积极监测并评估桥接安全,以便为调整铸造限制提供信息,而桥限的决定(或撤回/分配铸造权)可能需要 DAO投票(如果须做出这样的频繁选择,DAO成员可能会感到选举疲劳)。

这并不应被理解为对 ERC-7281 的价值评判。节点项目在风险容忍、长期目标和资源方面各不相同——这些因素共同决定了实施 ERC-7281 的长期益处是否超过短期及持续的成本。

例如,较小的项目可能更难管理发行 xERC-20 代币的开销,并选择像 Axelar 的 ITS (Interchain Token Service)或 Wormhole 的 NTT (Native Token Transfers)等托管的多链代币桥接服务。更成熟的项目可能具备资源去管理发行 xERC-20 代币的行政与运营成本,可能也会考虑到 ERC-7281 提供的控制能力值得额外的管理跨链代币的开销。

迁移现有代币到 xERC-20 标准的困难

对于那些没有铸造和销毁接口,或者无法通过继承使用 IERC20 升级代币合约,并且已经在非本地链上流通有标准表示的原生代币的项目,迁移到 xERC-20 代币是一个需要大量协调的漫长过程,涉及多个参与者之间错综复杂的合作——包括代币持有人、交易所(去中心化及中心化)、合作桥接及与传统 ERC-20 代币集成的应用。即使这一话题得到妥善处理,协议仍需承担从 ERC-20 解包至 xERC-20 代币完成迁移过程的费用。

正如 ERC-7281 规范的讨论所述,现有代币需要锁定在 Lockbox 中,以铸造包装的 xERC-20 为用户。随后原 legacy ERC-20 将会被锁定,并与社区沟通新(旧版)ERC-20 代币制造冻结时间的时间表。虽然从协议的角度上来看可能值得付出这一成本——但实现全生态迁移至 xERC-20 兼容代币的成本收益对某些项目可能也并不足以证明这一商业模型。

DAO 治理的更大风险面

在多个域上管理 xERC-20 代币需要 DAO 的积极治理机制来监督该协议。这涉及到设定如铸造限制、升级 Lockbox 合约、以及暂停铸造或销毁代币等参数。这些决定极具安全敏感性,并且需要 DAO 来管理,以避免闭门会议决策的责任。

ERC-7281 旨在让协议控制这些决策,而非第三方桥接。这是合乎逻辑的,能够全面管理本地链上的代币,令基于可扩展代币治理的框架延展至跨链代币的控制也是合理的。然而,一些协议可能出于对治理和稳定性的担忧而不愿望承担额外的 DAO 控制。

例如,像 Lido 这样的高知名度项目面临治理问题时审查的重大压力。增加对代币管理的控制可能增加治理攻防的风险。如果一个项目将所有 ERC-20 代币集中到一个 Lockbox 中,而 DAO 负责管理,那么攻击者可能会获得 Lockbox 的控制权,引入一个没有铸造限额的恶意桥接提供商,这会使其他链上的 xERC-20 代币失去价值。

这一情形与 Multichain 的攻击有相似之处,其中多方计算(MPC)签名基础设施中的漏洞使黑客能够控制以太坊和 Dogecoin 上代管原生代币的 Multichain 的初始地址——这些代币支撑在 Fantom 和 Moonriver等非本地链上铸造的代币,最终造成其它项目因针对 Etheream 和 Dogecoin 上 Multichain 的智能合约的攻击而损失。

与最大去中心度协议的不兼容性

当代币由拥有代币治理或中心化机构(例如 Circle 的 USDC 或 CZKC 稳定币)发行时,ERC-7281 非常有用。然而,如果协议是最大程度去中心化且缺乏正式治理——例如 Liquity 的 LUSD 稳定币就是一个使其与 xERC-20 标准兼容变得困难的代币。

xERC-20 代币需要某个实体来决定诸如铸造和销毁限制等特定参数,同时做出是否白名单某些桥接提供商等决策。这意味着需要对 xERC-20 代币的存在进行持续治理。对逐步去中心化协议关键部分(如 DAO 的代币合约)有更高追求的项目,可能会在这个过程中出现问题,并妨碍长期的去中心化计划。

核心组件(Lockbox 合约和桥接提供商)可能遭受的更大风险

我们已经提到路径依赖如何发挥作用,以及它为何能为保证攻击链 A不会影响链 B,或攻击 A 链上的桥不会影响 B 链上的桥提供保障。 ERC-7281 移除了路径依赖,尽管这带来了收益,但也在安全性方面引入了权衡:

一个桥的最大可用流动性不再表示其给代币发行人造成的损失影响的上限,因为不同桥接提供商铸造的代币在主体之间是可以替代的。 ERC-7281 的作者建议根据代币发行人为补偿因欺诈铸造造成损失能支出多少来选择桥接提供商的速率限制;纵然如此,所选的速率限制在回顾时可能会显得过于保守。

如果某一高限的桥被攻破,效果可能甚至很显著——即便是对于其他桥铸造相同代币的用户而言也是如此。协议可以通过将铸造权分散在众多桥接之间来降低风险(让其变得不只是有个别桥接提供商ос对这些代币可铸造的数量),但以这种方式对风险进行对冲,可能会通过使每一个桥需要 DAO 团队独立评估而增加低效率,并且更大范围地协调桥接会增加先前提到的行政开销。

由 DAO 监管的 Lockbox 合约可能在发生治理攻击时引起不利的传染效应。但是即便在有安全治理的 DAO 情况下,代币的本链或跨链上的 Lockbox 合约也可能引发同样1590214 个问题(Sifu 现已成为某项目 Lockbox 合约的所有者,资金则不再 SAFU)。相比之下,在现状下,这个问题减少,因为金库合约(即桥接提供商的 Lockbox 合约)只持有通过相应桥接服务剥离的代币。所以 одной 金库合约故障只会影响在该桥接中托管其他用户存入的代币。

生态系统整合的开销

使用 ERC-7281 增加行政工作还影响到使用项目的 xERC-20 代币的应用程序开发者和服务提供商。桥接聚合器需要跟踪 xERC-20 代币及其相应的 Lockbox 合约间的映射,以防止诸如恶意代币和伪造攻击等问题。虽然这样的映射注册可能有帮助,但建立这样的注册有挑战性,且有中心化风险,或者使 xERC-20 用户面临威胁。

这个风险在于攻击者可能向代币注册中包含恶意合约,并欺骗用户和开发者将代币发送至错误地址。这可能导致 L2 和 L1 网络的代币被盗。交易所也面临类似的挑战,因为伪造代币可能会引发严重问题,例如使代币行为异常,与获得的标准代币相悖。

结论# ERC-7281: 解决非同质化跨链代币问题的方案

ERC-7281 提供了一个引人注目的解决方案,解决了非同质化跨链代币的问题,并提供了增强用户体验、去中心化、安全性和灵活性的功能。在代币桥接设计中,这些问题直接影响了以 Rollup 为中心的路线图的可行性,使得 xERC-20 标准成为以太坊 L2 生态系统的关键基础设施。

包括 Hyperlane、Omni、Sygma、Router Protocol 和 Everclear 在内的多个桥接领域的关键参与者,已经承诺采用 ERC-7281,表明这一提案得到了显著的关注。甚至已建立的代币发行者(拥有桥接代币工作机制)——如 Circle——也对 ERC-7281 表示了兴趣,以应对影响用户和开发者的未批准代币带来的挑战。

ERC-7281 在解决这些问题的同时,降低了与以往在远程域上铸造规范代币相关的许多权衡。与已纳入设定的桥梁不同,它提供无流动性引导,不需要像代币发行者桥梁那样的自定义基础设施,并且通过允许经批准的桥接提供者进行多桥的规范代币铸造来避免供应商锁定。

对于有兴趣关注 ERC-7281 讨论的用户或希望集成 xERC-20 的开发者, 以太坊魔法师协会xERC-20 网站 是极好的资源。社区还建立了一个 xERC-20 启动平台,聚合了创建、监控和管理 xERC-20 代币的工具——这是构建者初次部署 xERC-20 代币或将现有代币迁移到 xERC-20 代币标准的有价值工具。

  • 原文链接: research.2077.xyz/how-to...
  • 登链社区 AI 助手,为大家转译优秀英文文章,如有翻译不通的地方,还请包涵~
点赞 0
收藏 0
分享
本文参与登链社区写作激励计划 ,好文好收益,欢迎正在阅读的你也加入。

0 条评论

请先 登录 后评论
2077 Research
2077 Research
https://research.2077.xyz