Zokyo Gas Savings
  • โ›ฝZokyo Gas Savings
  • ๐Ÿ“šTutorials
    • โœ”๏ธGas Saving Technique 1: Unchecked Arithmetic
    • โ›“๏ธGas Saving Technique 2: Immutable Variable
    • โœจGas Saving Technique 3: Double star ** inefficiency
    • ๐Ÿ’ฐGas Saving Technique 4: Cache Array Length
    • โฌ…๏ธGas Saving Technique 5: ++i costs less gas compared to i++
    • โš–๏ธGas Saving Technique 6: NOT operator ! cheaper than boolean FALSE
    • ๐ŸชกGas Saving Technique 7: Using Short Reason Strings
    • ๐ŸชตGas Saving Technique 8: Use Custom Errors instead of Revert Strings to save Gas
    • โœ’๏ธGas Saving Technique 9: Use Custom Errors instead of Revert Strings to save Gas
    • ๐Ÿ‘พGas Saving Technique 10: Calldata cheaper than memory
    • โ›”Gas Saving Technique 11: > 0 is less efficient than != 0 for unsigned integers
    • โž—Gas Saving Technique 12: SafeMath no longer needed
    • ๐Ÿ˜ฎGas Saving Technique 13: variables default to 0
    • ๐ŸงฑGas Saving Technique 14: struct layout/ variable packing
    • ๐Ÿ“žGas Saving Technique 15: Cache External Call
    • โœ๏ธGas Saving Technique 16: Early Validation before external call
    • ๐Ÿ˜ŽGas Saving Technique 17: Donโ€™t cache value that is used once
    • ๐Ÿ˜งGas Saving Technique 18: Redundant code
    • โœ…Gas Saving Technique 19: Early Validation before external call
    • โ›๏ธGas Saving Technique 20: Storage vs Memory read optimizations
    • โœ’๏ธGas Saving Technique 21: Unneeded If statements
    • ๐ŸŒ—Gas Saving Technique 22: >= is cheaper than >
    • ๐ŸŽ’Gas Saving Technique 23: Public to private constants
    • โน๏ธGas Saving Technique 24: Make unchanged variables constant/immutable
    • โฑ๏ธGas Saving Techniques 25: Redundant Access Control Checks
    • โžก๏ธGas Saving Technique 26: Shift Right instead of Dividing by 2
    • ๐ŸชƒGas Saving Tutorial 27: Efficient Boolean Comparison
    • ๐ŸคGas Saving Technique 28: && operator uses more gas
    • ๐Ÿ‘“Gas Saving Technique 29: x = x + y is cheaper than x += y
    • ๐Ÿ‘‚Gas Saving Technique 30: Using 1 and 2 rather than 0 and 1 saves gas
    • โšฝGas Saving Technique 31: Optimize Storage by Avoiding Booleans
    • ๐Ÿ”™Gas Saving Technique 32: Optimal Use of Named Return Variables in Solidity
    • ๐Ÿ›ข๏ธGas Saving Technique 33: Making Functions Payable for Optimized Gas Costs
    • โœ๏ธGas Saving Technique 34: Optimizing Storage References in Smart Contracts
    • โ›ฐ๏ธGas Saving Technique 35: Usage of uints/ints smaller than 32 bytes (256 bits) incurs overhead
    • ๐ŸŒช๏ธGas Saving Technique 36: Inlining Single Use Internal Functions for Savings
    • โ˜„๏ธGas Saving Technique 37: Switching from Public to External Functions for Savings
    • ๐ŸŽ†Gas Saving Technique 38: Upgrading Solidity Compiler to Improve Gas Efficiency and Security
    • ๐Ÿ•ถ๏ธGas Saving Technique 39: Avoiding Duplicated Code for Gas Savings
    • ๐Ÿ˜„Gas Saving Technique 40: Removal of Unused Internal Functions for Gas Savings
    • ๐Ÿ–‹๏ธGas Saving Tutorial 41: In-lining Single Use Modifiers For Gas Saving
    • โ›๏ธGas Saving Technique 42: `require` vs`assert`
Powered by GitBook
On this page
  1. Tutorials

Gas Saving Technique 28: && operator uses more gas

PreviousGas Saving Tutorial 27: Efficient Boolean ComparisonNextGas Saving Technique 29: x = x + y is cheaper than x += y

Last updated 1 year ago

Introduction: In the Solidity smart contract realm, efficient gas usage is paramount. One might think that condensing multiple conditions within a single require statement using the && operator is efficient, but in practice, this can consume more gas than splitting the conditions into separate require statements. This tutorial will delve into the reasons behind this, demonstrating the gas-saving potential of splitting conditions.


Concept: The require function in Solidity is used to ensure that certain conditions are met before executing subsequent code. When combining multiple conditions with the && operator within a single require, Solidity evaluates all conditions even if the first one fails. On the contrary, by separating the conditions into distinct require statements, Solidity can fail fast on the first condition not met, potentially saving gas.


Underlying Problem:

  1. Sequential Evaluation: The && operator results in a sequential evaluation of conditions. If the first condition is false, subsequent conditions are still evaluated, leading to unnecessary gas consumption.

  2. Fail Fast Principle: Combining conditions prevents utilizing the "fail fast" principle, which can be more gas-efficient when conditions are split.


Example:

Using && Operator in a Single require:

solidityCopy coderequire(amount_ != uint256(0) && amount_ <= MAX_TOTAL_XDEFI_SUPPLY, "INVALID_AMOUNT");

Splitting the Conditions into Separate require Statements:

solidityCopy coderequire(amount_ != uint256(0), "INVALID_AMOUNT_ZERO");
require(amount_ <= MAX_TOTAL_XDEFI_SUPPLY, "INVALID_AMOUNT_OVERLIMIT");

Recommendation:

  1. Scrutinize your contracts and locate any require statements using the && operator to combine multiple conditions.

  2. Decompose these combined conditions into individual require statements.

  3. Ensure that the ordering of conditions remains logical and doesn't compromise the contract's security.

  4. Test the refactored code thoroughly to ensure consistent behavior and actual gas savings.

  5. When writing new contracts, consider adopting the "fail fast" principle by default.


Conclusion: In the world of smart contracts where every gas unit matters, seemingly minor changes can lead to significant gas savings. By splitting conditions in require statements instead of chaining them with the && operator, developers can optimize their contracts for efficiency. Remember: In the blockchain space, efficiency is not just about code performance, but also about the cost-effectiveness of executing that code.

๐Ÿ“š
๐Ÿค
Book an audit with Zokyo