技术分析MakerDAO的清算机制缺陷及改进思路

作者:原始大胖鱼

2020 年 3 月 12 日,由于 COVID-2019 的全球爆发,引发了加密货币市场的一系列黑天鹅事件,整个市场全线崩溃。同时,以太坊 ETH 的价格暴跌,MakerDAO 的大量抵押债仓跌破清算门槛,引发了清算程序执行。

根据 MakerDAO 的系统设置,被清算的抵押物相比市场价存在折扣,因此能够吸引清算人参与其中,参与拍卖的清算人持续叫价,起拍价为 0 DAI,最终获胜者至少可以获得 3% 的折扣。而实际情况里,往往抵押物的最终清算价差会大于 3%,清算人的获益会更高。

也就是说,假设一共有市场价值 1500 DAI 的抵押物进行拍卖,对于清算人而言,最差情况下,参与者最高出价到 1455 DAI 就可以拍得这批抵押物(不计算其他费用)。而最好情况下,则有可能以 0 DAI 获得拍卖的抵押物。

只存在于理论里的 0 DAI 拍卖,在昨日实实在在的发生了。

根据媒体报道,由于以太坊网络 gas 费用剧增,导致 MakerDAO 的清算过程完全缺乏竞争,原本应该参与到清算过程中的清算机器人(Keeperbot)因为设置了较低的 gas 值,导致出价受阻,一位清算人(Keeper)在没有竞争者的情况下,以 0 DAI 的出价赢得了拍卖。

笔者在此从 MakerDAO 的合约代码层面,分析 0 DAI 事件的根本原因。

对于 MakerDAO 系统而言,当产生清算时,意味着系统会有潜在的债务损失,因此,为了避免损失,MakerDAO 通过一种拍卖机制来对 CDP 持有者进行抵押物的清算。

在拍卖开始之前,首先要确定的,是被清算的抵押物数量以及相应的债务,这依赖于一个 MarkerDAO 系统中事先预设的分割值 lump。也就是说,待清算抵押债仓 CDP 内的抵押物数量会被分割成为 m 批,

m=⌊n/lump⌋+1

对于 ETH-A,在当前的 MakerDAO 合约部署配置文件里,lump 被设置为 50:

所以实际被清算的数量 lot (lot≤lump) 被计算为

MIN(用户 CDP 抵押物总量 , 50)

在确定了被清算的抵押物数量之后 , 紧接着需要确定这笔抵押物所对应的的债务数量 art。

MakerDAO 的算法是根据 lot 在用户 CDP 中抵押的 ETH-A 总量确定其占比,然后该 CDP 内所有 ETH-A 所对应的总债务的同等占比值即为相应的债务值,在代码里表示为

mul(lot, art) / ink

但是 art 仅是单纯的抵押物与债务的对应值 , 并没有考虑利息,所以 , 如果这部分抵押物被清算,那同样也要归还相应的债务,因此实际这部分抵押物对应的债务为 art * rate;

MakerDAO 的清算罚金机制里,目前罚金的比例被配置为 13%,所以实际要被拍卖的目标金额 tab 为

tab: rmul(mul(art, rate), ilks[ilk].chop)

综上 , 发起一笔抵押物拍卖 (flip.kick) 时,抵押物的数量为 lot, 预期拍卖的目标金额为 tab。

MakerDAO 将抵押物拍卖设计为二阶段拍卖,其中第一阶段是一个「试价」的过程,就是参与者正向加价,直到出价满足 tab。基于此设计,MakerDAO 将拍卖起始价格设置为 0。理想情况下,参与者会衡量清算物 lot 的市场价值,以一个较为合理的价格进行叫价。

重点来了 , 起拍价为 0 其实是做了一个假设:一定会有足够数量的 Keeper 参与到拍卖中。

很遗憾的是,当以太坊网络剧烈拥堵时,普通 Keeper 在面临的高昂的 gas 费时很可能没有动力参与到拍卖中去。另一方面,善良的 Keeper bot 也很可能因为其在 gas 升高时没有及时调整 gas 上限 , 竞拍交易迟迟不被确认而无法维持拍卖系统的正常运作。

因此,恶意竞拍者就可以出价 0 DAI 而获胜。

让我们跟踪一下 0 DAI 是如何叫价成功的,下面是竞拍流程的代码:

前三个 require 是检查时间和系统状态的,这都是可以通过的;

第四个 require 检测的是第一阶段的出价必须固定要竞拍的抵押物数量 , 也就是上面发起拍卖时计算的 lot;

第五个 require 检测的是第一阶段的出价最大只能到 tab,相当于债务拍卖只卖出预期的债务数量;

第六个 require 检测的是当前出价必须大于上一次出价;

重点是第七个 require,检测的是当前出价必须大于一定的增价幅度 (beg,比如说 5%)。但是上面笔者提到过,发起拍卖时 bid 的值为 0,

bids[id].bid == 0

因此,如果恶意 Keeper 出价为 0,即 bid == 0,require 表达式会变成

require(0 * ONE >= beg * 0)

攻击者因此毫无阻碍的以 0 DAI 叫价成功。

等到竞拍周期结束以后,如果没有其他人跟恶意 Keeper 竞价,恶意 Keeper 就可以 0 DAI 成交。

到此为止,问题产生的核心就从代码层面分析完了,MakerDAO 系统拍卖机制的其他细节可以 参考这里

MakerDAO 的清算拍卖设计的目的,是尽可能的以最少的抵押物回收最大的 DAI,这一机制在正常情况下是可以成功运作的。但是当以太坊系统极其拥堵的时候,或者更极端一点来说,只要竞拍的参与度不足,就很容易被恶意 Keeper 通过极低报价获得拍卖物。

MakerDAO 作为如今 DeFi 生态的核心项目之一,在极端的市场行情下出了这起严重事故,造成了 400 万美元的系统债务,在不得已的情况下,系统启动了债务拍卖,将释放 MKR 代币进行拍卖,以弥补整个系统的债务损失,而这些损失,需要全体 MKR 的持币者承担。

根据墨菲定律,当一个灾难具备理论上发生的可能性时,无论其概率有多小,最终都是有可能发生的,MakerDAO 在清算机制上的设计过于简单,过于依赖链上操作,最终造成了这次的债务危机。

可惜了一直相信 MakerDAO,相信 DeFi 的核心用户。DeFi 的高速发展过程中留下了诸多隐患,从 bZx 闪电贷事件,到 Curve 合约攻击事件,再到 MakerDAO 的 0 DAI 清算危机,大家用自己的真金白银,为有漏洞的产品设计买了单,DeFi 在其尚且年幼的阶段,就承载了过多的价值和风险,不禁令人为之惋惜和捏一把汗。

下一个爆雷的 DeFi 应用,会是哪一个?受到的损失,又会有多少?

MakerDAO 社区目前已经紧急讨论了针对清算机制的改进措施,目前,社区提出了一个可能的改进方案——MakerDAO Keeper Pool,其要点主要有:

  1. 启动基于 Web 的 Keeper,让用户能够通过浏览器的界面操作 Keeper 参与清算,降低清算的参与难度;
  2. 将 Keeper 的代码和模板开源,并且降低部署难度;
  3. Non-custodial MakerDAO Keeper Pool,建立类似于第三方 Keeper 流动性池的设施,通过 Keeper 的收益分配,吸引外部资金注入。

笔者在此无意评价该方案的优劣,只是,由某种理念或优势成长起来的事物,最终往往被其理念 / 优势所困而无法获得持续性的发展,这种现象在自然界的发展过程中已经被无数次的证明。历史上,武装到牙齿的恐龙,曾经在地球盛极一时,可最终却因为身体过度特化,不适应环境的剧变而灭绝。

DeFi,受益于去中心化这一理念,诸多项目获得了资金和市场的广泛支持,最近一段时期,获得百万美元甚至千万美元级别融资的 DeFi 项目比比皆是。

然而,福兮祸之所伏,过于强调去中心化,恰好成为了 MakerDAO 清算危机的潜在原因。

我们不妨用另一种视角看待清算拍卖这一环节。

下图是淘宝法拍的界面,可以看到,在中心化的服务领域,拍卖系统已经发展得足够的完善。集中化的报价和处理系统,既能避免链上拥堵造成的毁灭性后果,又能够促进更多的用户参与到拍卖的过程中来,表面上中心化的淘宝拍卖,参与的人数和地域却是足够分布式。

如果一个清算拍卖系统,把报价这一环节放到链外,公开透明的集中处理,而只将最终的结果提交到链上进行执行,就能够彻底的避免 MakerDAO 类似的事件再次发生。

为了能够更加有效的开展服务,笔者认为,要不要在中心化和去中心化之中进行适当的 trade-off,这是值得 DeFi 的从业人员进行仔细的思考和权衡的重大问题。