ERC721 vs ERC721A , the differences and the advantage of the ERC721A.

almost everyone in the web3 space knows about the ERC721 NFT , you can read about it here .

The ERC721 refers to the Non-fungible tokens: These are the tokens that have a unique value, code, and metadata. No two non-fungible tokens can replace another, because the two are unique. For example, digit assets like in-game avatars, digital and non-digital collectibles, and even tickets are all non-fungible .

The user can only mint one token per transaction ,and each token Id should have explicitly one owner assigned to it .

function `mint` for ERC721 form openzeppelin library

as shown in this function _mint the user can only mint one token with a unique tokenId and then the function increment the balance of the owner by one .

the minting token mechanism is a bit different in the ERC721A , so first I will explain the purpose of ERC721A , which is created by the Azuki team to minimuze the gas cost of minting multiple ERC721 tokens in one call , For several months, there has been a continuous elevation in gas prices within the Ethereum network, prompting the development community to make necessary adjustments. The initiation of minting by well-liked NFT projects causes a sudden surge in gas prices, leading to a situation where the entire ecosystem is burdened with substantial gas fees for their transactions.

there are 2optimizations of this implementation :

1. Removing duplicate storage from OpenZeppelin’s (OZ) ERC721Enumerable: The commonly utilized OZ implementation of IERC721Enumerable incorporates duplicated storage of metadata for every token of the same owner .
2. updating the owner’s balance once per batch mint request, instead of per minted NFT : Imagine that Bob possesses 2 tokens and intends to acquire 8 additional ones. In Solidity, modifying a stored value incurs gas costs. As a result, if we are maintaining a record of Bob’s token ownership in storage, it would be more cost-effective to enhance Bob’s ownership from 2 to 10 tokens in a single update, rather than performing 8 separate updates .

for example , suppose that alice want to mint 3 tokens (#100 , #101 , #102) ,Instead of saving Alice as the owner 3 times (each time costing us gas), we can instead save the owner value just once in a way that semantically implies that Alice owns all 3 of those tokens.

How? Suppose Alice mints tokens #100, #101, and #102, and Bob mints tokens #103 and #104. The internal owner tracker would look like this:

The key here is that if we wanted to see who owned #102, we don’t need to actually have Alice set explicitly as the explicit owner of #102 to do so. We could just change the ownerOf function to do the following:

in order to understand how this function works , I will explain the previous example , To know the owner of the token Id #101 you will pass the 101 as tokenId to the function ownerOf this function will loop through all the max batch size of the minting process , so the last maxBatchSize of the tokenId should at least include one owner of this tokenId , else this token had not been minted .

so , if the maxBatchSize in our example is 5 , so the lowestTokenToCheck will be #97 so it will search for the owner in the last 5 tokens from this token #101 , and in case of the multiple owners in the same maxBatchSize the first owner will be found is the true owner of that token id , which in our example will be alice .

the total gas saving in the new mint function of the ERC721A is shown here :

this article is finished right here , I will it was useful .

you can follow me on twitter for more information about the smart contract security content here : https://twitter.com/0xfrank_auditor