It only gets interesting as we see it one by one.

Ethereum State Machine

Block Level State Transition

Where

A FINALIZED_BLOCK_TRANISTION is a collective of a number of valid transaction level STATE_TRANSITIONS.

In Gas Golfing #1, We visited the ReentrancyGuard.sol from OpenZeppelin and discussed why a uint256 variable is used to mark the entry and exit of functions. They could have in fact used a bool or a uint8 . One of the reasons was covered in the article. We will deep dive into major reasoning in this section.

Beginning with the ReentrancyGaurd from OpenZeppelin. It is below here.

// SPDX-License-Identifier: MIT
// OpenZeppelin Contracts (last updated v4.8.0) (security/ReentrancyGuard.sol)

pragma solidity ^0.8.0;
/**
 * @dev Contract module that helps prevent reentrant calls to a function.
 *
 * Inheriting from `ReentrancyGuard` will make the {nonReentrant} modifier
 * available, which can be applied to functions to make sure there are no nested
 * (reentrant) calls to them.
 *
 * Note that because there is a single `nonReentrant` guard, functions marked as
 * `nonReentrant` may not call one another. This can be worked around by making
 * those functions `private`, and then adding `external` `nonReentrant` entry
 * points to them.
 *
 * TIP: If you would like to learn more about reentrancy and alternative ways
 * to protect against it, check out our blog post
 * <https://blog.openzeppelin.com/reentrancy-after-istanbul/>[Reentrancy After Istanbul].
 */
abstract contract ReentrancyGuard {
    // Booleans are more expensive than uint256 or any type that takes up a full
    // word because each write operation emits an extra SLOAD to first read the
    // slot's contents, replace the bits taken up by the boolean, and then write
    // back. This is the compiler's defense against contract upgrades and
    // pointer aliasing, and it cannot be disabled.
    // The values being non-zero value makes deployment a bit more expensive,
    // but in exchange the refund on every call to nonReentrant will be lower in
    // amount. Since refunds are capped to a percentage of the total
    // transaction's gas, it is best to keep them low in cases like this one, to
    // increase the likelihood of the full refund coming into effect.
    uint256 private constant _NOT_ENTERED = 1;
    uint256 private constant _ENTERED = 2;
    uint256 private _status;
    constructor() {
        _status = _NOT_ENTERED;
    }
    /**
     * @dev Prevents a contract from calling itself, directly or indirectly.
     * Calling a `nonReentrant` function from another `nonReentrant`
     * function is not supported. It is possible to prevent this from happening
     * by making the `nonReentrant` function external, and making it call a
     * `private` function that does the actual work.
     */
    modifier nonReentrant() {
        _nonReentrantBefore();
        _;
        _nonReentrantAfter();
    }
    function _nonReentrantBefore() private {
        // On the first call to nonReentrant, _status will be _NOT_ENTERED
        require(_status != _ENTERED, "ReentrancyGuard: reentrant call");
        // Any calls to nonReentrant after this point will fail
        _status = _ENTERED;
    }
    function _nonReentrantAfter() private {
        // By storing the original value once again, a refund is triggered (see
        // <https://eips.ethereum.org/EIPS/eip-2200>)
        _status = _NOT_ENTERED;
    }
    /**
     * @dev Returns true if the reentrancy guard is currently set to "entered", which indicates there is a
     * `nonReentrant` function in the call stack.
     */
    function _reentrancyGuardEntered() internal view returns (bool) {
        return _status == _ENTERED;
    }
}

I am interested in the below section of the code.

uint256 private constant _NOT_ENTERED = 1;
uint256 private constant _ENTERED = 2;
uint256 private _status;

Why is OpenZeppelin using 1 and 2 integer constants and not 0 and 1 constant integers or false and true boolean constants to mark the entry and exit of execution of the code block?

The simple answer here is again Gas Optimization.

The best way to understand this is by

1. Creating a sample contract and checking the gas utilization of certain functions.

2. Learning about the EVM and opcodes in a certain depth

3. We will also visit certain snippets (The Uncharted Territory by most Solidity Developers) in the yellow paper.

Hence we will do this over multiple articles.

Zero Values

The default value of a variable is also called Zero Value. Examples are

0 --> for intergers and unsigned integers
false --> for booleans
0x0000000000000000000000000000000000000000 --> for address

Non-Zero Values

Any value other than zero values are non-zero values for that variable. Examples are

permitted numbers other than ZERO -> for integers and non-integers
true -> for boolean
other addresses -> for address

So what is the importance of this distinction?

Zero Values do not occupy any storage in the blockchain. Irrespective of what storage slot or variable type is associated with a slot, the blockchain does not need to manage the zero values as they are default. At the same time, any non-zero value that is to be stored on the chain needs to be updated on all the nodes of that chain.

Let’s take the below code sample deployed with no optimization

// SPDX-License-Identifier: MIT
pragma solidity 0.8.19;

contract Example {
    uint256 val;
    // Input : 100 
    // Transaction Cost: 43702 gas
    // Execution Cost = 43702 - 21000 = ~22500+ gas
    // SSTORE = 20000 units
    // Input : 0 
    // Transaction Cost: 21709 gas
    // Execution Cost = 21709 - 21000 = ~709 gas? 
    // But the actual execution cost is 5398 units
    function setval(uint256 _val) external {
        val = _val;
    }
}

val is initialized to zero on contract deployment And can be set to a desired unsigned integer using setVal.

Points to note:

1. Setting the uint256 val to 100 consumes more than 20000 units of gas towards storing the value on the chain. This is zero to non-zero transition. They are costly.

2. Setting the uint256 val to 0 consumes just 709 units of gas for storing the zero-value on the chain. This is non-zero to zero transition. They are gas-saving because the blockchain does not need to store the data on the chain. Hence Ethereum rewards the removal of value from the chain. Only 709 gas units of the sender are used while the execution cost is 5398 units.

3. A total of 23000+ units of gas for set and unset of val.

Now lets the try the sample with slight changes. val is initialized to 1.

// SPDX-License-Identifier: MIT
pragma solidity 0.8.19;

contract Example {
    uint256 val = 1 ;
    // Input : 100 
    // Transaction Cost: 26602 gas
    // Execution Cost = 26602 - 21000 = 5398 gas
    // Input : 1 
    // Transaction Cost: 26602 gas
    // Execution Cost = 26602 - 21000 = 5398 gas
    function setval(uint256 _val) external {
        val = _val;
    }
}

Points to note:

1. Setting the uint256 val to 100 consumes 5398 units of gas for storing the value on the chain. This is a non-zero to non-zero transition. And the same for setting val to 1.

2. A total of 10600+ units of gas for set and unset of val.

This is why ReentrancyGuard does not use either bool or zero-values for setting and unsettling the variable values in places where the values of a variable toggle frequently.

Just pick up a token and check its transactions and most likely you will see varying gas units consumed for the same token transfer and this is most likely the reason for the varying gas units consumed.

Conclusion

In conclusion, choose not only the variable type but also the initial variable values carefully.

Such excellent learning from just one contract of the OpenZeppelin. Kudos to the OZ team.

To get involved with the Footium universe one needs to own a Footium club. As a Footium club owner, one will receive:

🎮 GAME ACCESS: Gain access to the game

🏟️ STADIUM: A unique, 3D stadium associated with your club

⚜️ BADGE: A generative club badge that can be upgraded

📖 LORE: Unique, AI-generated lore for each club, including info on the fanbase, history, and more that can evolve through in-game achievements

👕 KIT: Club kit and colors for your team

👨🏻‍🤝‍👨🏾 SQUAD: An initial squad of 20 players of varying positions and ratings

🏫 ACADEMY: An academy that produces new youth players every season

Minted Clubs:

At the moment clubs are only available on secondary markets.

Rarible: https://rarible.com/footium/items

OpenSea: https://opensea.io/collection/footium-football-clubs

Assets

Club NFTs

ERC721 Tokens: https://etherscan.io/token/0x659cf1306edba213d1fb8f9352b4593a82b05d0c

The club NFTs have the below attributes:

1. Place:

   • Club Colour :

     • League: Each division has $2^n$ leagues, <String as “Division 8, League 136”>

     • Division : 1- 8

       • Stadium Capacity:

       {
         "name": "Swafornbursh",
         "description": "Swafornbursh F.C. is a professional football club based in Swafornbursh.",
         "external_url": "<https://footium.club/ethereum/clubs/624>",
         "image": "ipfs://Qmbs8JSa5hFxoktUcqzeVBqLsaKiSfDcdh3FMpi3NMgj5c/624.svg",
         "attributes": [
           {
             "trait_type": "Place",
             "value": "Swafornbursh"
           },
           {
             "trait_type": "Club colours",
             "value": "Blue and white"
           },
           {
             "trait_type": "League",
             "value": "Division 8 - League 136"
           },
           {
             "display_type": "number",
             "trait_type": "Division",
             "value": 8
           },
           {
             "display_type": "number",
             "trait_type": "Stadium capacity",
             "value": 1730
           }
         ]
       }
       

       More Info: https://footium.gitbook.io/footium-wiki/assets-breakdown/clubs

       Academy

       The academy is how new talent enters the game. All the players enter the game aged 18.

       • New football players up to age 20 are part of academy, bound to the club. Can play in the first team. Not on-chain

       • Greater than 20 are free agents that can be minted into the squad else any club can buy at auction.

       • Owning the player NFT, the club can sell or loan players

       • 10 new academy prospects every season(about a month in realtime).

       • Within each cohort there will be a varied distribution of quality

       • On chain : NFT player and contract

       • Off chain: Academy prospect

       Player Signing

       Club owner wants to sign a youth player on a contract, they mint them as an NFT. This will incur a small minting fee(in footium tokens) that will go toward funding prize pools corresponding to the club’s league

       Infrastructure Investments

       Investing in the club’s facilities such as the stadium and academy to improve their quality.

       • Investing in your academy will increase the average quality of players produced.

       • Investing in your stadium will give you the ability to upgrade its appearance and capacity, and also give your team a larger home advantage during home games.

       Coaching and Specialisation

       No specific details

       Stadium

       Each Footium club comes with a generative, upgradable 3D stadium — no NFT

       Customizable and Upgradeable.

       Home match advantage

       Customisation and Upgrades

       Club owners will be able

       • to invest capital( via tokens?) to enhance their stadium.

       • Higher division — higher upgradability options. can be earned via in-game rewards

       Impact on Performance

       • The home-ground advantage is a real thing.

       • Big Stadium → Big Crowd → Higher team morale → Higher winning chances

       Sponsorship Opportunities

       Big plans ahead to make Clubs profitable/ operatable via sponsorships

       An artist’s impression of the Footium National Stadium, where the Cup Finals will be played.

       Players

       Every player within the game is an NFT with either generative or bespoke artwork. (Could not find the NFT !!)

       • generative image

       • generated with a number of randomized attributes that ultimately contribute to their overall rating at the time of their minting

       • as well as their potential future overall rating.

       Footium sorts player attributes into how directly they affect the match simulation. These are:

       Influencer Attributes (External): Attributes that correspond to the different game state characteristics

       1. Injury status: Players can get injured which puts them out of action for a few games. Waiting for their condition to recover may be a wise move!

       2. Captain: A team’s captain is instrumental in binding a team together. Within Footium you must pick a captain from your starting eleven. Players have Leadership ratings, and choosing a captain with a high will give your team a boost. Captains serve to improve morale and therefore overall performance.

       3. Training: Training influences players’ performance by improving their skills and teamwork.

       4. Stadium: A great stadium can influence player performance by improving home-ground advantage. This morale indirectly impacts match performance by influencing players’ in-game performance

       Measured Attributes (Indirect): Attributes that correspond to the player’s response to external events.

       1. Positioning: A player can be fielded in any position. However, that player’s rating in his optimal position isn’t necessarily transferrable to other positions. Instead, players have a different rating for every position. The position a player is in during a match isn’t their defining characteristic generally, but it guides their decision-making and the nature of their performance on the pitch.

       2. Mentality

       3. Interceptions

       4. Decision making

       5. Leadership

       Conditional Attributes: Those attributes that indirectly affect match performance by influencing measured attributes. These attributes correspond to changes in the player’s internal and external state and mental and physical states.

       1. Internal StatesMental: Morale: External StatesPhysical: Condition corresponds to how physically fresh or tired a player is when playing a game. During a game, a player’s condition falls, and playing many games consecutively without rest can lead to significantly worsened performance

       2. **ConditionMental: Experience/Familiarity: **Experience is a function of the amount and the quality of a player’s match experience. Players gain experience by playing in matches. This improves the skills of the player, with a bias towards the main skills used in the position they played in for each match. For example, a centre-back will gain a lot of experience in tackling, whilst a center-forward would gain experience shooting.

       Math affecting the in-game match simulation (ELO rating): https://footium.gitbook.io/footium-wiki/assets-breakdown/players/conditional-attributes/condition

       Measured Attributes (Direct): Those attributes that directly affect events in the match

       1. Heading

       2. Shooting

       3. Pace

       4. Dribbling, etc.

       More on direct and indirect attributes here: https://footium.gitbook.io/footium-wiki/assets-breakdown/players/measured-attributes

       Competitions

       League Competitions

       Division: 1–8. (More in the future?)

       Each division has $2^{division-1}$ leagues

       Currently, the bottom of the FFL, Division 8, has 128 leagues of 12 teams (1,536 clubs in Division 8)*(from the doc)

       Note: Clubs in Division 1 cannot be promoted and clubs in Division 8 cannot be relegated.(Check on this ?)

       Games take place every day in seasons of 22 games.

       Cup Competitions

       Some discrepancies in the doc itself with the number of cup competitions. May not be relevant to solidity though. Will wait for further details

       Gameplay

       I do not expect everything to be on the chain. I guess things like the Tactics, Strategy shall be off-chain.

       Prize Pools Sources

       Academy Players

       Signing an academy player as part of the squad requires a “signing-on” fee, which is used for prize pools. Once an unsigned player reaches 21 they become a free agent and can be signed by any club. If you release him, any other club will be able to sign him via an auction.

       • Signing Fee/ minting fee

       Transfer Market

       • Transfer Fees applicable on Payer transfer — 5% → Club’s League prize pool

       Loans

       • Player Loan at a price or free on staking the player asset

       Academy Improvements

       Clubs will be able to purchase more coaching slots for your club, corresponding to how many coaches you can employ at any given time. This goes into the prize pool of the purchasing club’s league.

       Stadium Improvements

       You will be able to upgrade your stadium with larger and more stylistic stands by spending Footium tokens. These fees also flow into the prize pool for your league. Functionally, this permits a larger fanbase**,** leading to better morale and performance for your team, and visually allowing you to flex your club’s prestige.

       Legendary Player Auctions

       Each season we will auction off 20 Legendary players. These players will have bespoke artwork designed by different artists in different styles, as well as strong in-game stats and a high potential maximum rating.

       The revenue generated from sales of Legendary players will go into prize pools split across all divisions.

       Potential to have real-world players as Legendary players in the game in future.

       Sponsorship

       Sponsorship of Footium divisions

       Prize Distribution

       Prizes will be split across the Top 9 teams finishing each league season. The payout of the prize pool for each position will follow the distribution in the table below:

       Position % of Prize Pool Payout 1st 28 2nd 20 3rd 16 4th 10 5th 8 6th 6 7th 5 8th 4 9th 3

       Bottom 3 teams to relegate to the lower division. !st team to automatically promote to the higher division.

       Revenue split

       Initially, all revenue generated in-game will go into the prize pools. In the future.

       Previous Audit History

       None: Juicy fresh bugs.

       Scope

       footium-eth-shareable @ 6c181ea79af7f6715e3891e65ea5ee8def1e957c

       • footium-eth-shareable/contracts/FootiumAcademy.sol

       • footium-eth-shareable/contracts/FootiumClub.sol

       • footium-eth-shareable/contracts/FootiumClubMinter.sol

       • footium-eth-shareable/contracts/FootiumEscrow.sol

       • footium-eth-shareable/contracts/FootiumGeneralPaymentContract.sol

       • footium-eth-shareable/contracts/FootiumPlayer.sol

       • footium-eth-shareable/contracts/FootiumPrizeDistributor.sol

       • footium-eth-shareable/contracts/FootiumToken.sol

       • footium-eth-shareable/contracts/common/Errors.sol

       • footium-eth-shareable/contracts/interfaces/IFootiumClub.sol

       • footium-eth-shareable/contracts/interfaces/IFootiumPlayer.sol

       • footium-eth-shareable/contracts/mocks/FootiumPlayerMockV2.sol

       EIPs

       The FootiumEscrow contract complies with the EIP-1271 (Standard Signature Validation Method for Contracts) standard, the purpose is for each club to have its own FootiumEscrow contract deployed, and each contract can create a signature for OpenSea to buy or sell FootiumPlayer NFTs

       ERC20

       ERC721

This article is a continuation of Gas Golfing #1. In the previous article, we discussed how uint8 consumes more gas than uint256. Then a very natural question arises.

Variable Packing

If uint8 costs more than uint256 then what is the need to have all of those supported units from 8 256 and why not have uint256 alone?

The simple answer to that question is variable packing in solidity. Let us understand more of that through an example. (Deployment optimized for 1000 runs)

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.19;
contract VariablePacking {
    uint8 smallNum = 21;  // Occupies Slot 0 of Storage
    uint8 anotherSmallNum = 22; // Occupies Slot 0 of Storage
    uint256 bigNum = 12134567890; // Occupies Slot 1 of Storage
    // 2351 gas (Cost only applies when called by a contract)
    function readSmallNum() public view returns(uint8){
        return smallNum;
    }
    // 2307gas (Cost only applies when called by a contract)
    function readAnotherSmallNum() public view returns(uint8){
        return anotherSmallNum;
    }
    // 2248 gas (Cost only applies when called by a contract)
    function readBigNum() public view returns(uint256){
        return bigNum;
    }
    // Input 0: 0x0000000000000000000000000000000000000000000000000000000000001615
    // Input 1: 0x00000000000000000000000000000000000000000000000000000002d346cfd2
    function getValueAtSlot(uint256 slotNum) public view returns (bytes32) {
        bytes32 value;
        assembly {
            value := sload(slotNum)
        }
        return value;
    }
}

This sample just adds another variable anotherSmallNum to the previous example and a getter function for the same. This slightly changes the gas units consumed.

📑 But an important thing to note is that the values smallNum and anotherSmallNum occupy the slot0 of the storage. So there is less initial gas cost on deployment. But higher execution gas consumption. The solidity compiler does this by packing of variables in a slot whenever applicable.

A refactor in the below way can be beneficial concerning gas consumed in execution. But at the cost of using an extra storage slot during deployment.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.19;
contract Refactored {
    uint256 smallNum = 21;  // Occupies Slot 0 of Storage
    uint256 anotherSmallNumber = 22; // Occupies Slot 0 of Storage
    uint256 bigNum = 12134567890; // Occupies Slot 1 of Storage
    // 2324 gas (Cost only applies when called by a contract)
    function readSmallNum() public view returns(uint256){
        return smallNum;
    }
    // 2280gas (Cost only applies when called by a contract)
    function readAnotherSmallNum() public view returns(uint256){
        return anotherSmallNumber;
    }
    // 2247 gas (Cost only applies when called by a contract)
    function readBigNum() public view returns(uint256){
        return bigNum;
    }
    // Input 0: 0x0000000000000000000000000000000000000000000000000000000000000015
  // Input 1: 0x0000000000000000000000000000000000000000000000000000000000000016
    // Input 2: 0x00000000000000000000000000000000000000000000000000000002d346cfd2
    function getValueAtSlot(uint256 slotNum) public view returns (bytes32) {
        bytes32 value;
        assembly {
            value := sload(slotNum)
        }
        return value;
    }
}

When to use variable packing?

So is the packing of variables of any use at all?

It is useful when all the variables in the slot are read together. Like via the structs.

Let’s look at the sample codes below and check their gas utilization. (Deployment optimized for 1000 runs)

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.19;
contract PackingInStructs {
    struct VariablesNotPacked{
        address myAddress;
        uint256 myage;
        bool areYouHappy;
    }
    struct VariablesPacked{
        bool areYouHappy;
        uint8 myage;
        address myAddress;
    }
    VariablesNotPacked a;
    VariablesPacked b;
    constructor() {
        a = VariablesNotPacked(msg.sender, 36, false);
        b = VariablesPacked(true, 36, msg.sender); 
    }
    // 6774 gas (Cost only applies when called by a contract)
    function readVariablesNotPacked() public view returns(VariablesNotPacked memory){
        return a;
    }
    // 2550 gas (Cost only applies when called by a contract)
    function readVariablesPacked() public view returns(VariablesPacked memory){
        return b;
    }
    // Input 0: 0x0000000000000000000000005b38da6a701c568545dcfcb03fcb875f56beddc4  - a.myAddress
    // Input 1: 0x0000000000000000000000000000000000000000000000000000000000000024  - a.age
    // Input 2: 0x0000000000000000000000000000000000000000000000000000000000000000  - a.areYouHappy
    // Input 3: 0x00000000000000000000|5b38da6a701c568545dcfcb03fcb875f56beddc4|24|01|
    //            - | b.myAddress | b.age | b.areYouHappy|
    function getValueAtSlot(uint256 slotNum) public view returns (bytes32) {
        bytes32 value;
        assembly {
            value := sload(slotNum)
        }
        return value;
    }
}

📑 Below is the summary

Note the huge difference in gas units consumed

Note how the storage slot for VariablesNotPacked is spread across 3 slots while only one slot in VariabledPacked

Conclusion

In conclusion, choosing the appropriate data type is essential when designing smart contracts in Solidity. Also, enable variable packing by crafty arrangements of the variables.

Links:

https://github.com/sudeepjc/anuha/tree/main/contracts/gas-golfing-2

https://github.com/sudeepjc/anuha/tree/main/test/gas-golfing-2

Below is the ReentrancyGuard.sol from OpenZeppelin

// SPDX-License-Identifier: MIT
// OpenZeppelin Contracts (last updated v4.8.0) (security/ReentrancyGuard.sol)
pragma solidity ^0.8.0;
/**
 * @dev Contract module that helps prevent reentrant calls to a function.
 *
 * Inheriting from `ReentrancyGuard` will make the {nonReentrant} modifier
 * available, which can be applied to functions to make sure there are no nested
 * (reentrant) calls to them.
 *
 * Note that because there is a single `nonReentrant` guard, functions marked as
 * `nonReentrant` may not call one another. This can be worked around by making
 * those functions `private`, and then adding `external` `nonReentrant` entry
 * points to them.
 *
 * TIP: If you would like to learn more about reentrancy and alternative ways
 * to protect against it, check out our blog post
 * <https://blog.openzeppelin.com/reentrancy-after-istanbul/>[Reentrancy After Istanbul].
 */
abstract contract ReentrancyGuard {
    // Booleans are more expensive than uint256 or any type that takes up a full
    // word because each write operation emits an extra SLOAD to first read the
    // slot's contents, replace the bits taken up by the boolean, and then write
    // back. This is the compiler's defense against contract upgrades and
    // pointer aliasing, and it cannot be disabled.
    // The values being non-zero value makes deployment a bit more expensive,
    // but in exchange the refund on every call to nonReentrant will be lower in
    // amount. Since refunds are capped to a percentage of the total
    // transaction's gas, it is best to keep them low in cases like this one, to
    // increase the likelihood of the full refund coming into effect.
    uint256 private constant _NOT_ENTERED = 1;
    uint256 private constant _ENTERED = 2;
    uint256 private _status;
    constructor() {
        _status = _NOT_ENTERED;
    }
    /**
     * @dev Prevents a contract from calling itself, directly or indirectly.
     * Calling a `nonReentrant` function from another `nonReentrant`
     * function is not supported. It is possible to prevent this from happening
     * by making the `nonReentrant` function external, and making it call a
     * `private` function that does the actual work.
     */
    modifier nonReentrant() {
        _nonReentrantBefore();
        _;
        _nonReentrantAfter();
    }
    function _nonReentrantBefore() private {
        // On the first call to nonReentrant, _status will be _NOT_ENTERED
        require(_status != _ENTERED, "ReentrancyGuard: reentrant call");
        // Any calls to nonReentrant after this point will fail
        _status = _ENTERED;
    }
    function _nonReentrantAfter() private {
        // By storing the original value once again, a refund is triggered (see
        // <https://eips.ethereum.org/EIPS/eip-2200>)
        _status = _NOT_ENTERED;
    }
    /**
     * @dev Returns true if the reentrancy guard is currently set to "entered", which indicates there is a
     * `nonReentrant` function in the call stack.
     */
    function _reentrancyGuardEntered() internal view returns (bool) {
        return _status == _ENTERED;
    }
}

I am interested in the below section of the code.

uint256 private constant _NOT_ENTERED = 1;
uint256 private constant _ENTERED = 2;
uint256 private _status;

Why is OpenZeppelin using uint256 as against uint8 when the only required values 1 and 2 can fit in the range of uint8?

The simple answer is Gas Optimization.

When writing smart contracts in Solidity, gas optimization is crucial. One way to optimize gas usage is by choosing the appropriate data types. Solidity supported a wide range of unsigned integers ranging between uint8 to uint256 with a gap of 8 bits. In this write-up, we will explore which of these data types is more efficient to store and use.

Storage

uint8

As the name suggests, uint8 is an unsigned integer that can hold a maximum value of 2⁸-1, which is 255. Therefore, uint8 should use only 1 byte of storage space.

uint256

On the other hand, uint256 is an unsigned integer that can hold a maximum value of 2²⁵⁶-1, which is an incredibly large number. Therefore, uint256 requires 32 bytes of storage space.

Let’s take the below code sample

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.19;
contract Example {

    uint8 smallNum = 21;  // Occupies Slot 0 of Storage
    uint256 bigNum = 12134567890; // Occupies Slot 1 of Storage

    // 2311 gas (Cost only applies when called by a contract)
    function readSmallNum() public view returns(uint8){
        return smallNum;
    }

    // 2248 gas (Cost only applies when called by a contract)
    function readBigNum() public view returns(uint256){
        return bigNum;
    }

    // Input 0: 0x0000000000000000000000000000000000000000000000000000000000000015
    // Input 1: 0x00000000000000000000000000000000000000000000000000000002d346cfd2
    function getValueAtSlot(uint256 slotNum) public view returns (bytes32) {
        bytes32 value;
        assembly {
            value := sload(slotNum)
        }
        return value;
    }
}

In the contract storage, the variables are organized in slots of 32 bytes each irrespective of whether it was uint8 or uint256.

Values at a given slot can be accessed by using the assembly code below:

assembly {
     value := sload(slotNum)
}

Execution

The above contract was deployed with optimization turned on for 1000 runs.

• readBigNum requires 2248 units of gas

• readSmallNum requires 2311 units of gas

One of the primary reasons why reading the uint8 value is costlier than uint256 is because when the uint8 value is read by EVM it reads the whole slot first and performs extra masking operations, while the uint256 value is returned directly. And any extra opcode operations mean extra gas consumption.

Conclusion

In conclusion, choosing the appropriate data type is essential when designing smart contracts in Solidity. Please consider the learnings from the above section to choose the appropriate data type.

Now that we know the reason for openzeppelin’’s use of uint256 datatypes check the **anuha** GitHub repo and gas-golf-1 folder sample that compare and illustrate the ReentrancyGuard.sol‘s uint8 vs uint256 versions.

Links:

https://github.com/sudeepjc/anuha/tree/main/contracts/gas-golfing-1

https://github.com/sudeepjc/anuha/tree/main/test/gas-golfing-1

Who am I?

Solidity Smart Contract developer || Gas Golfing || Audit || Seasoned Software Developer

Social handles

LinkedIn: https://www.linkedin.com/in/sudeep-sagar/

GitHub: https://www.github.com/sudeepjc (needs serious cleanup)

Twitter: https://www.twitter.com/sudeepjc