Understand Solidity Storage in depth

Introduction

The slots in storage are stored as key-value pairs with a length of 256 bits (32 bytes). The default value of each slot is always 0, so we do not need to assign a value to 0 when the new declaration.

Basically, we can barely understand that variables in a contract will be stored in storage as follows:

  • Storage only stores variables, not constant

  • Each slot can store up to 256 bits (32 bytes)

  • The variables in turn are in slot in the order of lower-order (ie from right to left).

  • If the size of the variable exceeds the remaining size of the slot, this variable will be passed to the new slot.

  • Struct creates a new slot, the struct elements are put into the slot in the same way as above.

  • Fixed size array creates a new slot, struct elements are put into the slot in the same way as above.

  • Dynamic size array creates a new slot, this slot only stores the length of the array, while the values in the array will be stored at other locations (we will talk more in detail later)

  • Mapping always creates a new slot to hold a place, the values ​​in the array will be stored in other locations, we will talk more in detail later.

  • String creates a new slot, this slot stores both data & data length, we will talk more in detail later.

Going into practice, we will see that the combination of data types becomes much more complicated.

You may not know:

  • All variables in the contract are stored in storage and are accessible

  • Regardless of whether you have declared the variable privateor internalnot, it only works within the scope of the contract only, on the blockchain are all public. Of course, depending on the data type, there will be different encryption, but basically nothing is private at all.

Fixed size variables

The fixed size variables are single variables, using the basic data types such as uint8, uint16, uint24, uint32, uint64, uint128, uint256, bool, address we have a sample contract:

contract StorageTest {
uint256 a;
uint256[2] b;
struct Entry {
uint256 id;
uint256 value;
}
Entry c;
}

The variables will be stored in storage as follows:

  • ais stored in slot 0 and it occupies this slot due to the size of a256 bits (uint256)

  • boccupies a new slot (slot 1) which contains 2 elements. Because the data type of b is uint256, each element will occupy a slot. This means that b [0] will occupy slot 1, and b [1] will occupy slot 2

  • Struct Entry has just been declared, it does not count

  • cwill occupy a new slot (slot 3) and then put 2 elements in the struct in. Just like bthe above, every element is uint256so each will occupy a slot. The result is c.idoccupied slot 3 and c.valueoccupied slot 4

Another example:

pragma solidity ^0.5.9;
contract StorageTest {
uint8 public a = 7; //0
uint16 public b =10; //0
address public d = 0xbE03bCA4D65A86114668697867982Ecfc76f15F8; //0
bool public bb = true; //0
uint64 public c = 15; //0
uint256 public e = 200; //1
uint8 public f = 40; //2
uint256 public g = 789; //3
}

In this contract the variable is not full-slot size as before, so how is it arranged in storage?

  • a 8 bit size, put into slot 0

  • b 16 bit size, put into slot 0

  • d is the address. The address has 40 hexadecimal characters, so 160 bits

  • bb is bool type, only need 1 bit to store, but in solidity, the smallest data type is 8 bits, so bool will also occupy 8 bits; we put it into slot 0

  • c 64 bit, we still can put it into slot 0 because (a+b+d+bb+c = 256 bit)

  • e 256 bit, because slot 0 has been filled by (a,b,d,bb,c) with 256 bit, so e will be stored in slot 1

  • f 8 bit, f has to be stored in slot 2 because of a full of 256 bit of e

  • g 256 bit, put in slot 3

How do we verify this? We will deploy to a testnet network (here I use Ropsten) and then get the data to try.

Slot 0:

truffle(ropsten)> web3.eth.getStorageAt('0x9129970dce1274D3D6FB94B705F21eaAe8fABF1F', 0)
'0x000000000000000f01be03bca4d65a86114668697867982ecfc76f15f8000a07

So, as I've described earlier. It's stored from right to left in Hexadecimal, let's dive right into the analysis

0x000000000000000f01be03bca4d65a86114668697867982ecfc76f15f8000a070x000000000000000f01be03bca4d65a86114668697867982ecfc76f15f8000a07

a is 7 = 07 (Hex to Dec)

b is 10 = 0a (10 hex to Dec is a)

c is 0xbE03bCA4D65A86114668697867982Ecfc76f15F8

d is True = 01

bb is 15 = 0f

truffle(ropsten)> web3.utils.fromDecimal("0xbe03bca4d65a86114668697867982ecfc76f15f800")
'0xbe03bca4d65a86114668697867982ecfc76f15f800'

Slot 1:

e 200 = c8 (Hex to Dec)

truffle(ropsten)> web3.eth.getStorageAt('0x9129970dce1274D3D6FB94B705F21eaAe8fABF1F', 1)
'0x00000000000000000000000000000000000000000000000000000000000000c8'

Slot :2

f 40 = 28 (Hex to Dec)

truffle(ropsten)> web3.eth.getStorageAt('0x9129970dce1274D3D6FB94B705F21eaAe8fABF1F', 2)
'0x0000000000000000000000000000000000000000000000000000000000000028'

Slot 3:

g 789 = 315 (Hex to Dec)

truffle(ropsten)> web3.eth.getStorageAt('0x9129970dce1274D3D6FB94B705F21eaAe8fABF1F', 3)
'0x0000000000000000000000000000000000000000000000000000000000000315'

Dynamic Size variables