🖋️Gas Saving Tutorial 41: In-lining Single Use Modifiers For Gas Saving

Book an audit with Zokyo

Introduction: Modifiers in Solidity are powerful tools that provide a way to add pre-conditions to function executions. However, while they can make code more readable and modular, their use isn't always the most gas-efficient approach, especially when the modifier is used only once. In such scenarios, directly incorporating the modifier's logic into the function can save on gas costs. In this tutorial, we will discuss the concept of inlining modifiers and how it can help optimize gas consumption.

---

Concept: When a modifier is invoked, there's an associated overhead due to the added layer of execution. In cases where a modifier is used multiple times throughout a contract, this overhead can be justified by the enhanced readability and code reusability. However, when a modifier is used only once, the gas overhead becomes unnecessary, and inlining the modifier's logic directly into the function can result in gas savings.

---

Underlying Problem:

1. Extra Overhead: Using a modifier introduces additional gas costs related to its execution.

2. Redundancy: A modifier used only once doesn't capitalize on its primary advantage of code reusability.

---

Example:

With a Single-use Modifier:

solidityCopy codemodifier onlyWhitelistedProfileCreator() {
    require(isWhitelistedProfileCreator(msg.sender), "Not a whitelisted profile creator");
    _;
}

function createProfile(DataTypes.CreateProfileData calldata vars) external onlyWhitelistedProfileCreator {
    // Function logic
}

Inlining the Modifier:

solidityCopy codefunction createProfile(DataTypes.CreateProfileData calldata vars) external {
    require(isWhitelistedProfileCreator(msg.sender), "Not a whitelisted profile creator");
    // Function logic
}

---

Recommendation:

1. Review your contracts and identify any modifiers that are used only once.

2. For such single-use modifiers, directly incorporate the modifier's logic into the respective function.

3. Ensure that the logic's placement within the function doesn't affect the function's behavior or security.

4. Test the refactored code to guarantee consistent behavior.

5. Always prioritize gas optimization by assessing the true need for a modifier based on its frequency of use.

---

Conclusion: While modifiers are undeniably useful for enhancing code readability and modularization, they're not always the most gas-efficient option. Especially in cases of single-use modifiers, inlining them can save on gas, ensuring a more economical execution. By regularly evaluating the need for modifiers and balancing between readability and gas costs, developers can create efficient and cost-effective smart contracts.