猫币

全文： 前段时间智能化合同恶性事件多发，从BEC到SMT，从HXG到FXE等，前段时间这两个智能化合同出的难题，多半是虽然有理数外溢引致的。呢如果在大部份的地方性都加之巡查，保证他们的标识符没难题呢？

前段时间尼布寺（SECBIT）生物医学辨认出两个ERC20智能化合同的approve瑕疵，该瑕疵将引致工程项目token在去虚拟化证券买卖所中难以恒定买卖。

前段时间智能化合同恶性事件多发，从BEC到SMT，从HXG到FXE等，前段时间这两个智能化合同出的难题，多半是虽然有理数外溢引致的。我们对有理数外溢呢都沃苏什卡了？他们呢如果在大部份的地方性都加之巡查，保证他们的标识符没难题呢？

他们注意到在上面这段标识符：

function approve(address _spender, uint _amount) returns (bool success) {

// approval amount cannot exceed the balance

require ( balances[msg.sender] >= _amount );

// update allowed amount

allowed[msg.sender][_spender] = _amount;

// log event

Approval(msg.sender, _spender, _amount);

return true;

}

这是ERC20接口中的approve函数的两个实现，他们注意到，在函数最开始的地方性有这样一行：

require ( balances[msg.sender] >= _amount );

approve的时候对当前余额进行检测，要求授权的_amount小于或等于当前余额。这样写实际上是没什么意义的，因为在后续操作能够根据恒定逻辑产生和这个条件相违背的状态。比如approve给某个地址后，token的大部份者又把token都转走。

这样写除了没意义外，其实还会引起比较大的使用难题。

前段时间他们在和去虚拟化证券买卖所DDEX合作审计该平台上的ERC20 token的智能化合同，辨认出两个比较严重的难题。目前的去虚拟化证券买卖所，很多都用到了ZRX protocol或者类似的协议。在ZRX的智能化合同里，进行转账的时候，通过Exchange合同的fillOrder函数完成转账。

bitcoin官方客户端

去虚拟化的证券买卖所需要准备两个中间账户，由这个中间账户发起的买卖，中间账户需要向该合同approve足够的allowance。而ZRX提供的合同并不提供approve过程，需要证券买卖所提供的中间账户提前准备好这个approve工作。区块链优缺点 https://www.110btc.com/qukuai

打击比特币挖矿

然而如果这个中间账户并没提前拥有买卖的token，虽然上面那条标识符的检查条件，引致难以提前完成approve，这样的难题给去虚拟化证券买卖所带来了较大的困扰。

在各种去虚拟化证券买卖所中，甚至虚拟化的证券买卖所中类似的情况并不少见。因此他们强烈推荐我们在写ERC20智能化合同时不要这么写，不要画蛇添足的加之这样两个判断。

如果万一已经发布的ERC20 token合同已经这么写了，他们有什么办法吗？

当证券买卖所遇到这种情况的时候，只能由工程项目方向证券买卖所的中间账户打一笔足够大的token，才能保证能够approve成功，而且限制以后发生的买卖额不能超过此数量的限制。

他们使用SECBIT的两个内部工具，对提供源码的22681个ERC20 Token智能化合同进行了一次扫描，辨认出了21个智能化合同存在此难题，其中有3个合同的买卖量较大。涉及的Token包括：

IDH

GZR

ADE

SAINT

BULB

ZZZ

KTM

ETI-P

ZORRO01

ZORRO02

现在去虚拟化证券买卖所将越来越多，为了不影响工程项目token未来的买卖的流动性，他们建议各token仔细检查合同是否存在该难题，如果可能，尽早进行修正。

加密货币