【缺陷】技术分析MakerDAO的清算机制缺陷及改进思路( 二 ) 缺陷|思路|机

因此，恶意竞拍者就可以出价 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，其要点主要有：

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

笔者在此无意评价该方案的优劣，只是，由某种理念或优势成长起来的事物，最终往往被其理念 / 优势所困而无法获得持续性的发展，这种现象在自然界的发展过程中已经被无数次的证明。历史上，武装到牙齿的恐龙，曾经在地球盛极一时，可最终却因为身体过度特化，不适应环境的剧变而灭绝。
DeFi，受益于去中心化这一理念，诸多项目获得了资金和市场的广泛支持，最近一段时期，获得百万美元甚至千万美元级别融资的 DeFi 项目比比皆是。
然而，福兮祸之所伏，过于强调去中心化，恰好成为了 MakerDAO 清算危机的潜在原因。