Data Locations 🗺️ In Solidity

Each variable declared and used in a contract has a data location. It specifies where the value of that variable should be stored. In this article, we will go through the brief of data location and the rules. If you are new here, I would encourage you to read previous write-ups on Solidity.

Remember: The amount of gas you will use during a transaction depends on the data location you use in your smart contract. Hence, the best practice is to write an optimized code that uses a minimum amount of gas.

Solidity provides four types of data locations.

Storage
Memory
Calldata
Stack

Storage

The storage location is permanent data, which means that this data can be accessed into all functions within the contract. To make it more simple, you can think of it as the hard disk data of your computer where all the data gets stored permanently. Similarly, the storage variable is stored in the state of a smart contract and is persistent between function calls. Keep in mind that storage data location is expensive compared to other data locations.

Memory

The memory location is temporary data and cheaper than the storage location. It can only be accessible within the function. Usually, Memory data is used to save temporary variables for calculation during function execution. Once the function gets executed, its contents are discarded. You can think of it as a RAM of each individual function.

Calldata

Calldata is non-modifiable and non-persistent data location where all the passing values to the function are stored. Also, Calldata is the default location of parameters (not return parameters) of external functions.

Stack

Stack is a non-persistent data maintained by EVM (Ethereum Virtual Machine). EVM uses stack data location to load the variables during execution. Stack location has the limitation up to 1024 levels.

There are certain default rules in data locations

Rule 1

State variables are always stored in the storage.

pragma solidity ^0.5.0;
contract DataLocation {
//storage
uint stateVariable;
uint[] stateArray;
}

Also, you can not explicitly override the location of state variables.

pragma solidity ^0.5.0;
contract DataLocation {
uint storage stateVariable; // error
uint[] memory stateArray; // error
}

Rule 2

Function parameters including return parameters are stored in the memory.

Rule 3

Local variables with a value type are stored in the memory. However, for a reference type, you need to specify the data location explicitly.

pragma solidity ^0.5.0;
contract Locations {
/* these all are state variables */
//stored in the storage
bool flag;
uint number;
address account;
function doSomething() public {
/* these all are local variables */
//value types
//so they are stored in the memory
bool flag2;
uint number2;
address account2;
//reference type
uint[] memory localArray;
}
}

Local variables with value types cannot be overriden explicitly.

function doSomething() public {
/* these all are local variables */
bool memory flag2; //error
uint Storage number2; // error
address account2;
}

Rule 4

Function parameters (not including returns parameters) of external function are stored in the Calldata.

Default Copy Behavior

Data can be copied from one to another variable in two ways. One way is to copy the entire data (copy by value) and the second way is to copy by reference.

There are certain default behaviors of copy data location from one to another.

Rule 5

Assignment of one state variable to another state variable creates a new copy.

pragma solidity ^0.5.0;
contract Locations {
uint public stateVar1 = 10;
uint stateVar2 = 20;
function doSomething() public returns (uint) {
stateVar1 = stateVar2;
stateVar2 = 30;
return stateVar1; //returns 20
}
}

Here, in this example, stateVar1 and stateVar2 are the state variables. In doSomething function, we’re copying the value of stateVar2 to the stateVar1; now the value of stateVar1 would be 20. But to make sure it's creating a new copy, we have changed the value of stateVar2. So, if they would not create a copy, then the value of stateVar1 should be 30. However, as it’s creating a new copy, you will get 20 in return.

That same applies to reference type state variables.

Rule 6

Assignment to storage state variable from a memory variable always creates a new copy.

pragma solidity ^ 0.5.0;
contract Locations {
uint stateVar = 10; //storage
function doSomething() public returns(uint) {
uint localVar = 20; //memory
stateVar = localVar;
localVar = 40;
return stateVar; //returns 20
}
}

Here, in the above example, we’ve one state variable and one local variable. In the function, we’re assigning the value of the local variable to the state variable. To check the behavior, we’ve changed the value of our local variable; and returned the value of the state variable. Here you can see that it's returning 20 whether it's created a new copy or not.

Rule 7

Assignment to a memory variable from state storage variable will create a copy.

pragma solidity ^ 0.5.0;
contract Locations {
uint stateVar = 10; //storage
function doSomething() public returns(uint) {
uint localVar = 20; //memory
localVar = stateVar;
stateVar = 40;
return localVar; //returns 10
}
}

Here, we have assigned the value of the state variable to the local variable and changing the value of a state variable. Now, to check if the value of our local variable has changed or not, we’ve returned it. Here, localVar will have value 10 as its creating individual copy.

Rule 8

Assignment from one memory variable to another memory variable will not create a copy. This is applicable to reference type variables only. Local variable still creates a new copy.

Reference Type

pragma solidity ^ 0.5.0;
contract Locations {
function doSomething()
public pure returns(uint[] memory, uint[] memory) {
uint[] memory localMemoryArray1 = new uint[](3);
localMemoryArray1[0] = 4;
localMemoryArray1[1] = 5;
localMemoryArray1[2] = 6;
uint[] memory localMemoryArray2 = localMemoryArray1;
localMemoryArray1[0] = 10;
return (localMemoryArray1, localMemoryArray2);
//returns 10,4,6 | 10,4,6
}
}

In the above example, we have initialized one array variable in memory with the name localMemoryArray1 and assigned the values 4,5 and 6. Then, we copied that variable to the new memory variable called localMemoryArray2. Then, we have modified the value of the first index in localMemoryArray1 and returned both the arrays. This will give the same result as they both pointed at the same location.

Let’s check the same with a value type. The following function will create a new copy and return 20.

Value Type

pragma solidity ^ 0.5.0;
contract Locations {
function doSomething() public pure returns(uint) {
uint localVar1 = 10; //memory
uint localVar2 = 20; //memory
localVar1 = localVar2;
localVar2 = 40;
return localVar1; //returns 20
}
}

In this article, we have discussed different data locations - storage, memory, calldata, and stack. We've also covered default rules. In our next article, we will explore reference types in Solidity.

5 Comments

Join the conversation! Your thoughts help the community grow.

Sarathlal Saseendran7y ago
As usual good article in Solidity. I have a doubt on you. As per your opinion, which naming convention (for variables and methods and also for contracts) to be followed for Solidity? Javascript/Typescript or C#. Please advice
- Divyang Desai7y ago
  Thanks for the feedback Sarathlal and also thanks to asked the question :) Solidity has its own standard, find it at official doc: https://solidity.readthedocs.io/en/v0.5.3/style-guide.html
- Divyang Desai7y ago
  Well, I would say; both are on their own way, Ethereum is more suitable for public blockchain where some cryptocurrency transactions could take place, whereas Hyperledger (fabric) is more suitable for private or consortium blockchain and that can be used in enterprise applications.
- Sarathlal Saseendran7y ago
  Thank you very much Divyang Desai for your quick reply. I will check the entire document once I get free time. Your articles boost me to learn new things on Solidity :) Anyway I have a doubt on Hyperledger. Do you think, hyperledger has more edge than Etherium in future (I know this is irrelevant question in this current context)