符合ERC20标准的Token合约中，都有一个approve函数，其功能有些类似于开支票。但是近期有人认为，approve函数有“漏洞”，其理由如下：
Alice给Bob 开了1000面值的支票，Alice执行approve(Bob, 1000)；过了一段时间，由于某些原因，Alice觉得有点多，想修改为 600，Alice执行approve(Bob, 600)；在这里就可能出现问题了，因为Bob刚好在Alice执行修改操作的同时，试图取走1000个Token，Bob执行transferFrom(Alice, 1000)；假如Bob发起的操作比 Alice发起的操作优先被打包进区块（比如给出高一点的GasPrice），就会出现这样的操作序列：
approve(Bob, 1000)；
transferFrom(Alice, 1000);
approve(Bob, 600);
transferFrom(Alice, 600);
Bob可能先取走了1000个Token，然后Bob可能又接着取走了600个Token，最终Bob可能取走了1600个Token。然而Alice的本意只是修改approve的额度为600。于是，有人开始认为这是approve函数的严重“漏洞”。但是严格来说，这个不能算是漏洞，这只能算是一个值得注意的操作事项。因为在区块链系统中进行开支票或转账之前，用户都要清楚的认识到【泼出去的水是收不回来的】，比如Alice给Bob转账，但是地址却填错了，最终转到了一个黑洞地址，这个能说是以太坊的漏洞吗？
区块链在易用性方面确实是需要提升的，否则就难以得到普及。但是理论上说，“易用性不够”和“漏洞”完全是两回事。软件行业有一句流行的话：【It is a feature, not a bug.】，工程师分析一个系统时，应该具备区分什么是feature、什么是bug的能力。
解决黑洞地址的问题，可以引入支持地址校验功能的钱包；
解决approve修改额度问题，则可以采取如下安全序列进行操作，以尽可能减少损失：
Alice执行approve(Bob, 1000)；//这已经意味着Bob能够拿走1000个Token了，Alice需三思而后行。
Bob可能会执行transferFrom(Alice, 1000)；//这时候，Bob最多可以拿走1000个Token。
若Bob已经取走了1000个Token，则就没有必要继续修改支票额度了。下面的步骤也不需要执行了。若没有，则继续下面的操作：
Alice执行transfer(Alice的另一个账户, Alice当前账户的所有剩余额度)；//Alice把钱先全部转移到自己的另一个账户
Alice执行approve(Bob, 0）；
完成支票额度清零后，Alice再把另一个账户里的Token转移到这个账户下；然后
Alice执行 approve(Bob, 600）；
这样就完成了给Bob的支票额度修改。在这个过程中，Bob最多能取走1000个Token，而不是1600个Token。
网友评论