梳理Compound 8000万美元token分发错误事件

9 月 30 日，头部去中心化借贷协议 Compound 于官推表示，在今天通过并执行「治理提案 062」后，升级合约内发错了一个 BUG，致使 COMP 代币出现了异常分发情况。

具体来说，漏洞出现在升级后的「Compound : Comptroller」（0x3d9819210A31b4961b30EF54bE2aeD79B9c9Cd3B）合约内，原本应通过该合约缓慢分发给所有流动性提供者（借方、贷方）的 COMP 代币被错误释放，部分用户收到了远高于正常数量的 COMP。如下图所示，仅 0x2e4ae 开头的地址一个地址就从「Compound : Comptroller」合约内领取到了近 30000 枚 COMP，代币，价值约 900 万美元。

漏洞影响评估

首先需要强调的是，从漏洞影响来看，本次 Compound 事件只会直接影响到所有流动性提供者的预期收益，用户的存款、借款及仓位情况理论上不会受到任何干扰，所以不必太过恐慌。

此外，根据 Compound 创始人 Robert Leshner 的说法，「Compound : Comptroller」合约内的 COMP 总量有限，用于挖矿分发的更多 COMP 代币其实是存在另一个合约「Compound: Reservoir」（0x2775b1c75658Be0F640272CCb8c72ac986009e38）内，该合约仍在以每个区块 0.5 枚 COMP 的速度正常分发。最极端的情况下，也就是「Compound : Comptroller」合约内的代币被提空时，将有约 28 万枚 COMP 受到影响，总价值约 8000 万美元。

从链上状况来看，当前「Compound : Comptroller」合约内已被提走了约 17 万 COMP，还剩下约 11 万 COMP，而「Compound: Reservoir」合约当前的运转并未出现异常情况，与 Leshner 的说法相吻合。

事件发生原因

本次漏洞的起因在于前文提到的「治理提案 062」，该提案的目的旨在调节对不同流动性提供角色的 COMP 分配比例。

依照协议运转规则，Compound 每天会向所有流动性提供者分发 2880 枚 COMP 代币，这些代币的一半将分配给借方，一半将分配给贷方。然而，在日常运行之中，Compound 发现这种一半一半的分配方式并未充分考虑到市场需求状况，致使了市场出现了一些畸变（比如负利率）。所以在 9 月 22 日，社区成员 Tyler Loewen 于 Compound 治理模块内提交了改进提案，拟将这种一半一半的分配方式更改为依照利率状况动态调节。

这一提案的出发点显然是正向的，社区对于提案的态度也是以支持为主，大概一周左右，也就是今天上午，该提案顺利通过并得到了执行。

遗憾的是，代码层面的 BUG 往往就是这么难以预料。尽管社区内其他一些成员也审查过 Tyler Loewen 的升级代码，且所有升级合约已在 以太坊 Ropsten 测试网上顺利运转了一个月的时间，但 BUG 还是出现了。

解决措施及流程

关于补救工作，Leshner 本人在推特已表示：「没有任何管理控件或社区工具来打断 COMP 当前的异常分发，协议层面的任何更改都需要经过为期近一周的治理程序才可生效。Compound Labs 和社区成员当前正在评估修复发行版的可能方法。」

如其所说，Compound 有着一套既有的治理流程：

·任何地址都可以锁定 100 枚 COMP 来发起自治提议，当提议积攒够至少 65000 枚 COMP 的委托后将升级为治理提案，继而进入社区公投环节；

·社区公投为期 3 天，当提案获得了至少 40 万枚 COMP（即 ≥4% 的供应量）支持，且多数人投票赞成之时，即可通过公投环节。

·通过公投的提案将排队进入时间锁，并在 2 天的时间锁后正式执行。

梳理治理的整个流程，可以看到，仅公投和时间锁环节就要求了至少 5 天的时间，算上最初的提议以及流程过渡工作所需的时间，Leshner 所说的一周并不夸张。

关于「没有任何管理控件来打断 COMP 当前的异常分发」这一点，事实上，Compound 协议内存在一个用于处理极端情况的监护地址（Set Pause Guardian，0xbbf3f1421d886e9b2c5d716b5192ac998af2012c），该地址此前一直由 Compound Labs 持有，但在 8 月份的「治理提案 057」中已被转变为多签控制。不过，该监护地址的权限暂时仅规定了可在极端情况下暂停协议的存款、借款和清算，并未明确提及是否可用于当前发生的情况。

流程至此已厘清，但该采取什么样的补救措施，目前没有人给出具体方案。社区成员已在 Compound 治理论坛中建立了一个主题讨论帖，拟通过「治理提案 063」来执行修复。从已释放出的信息来看，大概率会先行暂停 COMP 的分发（可能通过监护地址执行？），直到可以测试完整的修复补丁。

经验教训总结

作为践行去中心化理治模式的先驱之一，Compound 本次事件的起因及处理在一定程度暴露了 DAO 治理的 B 面。

我们的惯性认知中，去中心化往往意味着用效率来换取公平。在 DeFi 领域，当一款协议实现了完全的去中心化治理，没有任何单一主体能够随意对合约进行修改时，调动社区整体来共同参与治理决策往往极大的组织精力及时间成本，这也是为什么 Compound 需要用七天的时间来修复一个明摆着会对协议造成极大负面影响的漏洞。实际上，在一众头部 DeFi 协议之中，Compound 七天左右的治理周期并不算慢了， Uniswap 走完全套治理流程（民意调查——共识检查——治理投票——时间锁）的时间周期至少需要半个月之久。

话说回来，既然明知事后的补救需要如此高的成本，那么在事件发生之前，是否需要对重大合约升级采取更加严格的评估标准呢？这是在本次事件发生后，Compound 社区所作出第一个的经验总结——社区成员 Phaze Jeff 于治理论坛内发起了一个讨论帖，主题为「对重大代码更改执行更严格的审核」。

结合具体事件来看，在社区成员 Loewen 提交「治理提案 062」后，参与测试工作的社区成员数量过少（似乎是大部分 DeFi 协议的通病），最终导致 BUG 被遗漏和「放行」。因此，Jeff 认为在协议进行重大更新时进行更细致的监测，并鼓励更多的社区成员参与到主网部署前的社区工作去。此外，Jeff 还提到了需要进一步明确多签监护地址的具体权限，以允许其在出现类似紧急情况时快速相应。

当前，关于该话题的讨论仍在进行中，感兴趣的朋友可以直接访问帖子参与讨论。