Gas Optimization for NFTs Flashcards

What is the main gas advantage of using `calldata` instead of `memory` for external function parameters?

Answer: calldata avoids copying data into memory, reducing gas

Parameters declared as `calldata` are read directly from the transaction input without being copied to memory, saving gas on reads.

How does a Merkle tree allowlist reduce gas costs for NFT mints?

Answer: It stores only the Merkle root on-chain; users provide a proof at mint time

Storing just the 32-byte Merkle root on-chain instead of thousands of addresses avoids expensive storage writes during setup.

Which deployment pattern minimizes gas when launching many identical NFT contracts (e.g., per-creator collections)?

Answer: Using the EIP-1167 minimal proxy (clone) pattern

EIP-1167 minimal proxies deploy a tiny forwarding contract pointing to a shared implementation, reducing deployment gas by ~10x.

What does marking a Solidity variable as `immutable` rather than `constant` allow, and how does it affect gas?

Answer: Immutable variables are set at construction time and inlined in bytecode, saving SLOAD gas at runtime

Immutable values are embedded directly in contract bytecode after construction, so reading them costs only 3 gas (like a constant) rather than a 2100-gas SLOAD.

Why should NFT contracts avoid using `_safeMint` when minting to known EOA addresses in bulk?

Answer: _safeMint makes an external call to check ERC-721 receiver support, adding gas overhead

`_safeMint` calls `onERC721Received` on the recipient if it's a contract, adding an external call and re-entrancy guard overhead unnecessary for plain EOAs.

What effect does enabling the Solidity optimizer (runs=200) have on a deployed NFT contract?

Answer: It reduces both deployment size and runtime gas through bytecode optimization

The optimizer rewrites bytecode to eliminate redundant operations, typically shrinking contract size and reducing runtime execution gas.