停止使用 Solidity 的 transfer()

译文出自：登链翻译计划 [1]

译者：翻译小组 [2]

校对：Tiny 熊 [3]

由于 EIP 1884[4] 已经在伊斯坦布尔硬分叉 [5] 实施，EIP 1884[6] 增加了 SLOAD 操作的 Gas 成本，因此_破坏了一些现有的智能合约_[7]。

这些合约将被破坏，因为它们的 fallback 函数 [8] 以前消耗的 Gas 不到 2300，而现在会消耗更多。为什么 2300 Gas 这么重要？这是合约的 fallback 函数通过 Solidity 的 transfer() 或 send() 方法 [9] 调用时可使用的 Gas 量。

刚才是简化的描述， 2300 是 Gas ”津贴“，如果是非零的以太币量转账，则 Gas ”津贴“ 明确传递给 CALL 。Solidity 的 transfer() 将 Gas 参数设置为 0，如果以太币的转账量为非零。在加上 gas”津贴“后，一共是 2300 。如果是零以太币转账，Solidity 明确地将 Gas 参数设置为 2300，因此在两种情况下都会是 2300 Gas。

自推出以来， transfer() 通常被安全界推荐，因为它有助于防范重入攻击。在 Gas 成本不会改变的假设下，这一指导意见是有意义的，但事实证明这一假设是不正确的。我们现在建议避免使用 transfer() 和 send() 。

Gas 成本可以改变

EVM 支持的每个操作码都有相关的 Gas 成本。例如， SLOAD ，从存储中读取一个字，在 EIP 1884 中 gas 由 200 修改为 800 。

Gas 费用不是随意的。它们旨在反映组成以太坊的节点上每个操作所消耗的基本资源。

来自 EIP 的动机部分 [10]。

操作的价格和资源消耗（CPU 时间、内存等）之间的不平衡有几个缺点：

可能被用于攻击，通过用低 Gas 操作填充区块，导致区块处理时间过长。

价格过低的操作码会歪曲区块 Gas 限制，有时区块完成得很快，但其他 Gas 使用量相似的区块完成得很慢。

如果操作定价更均衡，我们可以最大限度地提高块 Gas 限制，并有一个更稳定的处理时间。

SLOAD 历来价格偏低，EIP 1884 纠正了这一问题。

智能合约不能依赖 Gas 成本

如果 Gas 成本是可以变化的，那么智能合约就不能依赖于任何特定的 Gas 成本。

任何使用 transfer() 或 send() 的智能合约，都是通过转发固定数量的 Gas 来而产生 2300Gas 成本的硬性依赖。

因此建议停止在代码中使用 transfer() 和 send() ，而改用 call() 。

    contract Vulnerable {          function withdraw(uint256 amount) external {              // This forwards 2300 gas, which may not be enough if the recipient              // is a contract and gas costs change.              msg.sender.transfer(amount);          }      }      contract Fixed {          function withdraw(uint256 amount) external {              // This forwards all available gas. Be sure to check the return value!              (bool success, ) = msg.sender.call.value(amount)("");              require(success, "Transfer failed.");          }      }

除了转发固定的 2300Gas 之外，这两个合约是等价的。

关于重入攻击怎么办？

重入攻击 [11]，希望是你看到上述代码后的第一反应。引入 transfer() 和 send() 的全部原因是为了解决 The DAO[12] 上臭名昭著的黑客事件的原因。当时的想法是，2300Gas 足够触发一个日志条目，但不足以进行再重入的调用来修改存储状态。

不过请记住，Gas 成本是会变化的，这意味着无论如何这都不是解决再重入攻击的好办法。19 年初，君士坦丁堡分叉被推迟 [13]，就是因为 gas 成本的降低，导致以前重入攻击安全的代码不再安全。

如果我们不打算再使用 transfer() 和 send() ，我们就必须用更强大的方式来防止重入。幸运的是，这个问题有很好的解决办法。

检查-生效-交互模式

消除重入性 bug 最简单的方法是使用检查-生效-交互 (checks-effects-interactions)[14]。这是一个典型的重入 bug 的例子：

     contract Vulnerable {           ...           function withdraw() external {               uint256 amount = balanceOf[msg.sender];               (bool success, ) = msg.sender.call.value(amount)("");               require(success, "Transfer failed.");               balanceOf[msg.sender] = 0;           }      }

如果 msg.sender 是一个智能合约，它在第 6 行有机会在第 7 行发生之前再次调用 withdraw() 。在那第二次调用中， balanceOf[msg.sender] 还是原来的金额，所以会再次转账。这可以根据需要重复多次，以耗尽智能合约。

检查-生效-交互模式的想法是确保你所有的交互（外部调用）都发生在最后。上述代码的典型修复方法如下：

     1contract Fixed {       2    ...       3       4    function withdraw() external {       5        uint256 amount = balanceOf[msg.sender];       6        balanceOf[msg.sender] = 0;       7        (bool success, ) = msg.sender.call.value(amount)("");       8        require(success, "Transfer failed.");       9    }      10}

请注意，在这段代码中，余额在转账之前就被清零了，所以试图对 withdraw() 进行重入调用对攻击者来说没有收益。

使用重入防护

另一种防止重入的方法是明确地检查和拒绝这种调用。下面是一个简单版的重入防护，大家可以看看思路：

     1contract Guarded {       2    ...       3       4    bool locked = false;       5       6    function withdraw() external {       7        require(!locked, "Reentrant call detected!");       8        locked = true;       9        ...      10        locked = false;      11    }      12}

在这段代码中，如果尝试重入调用，第 7 行的 require 将拒绝它，因为 lock 仍然被设置为 true 。

在 OpenZeppelin 的 ReentrancyGuard [15] 合约中可以找到一个更复杂、更节省 gas 的版本。如果你继承了 ReentrancyGuard ，你只需要用 nonReentrant 来修饰函数，防止重入。

请注意，这个方法只应该用于保护重入， 如果你明确地将其应用于所有正确的函数 。由于需要在储存中保持一个值，它也会增加 Gas 成本。