How to Write Gas-Efficient and Optimized Solidity Code?

Understanding Gas Consumption Patterns

1. Every operation in the Ethereum Virtual Machine consumes a deterministic amount of gas, from simple arithmetic to storage writes.

2. Memory allocation and dynamic array resizing trigger disproportionately high gas costs compared to fixed-size structures.

3. External function calls incur overhead due to message passing, stack copying, and EVM context switching.

4. SLOAD and SSTORE operations remain among the most expensive instructions, especially when modifying storage slots repeatedly.

5. Loop iterations amplify gas usage exponentially if they contain storage reads or writes without proper bounds checking.

Optimizing Storage Layout

1. Packing multiple small variables into a single 256-bit storage slot reduces SSTORE calls and saves gas on deployment and runtime.

2. Declaring state variables in descending order of size—uint256 before uint128 before uint64—enables tighter packing and avoids implicit padding gaps.

3. Using immutable for constants initialized once in the constructor eliminates storage writes entirely after deployment.

4. Replacing address payable with plain address where no transfers occur removes unnecessary type conversion overhead.

5. Avoiding structs with mixed-size fields without alignment consideration leads to wasted space and increased gas per access.

Minimizing Runtime Computation

1. Calculating loop bounds off-chain or caching them in memory prevents repeated storage lookups inside iterations.

2. Using unchecked { ... } for arithmetic where overflow is mathematically impossible skips safety checks and cuts gas by up to 40% per operation.

3. Preferring require() over assert() ensures earlier failure with lower gas cost on invalid inputs.

4. Moving complex logic into libraries and using delegatecall avoids duplicating bytecode across contracts.

5. Inlining small helper functions manually can reduce call overhead, though compiler optimizations may handle this automatically at higher optimization levels.

Compiler and Toolchain Leverage

1. Enabling Solidity optimizer with --optimize --optimize-runs=200 significantly reduces deployed bytecode size and runtime gas through constant folding and jump reordering.

2. Using recent compiler versions like 0.8.24 unlocks built-in checks and more aggressive inlining strategies not available in older releases.

3. Analyzing generated opcodes with tools like solc --asm reveals hidden inefficiencies such as redundant DUPs or unnecessary SWAPs.

4. Integrating Foundry’s forge inspect helps identify storage slot collisions and unexpected memory allocations during testing.

5. Running gas snapshots via forge test --gas-report exposes hotspots before mainnet deployment.

Frequently Asked Questions

Q: Does using view functions eliminate all gas costs for callers?A: No. While view functions do not consume gas when called externally via RPC, they still cost gas when invoked internally from non-view functions within the same transaction.

Q: Can I safely replace require(msg.sender == owner) with msg.sender == owner in internal logic?A: Not safely. Removing require eliminates the explicit revert, leading to silent failures or unintended behavior instead of controlled error handling.

Q: Is it better to emit events or store data in mappings for off-chain indexing?A: Events are cheaper than storage writes and sufficient for indexing purposes. Storing identical data both in events and state variables wastes gas without added benefit unless on-chain access is required.

Q: Why does deleting an array element with delete arr[i] not reduce overall contract gas cost?A: The delete keyword only resets the value but does not shrink the array length or reclaim storage slots. Dynamic arrays retain capacity, and manual shifting or using push/pop patterns is needed for true cleanup.