跨链 DEX 可能有哪些潜在风险?又该如何防范

原文标题:为什么LP跨链机制更安全?

原文来源:HurricaneSwap

这次 O3 的盗币事件把跨链安全问题推向了风口浪尖。

8 月 11 日凌晨,黑客在以太坊网络上自问自答中写道:「为什么选择攻击 Poly Network?因为近期跨链协议攻击很『火』。」

「攻击跨链」的确很火

据 PeckShield 统计,截止目前 2021 年第三季度就发生了 19 起 DeFi 安全事件,其中 6 起发生在跨链协议上,相关损失达 6.44 亿美元位居榜首;其次是以太坊,达到 2,937 万美元;Polygon 位列第三,造成损失 122 万美元。

可见,即使剔除本次 O3 事件涉及的 6.11 亿美元,跨链协议安全事件造成的损失依然是 DeFi 领域最高的。从另一角度看,涉及跨链的安全事件频发、金额巨大所反映出的恰恰是跨链协议本身的火热。

跨链 DEX 的出现使得过去 DeFi 用户需要绕道中心化交易平台的异链 token 交易变得简单快捷。传统方式下,跨链交易需耗费短则数十分钟长则数日的时间,并花费多笔大额手续费。而只需 2-3 步,快至秒级交易的跨链 DEX 在这一场景下深受用户认可。但近期频发的安全问题则让用户意识到在效率、费率之外,安全问题可能是选择跨链 DEX 的重中之重。

跨链 DEX 可能有哪些潜在风险?

从 PeckShild 统计的一份数据来看,近两个月集中爆发的跨链安全问题主要出在协议的「逻辑错误」上:

1、假充值漏洞——THORChain 攻击事件

假充值漏洞是指黑客通过充值虚假的 Token,以此合约来让跨链桥为黑客生成真实的 Token。THORChain 曾遭受假充值攻击,其原因在于检验代币地址的函数中,初始化的代币符号为 ETH,攻击者在以太坊链上伪造了一个符号为 ETH 的 ERC-20 代币,跨链桥并获取了真实的 ETH 代币。

2、多签漏洞+配额漏洞——ChainSwap 第二次被盗

ChainSwap 第二次被盗是因为跨链桥的白名单地址配额是由节点自动增加,但是在检验白名单时,原本需要的多签地址因配置错误成为单签,恶意攻击者只需要通过跨链转入时的多重签名中的其中一个,调用另一链上的 Receive 函数即可转走资产。

3、足额兑付风险

以 OK 链(OEC)的 BNB 为例。Anyswap 跨链桥为 OEC 发行了 BNB,但是该 BNB 并非由官方发行而是 Anyswap 发行的,由于 BNB 本身并不支持 OEC 公链,OEC 上的 BNB 也并不等价于 BSC 上的 BNB。OEC 与 BSC 作为不同的公链,OEC 本身是无法产出任何 BNB 的,在 OEC 上的 BNB 实际上是由 Anyswap 发行的、流通于 OEC 的 BNB「债券」。

4、私钥泄漏风险——Anyswap 攻击事件

Anyswap 被攻击的最主要原因是签名使用了重复的 R 值。如果同一账户签名的两笔交易拥有相同的 rsv 签名的 R 值,则黑客可以反向推导出该账户的私钥。由于该账户在 BSC、ETH 和 FTM 上可以复用,故该账户多条链上资产被盗。值得注意的是,这也和单一账户权限过大有关。

5、闪电贷套利——bEarn Fi 事件

攻击者通过闪电贷借出 BUSD,通过 Alpaca Finance 的借贷生成 ibBUSD,并通过 bEarn Fi 的合约策略漏洞,利用 ibBUSD 价格高于 BUSD 的差价,进行套利攻击。

6、Keeper(Relayer)替换+签名伪造——O3 攻击事件

攻击者通过将替换 Keeper 的交易伪装为正常的跨链交易,替换了 Poly Network 中跨链中继人 Keeper 的地址为自己的地址,加上中继人校验函数校验难度不足,仅检查了 4 Bytes 字节,攻击者在伪造 Keeper 后通过碰撞形式碰出符合要求的 4 Bytes 后成功将自己的地址伪造为了 Keeper 地址并通过签名,调用 LockProxy 合约洗劫了整个 Poly Network 的跨链资产。

风险防范从协议做起

以上 6 种风险便是新诞生的 LP 跨链协议项目 HurricaneSwap 的安全小组所总结的。作为相对传统单币跨链全面升级的 LP 跨链协议,部署在 Avalanche 公链上的 HurricaneSwap 拥有区块链行业最顶端的架构顾问——Ted Yin,HotStuff 共识第一作者,现任 Avalanche 公链首席架构师。

从上述我们可以看到,这些受到攻击的跨链协议多数都存在自身协议漏洞或逻辑错误,要做好充分预防,跨链 DEX 的安全部署无疑要做到协议级。针对以上风险,行业顶层团队所构造的更先进的 LP 跨链协议 HurricaneSwap 早已做好了自己的保障方案:

1、假充值漏洞:在派盾针对 HurricaneSwap 的代码审计中已明确没有假充值风险。同时,HurricaneSwap 对 Station 中支持的可跨链币种有严格的币种限制和合约地址限制,避免假充值漏洞。

2、多签与配额漏洞风险:HurricaneSwap 的合约代码中目前没有掠夺用户 LP 资产的代码,详情可见派盾审计报告,不存在通过多签来提取用户流动性的可能。

Chainswap 等流动性跨链桥通过合约中存入 Token 来铸造跨链映射 Token 完成跨链,白名单用户依赖配额在 Chainswap 中存入和提取流动性。HurricaneSwap 并无硬性配额上限设置,用户提取流动性的上限源自其所拥有的 LP Token,避免了多签及配额漏洞。

3、兑付风险:HurricaneSwap 的 aToken 是源链资产的映射,目前用户可以通过查阅 Station 合约中锁住的流动性资产数量与 HurricaneSwap 中发行的 aToken 数量来比对二者是否 1:1 发行。未来我们也会通过与 Chainlink 合作来赋予 aToken 更稳定的刚性兑付特性

4、私钥泄露风险:HurricaneSwap 吸取了 Anyswap 私钥泄漏的风险,交易中不存在重复 R 值的签名,避免出现攻击者反推密钥的情况。其次,团队在部署合约阶段使用了专用的密钥管理工具,避免明文储存私钥导致的泄漏风险。

5、闪电贷风险:闪电贷攻击获利的核心方式是价格差距。HurricaneSwap 采用预言机喂价方式实时更新流动性池价格与它链代币价格,避免闪电贷操纵价格引起波动,未来也会引入熔断机制,通过暂停相关代币合约的调用,进一步预防闪电贷攻击。

此外, HurricaneAlliance 节点会根据代币价差进行套利,调控交易对价格。如果闪电贷攻击导致某一代币价格剧烈波动,节点会出面套利并降低价格差距,降低攻击者的攻击收益。

6、Relayer 替换与哈希碰撞风险:HurricaneSwap 中与 Keeper 功能类似的存在是 Roke Protocol 主账户。Roke Protocol 无法操控 LP 锁定在 Station 中的流动性;另一方面,执行 aToken mint 和 burn 的操作账户仅限 Roke Protocol Owner 账户,不存在通过替换 Roke Protocol 来伪造 aToken。

HurricaneSwap:天生优势+安全加持

之所以将单币跨链革新为 LP 跨链,主要原因之一就是 HurricaneSwap 团队看到了目前跨链机制的风险。作为更先进的一种跨链机制,HurricaneSwap 的 LP 跨链协议与传统单币跨链相比有着天然的安全优势,其最根本的区别在于 LP 机制下攻击者无法通过单币跨链逃逸资产。

除 LP 机制本身所具有的安全特性,HurricaneSwap 还通过 Roke Protocol、Hurricane Station 以及联盟节点 HurricaneAlliance,从跨链资产的价差、LP 权限和去中心化安全验证等方面对资产进行全方位的安全防护。而在这些安全机制的背后,更有 Ted Yin 等行业顶尖的成员为项目构造协议、代码和逻辑的底层保障。

新事物的出现都是伴随风险的。本次 O3 事件中黑客有一句话说的很对,这次攻击其实也给 O3 项目和 DeFi 行业再次敲响了警钟。

没有人天生喜欢作恶,除非你把机会放在他眼前。

郑重声明: 本文版权归原作者所有, 转载文章仅为传播更多信息之目的, 如作者信息标记有误, 请第一时间联系我们修改或删除, 多谢。

区块分享

DYDX斯坦福区块链和法学研讨:去中心化司法是否可行?

论文作者:Kleros 创始人兼首席执行官 Federico Ast、巴黎第二大学教授 Bruno Deffains 编译:白泽研究院 译者注:本文篇幅较长,但译者已经进行了逻辑整理,请读者朋友们安心阅读。 在线争议解决 (“ODR”) 行业诞生于 1990 年代。

Bitcoin随着机构投资者入场 DeFi能否迎来保险赛道的爆发?

随着DeFi的兴起以及伴生的暴富神话,风险也随之而来。 DeFi领域的风险损失总量多达10亿美元。有的损失可能是协议本身设计问题,但除此之外很大一部分风险是可保的。 2021年,不出意外的话DeFi业务依然会持续增长,这或许预示着DeFi保险行可能会爆发。

TRXFOMO情绪涌入NFT 重蹈动物币崩盘覆辙?

8月23日,支付巨头Visa宣布花费15万美元买入CryptoPunk#7610头像,进一步推动了NFT的大流行。 这一消息流出的24小时内,CryptoPunks遭爆炒,共200名买家买入了288个像素NFT头像,平均成交价为25.4万美元,其中多个头像以超过200 ETH的价格售出。

[0:15ms0-0:484ms