ERC20 智能合约开发常见问题

最近帮朋友做了一些合约审查的工作，原以为有了 OpenZeppelin合约库 作为参考，90%的合约应该一遍过，但事实并非如此，一遍过的合约接近于0。本文我把自己看到的简单通用类问题列举一下，希望看到的朋友可以避免类似问题的出现。还有一些相对复杂的问题，每一个问题都可以单独成篇，以后会找时间单独论述。

0x01 把全部代币给合约创建者

看看下面的代码：

   constructor() public {
        totalSupply_ = INITIAL_SUPPLY;
        balances[msg.sender] = totalSupply_;
        emit Transfer(address(0), msg.sender, totalSupply_);
    }

代码中把全部代币给合约创建者，如果合约创建者就真的是代币和合约拥有者也还说的过去。事实上我审查的这些合约，合约创建都是相关技术人员做的，并且会把合约创建者设为合约 owner，具有一些超级权限。在这种情况下，这种写法就有问题了：

1. 如果合约发布后仍然让合约创建者持有所有的代币资产，并进行以后的空投，挖矿等操作，就存在着巨大的运维风险。
2. 如果不让合约创建者持有代币，就要发起转账操作，进行代币转移，与其这样，为啥不开始时就把合约管理人与代币持有人分开呢。

0x02 忘记小数点

看看下面的代码，你认为发行量是多少：

uint256 public decimals = 4;
uint256 INITIAL_SUPPLY = 1000000000;

本意是发行 10 亿枚，实际只发行了 10 万枚。

0x03 代币锁定问题

看看下面的代码，你认为不让账户进行转账操作就真的把特定账户的代币锁定了么？

  function transfer(address _to, uint256 _value) public returns (bool)
    {
        require(!frozenAccount[msg.sender]);
        return super.transfer(_to, _value);
    }
    function transferFrom(address _from, address _to, uint256 _value) public returns (bool)
    {
        require(!frozenAccount[msg.sender]);
        return super.transferFrom(_from, _to, _value);
    }

0x04 重名问题

没错，ERC20 从技术上来讲是允许重名的，合约以合约地址来区分。但是当你看到钱包里把自己寄予厚望的代币 NBT显示为NBT2是啥心情？本来是想发一个牛逼Token，结果变成了牛逼Token二货。建议起名字时先上 etherscan 查一下，能不重名是最好。

0x05 对挖矿的误解

OpenZeppelin合约库 提供了 MintableToken 来支持挖矿行为，有朋友把挖矿只当作管理员转币了，没注意到挖矿是增加发行总量的。本来么，挖矿的本质就是代币发行。 代码献上：

 function mint(address _to, uint256 _amount) onlyOwner canMint public
    returns (bool)
  {
    totalSupply_ = totalSupply_.add(_amount);
    balances[_to] = balances[_to].add(_amount);
    emit Mint(_to, _amount);
    emit Transfer(address(0), _to, _amount);
    return true;
  }

总结

如果你对自己的区块链项目是认真的，请一定要认真对待自己的代币合约，在主网发布之前，多多测试和找人做代码审查还是很有必要的。并且想好万一合约有了漏洞要怎么办，要不要继承 OpenZeppelin合约库 里的 Destructible 合约等等这些问题多考虑一下总没坏处。