Peckshield:yam自救在技术拆卸中失败，75万YCLV在整个过程中被锁定

备受关注的流动性挖矿项目Yam finance因合同漏洞被锁定75万YCRV。Peckshield在网上解释了36小时的YAM。

原文的标题是：“天涯海角无路可回，YAM投票拯救注定失败的开始！》佩克希尔德的

36小时内，我看着他站起来，几分钟内他就倒下了。

北京时间3时，德福旗下备受关注的项目YAM金融宣布启动流动性挖矿。短短一天时间，锁定资产价值超过6亿美元，锁定资产增量和增长速度达到近乎疯狂的状态。根据这一发展趋势，一些前期向池中注入流动性的羊毛党的年利率甚至接近200倍，这从疯狂中可见一斑。

然而，就在大家都参与挖矿狂欢节的时候，事故发生了。

北京时间8月13日早间消息，YAM金融发现其智能合约的弹性供应机制（返基）存在漏洞，导致第二次触发合约时出现大量额外代币。这意味着社区将无法获得足够的代币来执行任何治理操作，yam将成为一台失控的机器，并最终失去社区用户的信任。

如何拯救我们的YAM红薯？

在发现漏洞后，YAM团队发起了一场“拯救行动”，称他们需要16万张代理票才能提交治理方案，因此他们呼吁社会各界投票。很快，充满活力的社区投票活动结束了。

然而，就在所有人都认为这只是虚惊一场的时候，北京时间8月13日下午16:01，YAM创始人布洛克·埃尔莫尔在微博上写道：“对不起，我失败了。”这是怎么回事？

在peckshield的安全人员介入分析后，很快发现问题的实质是在回扣机制中存在代码公式错误，导致系统在触发第二个回基时自动发出10^18个新代币。如果市场价格维持在高位，那么未来每一次回扣都会在触发时发生，YAM的数量将成倍增加，这将使YAM的数量变成一个可怕的天文数字。这意味着无论社区在后期如何委托投票，都无法获得足够的选票来控制制度，整个制度将陷入失控、无主的状态。

原来，YAM官员呼吁广大YAM持有人完成投票“拯救行动”，通过代理投票来弥补这一漏洞。不过，当亚克山德的官员开始进一步分析营救行动失败时，派克桑被安全人员发现。

有两个原因

1） 时间太晚了：任正非官员可能忽略了一点，即在其提案的投票救援行动准备工作完成后，至少需要12.5小时才能实施。根据当前的时间节奏，当它的实现生效时，已经触发了第二个回扣。

2） 新部署治理合同无法有效执行：由于第二次返基触发，原预计由政府执行的新治理合同到了执行时间，但发现总票数达不到合同约定总金额的4%，因此，它无法得到有效实施。

为什么？其次，技术干货：

技术概述

本文首先介绍了yam智能合约的柔性供应机制（rebase）

1） 系统会根据市场价格波动动态调整代币供应。当市场价格上涨时，将按比例发行额外代币，以降低单位代币的价值，直至其降至1美元。

2） 每笔回扣将改变代币供应，并根据当前市场价格发行或销毁一定数量的代币。

实施提案的另一个关键因素是：如果得票数超过总票数的1%，则可以将提案付诸执行安排。根据合同，安排时间需要等待12.5小时。提案实施时，投票数需超过总票数的4%。这样，新的治理契约才能得以实施和生效，项目才能继续正常运行。

有了以上技术要点的铺垫，让我们看看YAM官方的后续日程安排，来了解救援行动为何注定要失败。

如下图所示：

② 这是第一次触发rebase的时间。由于合同中的一个缺陷，供应资产总额异常增加。这位官员发现了这个窃听器并将其公布了出来。

③ 现在是正式宣布部署新治理合同的时候了，之后社区开始投票。

④ 这是投票目标的初始完成时间，也是新的治理契约进入执行安排的时间。从那以后，合同的执行就等了12.5个小时。

⑤ 是第二个回基的触发时间。

⑦ 这是投票通过后新的治理合同正式实施的时候。

⑥ 在第二次回扣触发后31分钟，也许项目方发现它无法回到今天。方案被成功取消，项目方正式宣布YAM失败。

① 之后，绿色区域是“黄金紧急时期”，投票和提议救援行动可以成功。整个救援行动的准备工作需要在第一次回基触发前半小时内完成。（即蓝色虚线应提前移至绿色区域）。

这意味着yam官员应该在第一次回扣（北京时间8月13日凌晨4:08）之前发现这个漏洞，并留出足够的时间来完成新治理合同的部署和投票。

然而，与我们的愿望相反，这位官员发现漏洞并公布投票呼吁已经太晚了，错过了唯一可以成功的黄金紧急时期。更糟糕的是，根据官方的时间节奏，当新的治理合同到了执行时间时，票数将超过总票数的4%。目前，总金额扩大了10^18*10^18。以前累积的票数只是九牛一毛。

因此，救援行动从一开始就注定要失败。

下面我们将对这一事件进行详细分析：（项目方GitHub地址）

详细过程分析

首先，让我们来看看我们第一次回基时发生了什么：

图1第一次返基资产变动

如上面链上的信息所示，在第一次返利之后，总供应量从3500000*10^18飙升至最大值。

我们进一步分析代码，看看代码中发生了什么：首先，从链上的信息可以看出，rebase操作调用了yamrebase契约的yamrebase:：rebase（）函数（我们将跳过这个函数，稍后再讨论）。最后，我们发现通过调用yam契约（0xa923af6d05993495257a872ec60dbbf01501eb0e）Totalsupply（代码逻辑如下图2所示）的rebase（）函数重新计算的。在340行对totalsupply的赋值操作中，我们可以看到这行代码有一个明显的错误——没有基数划分，这导致totalsupply的值增加了10^18倍。

任正非在第一次发现这个问题后，便公开了退基窃听事件，并展开了救市行动。

图2 yamtoken:：rebase（）获取异常大的totalsupply值

12小时后，yam触发第二个rebase，这是根据基于错误的totalsupply计算的，结果initsupply的值相同。

图3第二次返利资产变动

我们继续分析initsupply异常的原因。关键是上面提到了yamrebase:：rebase（）函数。此函数实现的主要逻辑基于总供应量（）计算此回扣需要发出的yam minthamount数量，并输入yam的_uminthamount（）函数用于根据异常的minthamount为initsupply赋值。由于在第一个rebase中，totalsupply已成为一个最大值，基于此异常值的后续操作（如图4中的红色箭头所示）最终导致initsupply的计算错误，这将成为一个天文值。

图4 yamrebase:：rebase（）使用错误的totalsupply计算initsupply

当出现第一个rebase异常时，项目方已发现问题并决定提出修复系统的建议，希望将该建议放入执行队列并通过投票方式执行。当收到足够数量的投票时，治理契约允许任何人通过调用governoralpha:：queue（）函数对问题进行排队。但是，由于治理契约代码逻辑的实现，无论是在第二次回基之前还是之后，救援行动都无法正确执行。

为什么说项目方的准备工作完成得太晚了？

让我们看看下图中的governoralpha:：queue（）代码，我们注意到在queueorrevert函数之前的第224行中，设置变量ETA=current timestamp+延时锁定（12.5小时），这使得有效时间必须是加入队列后的12.5小时，而第二次回基时间与第一次回基时间相差12小时，这意味着救援行动需要提前到第一次回基至少半小时才能成功，否则永远无法执行。

图5调控器alpha:：queue（）函数设置eta（有效时间）

为什么已经采取的救援行动毫无帮助？

当触发contract governoralpha:：execute（）时，首先执行state函数以获取当前的建议状态。

图6调控器alpha:：execute（）检测建议状态

在下面state（）函数的第330行中，如果投票提案Lt；=againstvotes（），建议状态设置为失败。

图7 governoralpha:：state（）执行返回失败的错误

从规范中可以看出，项目方设计系统时，票数必须大于initsupply总金额的4%，才能使方案合法，如下图所示。但是，在第二次重设基之后，initsupply已达到最大值。这就导致了这样一个事实：票数（for votes）永远不能gt；=quorumVoices（），它总是返回违例的。

图8 governoralpha:：quorumvotes（）返回错误异常值

除了提案状态异常的问题外，如图9和图10所示，在第二次转基之后，由于governoralpha:：propose（）检查的票数必须小于proposalthreshold（initsupply的1%），因此不能再提出新的提案，更不用说投票赞成实施了。

图9 governoralpha:：propose（）检测投票数是否大于initsupply的1%

3图10 governoralpha:：proposalthreshold（）返回1%initsupply

总结

YAM漏洞事件最终导致75万ycrv在治理合同中永久锁定，并出现快速下滑、短时间内无法恢复的局面。我不知道有多少人被高价埋没了。它的疯狂程度已经成为当前非流动性挖矿最真实的写照。残酷的魔法程度是多少？如果项目方在部署契约之前测试了一次rebase过程，那么它将能够发现漏洞的存在。由此可见，安全审计对DeFi项目的重要性。

总而言之，peckshield想告诫你，在区块链的世界里，你必须敬畏每一行合同代码，因为任何细微的疏漏都可能造成无法挽回的局面。毕竟，代码是由人编写的，漏洞很难完全避免。因此，在合同部署上线前，项目方有必要做好测试和第三方安全审计工作。这将帮助他们尽早发现并检查合同代码的潜在安全漏洞。漏洞一旦出现，再补也不晚。