编者按：本文来自DOSNetwork，作者：nrek，Odaily星球日报经授权发布。熟悉以太坊代币经济和ICO的同学一定对ERC20这个词不陌生，市面上几乎绝大部分基于以太坊智能合约的项目都宣称自己的代币是ERC20代币，那么究竟什么是ERC20，为什么1个以太坊地址能够作为所有ERC20代币的钱包地址呢？ERC20(EthereumRequestforComment20)是社区在2015年底提出的一项以太坊改进计划(EIP)，旨在给智能合约的实现提供一个标准，让智能合约能够像那些有自己区块链的原生数字货币(比如比特币、以太币)一样具有发送、转账、查询余额等等类似功能。凡是实现了这套标准的智能合约都可称为ERC20代币。发行基于ERC20标准的代币变得很简单，基本不超过10分钟，50行代码。ERC20让代币间变得互相兼容，也增强了代币的交易量和流动性。正是得益于ERC20标准的出现，基于以太坊的去中心化应用开始百花齐放。言归正传，ERC20标准其实很简单，一共定义了以下5个函数接口和2个状态接口(event)：下面将结合etherscan.io和EtherDelta上的具体例子(EETHtoken,bitcointalk.org上一个恶作剧空投币)来更直观的解释:totalSupply和balanceOf(address)
首先这两个接口很简单，分别是该币的发行总量和给定地址的余额，注意上图中decimals(8)代表它支持的精度到小数点后8位，所以该地址实际余额是317047792083/10^8=3170.4;同时注意上图中allowance一项的查询结果为0，将会在下文进行比较和说明。transfer(address_to,uint256_value)
这个也比较简单，表示把当前调用该函数用户的_value数量的代币转移给_to这个用户。当然具体实现时需要进行边界条件检查以防止溢出和其它安全问题，现在一般都选择继承自OpenZepplin的SafeMath.sol和StandardToken.sol库。transferFrom,approve,allowance
这三个接口比较有意思，transferFrom(address_from,address_to,uint256_value)接口并不冗余，它是专门给第三方智能合约设计的，表示允许该函数的调用者msg.sender(通常是另一个已授权的智能合约)从_from账户转移_value个代币到_to账户，同时也会触发Transfer()这个事件在区块链上留下log以便客户端监听。而在调用transferFrom()之前需要让用户先调用approve(address_spender,uint256_value)函数，表示用户授权_spender(即调用transferFrom()的第三方智能合约)从你的账户最多转移_value个代币。而allowance(address_owner,address_spender)返回_owner仍然允许_spender转移的代币个数。如果你在EtherDelta进行过交易就会很容易理解这三个函数的意义：在EtherDelta交易的第一步是需要向EtherDelta合约“充值”：如果你有所留意，当点击”Deposit”后Metamask会让你确认两次：第一次确认的地址0xf152Fc...99c3是EETHcontract的地址，这实际上就是调用了approve()函数，允许EtherDalta合约从该账户转走最多3170.478个代币。我们先不点击第二个确认，这时再来观察一下etherscan.io有什么变化：可以看到此时余额不变，但是授权EtherDelta挪用的额度变了。这时再点击第二个确认：注意第二次确认的地址0x8d12A1...6819是EtherDelta合约的地址，此时调用了transferFrom()函数，之后再观察下etherscan.io和EtherDelta的变化如下：在etherscan看到此时用户账户余额已经清零了，而且允许EtherDelta再挪用的额度也清零，同时EtherDelta账户显示了应该有的3170.478个EETH。安全问题
值得一提的是ERC20的approve()函数存在安全隐患(front-runningattack)，并且该问题至今没有完全解决。可行的攻击场景如下：Alice授权Bob可以挪用100个她的TokenA.(tx1)tx1被矿工确认后，Alice想把授权上限改为50个TokenA.(tx2)Bob探测到tx1已经确认，同时tx2还在pending状态，他给高额gas并调用transferFrom()函数直接在tx2被确认前从Alice账户转移了100个TokenA.(tx3)tx3先于tx2被确认，之后不久tx2也被确认，在Alice还没反应过来之前Bob立马再次调用transferFrom()又从Alice那转移了50个TokenA。这样Bob一共从Alice那转移了150个TokenA，虽然Alice的本意是只希望授权50个给Bob挪用。有兴趣的可以参见https://github.com/ethereum/EIPs/issues/20#issuecomment-263524729中具体讨论。虽然社区有人提议如果需要重新设置允许值的话，首先在客户端主动重置允许值为0，等待这笔交易被确认，再检查此期间是否发生过代币转移，最后再设置新的允许值。但是首先这是取决于客户端的实现行为，并不在ERC20标准里；其次哪怕客户端实现了这个方案，上文所述的front-running攻击仍然存在，只是让人们有意识的去多一步检测并发现可能的问题，并没有从根本上解决问题。不过也不用太担心，如今实现了ERC20标准的合约千千万，大家都有这问题。而且正如EIPissue里一个评论所提到的，一般用户调用approve(_spender,_value)的场景多是在信任_spender的前提下才会这么调用，而_spender多为交易所的智能合约，一般不会故意想要黑用户的币。然而这个历史遗留问题估计要等到下一版标准出来才有望彻底解决了。
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。