DeFi之暗面——HackFi:2020年DeFi安全事件盘点
DeFi 的热潮点燃了 2020 年的市场情绪,但伴随着应用的发展,新的风险也悄然滋生。
据 Odaily 星球日报不完全统计,从二月借贷及交易协议 bZx 被盗,到年末明星保险项目 Cover Protocol 崩盘,2020 年 DeFi 领域内已发生了四十余起起攻击事件,损失金额高达 1.774 亿美元(其中约 4939 万美元已追回,完整可见下方表单)。从刚刚上线的全新应用,到成名已久的头部协议,黑客们已然“鲨疯了眼”,恍惚之间,DeFi 似乎变成了“科学家们”的提款机,甚至被戴上了 HackFi 这一调侃式的昵称。
为了尽可能清晰地复盘 2020 年 DeFi 领域的安全状况,我们将根据各大 DeFi 应用在遭遇攻击后发布的事件报告,同时结合派盾(PeckShield)、慢雾(Slowmist)等业内头部安全公司给出的调查分析,对 DeFi 领域2020年发生的所有安全事件进行一次系统梳理。
根据事件发生的不同起因,本文将所有攻击分为了「技术因素事件」、「金融因素事件」、「人性因素事件」以及「其他事件」四大类。
需要注意的是,DeFi 应用跨越了科技及金融两大维度,因此一起安全事故的起因往往是多因素、多维度的复合,下文中,即便某起事件被划分为 A 类,也不代表该事件的发生不存在其他 B 类因素,在一些具体案例内我们会指明标注。
一、技术因素事件
“币圈一天,人间一年;DeFi 一天,币圈一年。”
外部市场的瞬息万变以及 DeFi 应用本身的创新性和复杂性决定了,即便是思维最缜密的开发者也很难在产品快速迭代的同时做到十全十美,因此在合约编写或产品设计中往往难免出现或大或小的漏洞及不完善之处。纵观一年以来发生的针对 DeFi 应用的各种攻击,可归于此类别的事件数量最多。
往细了说,这一大类可以再分为三个细分类别:协议本身存在漏洞或是设计存在不完善之处;协议在交互过程中存在兼容问题;底层网络存在特殊性或发生故障。
第一类:协议本身存在漏洞或是设计存在不完善之处
首先是第一类 —— DeFi 协议本身存在漏洞或是设计存在不完善之处,这一细分类别的逻辑最为清晰,理解起来也最容易,我们将直接通过几个典型案例加以说明。
- 典型案例一:Pickle Finance(11 月 22 日)
11 月 22 日,旨在通过流动性挖矿方案来帮助稳定币实现价格强锚定的 DeFi 应用 Pickle Finance 遭黑客攻击。黑客在调用 Controller 合约中的 swapExactJarForJar 函数时伪造了 _fromJar 和 _toJar 的合约地址,通过转入假币换取了合约中的真 DAI,成功窃取了约 2000 万美元的 DAI(完整攻击流程可查看慢雾科技的 调查分析 )。从失窃金额上来看,Pickle Finance 被黑无疑是本年度最严重的 DeFi 安全事件之一(仅次于 Harvest.finance 和 Lendf.Me,后者失窃资金已追回)。
事件的结局有些出人意料,遭遇重创的 Pickle Finance 最终迎来了他们的救世主 —— DeFi 领域最活跃的男人、Yearn(YFI)创始人 Andre Cronje。11 月 24 日,Andre 宣布 Yearn 将合并 Pickle Finance 的开发资源,同时 Pickle Finance 还将推出全新的治理代币 DILL,并将向受本次黑客事件影响的用户分发补偿代币 CORN。CORN 的申领已于 11 月 29 日正式启动。
回顾 Pickle Finance 事件的整个攻击流程,其关键在于 swapExactJarForJar 未能识别黑客部署的两个伪 Jar,合约漏洞最终酿成了悲剧。
- 典型案例二:Cover Protocol(12 月 28 日)
明星保险项目 Cover Protocol 这一年过的可以说是跌宕起伏,从 SAFE 时代的创始人决裂,到 Cover 初期成功抱上 Yearn 的大腿,再到 12 月末的惊魂一夜,电影剧本都不敢这么写。
12 月 28 日,Cover Protocol 遭遇黑客攻击,这也是 2020 年发生的最后一起 DeFi 安全事件(完整攻击流程可查看 PeckShield 的 调查分析 )。当晚,攻击者利用 Cover Protocol 的业务逻辑错误天量增发 COVER 代币并砸盘套现,COVER 的价格也从 800 美元左右开始一路暴跌,几近归零。
图片来自:PeckShield
有意思的是,本次黑客事件中的主要攻击地址指向了另一个 DeFi 项目 Grap Finance,该项目随后也已将其套现获取的 4350 枚 ETH 还给了 Cover Protocol 团队,并销毁了剩余的增发 COVER。尽管客观上来讲,Grap Finance 的行为确实像是白帽黑客为了保护 Cover Protocol 而采取了极端措施,但其行为仍然引起了不少的争议,一些声音质疑 Grap Finance 其实是因为身份泄漏不得不选择归还“赃款”。
事件发生后,Cover Protocol 官方宣布计划根据漏洞发生之前的数据快照结果分发新的 COVER 代币,并将向流动性提供者分发共 4441 枚 ETH 作为激励。币安方面随后也宣布将启用「SAFU 基金」为快照时间后在币安买入 COVER 的持仓受损用户进行补贴。
- 典型案例三:MakerDAO(3 月 12 日)
作为稳定币赛道乃至整个 DeFi 领域的头部协议之一,MakerDAO 也未能幸免。
「312」黑天鹅期间,由于 ETH 价格暴跌,MakerDAO 内大量借贷的抵押率跌破清算门槛,引发了清算拍卖程序执行。然而,因同时以太坊网络 gas 费用出现短时激增,清算机器人(Keeperbot)提交的交易请求由于 gas 设置过低而受阻,某一清算人(Keeper)在没有其他竞争者的情况下,以 0 DAI 的出价赢得了拍卖。
事件发生后,分析公司 Whiterabbit 发布 报告 称,12、13 日 MakerDAO 因清算机制失灵而零价拍出的 ETH 抵押品价值高达 832 万美元,且系统内出现了 567 万 DAI 的无担保坏账。此后,为了弥补系统担保不足问题,MakerDAO 启动了首次 MKR 拍卖以填补漏洞,后续又对协议机制进行了一系列改进以防止类似事件再次发生。不过,MakerDAO 9 月完成的一次社区投票 拒绝 了对受到该事件影响的用户做出赔偿,以 Peter Johnson 为首的受损用户随后将一项指控 MakerDAO 虚假陈述 DAI 相关风险的诉讼提交仲裁。
梳理 MakerDAO 清算事件发生的始末,尽管严格来说 MakerDAO 在协议层面并没有出现硬性漏洞,但造成损失的主要原因仍是系统在设计上对极端情况准备不足,未能考虑到极端行情下 gas 费用暴涨的问题,从而导致其清算机制无法正常执行。
第二类——协议在交互过程中存在兼容问题
其次是第二类 —— 协议在交互过程中存在兼容问题,本细分类别与第一个细分类别之间的界线其实较为模糊,从根本上来说都是协议存在不完善之处,但在细节上还是有着一定的差异,具体请看以下两个典型案例。
- 典型案例一:Uniswap & Lendf.Me(4 月 18 日,4 月 19 日)
之所以将这两起安全事件放在一起,一是因为两起攻击发生的时间较为接近,二是因为造成两起攻击的原因基本相同。
4 月 18 日,黑客利用 Uniswap 和 ERC777 标准的兼容性问题缺陷实施了重入攻击,获利约 22 万美元。仅仅一天后,又一知名 DeFi 平台 Lendf.Me(即 dForce)也被黑客以类似的手段实施了攻击,0x538359 开头的攻击地址这一次共计从 Lendf.Me 获利约 2523 万美元,这也成为了 2020 年失窃数额第二大的一起 DeFi 黑客事件(完整攻击流程可查看 PeckShield 的 调查分析 )。
图片来自:PeckShield
幸运的是,交易聚合平台 1inch 发现(Lendf.Me 事件)黑客在交易时无意中泄露了有关其个人信息的重要元数据,随后将相关信息提交给了新加坡警方。重重压力下,黑客最终选择了妥协,全额归还了本次黑客事件的赃款。
PeckShield 分析指出,ERC777 出现的目的是对 ERC20 标准进行改进,其愿景是成为 ERC20 标准的有效继承者。不过由于 DeFi 项目的可组合特性,一个合约在不同产品之间相互调用时,其业务逻辑复杂度也会大大增加,这就给注入代码攻击提供了可能性。
- 典型案例二:Balancer(6 月 29 日)
6 月 29 日,AMM 型 DEX Blalancer 遭黑客攻击,由于 Balancer 上的通缩型代币和其智能合约在某些特定场景不兼容,使得攻击者可以创建价格偏差的 STA/STONK 流通池并从中获利。
黑客通过四个步骤实施了本次攻击,具体流程如下:
- 先是通过闪电贷从 dYdX 平台借出了 104331 个 WETH;
- 反复执行 swapexactMountin() 调用,直至 Balancer 拥有的大部分 STA 代币被消耗殆尽,最终 Balancer 仅仅剩余 0.000000000000000001 个 STA;
- 利用 STA 代币和 Balancer 智能合约存在的不兼容性即记账和余额的不匹配性实施攻击,将资金池中的其他资产耗尽,最终共计获利价值 523616.52 美元的数字资产;
- 偿还从 dYdX 借出的闪电贷,并卷走攻击所得。
事情发生后,Blalancer 很快作出反应,先是宣布将把通缩型代币添加至其 UI 黑名单,随后又宣布将对蒙受损失的用户进行全额赔偿。
不同应用之间的可组合性筑造了 DeFi 的高楼,同时也带来了新的兼容性风险。在日新月异的DeFi 领域,不同协议之间的组合未来势必会变得更加繁复,类似的黑客攻击大概率还会再次发生。
第三类——底层网络存在特殊性或发生故障
以太坊网络孕育了如今的 DeFi 世界,用户也早已习惯了以太坊的底层状况,当转而使用基于其他公链的 DeFi 应用时,用户一般都会想当然地以过往经验来进行风险评估,但事实往往却很残酷。此外,以太坊网络本身也不是绝对安稳,具体情况请看如下两个例子:
- 典型案例一:EMD(9 月 9 日)
首先申明一点,所有的 DeFi 跑路事件都是不良项目方主观做恶所导致的结果,这一点无论在哪条底层网络上都是一样。就 EMD 而言,客观来讲也应该归类于第三大类「人性因素事件」,但鉴于该事件本身以及 EOS 底层网络的特殊性,我们还是选择了将其归类于此。
9 月 9 日早间,慢雾、PeckShield 相继发布风险提示,基于 EOS 的 DeFi 项目 EMD(翡翠)疑似跑路,项目合约 emeraldmine1 向账号 sji111111111 转移了 78 万 USDT、49 万 EOS 及 5.6 万 DFS。万幸,由于 TokenPocket 钱包表示 EMD 项目方曾使用过该钱包,留下了 IP 地址以及移动设备等信息,在法律制裁面前,最终项目方不得不同意归还资产。
值得注意的是,造成本次事件的一大关键点在于,EOS 网络本身的特殊性导致非多签的 EOS 合约账号可转移合约内资金。主网部署记录显示,EMD 在发布后确实曾对合约进行升级。项目方在跑路后甚至还通过转账附加信息叫嚣称:“EOS 就是可以这么为所欲为。”
在 EOS 生态深耕多年的 Meet.one 负责人高锋也表示,不同于以太坊,EOS 上的智能合约在发布后可以修改,且即使是多签也有权重高低之分,bloks.io 等浏览器可以查看智能合约,但很多项目合约并没有开源。因此理论上,DeFi 项目在 EOS 上比其他公链的风险也高些。
慢雾就此提醒称,投资者在参与 EOS DeFi 项目时应注意项目方权限是否为多签,是否存在修改权限等不安全因素。
- 典型案例二:Infura(11 月 11 日)
11 月 11 日,以太坊 API 服务商 Infura 的服务暂时中断,币安、Upbit、Bithumb 等多个交易平台被迫暂停了 ETH 以及 ERC20 代币充提服务,参与 DeFi 时最常用的轻钱包 MetaMask 也出现余额显示异常、数据延迟等情况。
严格来说,Infura 宕机事件的影响并不局限于 DeFi 领域,且从结果上看并未造成资金丢失,因此也算不上什么黑客事件,但该事件导致的网络数据异常确实对用户正常访问 DeFi 应用造成了阻碍。
二、金融因素事件
熟悉 DeFi 的朋友们可能还记得,入冬以来曾有过一阵安全事件高峰期,Harvest Finance、Value DeFi、Akropolis、Cheese Bank、OUSD 等多个 DeFi 项目先后遭遇攻击,复盘那一段时间内发生的所有黑客事件,其中多起最终都指向了同一种手段——「闪电贷攻击」。
所谓「闪电贷攻击」,其实是一个定义偏差,我们认为这一类攻击手段最准确的名字应该叫做「预言机操控攻击」,其基本逻辑是,黑客通过一系列手段出入各类抵押、借贷、交易协议,利用巨额资金扭曲某个单一市场的价格数据,进而扰乱预言机报价结果,最终实施套利。在此类事件中,黑客们往往会选择使用闪电贷 —— 允许用户零抵押贷出巨额资产,但必须在同一个区块内还款,否则交易会回滚 —— 来获取攻击所需的巨额筹码,长此以外,闪电贷便背上了“污名”,但我们需要清晰地认识到,闪电贷仅仅只是个金融工具,黑客成功干扰了预言机数据才是此类事件发生的根本原因。
尽管从具体情形来看,本类安全事件并非与技术因素毫无关系,但与第一大类「技术因素事件」不同,本类事件的起因往往更加偏向于金融维度,具体情况请看以下几个典型案例。
- 典型案例一:bZx(2 月 15 日,2 月 18 日)
如果评选年内最倒霉的 DeFi 项目,借贷协议 bZx 绝对可以争一争头名。一方面,它是本年度第一个遭受攻击的 DeFi 项目,另一方面,bZx 先后三次遭遇攻击也是本年度之最。
2 月 15 日,2 月 18 日,bZx 在短短的三天内先后两次遭遇黑客攻击。PeckShield 对两起事件的攻击流程进行了梳理,其中第一起的流程可概括为“闪电贷获取可用资金,囤积 WBTC 现货,杠杆拉盘 WBTC 价格,抛售 WBTC 现货,归还闪电贷”;第二起的流程可概括为“闪电贷获取可用资产,拉升 sUSD 价格,吸纳更多筹码,抵押 sUSD 借出更多 ETH,归还闪电贷”(完整攻击流程可查看 PeckShield 的 调查分析一 、 调查分析二 )。两次攻击分别对 bZx 造成了 1271 枚 ETH、2378 枚的损失,按当时价格计算约为 35 万美元、64 万美元。
从攻击流程上看,尽管两次攻击的具体流程完全不同,但整体上的套利思路还是一致的,黑客利用了平台间共享流动性不足以及取价机制设计不够完善等客观条件,通过闪电贷短时间内获得了巨额筹码,针对性地干扰了某一市场内(往往流动性不高)的价格数据,最终再利用操控后的报价成功于 bZx 内套利。
不幸中的万幸是,保险项目 Nexos Mutual 此前已支持了对 bZx 的保险服务,这意味着在 Nexos Mutual 内购买了 bZx 相关保险的用户可以申领赔偿。在事件发生后,Nexos Mutual 社区也认同此次攻击造成的损失符合赔偿条件,bZx 事件就此成为了 Nexos Mutual 的首个实施赔偿案。
不过,bZx 的霉运并未就此结束,9 月 14 日,该项目再次因合约漏洞失窃 4700 枚 ETH,好在这一次 bZx 仅用了两天便找回了被盗资产。
- 典型案例二:Harvest.finance(10 月 26 日)
10 月 26 日,DeFi 聚合协议 Harvest Finance 遭遇黑客攻击,根据项目官方后续发布的公告,本次攻击损失共计 3380 万美元(黑客已退回 247 万美元),约占攻击发生前协议中锁仓总价值的 3.2%,这也是整个 2020 年失窃金额数量最大的 DeFi 安全事件。
简单梳理本次 Harvest Finance 事件的黑客攻击逻辑(完成流程可查看 Odaily 星球日报当时的 跟踪报道 ),大致可分为如下三步:借贷 —— 正向操作价格 —— 逆向操纵价格。
黑客首先是通过闪电贷借出了大量的 USDT 以及 USDC;随后在Curve 协议 y 池将大量 USDT 兑换成 USDC,导致 USDC 价格升高;由于 Harvest 池内 USDC 价格参考 y 池,也跟着上涨;此时再用 USDC 在 Harvest 池兑换更多的 fUSDC;在 y 池对上述过程逆向操作,将大量 USDC 兑换成 USDT,导致 USDC 价格降低;此时 Harvest 池内 USDC 价格也跟着下降;再用 fUSDC 可以兑换出比原来更多的 USDC,最终完成套利。
12 月 9 日,Harvest Finance 正式启动了对受损用户的赔偿,因本次事件而蒙受损失的用户可在官方索赔网站上申领 USDC、USDT 以及全新的 GRAIN 代币(用户透露 GRAIN 占绝大部份)。然而,Harvest Finance 的赔偿方法却再次引发争议,鱼池创始人神鱼也在微博上直言项目方“鸡贼”,因为 Harvest Finance 在推出 GRAIN 时已大幅折价(发行价 0.21 美元),用户几乎无法得到全额损失补偿,且 GRAIN 在上线二级市场后又是一路走低,截至 1 月 3 日凌晨,GRAIN 报价已跌至 0.04 美元。
- 典型案例三:Compound(11 月 26 日)
Compound 创造性的流动性挖矿掀开了 2020 年 DeFi 热潮的第一章,但作为龙头借贷项目,Compound 也未能逃过攻击者的狙击。
11 月 26 日下午,Compound 内突然出现了近 9000 万美元的清算数据,导致出现巨额清算的主要原因是,Compound 的预言机数据源 Coinbase Pro 的 DAI 价格出现了异常波动,一度飙升至 1.34 美元的不合理值。受此影响,Compound 内大量借贷的抵押率跌破了清算阈值,除了使用 ETH 等非稳定资产贷出 DAI 的用户遭遇影响外,用稳定币借贷稳定币(主要为了挖矿)的用户也未能幸免。
事后看来,这是一起典型的预言机操控攻击,攻击者通过操控 Compound 预言机所依赖的信息源实现了短时间的价格操纵,成功误导了链上价格。数字资产服务商 StakeCapital 的创始人 Julien Bouteloup 的链上分析证实了这一点,巨额清算发生期间,曾有人成功套利逾 355 万美元,该攻击过程主要分为如下几个步骤:使用闪电贷从 Uniswap WETH-DAI 池借出 4600 万 DAI;偿还 Compound 中的 DAI 债务;从清算中获取约 23.96 亿 cDAI;将约 22.26 亿 cDAI 换成 4628 万 DAI;向 Uniswap 偿还DAI的借款和利息;最后剩下 1709 万 cDAI,折合约 3553325 美元,顺利完成套利。
Compound 社区曾提交 治理提案 032 号 ,以讨论是否为受本次事件影响的用户发放 COMP 补偿,但该提案最终未能通过。Compound 创始人 Robert Leshner(在投票中弃权)则表示,希望社区可以利用这次清算事件作为进一步强化协议的催化剂,讨论激进或温和清算系统间的权衡方案,并在必要时增加额外的保障措施。
- 典型案例四:Value DeFi(11 月 14 日)
11 月 14 日,曾宣称可防范闪电贷攻击的 Value DeFi 惨遭黑客“打脸”,黑客利用闪电贷从 Aave 及 Uniswap 中借用了 8 万枚 ETH 以及 1.16 亿枚 DAI,再通过一番骚操作成功从 Value DeFi 内薅走约 540 万美元(总计 740 万美元,退还 200 万美元,完整攻击流程可查看 PeckShield 的 调查分析 )。值得一提的是,黑客在攻击得手后还给项目方留了一句挑衅意味十足的文字:“你真的懂闪电贷吗?”
事后,一名自称是护士的用户试图联系黑客称,其已把毕生的积蓄(近10万美元)投入到该项目中,并请求黑客归还这些钱,尽管多位推特用户均质疑了该用户所言是否真实,但黑客还是向该用户转账了价值 5 万美元的稳定币;另一名用户称自己是一名 19 岁的大学生,为了所谓的高收益回报,损失了家里 20 万美元的积蓄,黑客后来也给这名用户发送了 4.5 万枚 DAI。
惨遭“打脸”的 Value DeFi 也吸取了教训,该协议在半个月后宣布集成了 Chainlink 喂价,以降低喂价操控攻击风险。该协议此后发布的 Vaults v1 版本代码也已通过了 Peckshield 的审计,未发现重大问题。
- 典型案例五:Cheese Bank(11 月 7 日)
11 月 7 日发生的 Cheese Bank 攻击事件是一次极其典型的预言机操控攻击。
攻击发生在当日凌晨 03:22,黑客先是通过闪电贷从 dYdX 贷出了 21000 枚 ETH 作为本金,再人为影响了 UniswapV2 上 CHEESE 池子的平衡,抬高 CHEESE 价值以及相应的 UNI_V2 LP 代币的价值,最终从 Cheese Bank 内成功薅走了约 330 万美元(完整攻击流程可查看 PeckShield 的 调查分析 )。
本次攻击的精妙之处在于,在实施攻击之前,黑客仔细演算过其持有的 LP 代币数量正好是能把 Cheese Bank 清空的数额,不得不承认,这是一次从设计到执行都堪称“完美”的攻击。
11 月 24 日,Cheese Bank 官推宣布已经追踪到一部分被盗资产和相关人员,目前已经锁定一名来自中国浙江的犯罪嫌疑人“张先生”,如果不能收回违法所得,Cheese Bank 将把所有相关证据移交中国警方。然而,截至发文,事件并没有出现任何实质性的进展,自那以后 Cheese Bank 再也没有更新过任何推文。
三、人性因素事件
就像前文提到的 EMD 跑路事件,除了技术及金融相关风险外,DeFi 领域内的人性之恶同样不容忽视。DeFi 最火热时,新项目为了攫取更多流动性,往往会在初期给出惊人的收益回报,浮动年化收益率(APY)上百、上千乃至上万的项目相继出现。
高收益刺激着投机者们的神经,为了抢占头矿,获取最高收益,一些用户在未经充分调研的情况下匆匆存入资金,这也给恶意项目方提供了作恶机会,跑路事件屡见不鲜。
- 典型案例一:Sushiswap(9 月 5 日)
Sushiswap 显然当然跑路,这里要说的发生在 9 月的 Chef Nomi 套现事件。
9 月 5 日,Sushiswap 匿名创始人、首任大厨 Nomi(当时 Sushiswap 尚不是多签,Nomi 个人拥有合约控制权)从协议内突然转走了约 500 万枚 SUSHI 代币并套现获利,此举很快就在社区内引发了关于 Sushiswap 是否构成退出骗局的热议。
尽管 Nomi 本人回应称将继续履行承诺,完成 Sushiswap 后续的多签迁移工作,但该项目乃至整个 DeFi 社区显然对此无法满意。FTX 创始人兼首席执行官 Sam Bankman Fried(SBF)连发 16 条推文,怒喷 Nomi 是“a piece of shit”。
重重压力之下,Nomi 最终选择了将合约控制权转移给 SBF,由后者来牵头处理该协议后续的多签迁移工作事宜。9 月 11 日,Nomi 再次发声称对自己此前的套现行为感到后悔,自己已向 SushiSwap 的金库返还了约 38000 ETH 套利所得,这笔资产在当时的价值约为 1400 万美元。
Nomi 个人的套现行为对 Sushiswap 社区造成了巨大伤害,尽管在 SBF 的牵头下,Sushiswap 此后再次走上正轨,且随着整合至 Yearn 生态,大有挑战 DEX 龙头 Uniswap 之势,但截至 1 月 4 日,SUSHI 代币价格仍未回到 9 月 5 日 Nomi 套现前的价格水平(约 4.5 美元)。
- 典型案例二:YYFI(8 月 1 日)
8 月末,YFI 以及 YFII 的暴涨将整个 DeFi 市场的情绪推至高峰,一时间多个“姨夫”仿盘项目出现,投机者们也相继涌入,生怕错过下一个 YFII。
贪欲最终酿成了悲剧,8 月 1 日,YFII 硬分叉项目 YYFI 跑路。事后回看,YYFI 从一开始似乎就打定了跑路的主意,其骗局汇总起来大概就是以下几步:建立一个可以蹭上热点的合约开始预挖自己所发的流动性挖矿代币;建立各种社交渠道(Telegram、Discord、微信);利用高收益吸引用户参与,操控币价涨幅营造可套利的假象,持续给社区信心;最后利用预挖代币砸盘,砸不下来的情况下甚至可以无限增发导致代币暴跌;套利离场,解散社群彻底消失。
- 典型案例三:justfolio(9 月 10 日)
在众多跑路项目中,justfolio 可以说是玩出了花样。9 月 10 日,波场链上 DeFi 项目 justfolio(JFT)跑路。值得一提的是,该项目为了诱骗更多资金,曾自称其智能合约已通过了成都链安的审计,但成都链安方面却向 Odaily 星球日报回应表示“从未审计过这个项目”。
justfolio 虽然消失了,其“创举”却被其他不良项目方学了去,9 月跑路的另一个 DeFi 项目 LV Finance 后来也伪造了虚假的审计网站,试图通过虚假的审计报告来迷惑投资者。
四、其他事件
除上述各类事件外,用户在参与 DeFi 时还会面临其他一些陷阱。依照前文的分类方式,我们很难将这些事件准确归类,因为陷阱往往存在于协议外部,与相关 DeFi 应用是否存在漏洞并无关系。
比如假币肆虐现象,由于以 Uniswap 为代表的一众 DEX 上币无需审核,一些诈骗者便瞄准了那些尚未发币或是刚刚发币的明星项目进行假币诈骗,Odaily 星球日报此前曾发表过一篇《 如何仅用 46 美元的成本在 Uniswap 上发币 》。此外,针对关键人士的钓鱼攻击也在年末刷了一波屏,12 月 14 日,保险龙头 Nexus Mutual 的创始人 Hugh Karp 在 Ledger 上执行一笔简单的交易时,未能意识到转账地址已被替换,最终损失了 37 万枚 NXM,价值约 833 万美元,黑客随后在二级市场抛售砸盘,对 Nexus Mutual 以及投资者造成了严重伤害。
风险启示
回看过去一年发生的所有 DeFi 安全事件,随着功能的日渐扩展,协议的复杂程度也在日渐提升,黑客的攻击手段相较过往已变得更加难以捉摸。未来,DeFi 将继续向 Layer 2、跨链以及其他全新的方向进一步扩展,程序只会变得越来越复杂,这也将带来新的安全挑战,无论是项目方还是投资者均需做好风控工作。
对于项目方而言,需要在产品上线预先进行充分测试,尤其是要测试极端情况下的协议承压状况;此外,项目方有必要寻求专业的第三方审计机构对协议进行全面审查,后续也可以通过一些 Bug 赏金计划来积极调动社区力量;鉴于一些经典的攻击手段(比如代币遭异常增发)相对而言有迹可循,项目方或许还可以针对一些特定的被黑场景提前部署灾备方案,以便在意外发生时快速做出反应。
对于投资者而言,在决定参与某款 DeFi 协议前应首先确认该项目是否已完成审计;此外,投资者需要清晰地认识到收益及风险往往并存,合理调配自己的仓位,同时也需要保持良好的钱包操作习惯;最后,虽然 Nexus Mutual 和 Cover Protocol 等保险项目2020年都没有逃过黑客魔爪,但 DeFi 保险赛道绝不会就此消寂,未来 DeFi 领域的保险服务一定会日益完善,投资者可以考虑适当投保,以规避潜在的黑客攻击风险。
值得一提的是,2020年发生的多起 DeFi 安全事件都有一个共同特点 —— 黑客最终归还了一定数额的赃款。在那些黑客身份尚不可知的事件中,我们很难推测黑客的确切心理,但在 Lendf.Me 及 EMD 等案例中,黑客妥协的主要原因都是身份泄漏,其个人面临着来自项目方及受损用户的起诉“威胁”。相关案例告诉我们,尽管 DeFi 在交互层面上已实现了去中心化,但一个个受法律保护及约束的人类才是参与 DeFi 的主体,因此 DeFi 绝不是什么无法之地,在资产意外遭遇损失时,报警才是普通人最有效的解决手段。
安全是 DeFi 乃至整个加密货币世界永恒的主题。2020 年,我们眼见了 DeFi 起高楼,但如果底基或是结构不够牢固,万丈巨厦也会有倾倒之险。
空投周报 | Magic Eden代币将于12月10日TEG;Side Protocol空投将于11月26日开放申领(11.18-11.24)
Telegram游戏Major拟于11月28日TEG;Suilend 公布代币经济学,空投占比40% 。
浅析区块链技术在全球选举和治理中的作用 | TrendX研究院
近年来,加密货币及其底层技术区块链在全球范围内引起了广泛的关注与讨论。从金融交易到政治治理,加密货币的影响力似乎正在逐步扩大。
下周必关注|WalletConnect开放空投申领;Ethena将敲定“费用开关”相关参数(11.25-12.1)
Starknet主网STRK质押功能将于11月26日启用。