原文标题:《 Say NO to Vendor-lock-in: Calling for An Open Canonical Token Bridge Standard 》原文来源:Celer Network
在这个智能合约兼容链如雨后春笋般层出不穷的时代,用户对各种原生资产的第三方跨链桥的需求也随之日益增长。区块链生态和项目通常采用简单的「铸币&销毁(mint & burn)」跨链解决方案,这会导致跨链资产的无限制控制权归属于某个单一的跨链桥供应商。然而很少有人讨论的是,一旦绑定了供应商,就很容易对资产安全和区块链生态造成难以补救的巨大风险。在这篇文章中,我们将首先详细讨论在使用单一原生资产跨链解决方案和供应商锁定的情况下,存在的各种高安全隐患和区块链生态风险;其次,我们在这里提出一个开放的原生资产跨链桥标准,真正将用户、项目开发者和区块链生态的共同利益置于任何单一桥的短视利益之上;最后,我们呼吁所有跨链桥建造者、区块链生态、区块链应用创始人、意见领袖和用户,采纳这份开放的原生资产跨链桥标准,以共同实现互操作性更好的未来。当我们需要将一条链上的原生资产跨到另一条链上时,在进行该项跨链的同时保持该资产在市面上的总流通量不变,是一个广泛的需求。比如当一个项目想要扩展到多链发展时,通常需要将自己的合约 token 进行跨链并用于流动性挖矿奖励或治理(例如 $SUSHI 或任何其他多链 DeFi 项目)。再如,新推出的 EVM 兼容链通常需要跨链接入一些主流资产(如 WETH、USDT 和 USDC 等)以激发 DeFi 生态的活跃度。这就是「原生资产跨链桥」发挥作用的地方,它的「铸币和销毁」工作流程如下:· 从源链到目标链: 用户将源链上的原始资产「锁定」在一个主体(去中心化或中心化)控制的保险柜智能合约中,然后由该主体在目标链上向用户「铸造」原始资产的规范映射。· 从目标链返回源链:用户在桥接的目标链上「销毁」铸造的规范映射资产,确认销毁后再由该主体向用户在源链上「释放」相同数量的锁定资产(减去相应跨链手续费)。为了简化下面的讨论,我们借用网络研究界的一个术语,把这个控制资产的主体称为「桥结构」。对于像 Avalanche 或 Polygon 这样的区块链或二层侧链,或像 Arbitrum 和 Optimism 这样的 rollup,通常会建立一个官方的原生资产跨链桥来连接到以太坊,并用于主流资产跨链,如 WETH、USDT、USDC、DAI 等等。通常这些官方跨链桥的「桥结构」具有与底层链共识相同的安全级别(当然也有一些例外),或者在二层 Rollup 的情况下,与以太坊一层进行安全绑定。由于汇合点是以太坊,在链和其原生资产跨链桥之间形成了一个星形拓扑结构。然而,这种星形拓扑结构并不能满足所有原生资产的跨链需求:· 如果一个 token 最初不是在以太坊上发行的,并且想从例如 Avalanche 到 BSC 上有一个直接的原生资产跨链桥,但没有对应的官方原生资产跨链桥可以支持这种用例。· 如果一个链选择不运营一个去中心化和非准入的原生资产跨链桥,自然就没有办法直接满足建立在该链上的生态项目跨链需求。这样的例子包括 Moonriver, Celo, Oasis Emerald, BSC(目前 BSC 官方桥已停止运营) 等等。在这种情况下,不仅是项目的合约资产,包括 USDT/USDC/WETH 在内的主流资产都没有办法官方桥接到该链上。第三方原生资产跨链桥解决方案的出现就是为了满足上述的这些需求。它不使用共享底层链安全级别的「桥结构」,而是构建自己的安全假设和模型,使用自己的「桥结构」进行铸币和销毁这个过程。在许多现有的解决方案中(例如 Anyswap),「桥结构」本质上是一个由一组签名者服务器维护的门限多重签名。对于 Celer cBridge 来说,「桥结构」是状态守卫者网络(SGN),一个基于 tendermint 的 PoS 区块链本身。现在,我们假设 Oasis Emerald 上的某 DEX 想要上线$ROSE/$USDT,它应该选择使用哪种版本的跨链$USDT?或者假如一个 DeFi 项目想扩展到 BSC,并希望将自己的合约资产跨过去,应该使用什么跨链桥来创建 token 的规范映射?如今每个现有原生桥都创造了自己独有版本的规范映射 token,而这些 token 是完全不兼容的。这是个很讽刺的现实:原生资产跨链桥作为实现区块链互操作性的关键组件,它们相互之间却并不具有互操作性。既然这样,那么问题来了,只能从中选一个了对吧?应该选 Anyswap、cBridge,Wormhole,还是别的跨链桥?如果你已经开始准备做个对照表格来比较它们的安全模式、UI/UX、SDK、聚合器支持、未来可扩展性和成本等等,那大可不必。对没错,这些都很重要,但你不应该一开始就被迫做出选择。当你,作为一名 DeFi/GameFi/NFT/Metaverse/dApp/blockchain 开发者,决定采用第三方原生资产跨链桥作为解决方案时,要问的最重要的事情是:它是否会被供应商锁定?不幸的是,所有现有的第三方原生资产跨链桥都有供应商锁定的问题。那么对项目开发者来说,当你选择使用任何跨链方案的时候,不管它是好是坏,项目都会被永远限制在这个桥上。从技术上讲,这是因为你选择的跨链桥是目标链上该资产唯一的规范映射 token 的铸造者。首先从巨大的资产安全风险说起。假设你开发了一个区块链上的 DEX,目前完全依赖由一个名为 SuperNice Bridge 铸造的唯一一版$USDT 映射。如果 SuperNice Bridge 的「桥结构」有一个关键的安全流程漏洞,让黑客能够铸造无限量的$USDT 并耗尽你的 DEX 上的每一个资产,会发生什么?或者说你把你的项目 token 扩展到了多个链上,现在 80% 的 token 被锁定在该桥控制的池子里,同样的安全漏洞发生了,你会经历打击性的市场价格崩溃,而且比任何交易平台黑客事件对你的资产的攻击都要严重。接下来是可靠性的问题。如果跨链系统出现拥堵怎么办?如果跨链服务质量下降怎么办?如果跨链桥倒闭了怎么办?那些持有你项目 token 的用户就彻底陷入了困境。最后,这种供应商锁定的跨链桥会产生一系列你难以预料的生态问题:· 如果它决定增加手续费怎么办?· 如果它决定对你的用户进行费率限制怎么办?· 如果它停止了对用户体验的迭代造成你的用户不满怎么办?· 如果它不能支持未来通用消息传递的使用场景怎么办?· 如果它不与外部的桥接聚合器合作或者 API 损坏怎么办?你能做些什么?没错,你无能为力。而以上列举的只是一小部分可能发生的情况,你的 dApp 和你的用户将完全受制于难以预测但真实的垄断力量。好消息是,这种供应商锁定的情况可以很容易地解决。我们可以制定统一的「单一资产规范映射框架」,把区块链项目和开发者社区放在主导地位,在多个跨链桥当中选择最佳的原生资产跨链解决方案。更重要的是,作为项目开发者,你没有任何额外的负担。在更多的技术层面上,首先要做的,也是最重要的事是:根除原生 token 单一铸造者合约的概念。因为在这种情况下,token 只能由单一跨链桥铸造,所以会导致供应商锁定的问题。相反,当一个项目选择扩展到其他链时,该项目的开发者社区应该要求一个多跨链桥兼容的合约。有了这种 token 合约,项目可以允许多个跨链桥同时作为其合约 token 的原生资产跨链桥,因为每个跨链桥将铸造同一种版本的原生规范映射 token。DeFi 应用还可以要求支持该开放跨链桥标准的 USDT/USDC/WETH 等主流资产的规范映射。每座桥也可以根据 DAO 对安全级别、用户体验和其他因素的评估,动态分配最大的铸造值上限。显而易见,项目方现在成为了跨链桥的支配者。那么让我们回过头来看看上个章节提到的风险设想场景。在其中一个跨链桥遭到攻击,导致无上限铸币的情况下,只有分配给该跨链桥的剩余铸币配额(通常甚至远小于该跨链桥的铸币上限)会减少,而不会导致该合约 token 的总供应量急剧下降,大大降低了该情况下的风险。如果其中一个跨链桥不能正常使用了怎么办?不用担心,还有其他的跨链桥可以继续正常为用户服务!如果某个桥费用太高?耗费太多跨链手续费?UI/UX 不直观?功能支持有限?没有外部生态系统的整合?别担心,项目的 DAO 可以简单地降低该跨链桥的铸币上限,并引导用户使用其他的桥!现在大家应该很清楚了,一个开放的原生资产跨链桥标准是针对同一种原生资产允许多个跨链桥共存的,同时将用户、dApp 开发者和区块链生态的利益放在最核心的位置。我们想跟大家明确的是,今天我们发布这篇内容并不是为了制定一个标准规范,而是希望它能为这种开放标准的必要性提供一个强有力的理由。我们期待着与区块链生态中的每位成员合作,为更大的共同利益,促进和定义这种标准。历史已经一次又一次向我们证明,开放的标准才能实现共赢,闭关自守只会满盘皆输。我们抱着完全开放的态度,期待着与任何跨链桥以及区块链互操作性基础设施项目合作,共同建立这个开放标准,实现共赢的局面。我们希望这篇文章可以让大家认识到,使用非供应商锁定的原生资产跨链方案是极其重要的。如果你正在考虑跨链资产集成或者扩展至新的链,无论你目前考虑的是哪一种跨链桥解决方案,我们希望你能找到一个真正对你有益的方案,而不是单纯地去找一个跨链桥供应商。如果你已经集成了某些供应商锁定的 token,我们希望有幸与你合作,一起将它们迁移到更加开放的版本上,同时为对应的迁移损耗提供额外的激励。别再犹豫,赶快联系我们吧。请加入我们,一起将开放的原生资产跨链桥标准带来的好处传递给全世界每一位正在寻找建议的开发者,并告知他们供应商锁定的潜在隐患。让我们携手,一起建立一个开放的互操作未来。
原创文章,作者:惊蛰财经,如若转载,请注明出处:http://www.xmlm.net/wang/13838.html