9月30日，头部去中心化借贷协议Compound于官推表示，在今天通过并执行「治理提案062」后，升级合约内发错了一个BUG，致使COMP代币出现了异常分发情况。
具体来说，漏洞出现在升级后的「Compound:Comptroller」合约内，原本应通过该合约缓慢分发给所有流动性提供者的COMP代币被错误释放，部分用户收到了远高于正常数量的COMP。如下图所示，仅0x2e4ae开头的地址一个地址就从「Compound:Comptroller」合约内领取到了近30000枚COMP，代币，价值约900万美元。
漏洞影响评估
首先需要强调的是，从漏洞影响来看，本次Compound事件只会直接影响到所有流动性提供者的预期收益，用户的存款、借款及仓位情况理论上不会受到任何干扰，所以不必太过恐慌。此外，根据Compound创始人RobertLeshner的说法，「Compound:Comptroller」合约内的COMP总量有限，用于挖矿分发的更多COMP代币其实是存在另一个合约「Compound:Reservoir」内，该合约仍在以每个区块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日，社区成员TylerLoewen于Compound治理模块内提交了改进提案，拟将这种一半一半的分配方式更改为依照利率状况动态调节。这一提案的出发点显然是正向的，社区对于提案的态度也是以支持为主，大概一周左右，也就是今天上午，该提案顺利通过并得到了执行。遗憾的是，代码层面的BUG往往就是这么难以预料。尽管社区内其他一些成员也审查过TylerLoewen的升级代码，且所有升级合约已在以太坊Ropsten测试网上顺利运转了一个月的时间，但BUG还是出现了。解决措施及流程
关于补救工作，Leshner本人在推特已表示：“没有任何管理控件或社区工具来打断COMP当前的异常分发，协议层面的任何更改都需要经过为期近一周的治理程序才可生效。CompoundLabs和社区成员当前正在评估修复错误分发的可行方法。”
如其所说，Compound有着一套既有的治理流程：任何地址都可以锁定100枚COMP来发起自治提议，当提议积攒够至少65000枚COMP的委托后将升级为治理提案，继而进入社区公投环节；社区公投为期3天，当提案获得了至少40万枚COMP支持，且多数人投票赞成之时，即可通过公投环节。通过公投的提案将排队进入时间锁，并在2天的时间锁后正式执行。梳理治理的整个流程，可以看到，仅公投和时间锁环节就要求了至少5天的时间，算上最初的提议以及流程过渡工作所需的时间，Leshner所说的一周并不夸张。关于「没有任何管理控件来打断COMP当前的异常分发」这一点，事实上，Compound协议内存在一个用于处理极端情况的监护地址，该地址此前一直由CompoundLabs持有，但在8月份的「治理提案057」中已被转变为多签控制。不过，该监护地址的权限暂时仅规定了可在极端情况下暂停协议的存款、借款和清算，并未明确提及是否可用于当前发生的情况。流程至此已厘清，但该采取什么样的补救措施，目前没有人给出具体方案。社区成员已在Compound治理论坛中建立了一个主题讨论帖，拟通过「治理提案063」来执行修复。从已释放出的信息来看，大概率会先行暂停COMP的分发，直到可以测试完整的修复补丁。
经验教训总结
作为践行去中心化理治模式的先驱之一，Compound本次事件的起因及处理在一定程度暴露了DAO治理的B面。我们的惯性认知中，去中心化往往意味着用效率来换取公平。在DeFi领域，当一款协议实现了完全的去中心化治理，没有任何单一主体能够随意对合约进行修改时，调动社区整体来共同参与治理决策往往极大的组织精力及时间成本，这也是为什么Compound需要用七天的时间来修复一个明摆着会对协议造成极大负面影响的漏洞。实际上，在一众头部DeFi协议之中，Compound七天左右的治理周期并不算慢了，Uniswap走完全套治理流程的时间周期至少需要半个月之久。话说回来，既然明知事后的补救需要如此高的成本，那么在事件发生之前，是否需要对重大合约升级采取更加严格的评估标准呢？这是在本次事件发生后，Compound社区所作出第一个的经验总结——社区成员PhazeJeff于治理论坛内发起了一个讨论帖，主题为「对重大代码更改执行更严格的审核」。结合具体事件来看，在社区成员Loewen提交「治理提案062」后，参与测试工作的社区成员数量过少，最终导致BUG被遗漏和“放行”。因此，Jeff认为在协议进行重大更新时进行更细致的监测，并鼓励更多的社区成员参与到主网部署前的社区工作去。此外，Jeff还提到了需要进一步明确多签监护地址的具体权限，以允许其在出现类似紧急情况时快速相应。当前，关于该话题的讨论仍在进行中，感兴趣的朋友可以直接访问帖子参与讨论。
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。