ERC721 optimised for sequential id and no burn

🧐 Motivation

The high values for gas fees when minting has been a big issue. There have been some suggestions on how to lower these when using the ERC721 contract but then these are limited to the implementation of this same contract.

The ERC721 contract is rightfully a general implementation but there’s one case where it should be possible to considerably reduce the gas usage. I believe this is a very common case.

📝 Details

For the case when using sequential ids and there’s no support for burning tokens the following optimizations for ERC721 are possible:

1. _owners can be an array instead of a mapping.

https://github.com/aalmada/openzeppelin-contracts/blob/44d55cfe3298d563a63df7b5d67711312810112b/contracts/token/ERC721/ERC721Lite.sol#L32

1. exists() can just check if the tokenIdis smaller than _owners.length

https://github.com/aalmada/openzeppelin-contracts/blob/44d55cfe3298d563a63df7b5d67711312810112b/contracts/token/ERC721/ERC721Lite.sol#L233-L235

1. mint() can generate the tokenId from the value of _owners.length and _owners can be updated by using _owners.push(to)

https://github.com/aalmada/openzeppelin-contracts/blob/44d55cfe3298d563a63df7b5d67711312810112b/contracts/token/ERC721/ERC721Lite.sol#L289-L302

ERC721Enumerable can also be optimized:

1. _allTokens and _allTokensIndex can be removed.

2. totalSupply() can return the _owners.length from ERC721 exposed as an internal _totalSupply() method.

https://github.com/aalmada/openzeppelin-contracts/blob/44d55cfe3298d563a63df7b5d67711312810112b/contracts/token/ERC721/extensions/ERC721LiteEnumerable.sol#L40-L42

1. tokenByIndex() can simply return the index value

https://github.com/aalmada/openzeppelin-contracts/blob/44d55cfe3298d563a63df7b5d67711312810112b/contracts/token/ERC721/extensions/ERC721LiteEnumerable.sol#L47-L50

Conclusions

My tests show that gas usage for minting reduces from around 161k to around 101k. I believe this can be considered a significant improvement for a very common scenario.

I’d like to know your opinions and if I should consider submitting a PR.

[Amxx]

shameless advertisement for my generic subgraph

It indexes all ERC721 contracts on mainnet, and you can easily build equivalent instances for other chains using our @openzeppelin/subgraphs toolkit.

[Amxx]

Hello @aalmada

There is a lot of discussion around the gas usage of ERC721 lately, and we appreciate the clarity of your approach. We understand that in very specific cases, our implementation is not the most gas effective. Sequential tokens minting with no burn is definitely one of these specific cases.

We care a lot about the versatility and backward compatibility of our codebase. For this reason, we don’t think it would be reasonable to deprecate our current proposal. AFAIK, nobody is asking for that anyway.

If we were to provide an implementation optimized for this specific case, we would be splitting our codebase, with unclear compatibility with ERC721 modules (voting being the last one). I don’t think this is optimal.

An opinion that we have shared, and that we will continue to share, is that ERC721Enumerable should not be used unless absolutely necessary. I have personally never seen any situation where it was actually needed. If you don’t include Enumerability, our (generic) implementation is as cheap as any other (that is focused on “batch-minting”) within the margin or error.

My answer to your issue would then be:

• We strongly encourage the community to build and distribute contracts that are optimized for specific requirements (that our generic contracts are not optimized for)
• Please please please, don’t use enumerability unless you really need to. And if you don’t need it, then benchmark other implementations against our “core” erc721 contract.