Memory, Calldata, and Storage in Solidity: Understanding the Differences

:::warning DISCLAIMER:

• The code in this article is for educational purposes only.

:::

If you are finding it difficult to comprehend either storage, memory, or calldata, you are not alone. This is an area most beginner developers struggle to grasp, and even some experienced Solidity developers still don’t fully understand.

What are these ‘special words’? They are words that specify the main data locations in a Solidity smart contract. Data locations in Solidity describe where data can be stored and how it can be accessed on the Ethereum blockchain. Other data locations include the following:

• Stack
• Code
• Logs

In this article, you will learn the differences between each main data location option and where to use each.

Firstly, what is storage?

Storage

Storage is the data location that holds a smart contract’s state variables. A state variable is data that lives permanently on the blockchain. Each smart contract has its own storage space (an array of 2^256 32-byte slots), and state variables are automatically assigned to storage.

The code snippet below shows a simple implementation of a state variable stored in storage, as well as its getter and setter functions: \n

// SPDX-License-Identifier: MIT pragma solidity ^0.8.26; contract Storage {     /////////////////////////////     // STATE VARIABLES //////////     /////////////////////////////     uint256 public s_storedData; // s_storedData is a storage variable, s_ denotes a storage variable     /////////////////////////////     // SETTER FUNCTION //////////     /////////////////////////////     function set(uint256 x) public {         s_storedData = x; // This value is saved permanently on-chain     }     /////////////////////////////     // GETTER FUNCTION //////////     /////////////////////////////     function getStoredData() public view returns(uint256) {         return s_storedData;     } } 

In the code above, the  s_storedData remains on the blockchain after the set() function runs.

More importantly, storage is one of the major data location options that isn’t explicitly specified. Any variable declared outside any function is implicitly converted to a storage variable.

Use-case

The Bank contract above acts as a simple bank, as the name implies. The balancesmapping is stored in storage, which means it remembers values across function calls.

For instance, if Alice calls deposit(100), her balance is saved in storage in the balances mapping. Conversely, if she calls withdraw(60), she receives 60 and the mapping updates to 40.

Memory

Unlike Storage, Memory is a temporary, function-scope data location. Function-scope means, variables exist only during a function call, not at the contract-level, and clears afterwards. Additionally, memory allows for read-write access; this means variables are modified within a function. Solidity allocates memory to variables defined inside a function(local variables) or parameters marked memory.

To demonstrate:

// SPDX-License-Identifier: MIT pragma solidity ^0.8.26; contract Memory {     function multiply(uint256 a, uint256 b) public pure returns (uint256) {         uint256 result = a * b; // 'result' is stored in memory         return result; // 'result' does NOT persist after the function ends     } } 

In the code above, Solidity implicitly stores result in memory, which does not persist after the function execution.

Use-case

The code below concatenates two string inputs, string memory first, string memory second exist while the function combineStrings runs.

A note on function parameters

// SPDX-License-Identifier: MIT pragma solidity ^0.8.26; contract Memory {     function multiply(uint256 memory a, uint256 memory b) public pure returns (uint256) {         uint256 result = a * b;         return result;      } } 

For function parameters, you can’t specify the memorykeyword for uint, bool, addressand enum variables as they are directly stored on the contract’s stack, no explicit keyword.

Whereas for reference types like strings, bytes, arrays, structs, and mapping, you will have to specify or defaults to memory for internal and private functions and calldata for external and public functions(more on this below👇).

Calldata

Lightly touched on in the previous section, calldata is another temporary data location, but it’s reserved for external function parameters.  Also, unlike memory, calldata cannot be modified. To explain what this means, let’s take a look at the code below:

\

// SPDX-License-Identifier: MIT pragma solidity ^0.8.26; contract Example {     function tryChangeCalldata(uint[] calldata nums) external pure returns (uint[] calldata) {         nums[0] = 999; // ❌ ERROR — "calldata is read-only"         return nums;     } } 

The error message above shows that calldata is read-only. To modify calldata variables, they must first be loaded into memory.

Take the adjusted code below now modified .The code below works because the it loads nums variable to memory before modifying it in the if block.

\

// SPDX-License-Identifier: MIT pragma solidity ^0.8.26; contract Example { &nbsp; &nbsp; function tryChangeCalldata(uint[] calldata nums)&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; external&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; pure&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; returns (uint[] memory)&nbsp; &nbsp; &nbsp; { &nbsp; &nbsp; &nbsp; &nbsp; // Copy from calldata to memory &nbsp; &nbsp; &nbsp; &nbsp; uint[] memory numsCopy = new uint[](nums.length); &nbsp; &nbsp; &nbsp; &nbsp; for (uint i = 0; i < nums.length; i++) { &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; numsCopy[i] = nums[i]; &nbsp; &nbsp; &nbsp; &nbsp; } &nbsp; &nbsp; &nbsp; &nbsp; // Now modify the copy &nbsp; &nbsp; &nbsp; &nbsp; if (numsCopy.length > 0) { &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; numsCopy[0] = 999; &nbsp; &nbsp; &nbsp; &nbsp; } &nbsp; &nbsp; &nbsp; &nbsp; return numsCopy; &nbsp; &nbsp; } } 

\

Why Data Locations Matter

Using appropriate data locations matters as they directly affect how your contracts store, access, and pay for data. The differences can have a large impact on cost, behaviour, and security of your smart contracts. Here’s how:

Gas Costs

• Writing data to Storage is the most expensive.
• The gas costs in Memory is more moderate than storage.
• Calldata is the cheapest data location, i.e., writing to calldata costs the least amount of gas.

Persistence and Temporariness

• Any data written to Storage lives onchain, meaning the data is permanent.
• Memory only persists during the function’s lifecycle.
• Calldata acts like memory in handling data, only it can’t be changed.

Mutability

• Storage data can be modified.
• Similar to Storage, Memory can be modified but only within the context of a function.
• Calldata is read-only.

Safety

• Storage can be a risky choice of location because mistakes or hacks can permanently change the blockchain’s state.
• Memory is a safer option since changes are temporary.
• Calldata is the safest for passing input for external functions.

Wrapping Up

That’s it for this piece, as previously stated, using the appropriate data locations is integral to the functionality of your contracts. I implore you to research further about the other types of data locations mentioned in the introduction of this article.

Happy Hacking!!