A quick Q&A with our dev
A few days ago we asked our community if they had any questions about our smart contract dev — @Baostronaut. Here are a few that were asked in the Discord…
What kind of contract optimizations did you consider & employ (e.g. versions of ERC721A) to help reduce gas fees?
There are a number of different strategies utilised to minimise gas. Firstly, it is important to break down what the major components of gas cost are. There’s the gas price in Gwei, based on network demand. Then storage gas for the space complexity of a write operation (how much memory it needs). And then a complexity factor to gas for the number of operations you do on the network.
- How much gas: how many things we are doing * how much memory they require
- How much gas costs: the network demand-based auction
- gas * gasPrice = total tx fee.
What we have done is start from the most recent ERC721A contract from Azuki:
- This causes minting cost to scale sublinearly because it only does the ownership update once per transaction, rather than once per NFT mint. So if you mint 5, it does this work 1 time, labelling the whole block, instead of 5x the operations and 5x the memory. It then overrides the reading logic to be able to handle the “blocks” of ownership in the owners’ data structure.
- Not use ERC721Enumerable out of the box because the implementation of total supply is one of the main reasons gas used to be $100 on a mint.
- Have separate mint functions per minting group. This means we can know which Merkle root you’ll be on and only check that one. Less operations.
- Use only < and >, no >= or <=. Less operations.
- Generally not doing anything that is not absolutely necessary. We have optimised our mint restrictions around 2 factors:
(a) Simplest code to enforce so that you are not paying gas to restrict your own minting rights; and
(b) Avoid network congestion by separating the mint into 3 phases. This lowers average network demand and therefore gas price. Helping every user save money, and support the network.
- Using modifiers requires that block the tx as early as possible in the function to stop you wasting gas on a failed tx.
Other things I have seen done is limiting wallets to 1 mint transaction to also minimise network congestion.
Were any measures taken to make d contract easily understandable even by non-coders?
Not really but I believe good code generally should be expressive to what it is trying to achieve in the naming of variables. Sometimes when developing smart contracts I will violate this principle to achieve more gas efficiency, i.e. if I can optimise a function but it becomes less readable, I will. Because my top priority is the cheapest gas for our users.
Have any further questions? Make sure you post them in the #ama-channel via our Discord