从技术角度解析：为什么通缩机制的代币易受攻击

概述

在区块链上具有通缩机制的代币最近经常受到攻击。本文将讨论并分析代币令牌受到攻击的原因，并给出相应的防御方案。

在代币中实现通缩机制通常有两种方式，一种是燃烧机制，另一种是反射机制。下面我们将分析这两种实现方式可能存在的问题。

燃烧机制

通常，具有燃烧机制的代币将在其 _transfer 函数中实现燃烧的逻辑。有时候会存在发送者承担手续费的情况。在这种情况下，接收方收到的代币数量不会发生变化，但发送方需要支付更多代币，因为其需要承担手续费。下面是一个简单的例子：

function _transfer(address sender, address recipient, uint256 amount) internal virtual returns (bool) {

require(_balances[sender] >= amount, "ERC20: transfer amount exceeds balance");

require(sender != address(0), "ERC20: transfer from the zero address");

require(recipient != address(0), "ERC20: transfer to the zero address");

burnFee = amount * burnFeeRate;

_balances[sender] -= amount;

_burn(sender, burnFee);

_balances[recipient] += amount;

}

然后我们讨论这种情况下可能存在的风险。

如果单看代币合约，我们会发现这种写法其实没有什么问题，但是区块链中有很多复杂的情况，需要我们考虑很多方面。

通常，为了让代币有价格，项目方会在 Uniswap、Pancakeswap 等去中心化交易所为代币添加流动性。

其中，在 Uniswap 中，有一个函数 skim，它会将流动性池中两种代币的余额和储备金的差值转移给调用方，以平衡余额和储备金：

function skim(address to) external lock {

address _token0 = token0; // gas savings

address _token1 = token1; // gas savings

_safeTransfer(_token0, to, IERC20(_token0).balanceOf(address(this)).sub(reserve0));

_safeTransfer(_token1, to, IERC20(_token1).balanceOf(address(this)).sub(reserve1));

}

此时发送方变成了流动性池，当调用 _transfer 时，流动性池中的代币将被部分销毁，导致代币价格部分上涨。

攻击者利用此特性将代币直接转入流动性池中，然后调用 skim 函数转出，然后多次重复此操作，导致流动性池中大量代币被燃烧，价格也随之飙升，最后卖出代币获利。

一个真实的攻击案例，winner doge (WDOGE) :

function _transfer(address sender, address recipient, uint256 amount) internal virtual returns (bool) {

require(_balances[sender].amount >= amount, "ERC20: transfer amount exceeds balance");

require(sender != address(0), "ERC20: transfer from the zero address");

require(recipient != address(0), "ERC20: transfer to the zero address");

?

if(block.timestamp >= openingTime && block.timestamp <= closingTime)

{

_balances[sender].amount -= amount;

_balances[recipient].amount += amount;

emit Transfer(sender, recipient, amount);

}

else

{

uint256 onePercent = findOnePercent(amount);

uint256 tokensToBurn = onePercent *4;

uint256 tokensToRedistribute = onePercent * 4;

uint256 toFeeWallet = onePercent*1;

uint256 todev = onePercent* 1;

uint256 tokensToTransfer = amount - tokensToBurn - tokensToRedistribute - toFeeWallet-todev;

?

_balances[sender].amount -= amount;

_balances[recipient].amount += tokensToTransfer;

_balances[feeWallet].amount += toFeeWallet;

_balances[dev].amount += todev;

if (!_balances[recipient].exists){

_balanceOwners.push(recipient);

_balances[recipient].exists = true;

}

?

redistribute(sender, tokensToRedistribute);

_burn(sender, tokensToBurn);

emit Transfer(sender, recipient, tokensToTransfer);

}

return true;

}

在 WDOGE 合约的_transfer 函数中，当 block.timestamp > closingTime 时，进入 else 循环。在代码第 21 行中，转账金额从发送方的余额中扣除，在代码第 31 行中，发送方又被燃烧了 tokensToBurn 数量的代币。攻击者利用这种手续费的机制，通过上述的攻击方式窃取流动性池中的所有价值代币 (WBNB)。

反射机制

在反射机制中，用户每次交易都会收取手续费，用于奖励持有代币的用户，但不会触发转账，只是单纯修改一个系数。

在这个机制中，用户有两种类型的代币数量，tAmount 和 rAmount。 tAmount 为实际代币数量，rAmount 为反映后的代币数量，比率为 tTotal / rTotal，一般的代码实现如下：

function balanceOf(address account) public view override returns (uint256) {

if (_isExcluded[account]) return _tOwned[account];

return tokenFromReflection(_rOwned[account]);

}

function tokenFromReflection(uint256 rAmount) public view returns(uint256) {

require(rAmount <= _rTotal, "Amount must be less than total reflections");

uint256 currentRate = _getRate();

return rAmount.div(currentRate);

}

function _getRate() private view returns(uint256) {

(uint256 rSupply, uint256 tSupply) = _getCurrentSupply();

return rSupply.div(tSupply);

}

反射机制的代币中一般有一个叫做 deliver 的函数，会销毁调用者的代币，降低 rTotal 的值，所以比率会增加，其他用户反射后的代币数量也会增加：

function deliver(uint256 tAmount) public {

address sender = _msgSender();

require(!_isExcluded[sender], "Excluded addresses cannot call this function");

(uint256 rAmount,,,,,) = _getValues(tAmount);

_rOwned[sender] = _rOwned[sender].sub(rAmount);

_rTotal = _rTotal.sub(rAmount);

_tFeeTotal = _tFeeTotal.add(tAmount);

}

攻击者注意到这个函数，并用它来攻击相应的 Uniswap 的流动性池。

那他该如何进行利用呢？同样从 Uniswap 的 skim 函数开始：

function skim(address to) external lock {

address _token0 = token0; // gas savings

address _token1 = token1; // gas savings

_safeTransfer(_token0, to, IERC20(_token0).balanceOf(address(this)).sub(reserve0));

_safeTransfer(_token1, to, IERC20(_token1).balanceOf(address(this)).sub(reserve1));

}

Uniswap 中 reserve 是储备金，与 token.balanceOf(address(this)) 不同。

攻击者先调用 deliver 函数销毁自己的代币，导致 rTotal 的值减少，比率随之增加，所以反射后的代币的值也会增加，token.balanceOf(address(this)) 也会相应变大，与 reserve 的值出现了差距。

因此，攻击者可以通过调用 skim 函数转出数量为两者之间差值的代币从而进行获利。

Attacker: token.deliver

rtotal: decrease

rate: increase

tokenFromReflection: increase

balanceOf: increase -> token.balanceOf(address(this)) > reserve

Attacker: pair.skim

token.balanceOf(address(this)) > reserve

token.transfer

一个真实的攻击案例，BEVO NFT Art Token (BEVO)：

而当代币合约中存在 burn 函数时，存在了另外一种相似的攻击手法：

function burn(uint256 _value) public{

_burn(msg.sender, _value);

}

?

function _burn(address _who, uint256 _value) internal {

require(_value <= _rOwned[_who]);

_rOwned[_who] = _rOwned[_who].sub(_value);

_tTotal = _tTotal.sub(_value);

emit Transfer(_who, address(0), _value);

}

当用户调用 burn 函数时，自己的代币会被销毁，同时 tTotal 的值会减少，所以比率会降低，对应的反射后的代币数量也会减少，所以在此时流动性池的代币的数量也会减少，从而代币的价格会上涨。

攻击者利用这个特性通过多次调用 burn 函数来减少 tTotal 的值，然后调用流动性池的 sync 函数同步 reserve 和 balances。最后，流动性池中的代币大幅减少，价格飙升。然后攻击者出售代币以获取利润。

Attacker: token.burn

tTotal: decrease

rate: decrease

tokenFromReflection: decrease

balanceOf: decrease

Attacker: pair.sync

token.balanceOf(address(this)) > reserve

token.transfer

一个真实的攻击案例，Sheep Token (SHEEP):