在 OpenZeppelin 的 ERC20 的 transferFrom 实现中，为什么在检查提款机限额之前调用了 _transfer()答案

【问题标题】：In OpenZeppelin's implementation of ERC20's transferFrom, why is _transfer() called before withdrawer allowance is checked在 OpenZeppelin 的 ERC20 的 transferFrom 实现中，为什么在检查提款机限额之前调用了 _transfer()
【发布时间】：2021-06-03 15:36:53
【问题描述】：

这取自 OpenZeppelin 的 ERC20 transferFrom 实现：

    function transferFrom(address sender, address recipient, uint256 amount) public virtual override returns (bool) {
        _transfer(sender, recipient, amount);

        uint256 currentAllowance = _allowances[sender][_msgSender()];
        require(currentAllowance >= amount, "ERC20: transfer amount exceeds allowance");
        _approve(sender, _msgSender(), currentAllowance - amount);

        return true;
    }

在检查提款人 (msg.sender) 限额之前调用 _transfer 是否有原因？

如果先检查余量require，transferFrom 是否仍能正常工作？

【问题讨论】：

标签： ethereum solidity openzeppelin

【解决方案1】：

我在 OpenZeppelin GitHub Issues 上发现了关于同一主题的讨论，代码作者确认该顺序与 ERC-20 的上下文无关。

在 ERC20 的情况下，顺序无关紧要，因为 _transfer 和 _approve 是独立的，从不调用任何其他合约：它们是原子执行的。

另外，他指出，当有人想要覆盖函数时，保持顺序稳定很重要。

但是，这对于打算用自己的实现覆盖 _transfer 或 _approve 的用户非常重要：我们应该清楚这些事情发生的顺序。

来源：https://github.com/OpenZeppelin/openzeppelin-contracts/issues/2030#issuecomment-568487500

因此，假设您没有在覆盖的 _transfer() 和 _approve() 内部函数中使用自定义逻辑，那么如果您切换顺序，transferFrom() 仍然可以正常工作。

【讨论】：

感谢您的确认。由于它无关紧要，奇怪的是他们没有选择语义上最有意义的排序。然而，ERC1155 的实现遵循这种模式，这很好：github.com/OpenZeppelin/openzeppelin-contracts/blob/master/…

【解决方案2】：

我实际上是在寻找同样的东西，然后我发现了这个讨论 [https://forum.openzeppelin.com/t/in-erc20-tranferfrom-why-transfer-before-checking-allowance/5312/3] 它提供了更多细节并阐明了其背后的原因。

【讨论】：