:::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 balances
mapping 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 memory
keyword for uint
, bool
, address
and 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 {
function tryChangeCalldata(uint[] calldata nums)
external
pure
returns (uint[] memory)
{
// Copy from calldata to memory
uint[] memory numsCopy = new uint[](nums.length);
for (uint i = 0; i < nums.length; i++) {
numsCopy[i] = nums[i];
}
// Now modify the copy
if (numsCopy.length > 0) {
numsCopy[0] = 999;
}
return numsCopy;
}
}
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!!