Gas cost for an arbitrary big mapping

[jbastruz]

Hi guys,

I try something on my project, but I think i'll have a scalability issue, I would like to know if i'm right or not.

I'm developing a dynamic NFT, which evolves with two things :

• the number of previous owners
• the time elapsed since the purchase of the object

I decided to store those informations on-chain as follow :

contract Nft is ERC721Royalty, ERC721Enumerable, Ownable, PaymentSplitter {

    struct NFTInfo {

        uint32 nbOwners;
        uint32 MintingDate; // max 4294967295
    }

    uint32 private s_tokenCounter;
    uint256 private constant diams_time = 3 days * 86400;

    mapping(uint32 => NFTInfo) private obsolescence;

[...]

    function mintNft() external{
        require(!paused, "The mint's not available for now, be patient ;)");

        s_tokenCounter = s_tokenCounter + 1;
        _safeMint(msg.sender, s_tokenCounter);

        obsolescence[s_tokenCounter] = NFTInfo(1, uint32(block.timestamp));
    }

[...]

    function tokenURI(uint256 _tokenId) public view override returns (string memory) {

        if (block.timestamp - obsolescence[uint32(_tokenId)].MintingDate <= diams_time && obsolescence[uint32(_tokenId)].nbOwners > 1){

            [...]

        }
    }
    function safeTransferFrom(
        address _from,
        address _to,
        uint256 _tokenId,
        bytes memory _data
    ) public virtual override {
        require(
            _isApprovedOrOwner(_msgSender(), _tokenId),
            "ERC721: caller is not token owner or approved"
        );
        _safeTransfer(_from, _to, _tokenId, _data);
        obsolescence[s_tokenCounter].nbOwners += 1;
    }
}

my tests prove me that the code works properly on small amount of nfts (about 10), but the purpose of this NFT is to be not caped by a max supply.

My fear is to see an explosive gas cost growing with the increasing amount of nft minted.

Am i right ? if so, is there a solution to fix this problem ?

Kind regards.

[jbastruz]

@alymurtazamemon you seems skilled, maybe you know the answer ? I tried to find the solution on internet, but I didn’t find anything on it…

@PatrickAlphaC i think this question seems close to the issue with the marketplace listing (solved with off-chain solution), but I’m not sure, do you have an idea of this issue?

[alymurtazamemon]

@jbastruz Could you please describe your scenario so we can provide you a solution or any alternative?

[jbastruz]

@alymurtazamemon Sure !

the common scenario is the following :

1. The NFT is minted, during the mint :

   • the contract set the date of the mint in the mapping "obsolescence"
   • it set the number of previous owner equal to 1
     those informations are unique for each NFT minted (king that we can mint as many NFTs as we want, there is no MaxSupply)

2. When a user sells its NFT (thanks to "safeTransferFrom") :

   • the smart contract increase by one the number of previous owners.

3. the contrat adjust the tokenURI according the informations in the mapping "obsolescence" as following :

   • if the timestamp - mintDate < 3 days AND the number of previous user > 1 then the contract show a specific IPFS file
   • if the timestamp - mintDate > 3 days AND the number of previous user < 1 the the contract show a specific IPFS file
   • if the timestamp - mintDate < 3 days AND the number of previous user < 1 then the contract show a specific IPFS file
   • if the timestamp - mintDate > 3 days AND the number of previous user > 1 the the contract show a specific IPFS file

in this scenario I need to keep the "MintingDate" and the "nbOwners" to be able to select the right IPFS file

[alymurtazamemon]

@jbastruz I apologize for the late reply.

Mapping's each key/value takes its own storage slot (selected using a kaccek256 hash function based on mapping location and the hash of key type) so increasing the number of items in the mapping occupies more storage slots. But when it comes to WRITE and READ, it does not matter how many values you already have in the mappings, gas cost will always be based on the complexity of the contract's code and the number of computations it performs in order to WRITE or READ. So if the code's complexity and computation are the same for WRITING the first key/value and the 100th or 1000th key/value the gas cost will be the same.

Let's tag @PatrickAlphaC so we both can learn more about it.

[jbastruz]

@alymurtazamemon
Just to be sure I understood what you said

• READING/WRITING the 1000th value in my mapping will cost the same as READING/WRITING the 1st value (All other things being equal).

• In the case of adding a new key/value pairs, adding the 1000th pair will cost the same than adding the 2nd pair?

• Will The cost of READING/WRITING the n-th value cost more in a bigger mapping object?

[alymurtazamemon]

@jbastruz Yes, I would recommend you read this How are mappings stored in smart contract storage?. This will answer your all queries.

[jbastruz]

@alymurtazamemon

I'm maybe not that clear sorry,
I just want to know if I have to expect some gas fee increasing if i use a mapping containing a huge amount of Key/value pair. (using it to overwrite values in the mapping, or adding a new key/value pair)

sorry if it's not clear