Storage layout in Blockchain / Solidity - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Predict Output

intermediate

Storage slot assignment in Solidity structs

Consider the following Solidity contract snippet. What will be the storage slot of the variable c inside the struct Data?

Blockchain / Solidity

pragma solidity ^0.8.0;

contract StorageTest {
    struct Data {
        uint128 a;
        uint128 b;
        uint256 c;
    }

    Data public data;
}

A Slot 0

B Slot 2

C Slot 1

D Slot 3

💡 Hint

Remember that Solidity packs variables into 32-byte slots when possible.

The struct has two uint128 variables (a and b) which fit together into slot 0. The uint256 variable c requires a full slot and is stored in slot 1.

❓ Predict Output

intermediate

Storage layout of dynamic arrays in Solidity

Given the following Solidity contract, what is the storage slot of the first element of the dynamic array arr?

Blockchain / Solidity

pragma solidity ^0.8.0;

contract ArrayStorage {
    uint256[] public arr;
}

A Slot 1

B keccak256(0)

C Slot 0

D keccak256(1)

💡 Hint

Dynamic arrays store their length at the declared slot, elements start at keccak256(slot).

The array length is stored at slot 0. The elements start at the slot computed by keccak256(0).

🔧 Debug

advanced

Identify storage collision in upgradeable contracts

You have two versions of a Solidity contract. Version 1 has variables uint256 x and uint256 y. Version 2 adds a new variable uint256 z before y. What problem arises with this change?

A Storage collision causing <code>y</code> to overwrite <code>z</code>

B No problem, variables are automatically reordered

C Compiler error due to variable reordering

D Storage collision causing <code>z</code> to overwrite <code>y</code>

💡 Hint

Changing variable order in upgradeable contracts can cause storage slot mismatches.

Adding z before y shifts y to a new slot, but existing storage still expects y at the old slot, causing z to overwrite y data.

🧠 Conceptual

advanced

Storage layout of mappings in Solidity

How does Solidity compute the storage slot for a value in a mapping like mapping(address => uint256) balances stored at slot 3?

A keccak256(abi.encodePacked(key, 3))

B Slot 3 + key

C keccak256(abi.encode(3, key))

D Slot 3 * key

💡 Hint

Mapping storage uses keccak256 hash of the key concatenated with the slot.

Solidity stores mapping values at keccak256 of the concatenation of the key and the mapping's slot number.

❓ Predict Output

expert

Storage layout with inheritance and variable shadowing

Consider these Solidity contracts:

pragma solidity ^0.8.0;

contract A {
    uint256 public x = 1;
}

contract B is A {
    uint256 public x = 2;
}

What is the value of B.x() when called?

A 2

B 1

C Compiler error due to variable shadowing

D 0

💡 Hint

Derived contracts can shadow base contract variables, but the derived variable is accessed.

Contract B declares its own x, which shadows A.x. Calling B.x() returns 2.

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