Gas Optimization Techniques
Learn strategies to write gas-efficient Solidity code, reducing transaction costs and improving DApp performance on the blockchain.
Gas Optimization Techniques is a free Web3 & DApp Development Fundamentals lesson on CoddyKit — lesson 3 of 3. You can read the complete lesson below for free — then practise it hands-on in the browser with a built-in code editor and a 24/7 AI tutor. It is part of the Web3 & DApp Development Fundamentals learning path, one of 3 lessons in the course, and your progress syncs across the web and the CoddyKit app.
Why Gas Optimization Matters
Welcome to the final lesson in DApp Security & Auditing! Today, we'll master Gas Optimization Techniques.
Gas is the fee paid to execute transactions on the Ethereum network. It's like fuel for your car.
- Cost Reduction: Lower gas fees mean cheaper transactions for users.
- Performance: Optimized contracts execute faster.
- User Experience: Better performance leads to happier users and smoother DApps.
Understanding Gas Costs
Every operation the Ethereum Virtual Machine (EVM) performs costs a certain amount of gas. Complex operations cost more.
When you deploy or interact with a smart contract, you pay gas for:
- Storing data on the blockchain (most expensive).
- Performing computations.
- Sending Ether.
Our goal is to write code that uses fewer of these expensive operations.
Storage vs. Memory vs. Calldata
Understanding where your data lives is key to saving gas. Each location has different costs:
- Storage: Permanent, on-chain. Most expensive to read/write (SSTORE/SLOAD).
- Memory: Temporary, exists only during function execution. Cheaper than storage.
- Calldata: Immutable, read-only, temporary. Used for external function arguments. Cheapest for external inputs.
Prioritize using calldata or memory for variables that don't need to persist on-chain.
Minimize Storage Writes (SSTORE)
Writing to storage (SSTORE) is the single most expensive operation in Solidity. Always ask: does this variable really need to be stored on-chain?
Instead of updating a counter in storage for every iteration, compute it once at the end or use events to log changes.
Consider this simple example:
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;
contract StorageCostExample {
uint256 public counter;
// High gas cost: writes to storage every call
function incrementBad() public {
counter++;
}
// Lower gas cost: only reads state
function getCounter() public view returns (uint256) {
return counter;
}
}Packing Storage Variables
Solidity stores variables in 256-bit (32-byte) 'slots'. If you declare multiple variables that fit within a single slot, they can be 'packed' together, saving gas.
For example, three uint8 variables take up less storage than three uint256 variables if declared consecutively. This saves SSTORE operations.
- Declare smaller data types (e.g.,
uint8,bool) when possible. - Group variables of similar sizes together.
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;
contract StoragePacking {
// These will likely pack into one slot
uint8 public value1;
bool public isActive;
uint8 public value2;
// This will take a separate slot
address public owner;
function setValues(uint8 _v1, bool _active, uint8 _v2) public {
value1 = _v1;
isActive = _active;
value2 = _v2;
}
}Short-Circuiting Conditionals
When using logical operators like && (AND) or || (OR), Solidity uses 'short-circuiting'. This means it stops evaluating conditions once the result is known.
You can save gas by placing the cheaper, more likely-to-fail, or more likely-to-be-true conditions first.
- For
&&, put the condition most likely to be false first. - For
||, put the condition most likely to be true first.
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;
contract ShortCircuitExample {
uint256 public data = 100;
function checkCondition(uint256 _input) public view returns (bool) {
// Cheaper check (input) before more expensive check (storage read)
return (_input > 0 && data > 50);
}
}Efficient Loops & Iterations
Loops can be gas-expensive, especially if they iterate over large arrays stored in storage. Avoid unbounded loops or loops over dynamic arrays in storage when possible.
- Process data off-chain if possible.
- Use fixed-size arrays instead of dynamic ones if the size is known.
- Refactor logic to avoid loops or reduce iterations.
- Consider a pull-based system for payouts instead of pushing to many recipients in one transaction.
Using `view` and `pure` Functions
Functions marked as view or pure do not modify the blockchain state. When called externally, they don't cost any gas!
view: Reads state variables but doesn't modify them.pure: Neither reads nor modifies state variables.
Internal calls to view/pure functions still consume gas (as part of the larger transaction), but using them correctly for external queries is a huge gas saver for users.
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;
contract ViewPureExample {
uint256 public myNumber = 42;
// Costs no gas for external calls
function getNumber() public view returns (uint256) {
return myNumber;
}
// Costs no gas for external calls
function add(uint256 a, uint256 b) public pure returns (uint256) {
return a + b;
}
}Error Handling Gas Costs
Solidity provides several ways to handle errors: require(), revert(), and assert().
require(): Used for validating inputs and conditions. Refunds unused gas when it fails. (Recommended for most checks)revert(): Similar torequire, also refunds unused gas.assert(): Used for internal invariants and should *never* fail. Consumes ALL remaining gas when it fails. (Use sparingly for critical internal checks)
Failing an assert is much more expensive than failing a require, so choose your error handling wisely.
Question: Gas Optimization
Consider the following Solidity snippet. Which change would likely lead to the MOST significant gas savings for a user calling updateStatus?
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;
contract GasPuzzle {
uint256 public statusId;
string public statusName;
address public owner;
constructor() {
owner = msg.sender;
statusId = 1;
statusName = "Initial";
}
function updateStatus(uint256 _newId, string memory _newName) public {
require(msg.sender == owner, "Not owner");
statusId = _newId;
statusName = _newName;
}
}Recap: Gas Optimization Mastery
You've unlocked key strategies for writing gas-efficient Solidity code!
Remember these principles:
- Minimize Storage Writes: The golden rule.
- Pack Variables: Group smaller variables to fit slots.
- Use Efficient Data Locations: Prefer
calldata/memoryoverstorage. - Optimize Loops: Avoid unbounded or large iterations.
- Leverage
view/pure: For gas-free external reads. - Smart Error Handling: Use
require/revert, notassertfor user input.
Applying these techniques will lead to more affordable, faster, and user-friendly DApps. Keep practicing!
Frequently asked questions
Is the “Gas Optimization Techniques” lesson free?
Yes — the full text of “Gas Optimization Techniques” is free to read here on the web, and the Web3 & DApp Development Fundamentals course includes 3 lessons in total. To practise it interactively (a built-in code editor and a 24/7 AI tutor) and unlock the rest of the Web3 & DApp Development Fundamentals course, upgrade to CoddyKit PRO.
What will I learn in “Gas Optimization Techniques”?
Learn strategies to write gas-efficient Solidity code, reducing transaction costs and improving DApp performance on the blockchain. You practise Web3 & DApp Development Fundamentals with hands-on code you run directly in the browser, and a 24/7 AI tutor answers your questions as you work through the lesson.
Do I need any experience to start Web3 & DApp Development Fundamentals?
No prior experience is required. Web3 & DApp Development Fundamentals on CoddyKit is structured for beginners through advanced learners; this is — lesson 3 of 3, so you can start here or from the beginning and move at your own pace.
How long does the “Gas Optimization Techniques” lesson take?
Most CoddyKit lessons take about 5–10 minutes. Each one is bite-sized and interactive, so you make steady progress and pick up exactly where you left off across the web and the app.
Can I write and run code in this Web3 & DApp Development Fundamentals lesson?
Yes. Every Web3 & DApp Development Fundamentals lesson includes a built-in code editor, so you write and run real code right in your browser and get instant AI feedback — no local setup required.
All lessons in this course
- Common Smart Contract Vulnerabilities
- Security Tools & Audits
- Gas Optimization Techniques