Library_packed

🧐 Motivation The current design pattern for all ERC tokens is to use the uint256 as this interfaces with EVM. This is understandable. However, not all use cases of these tokens need a pure uint256 standard. The most important part is that we keep the interface of the uint256 but in the library.cairo we can make a low-level conversion into a felt if it is appropriate for the use case. It is then the responsibility of the developer to choose what they wish to use.

For the upcoming ERC1155 standard this is particularly helpful as it will effectively half the storage space for the tokens.

📝 Details Proposes design pattern:

library_packed.cairo

This file would simply have a low-level conversion from uint to felt and vice versa where needed. This would then just be chosen by the developer when they deploy the contract.

Thoughts?

[milancermak]

Using felts instead of Uint256 would also save on transaction execution resources.

I was curious about the savings. I forked the repo and created a library_felt for ERC20 (code can be found in this branch). The public API is kept the same, but internally, it uses felts for everything.

In a simple transfer TX went from needing 870 steps and 32 range_check_builtins to 683 steps and 18 range_check_builtins; the rest stayed the same. That’s a saving of about 15 gas / transfer (870 - 683) * 0.05 + (32 - 18) * 0.4.

Not much in absolute terms, but somewhat significant in relative terms. Given that these contracts are going to be the canonical implementation of tokens used on Starknet, that we’re still early and that scaled out to hundreds of millions of TX in the future, the savings are serious. I’d urge OZ to consider a felt-based implementation for ERC tokens as originally suggested.

[ponderingdemocritus]

yes, very valid point. I think you might be correct, the only question is if storage structs costs more to update, or if they count towards two storage updates on every write