What if your blockchain app lost all data just because you mixed up memory and storage?
Storage vs memory usage in Blockchain / Solidity - When to Use Which
Start learning this pattern below
Jump into concepts and practice - no test required
Imagine you are building a blockchain app that keeps track of user data. You try to store all information directly in memory while the app runs, hoping it will be fast and easy.
But memory is limited and expensive. If you keep too much data in memory, your app slows down or crashes. Also, when the app stops, all data in memory disappears. You lose important information.
Understanding the difference between storage and memory helps you save data safely and use memory efficiently. Storage keeps data permanently on the blockchain, while memory is for quick temporary use during transactions.
mapping(address => uint) balances; // storing all balances in memory during executionmapping(address => uint) balances; // balances stored in blockchain storage, memory used only for temporary calculations
This knowledge lets you build blockchain apps that run smoothly, save data securely, and avoid costly errors.
For example, a decentralized bank stores user balances in blockchain storage to keep them safe forever, but uses memory to calculate interest during each transaction.
Memory is fast but temporary and limited.
Storage is permanent but costs more and is slower.
Using both wisely makes blockchain apps efficient and reliable.
Practice
storage in blockchain smart contracts?Solution
Step 1: Understand storage purpose
Storage holds data permanently on the blockchain, so it remains after function execution.Step 2: Compare with memory
Memory is temporary and only lasts during function execution, unlike storage.Final Answer:
Permanent data saved on the blockchain that persists between function calls. -> Option AQuick Check:
Storage = permanent data [OK]
- Confusing memory with storage permanence
- Thinking storage is temporary
- Assuming storage is off-chain
- Believing storage is encrypted by default
memory?Solution
Step 1: Recall Solidity syntax for memory arrays
In Solidity, the correct syntax istype[] memory variableName;for memory arrays.Step 2: Check each option
uint[] memory numbers; matches the correct syntax:uint[] memory numbers;. Others have wrong order or keywords.Final Answer:
uint[] memory numbers; -> Option DQuick Check:
Memory arrays use 'type[] memory name' syntax [OK]
- Placing 'memory' before type
- Using 'storage' instead of 'memory'
- Incorrect array syntax
- Missing brackets for array type
pragma solidity ^0.8.0;
contract Test {
uint[] storageArray;
function addAndReturn() public returns (uint) {
uint[] memory tempArray = new uint[](1);
tempArray[0] = 5;
storageArray.push(10);
return tempArray[0];
}
}Solution
Step 1: Analyze tempArray usage
The function creates a memory array with one element set to 5, then returns that element.Step 2: Understand storageArray effect
storageArray.push(10) adds 10 to storage but does not affect the returned value.Final Answer:
5 -> Option CQuick Check:
Return value from memory array = 5 [OK]
- Confusing storage push with return value
- Expecting storageArray value as output
- Thinking memory array persists after function
- Assuming compilation error due to storage usage
pragma solidity ^0.8.0;
contract Example {
uint[] storageArray;
function copyArray() public view returns (uint[] memory) {
uint[] memory tempArray = storageArray;
return tempArray;
}
}Solution
Step 1: Understand storage to memory assignment
In Solidity, you cannot directly assign a storage array to a memory array variable.Step 2: Identify correct copying method
You must copy elements manually or use a loop to transfer data from storage to memory.Final Answer:
Cannot assign storage array directly to memory array. -> Option AQuick Check:
Direct storage to memory assignment is invalid [OK]
- Trying direct assignment from storage to memory
- Ignoring need for loops to copy arrays
- Assuming view functions can modify storage
- Believing memory arrays can't be returned
Solution
Step 1: Understand temporary modification needs
To avoid changing stored data, use a memory copy for temporary changes.Step 2: Evaluate options
Copy the storage array to a memory array, modify the memory array, then discard it. copies storage to memory, modifies memory, and discards changes, preserving storage.Step 3: Reject incorrect options
A declares memory in state (invalid syntax); B risks permanent changes if revert fails; C modifies storage directly.Final Answer:
Copy the storage array to a memory array, modify the memory array, then discard it. -> Option BQuick Check:
Use memory copy for temporary changes [OK]
- Modifying storage directly for temporary needs
- Trying to declare storage variables as memory in contract
- Assuming revert undoes all changes safely
- Using storage pointers for temporary changes
