Storage layout in Blockchain / Solidity - Step-by-Step Execution

Concept Flow - Storage layout

Define variables

↓

Assign storage slots

↓

Store values in slots

↓

Read values from slots

↓

Use values in contract logic

Storage layout shows how variables are assigned to storage slots in a blockchain contract and how values are stored and read.

Execution Sample

Blockchain / Solidity

uint256 a = 5;
uint256 b = 10;

// a stored at slot 0
// b stored at slot 1

function getA() public view returns (uint256) {
  return a;
}

This code stores two numbers in separate storage slots and reads one back.

Execution Table

Step	Action	Storage Slot	Value Stored	Variable	Result/Output
1	Define variable a	slot 0	uninitialized	a	none
2	Define variable b	slot 1	uninitialized	b	none
3	Assign a = 5	slot 0	5	a	none
4	Assign b = 10	slot 1	10	b	none
5	Call getA()	slot 0	5	a	returns 5
6	End	-	-	-	Execution complete

💡 Execution stops after returning value of a from slot 0

Variable Tracker

Variable	Start	After Step 3	After Step 4	Final
a	uninitialized	5	5	5
b	uninitialized	uninitialized	10	10

Key Moments - 2 Insights

Why does variable 'a' use slot 0 and 'b' use slot 1?

Variables are assigned storage slots in the order they are declared. 'a' is first, so slot 0; 'b' is second, so slot 1, as shown in steps 1 and 2 of the execution_table.

What happens if we read a variable before assigning a value?

Reading before assignment returns default uninitialized value (usually 0). In the table, before step 3, 'a' is uninitialized.

Visual Quiz - 3 Questions

Look at the execution_table, what value is stored in slot 1 after step 4?

A 10

B 5

C uninitialized

D 0

💡 Hint

Check the 'Storage Slot' and 'Value Stored' columns at step 4 in execution_table.

At which step does variable 'a' get its value assigned?

A Step 2

B Step 3

C Step 4

D Step 5

💡 Hint

Look at the 'Action' column in execution_table where 'Assign a = 5' happens.

If we add a new variable 'c' after 'b', which storage slot will it use?

A slot 0

B slot 1

C slot 2

D slot 3

💡 Hint

Variables are assigned slots in order; 'a' is slot 0, 'b' slot 1, so next is slot 2.

Concept Snapshot

Storage layout assigns each variable a unique storage slot.
Variables declared first get lower slot numbers.
Values are stored and read from these slots.
Uninitialized slots hold default values.
Reading a variable returns the value in its slot.

Full Transcript

Storage layout in blockchain contracts means each variable is stored in a specific slot in contract storage. When you declare variables, the first one gets slot 0, the second slot 1, and so on. Assigning a value stores it in that slot. Reading a variable fetches the value from its slot. If a variable is not assigned yet, its slot holds a default value, usually zero. This layout helps the contract know where to find each variable's data.

Practice

1. What does storage layout in a blockchain smart contract primarily describe?

easy

A. The order of function execution

B. The gas cost of transactions

C. How contract variables are stored in storage slots

D. The network consensus mechanism

Solution

1. Step 1: Understand storage layout concept

   Storage layout defines how contract variables are arranged and saved in storage slots on the blockchain.

2. Step 2: Differentiate from other concepts

   It is not about function order, gas cost, or consensus, but specifically about variable storage.

3. Final Answer:

   How contract variables are stored in storage slots -> Option C

4. Quick Check:

   Storage layout = variable storage arrangement [OK]

Hint: Storage layout = variable storage slots arrangement [OK]

Common Mistakes:

• Confusing storage layout with function execution order
• Thinking storage layout relates to gas costs
• Mixing storage layout with consensus mechanisms

2. Which of the following is the correct Solidity syntax to declare a uint256 variable named count stored in contract storage?

easy

A. uint256 count;

B. uint256 count = storage;

C. storage uint256 count;

D. var count uint256;

Solution

1. Step 1: Recall Solidity variable declaration

   In Solidity, storage variables are declared simply by specifying the type and name, e.g., uint256 count;.

2. Step 2: Identify incorrect syntax

   Options A, B, and D use invalid or unsupported syntax for storage variable declaration.

3. Final Answer:

   uint256 count; -> Option A

4. Quick Check:

   Correct Solidity declaration = uint256 count; [OK]

Hint: Declare storage vars as 'type name;' in Solidity [OK]

Common Mistakes:

• Adding 'storage' keyword in variable declaration
• Using 'var' keyword incorrectly
• Assigning 'storage' as a value

3. Given the Solidity contract snippet:

contract Example {
    uint128 a = 1;
    uint128 b = 2;
    uint256 c = 3;
}

How are the variables a, b, and c stored in storage slots?

medium

A. a and b share slot 0; c is in slot 1

B. Each variable occupies its own slot: a slot 0, b slot 1, c slot 2

C. a and c share slot 0; b is in slot 1

D. All variables share slot 0

Solution

1. Step 1: Understand slot packing rules

   Two uint128 variables fit into one 256-bit slot because 128 + 128 = 256 bits.

2. Step 2: Assign slots based on order and size

   a and b share slot 0; c is a uint256 and occupies slot 1 alone.

3. Final Answer:

   a and b share slot 0; c is in slot 1 -> Option A

4. Quick Check:

   Slot packing = smaller vars share slots [OK]

Hint: Smaller vars pack into one slot if total ≤ 256 bits [OK]

Common Mistakes:

• Assuming each variable always gets its own slot
• Mixing variable order in slots
• Ignoring bit size when packing variables

4. Consider this Solidity contract snippet:

contract Test {
    uint256 x;
    bool y;
    uint256 z;
}

What is the main storage layout issue here?

medium

A. The contract uses too many storage slots causing runtime error

B. The uint256 variables cannot be stored in the same slot

C. The variables are declared in the wrong order causing a syntax error

D. The bool y wastes storage slot space between x and z

Solution

1. Step 1: Analyze variable sizes and order

   uint256 uses full 256-bit slot; bool uses 8 bits but placed between two uint256 variables.

2. Step 2: Identify wasted storage

   Because bool y is between x and z, it cannot share slots efficiently, wasting space.

3. Final Answer:

   The bool y wastes storage slot space between x and z -> Option D

4. Quick Check:

   Storage gaps caused by small vars between large vars [OK]

Hint: Place small vars together to avoid wasted slots [OK]

Common Mistakes:

• Thinking variable order causes syntax errors
• Assuming all vars always share slots
• Believing too many slots cause runtime errors

5. You want to optimize storage in this Solidity contract:

contract Optimize {
    uint128 a;
    uint256 b;
    uint128 c;
    bool d;
}

Which variable order best minimizes storage slots used?

hard

A. uint256 b; uint128 a; uint128 c; bool d;

B. uint128 a; uint128 c; bool d; uint256 b;

C. bool d; uint128 a; uint256 b; uint128 c;

D. uint128 a; bool d; uint256 b; uint128 c;

Solution

1. Step 1: Group smaller variables to pack slots

   Placing uint128 a, uint128 c, and bool d together allows packing into fewer slots.

2. Step 2: Place large uint256 b separately

   uint256 b requires a full slot, so placing it last avoids gaps.

3. Step 3: Evaluate options

   uint128 a; uint128 c; bool d; uint256 b; groups small vars first, then large var last, minimizing slots used.

4. Final Answer:

   uint128 a; uint128 c; bool d; uint256 b; -> Option B

5. Quick Check:

   Group small vars first, large vars last [OK]

Hint: Put small vars together before large vars to save slots [OK]

Common Mistakes:

• Scattering small vars causing wasted slots
• Placing large vars before small vars
• Ignoring bool size when packing