图一：The deposit() function in blacksmith.sol
通过调用deposit函数，攻击者将得到的BPT流动性证明质押到cover protocol中。 首先通过图一中118行将当前流动性证明代币的pool数据读取到memory，然后调用121行代码对当前pool的数据进行更新。
图二：blacksmith.sol中的updatePool()函数
如图二第75行所示，在updatePool()函数中修改的当前流动性证明代币的pool数据是一份存储在storage中的数据，与在deposit()中存储在memory中当前流动性证明代币的pool数据是两份数据。 在图二第84行lpTotal的值代表当前合同中总共存入的流动性证明代币数目，由于该变量数值较小，因此通过84行公式pool.accRewardsPerToken的数值将会增大，更新过的accRewardsPerToken值存储在storage中。
图三：blacksmith.sol中的_claimCoverRewards()函数
接下来如图三中318行所示，deposit()通过调用_claimCoverRewards()函数，向函数调用者(msg.sender)铸造一定数目的cover代币。 铸造cover代币的数目与pool.accRewardsPerToken， CAL_MULTIPLIER以及miner.rewardWriteoff三个变量相关。 请注意这里pool.accRewardsPerToken的数值是使用了存放在memory中的pool数据，并非使用图二中update()函数更新之后的数值。 同时，通过图1中deposit函数得知，miner.rewardWriteoff的数值更新是在_claimCoverRewards()函数执行完成之后发生。 因此原本设计上应使用更新过的miner.rewardWriteoff的数值计算需要铸造cover代币的数目，这里错误的使用了未更新过的miner.rewardWriteoff的数据，导致实际铸造cover代币数目比应铸造代币数目增多，最终导致了代币增发。 质押成功之后，攻击者通过调用blacksmith.sol智能合约中的withdraw()函数,将质押的BPT取回，同时取得额外铸造的cover代币，完成攻击。 通过对比执行deposit()函数和执行withdraw()函数之后的代币结余表，我们可以发现通过这一组deposit和withdraw函数调用之后，攻击者可以获得约704个COVER代币。 deposit()之后：郑重声明：本文版权归天网查所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。
