Keep ERC-20 balances and approval slots non-zero about openzeppelin-contracts HOT 2 OPEN

Thank you @CodeSandwich for this idea.

Backward compatibility is a must for us (because of the upgradeable version). Its good that you approach provides that feature! This limitation of balances to 2**255-1 is an issue though. We will want to avoid silent errors that may arrive if balances overflow into the mask. That will have to be checked ... and checks add gas cost for everyone ...

I'm curious about the gas cost increase from loading and applying the mask. There is a minority cases where that indeed will save cost, but there is also a majority of cases where that will slightly increasse the costs as well.

I'll try to find banwidth to research that

from openzeppelin-contracts.

I'm curious about the gas cost increase from loading and applying the mask. There is a minority cases where that indeed will save cost, but there is also a majority of cases where that will slightly increasse the costs as well.

I don't think that you should be worried about the gas cost and savings balance. The mask is a constant, so it's loaded by pushing a value to the stack, with the binary operation it will probably cost less than 10 gas in total. The savings on the other hand is 17,100 gas when the storage slot doesn't need to be set from 0 to non-0. This isn't an uncommon case for ERC-20 to drain a balance or an approval to zero, and then make it non-zero again.

This limitation of balances to 2**255-1 is an issue though. We will want to avoid silent errors that may arrive if balances overflow into the mask. That will have to be checked ... and checks add gas cost for everyone ...

I agree that this is an issue, and it may affect the consumers of OZ. I don't think that gas usage is a problem though, at least not on the OZ level. The only place where a new check is needed is in _update, where _totalSupply += value; is performed. The compiler already catches values larger than 2^256-1, but now we would need to catch values larger than 2^255-1. The nice side effect is that we would start emitting an explicit error when somebody mints too much, instead of the cryptic overflow panic. (It may be worth implementing regardless of this gas improvement)

Thanks for looking into it!

from openzeppelin-contracts.