当前位置:首页区块链Peckshield:yam自救在技术拆卸中失败,75万YCLV在整个过程中被锁定

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

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

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

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

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

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

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

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

如何拯救我们的YAM红薯?

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

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

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

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

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

有两个原因

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

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

为什么?其次,技术干货:

技术概述

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

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

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

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

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

如下图所示:

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

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

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

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

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

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

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

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

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

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

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

下面我们将对这一事件进行详细分析:(项目方GitHub地址)

详细过程分析

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

Peckshield:yam自救在技术拆卸中失败,75万YCLV在整个过程中被锁定3图1第一次返基资产变动

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

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

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

Peckshield:yam自救在技术拆卸中失败,75万YCLV在整个过程中被锁定4图2 yamtoken::rebase()获取异常大的totalsupp值

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

Peckshield:yam自救在技术拆卸中失败,75万YCLV在整个过程中被锁定5图3第二次返利资产变动

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

Peckshield:yam自救在技术拆卸中失败,75万YCLV在整个过程中被锁定6图4 yamrebase::rebase()使用错误的totalsupp计算initsupp

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

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

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

Peckshield:yam自救在技术拆卸中失败,75万YCLV在整个过程中被锁定7图5调控器alpha::queue()函数设置eta(有效时间)

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

当触发contract governoralpha::execute()时,首先执行state函数以获取当前的建议状态。

Peckshield:yam自救在技术拆卸中失败,75万YCLV在整个过程中被锁定8图6调控器alpha::execute()检测建议状态

在下面state()函数的第330行中,如果投票提案Lt;=againstvotes(),建议状态设置为失败。

Peckshield:yam自救在技术拆卸中失败,75万YCLV在整个过程中被锁定9图7 governoralpha::state()执行返回失败的错误

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

图8 governoralpha::quorumvotes()返回错误异常值

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

Peckshield:yam自救在技术拆卸中失败,75万YCLV在整个过程中被锁定10图9 governoralpha::propose()检测投票数是否大于initsupp的1%

Peckshield:yam自救在技术拆卸中失败,75万YCLV在整个过程中被锁定113图10 governoralpha::proposalthreshold()返回1%initsupp

总结

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

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

温馨提示:

文章标题:Peckshield:yam自救在技术拆卸中失败,75万YCLV在整个过程中被锁定

文章链接:https://www.btchangqing.cn/94913.html

更新时间:2020年08月31日

本站大部分内容均收集于网络,若内容若侵犯到您的权益,请联系我们,我们将第一时间处理。

区块链

顾彦西:区块链为虚拟银行带来差异化竞争优势

2020-8-31 11:04:11

区块链

为什么ampl永远不能成为稳定的货币?

2020-8-31 14:04:49

0 条回复 A文章作者 M管理员
    暂无讨论,说说你的看法吧
个人中心
购物车
优惠劵
今日签到
有新私信 私信列表
搜索