Storage layout in Blockchain / Solidity - Cheat Sheet & Quick Revision

Recall & Review

beginner

What is storage layout in blockchain smart contracts?

Storage layout is how data is organized and stored in the blockchain's persistent storage for a smart contract. It defines where each variable is saved so the contract can access it later.

intermediate

Why is understanding storage layout important when upgrading smart contracts?

Because changing the order or type of variables can corrupt stored data. Proper storage layout ensures new versions read and write data correctly without breaking existing state.

intermediate

How are state variables stored in Ethereum smart contracts?

Each state variable is stored in a 32-byte slot. Variables declared first use lower slot numbers. Complex types like arrays or mappings use hashing to find their storage location.

intermediate

What happens if you add a new variable in the middle of existing variables in a contract?

It shifts the storage slots of variables declared after it, causing data corruption. New variables should be added only at the end to keep the layout consistent.

advanced

Explain how mapping types are stored in storage layout.

Mappings do not store data sequentially. Instead, each key-value pair is stored at a slot calculated by hashing the key with the mapping's slot number. This allows efficient lookups.

In Ethereum, where is the first declared state variable stored?

A Slot 0

B Slot 1

C Slot 32

D Slot 255

The first declared state variable is stored in slot 0, the starting point of storage slots.

What is the risk of changing the order of variables in an upgraded contract?

A Data corruption due to slot mismatch

B No risk, storage adapts automatically

C Faster contract execution

D Lower gas costs

Changing variable order shifts storage slots, causing data corruption.

How are mapping values located in storage?

A They are not stored

B Sequential slots starting from 0

C In a separate database

D By hashing the key with the mapping slot

Mapping values are stored at slots computed by hashing the key with the mapping's slot number.

Where should you add new variables to avoid breaking storage layout?

A At the beginning of the contract

B In the middle of existing variables

C At the end of existing variables

D Anywhere, it doesn't matter

Adding variables at the end preserves existing storage slots and prevents corruption.

What size is each storage slot in Ethereum?

A 16 bytes

B 32 bytes

C 64 bytes

D 128 bytes

Each storage slot in Ethereum is 32 bytes.

Describe how storage layout affects smart contract upgrade safety.

Think about what happens if variables move around in storage.

Explain how mappings are stored differently from simple variables in storage layout.

Consider how keys help find values in storage.

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