2

I am studying popular Ethereum smartcontract's source code and there is something i do not understand on ERC20 standard.

Let's took this example:

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

Here is a portion of this smartcontract's solidity source code:

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

As you can see, the total supply is stored on a separate variable. This total supply is the sum of all the balances.

What i've learned about Solidity optimization is we should give priority to storage rather than calculation.

If i had to write an ERC20 contract, i would write a view function which sums _balances in order to provide total supply. Why ? A view function can sum balances for free gas because it does not write anything on blockchain. If we have a _totalSupply variable, we have to update it each time one balance change. So it will cost some gas to write this variable.

My question is: Why everybody puts a _totalSupply variable on ERC20 contracts, rather than a view function which sums balances ?

Thanks

Bob5421
  • 1,457
  • 1
  • 12
  • 38

2 Answers2

1

If we have a _totalSupply variable, we have to update it each time one balance change. So it will cost some gas to write this variable.

That's not correct. For example, if Bob transfers x tokens to Alice, their balances will be updated but not the total supply. The same principle applies to fiat money, a bank or cash transfer has no impact on the total supply. _totalSupply is however updated for each mint and burn which are respectively the creation and destruction of tokens. The ERC20 standard does not specify theses fonctions as the supply mechanism is very specific for each token. Their implementation is therefore free.

Why everybody puts a _totalSupply variable on ERC20 contracts, rather than a view function which sums balances ?

How do you implement this sum function ? For this you would need to track each address holding tokens, which is not an optimal solution. The _totalSupply approach is a much easier one as the total supply is tracked through the use of the mint and burn methods.

clement
  • 4,302
  • 2
  • 17
  • 35
  • 1
    You are true, total supply only change on mint and burn operations. But it is possible to make a loop on balance in order to sum in a view function – Bob5421 Jan 17 '21 at 14:42
  • 3
    If you're thinking about iterate over the mapping _balances that's not possible. You cannot make a loop on a mapping as it is a key/value system with an infinite quantity of keys. For exemple an address which doesn't hold tokens exists in the mapping and will return zero as value. – clement Jan 17 '21 at 14:55
  • 2
    To sum the balances you could use an array to register all the addresses with a non zero amount of tokens by adding some logics in the transfer function. – clement Jan 17 '21 at 14:58
  • 1
    But that would be a bad idea if you are looking for optimization. – clement Jan 17 '21 at 15:04
0

That's not correct. We cannot iterate mapping variable. So we cannot calculate the sum of _balances.

Oliver Chang
  • 1
  • It is true that mapping aren't iteratable, but it is possible to add an index to the mapping, see https://ethereum.stackexchange.com/questions/13167/are-there-well-solved-and-simple-storage-patterns-for-solidity. – Ismael Nov 02 '22 at 04:34
  • Yes, you are right. There are some techniques to iteratable mapping but it takes lots of gas fee. Instead of implementing iteratable mapping, we can simply add _totalSupply. – Oliver Chang Nov 23 '22 at 03:09