Gas cost optimization in 1/n ERC721

bahlsenwitz · February 2, 2021, 12:45am

This inquiry is specifically related to the following OpenZeppelin-based ERC721 contract:

This contact supports releases of tokens that are 1/n, i.e. not exclusively 1/1.

For all the instances of tokens of a particular set (1/n, 2/n, …, n/n), where all the tokens correspond to the same ipfsHash, would it be possible to use the same tokenURI for all of them?

Would this reduce the amount of storage, and correspondingly the amount of gas used when the contract is called?

Would this have any negative externalities regarding the correct functionality as its implemented today?

abcoathup · February 2, 2021, 12:58am

Hi @bahlsenwitz,

Welcome to the community

Yes. The OpenZeppelin Contracts ERC721 implementation supports:

tokenURI
baseURI + tokenURI
baseURI + tokenID

github.com

OpenZeppelin/openzeppelin-contracts/blob/v3.4.0-rc.0/contracts/token/ERC721/ERC721.sol#L142-L150


if (bytes(base).length == 0) {
    return _tokenURI;
}
// If both are set, concatenate the baseURI and tokenURI (via abi.encodePacked).
if (bytes(_tokenURI).length > 0) {
    return string(abi.encodePacked(base, _tokenURI));
}
// If there is a baseURI but no tokenURI, concatenate the tokenID to the baseURI.
return string(abi.encodePacked(base, tokenId.toString()));

If you were using centralized metadata (e.g. from a server) then the lowest cost minting is just setting a single baseURI.

If you are using decentralized metadata (e.g. IPFS) then you could override the tokenURI function (from Release Candidate for Contracts 3.4) to return your IPFS.

Using either baseURI + tokenID or a single IPFS hash for the entire contract would reduce the cost of minting as you wouldn’t need to store any metadata onchain for each token ID.

Not that I am aware of. You should test this with any services that you want to use (e.g. OpenSea) and what format you need to use for the URI when using IPFS.