皇冠管理端登3手机(www.9cx.net):走过最长的路竟是自己的套路:Alchemix事宜剖析

欧博电脑版

欢迎进入欧博电脑版(www.aLLbetgame.us),欧博官网是欧博集团的官方网站。欧博官网开放Allbet注册、Allbe代理、Allbet电脑客户端、Allbet手机版下载等业务。

,

By:yudan@慢雾平安团队

据慢雾区新闻,2021 年 06 月 16 日,以太坊 DeFi 项目 Alchemix 的 alETH 合约疑似泛起平安问题。17 日,Alchemix 宣布了事故剖析讲述,慢雾平安团队迅速介入剖析,并在官方剖析讲述的基础上梳理了本次事宜的整个脉络和焦点要害点,供人人参考。

太长不看系列

本次剖析文章很长。这里先说结论,利便人人有个也许的明白。本次事故的主要缘故原由在于 Alchemix 通过 tran *** uter 添加了 3次 vault,导致收益信息纪录在了一个错误的元素上,而在挪用 tran *** uter 的 harvest 函数时也没有传入准确的 index 值,导致通过错误的元素获取了错误的收益,将错误的 4300 ETH 的收益发送到 adapter 合约,辅助用户送还了 alETH 的贷款,造成收益增多的问题,导致了悲剧。

焦点剖析——Round 1

凭证官方宣布的事故剖析讲述,本次事故的缘故原由是官方的 alETH 的部署剧本意外地确立了分外的 vaults,导致 Alchemix 使用了 vaults 数组中错误的索引并盘算出了错误的奖励,导致 tran *** uter 把所有的奖励用于送还了用户的所有欠债。我知道单单是这句简短的剖析让人有点云里雾里,摸不着头脑,以是我们只能把目的放在官方给出的生意中,看看能不能找到真相。

凭证官方给出的生意,通过 ethtx.info 剖析工具举行剖析,我们不难发现,这笔生意挪用了 AlchemistEth 合约的 harvest 函数,而且传入了 _vaultId=0 这个参数,最后返回了

"4308144937764982868765" 和 "4308144937764982866415" 这两个值。

为了加倍领会 harvest 函数的作用,我们需要对整个函数举行剖析:

不难发现,harvest 函数实在包罗两个主要的操作,划分是收获奖励和将奖励分发给 tran *** uter 合约。其中 vault 是一个 library 库合约,其中的 harvest 逻辑实现如下:

通过代码剖析不难发现,vault 库合约的 harvest 函数实在是检查了外部的 adapter 的总的资金量,然后凭证 adapter 中的资金量减去用户的充值数目盘算出收益的部门。

这里我们可以将这个 adapter 明白为一个战略池,用于治理用户的资金和收益。然后我们回到用户一最先的 AlchemistEth 合约中的 harvest 函数,发现返回的 "4308144937764982868765" 和 

"4308144937764982866415" 这两个值实在对应的就是 vault 库合约的 harvest 函数盘算出的需要提现的代币数目和从 adapter (战略池) 中取回的代币的数目。由于这个 adapter 对应的收益代币是 WETH,精度为 18 位,那么 "4308144937764982866415" 这个数值换算过来就是 "4308.144937764982866415" 个 WETH。

也就是说,本次 harvest 操作,收益了跨越 4300 个 ETH 的收益,然后这个收益在下一步中通过 _distributeToTran *** uter 函数给到了 tran *** uter 合约举行分发,我们看下分发历程中的逻辑是怎样的:

_distributeToTran *** uter 函数的逻辑只有简朴的 3 行,我们主要关注的是最后的外部挪用 —— lowerHashMinted 函数。该函数所对应的 xtoken 在这里指的是 alETH 自己。由于 alETH 自己是用户通过借贷借出来的,以是 lowerHashMinted 这里的操作实在是使用 harvest 的收益将 alETH 总的贷出数目削减了,从而削减了每个用户的贷款。总结来说就是用 harvest 4300 ETH 的收益送还用户的 alETH 贷款。

皇冠管理端登3手机

皇冠管理端登3手机(www.9cx.net)实时更新发布最新最快最有效的皇冠管理端登3手机网址,包括新2登3手机网址,新2登3备用网址,皇冠登3最新网址,新2足球登3网址,新2网址大全。

打个小总结

这里先总结下这个流程,就是 AlchemistEth 合约通过 harvest 函数,获得了 4300 ETH 的收益,并将这个收益分发出去了,用于送还用户的 alETH 贷款,导致了我们看到的情形 —— 已经贷出 alETH 的用户在不需要还款的情形下就可以拿回他们质押的 ETH。那事实是为什么,会有这 4300 ETH 的收益呢?这多出来的 4300 ETH 的收益是怎么来的?针对这个问题,我们最先下一轮的剖析。

焦点剖析——Round 2

要领会为什么会多出来 4300 ETH,就必须领会 AlchemistEth 的资金存储历程。在 AlchemistEth 合约中,合约总的充值情形是使用 Vault library 库的 Data 结构体举行纪录的,然后通过 flushActiveVault 函数更新对应的充值数目(totalDeposit)。

然后 depositAll 函数会将充值的代币金额打到对应的 adapter(战略池) 中,那么在下一次 harvest 的时刻,通过 adapter(战略池) 获取的 totalValue,就会是用户的本金加上战略池的收益。为了盘算收益历程中的本金部门,我们对官方给出的生意举行 debug,发现本金仅为 9000 ETH,从 adapter 获取的收益加上本金共有 13000 ETH,也就是说 9000 ETH 的本金发生了 4300 ETH 的收益。

然则,根据上面剖析的逻辑,用户的本金是不会发生那么大的收益的,问题一定是出在了 adapter 获取的 totalValue。也就是说 adapter 不止只有 AlchemistEth 充值代币,还存在其他的收益渠道。为了验证我们的想法,慢雾平安团队剖析了 adapter 的所有代币收入,果真发现了一笔异常的转入行为,而且金额也能恰好对上多出的 4300 ETH 的收益。也就是说,问题就在这里了。

通过查看生意数据,发现这是一笔挪用 harvest 操作的生意,挪用的合约是 tran *** uter 合约:

也就是说,是这个 harvest 函数出问题了,harvest 函数的逻辑如下:

同样是挪用了 vault 的 harvest 函数,熟悉的配方,熟悉的味道。我们再次举行 debug,发现一个惊人的事实 —— 在举行收益的时刻,vault 的 totalDeposit 竟然为 0,导致 4300 ETH 的收益直接分发给了 adapter,导致了 adapter 获取的 totalValue 错误了,多了 4300 个 ETH,缘故原由就是在这里。

到了这里,我们已经很靠近真相了,剩下要解决的就是为什么 totalDeposit 会为 0?我们查询了tran *** uter 合约中能改变 totalDeposit 的地方,发现只有 _plantOrRecallExcessFunds 函数可以改变这个值,而这个函数上层挪用的又是 distribute 函数。而 tran *** uter 合约的 distribute 函数是 AlchemistEth 合约在收益的时刻举行挪用的。也就是说自己的流程应该是:

1. AlchemistEth 合约挪用 harvest 举行收益

2. AlchemistEth 合约挪用 tran *** uter 合约的 distribute 函数纪录收益情形,并把收益部门给 adapter

3. adapter 收到了 tran *** uter 的收益,凭证收益送还用户的 alETH 的贷款

然则问题就出在了 _plantOrRecallExcessFunds 函数中。由于在纪录充值信息的时刻,用的是 _vaults.last() 来获取最新的 vault,以是实在充值信息叠加在了最后一个元素上。然则项目方挪用了三次 setActiveVault 函数,以是实在充值信息是叠加到了 _vaults 数组的 3 号元素,也就是 index 为 2 的 vault 元素上。然则在 tran *** uter 合约在 harvest 的时刻传入的 _vaultId 却是 0,0 号元素是没有任何充值纪录的,以是 tran *** uter 合约就误将所有的收益都给了 adapter 了。导致了悲剧的发生。

总结

到这里,整个事情已经变得很清晰了,Alchemix 项目方由于某种缘故原由,通过 tran *** uter 添加了 3 次 vault,导致收益信息纪录在了一个错误的元素上,而在挪用 tran *** uter 的 harvest 函数时也没有传入准确的 index 值,导致通过错误的元素获取了错误的收益,错误收益被发送到 adapter 合约,造成收益增多,导致了悲剧。

添加回复:

◎欢迎参与讨论,请在这里发表您的看法、交流您的观点。