Optimizing Storage

Reduce Solidity storage costs on peaq with mappings, packed variables, and events. Choose data structures and storage slots to lower gas usage.

Writing to storage is the most expensive thing a Solidity contract does. Every write costs gas, and a larger storage footprint raises both deployment and execution costs. peaq runs a standard EVM, so the optimizations that apply on Ethereum apply here too.

Prerequisites

• Solidity basics.
• How the EVM handles storage, memory, and calldata, and what each costs in gas.

Optimizations

Use mappings instead of arrays

Dynamic arrays need extra operations to manage (iteration, boundary checks) and can grow unbounded. A mapping suits sparse or keyed data. Keep an array when you need to iterate over every element or read the length.

// Example: Using a mapping instead of a dynamic array

// Less optimal: using a dynamic array
contract TestArray {
    uint256[] public items;
    
    function addItem(uint256 value) external {
        items.push(value);
    }
    
    // Accessing an element
    function getItem(uint256 index) external view returns (uint256) {
        return items[index];
    }
}

// More optimal: using a mapping
contract TestMapping {
    mapping(uint256 => uint256) public items;
    uint256 public itemCount;
    
    function addItem(uint256 value) external {
        items[itemCount] = value;
        itemCount++;
    }
    
    // Accessing an element
    function getItem(uint256 index) external view returns (uint256) {
        return items[index];
    }
}

TestMapping suits sparse data and skips the bounds checks an array needs. A separate counter (itemCount) tracks indices when you want array-like ordering.

Pack variables into slots

The EVM stores data in 256-bit slots. Variables smaller than a slot share one slot when they are declared next to each other.

contract DataPacking {
    // These three fill one 256-bit slot
    uint128 public valueA; // 128 bits
    uint64  public valueB; // 64 bits
    uint64  public valueC; // 64 bits
    
    // Another slot
    address public owner;   // 160 bits
    bool    public isActive; // 8 bits
    uint88  public counter;  // 88 bits
}

Group small types together and order them to fill each 256-bit slot. Fewer slots means fewer SSTORE operations and lower gas.

Use events for data you do not read on chain

Data you only need for history or off-chain display does not have to sit in storage. Emitting an event is cheaper, and the data stays retrievable from the transaction logs.

contract UseEvents {
    // Instead of storing all these logs on-chain...
    // mapping(uint256 => string) public logs;  // This can grow unbounded
    
    // Emit an event to record data
    event LogRecorded(uint256 indexed id, string info);
    
    function recordLog(uint256 _id, string memory _info) external {
        emit LogRecorded(_id, _info);
    }
}

Contracts cannot read event data, only off-chain indexers can, so move data to events only if your contract never needs it again. See indexing solutions for querying events.

Use bytes for variable-length data

For strings and other variable-length data, one bytes array packs the bytes continuously, with no space wasted per element.

contract BytesStorage {
    bytes public data; 
    
    function appendData(bytes memory newData) external {
        // Append in memory, then store
        data = abi.encodePacked(data, newData);
    }
}

Cut storage reads and writes

Each SSTORE costs gas, so write once instead of repeatedly:

• Cache a frequently updated value in memory and write it back once.
• Read a slot into a local variable rather than reading it several times in the same function. A memory read is far cheaper than a storage read.

contract StorageWrites {
    uint256 public counter;
    
    function incrementCounter(uint256 times) external {
        uint256 temp = counter; // Only one storage read
        for (uint256 i = 0; i < times; i++) {
            temp++;  // Increment in memory
        }
        counter = temp; // Single storage write
    }
}

Reset storage slots to zero

The EVM refunds gas when you clear a storage slot, that is, when you write zero to a slot that was non-zero. The refund is capped at a share of the transaction’s gas, so the saving is partial but real on large transactions.

contract StorageCleanup {
    mapping(address => uint256) public balances;
    
    function withdrawAll() external {
        uint256 amount = balances[msg.sender];
        require(amount > 0, "No balance");
        
        // Clear the slot
        balances[msg.sender] = 0;
        
        // Transfer or other business logic
        // ...
    }
}

Use structs

Grouping related variables into a struct keeps the data together and follows the same packing rules: fields smaller than 256 bits share a slot when they are declared next to each other.

struct UserInfo {
    uint8 age;
    uint64 score;
    bool isActive;
    // uint8 + uint64 + bool is 10 bytes, so these three share one slot
}

contract ManageUsers {
    mapping(address => UserInfo) public users;
    
    function setUserInfo(uint8 _age, uint64 _score, bool _active) external {
        // Single store operation if we read the struct first into memory, modify it, then write once
        UserInfo memory tempUser = users[msg.sender];
        tempUser.age = _age;
        tempUser.score = _score;
        tempUser.isActive = _active;
        
        users[msg.sender] = tempUser;
    }
}