ERC20优化

Question

我正在学习流行的的源代码，在ERC20标准上有些东西我不明白。

让我们以这个例子为例：

https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/ERC20.sol

以下是此智能契约的可靠源代码的一部分：

mapping (address => uint256) private _balances;
uint256 private _totalSupply;

如您所见，总供应量存储在一个单独的变量上。这个总供应量是所有余额的总和。

关于稳健性优化，我学到的是，我们应该优先考虑存储，而不是计算。

如果我必须编写一个ERC20合同，我将编写一个视图函数，该函数对_balances进行求和，以提供总供应量。为什么？视图函数可以将自由气体的余额和起来，因为它没有在区块链上写任何东西。如果我们有一个_totalSupply变量，我们必须在每次平衡发生变化时更新它。所以写这个变量需要一些气体。

我的问题是:为什么每个人都在_totalSupply契约上添加一个ERC20变量，而不是一个与余额相加的视图函数？

谢谢

Answer 1

如果我们有一个_totalSupply变量，我们必须在每次平衡发生变化时更新它。所以写这个变量需要一些气体。

这不对。例如，如果Bob将x令牌转移给Alice，则将更新它们的余额，但不会更新总供应量。同样的原则也适用于法定货币，银行或现金转移对总供应量没有影响。但是，_totalSupply是针对每个mint和burn更新的，它们分别是令牌的创建和销毁。ERC20标准没有指定这些字体，因为每个令牌的供应机制非常具体。因此，它们的执行是免费的。

为什么每个人都在_totalSupply契约上放置一个ERC20变量，而不是一个与余额相加的视图函数？

如何实现这个sum函数？为此，您需要跟踪每个包含令牌的地址，这不是最佳解决方案。_totalSupply方法要简单得多，因为通过使用mint和burn方法来跟踪总供应量。

Answer 2

这不对。我们不能迭代映射变量。所以我们不能计算_balances之和。