Reentrancy guard pattern in Blockchain / Solidity - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Predict Output

intermediate

What is the output of this Solidity contract call?

Consider this simplified Solidity contract using a reentrancy guard. What will be the value of counter after calling increment() once?

Blockchain / Solidity

pragma solidity ^0.8.0;

contract ReentrancyGuard {
    bool private locked;
    uint public counter;

    modifier noReentrant() {
        require(!locked, "No reentrancy");
        locked = true;
        _;
        locked = false;
    }

    function increment() public noReentrant {
        counter += 1;
        if(counter < 3) {
            increment();
        }
    }
}

A The call will revert with "No reentrancy" error

B counter will be 3

C counter will be 2

D counter will be 1

💡 Hint

Think about what happens when the function calls itself recursively with the reentrancy guard active.

The noReentrant modifier sets locked to true before the function body and resets it after. The recursive call to increment() happens while locked is true, so the require fails and the call reverts.

🧠 Conceptual

intermediate

Why is a reentrancy guard important in smart contracts?

Which of the following best explains why a reentrancy guard is used in smart contracts?

A To increase the speed of contract execution by caching results

B To allow the contract to call external contracts safely

C To stop a function from being called again before the first call finishes, avoiding unexpected state changes

D To prevent multiple users from calling the contract at the same time

💡 Hint

Think about what happens if a function changes state and then calls an external contract that calls back before the first call finishes.

A reentrancy guard prevents a function from being entered again before the first call completes, which stops attackers from exploiting state changes by reentering the function unexpectedly.

🔧 Debug

advanced

Identify the bug in this reentrancy guard implementation

What is wrong with this reentrancy guard modifier?

Blockchain / Solidity

modifier noReentrant() {
    require(!locked, "No reentrancy");
    _;
    locked = true;
}

A The modifier does not check the <code>locked</code> variable at all

B The <code>locked</code> variable is never set to false, so the guard locks forever

C The <code>require</code> condition is reversed, allowing reentrancy

D The modifier sets <code>locked</code> before the function body, which is incorrect

💡 Hint

Look at when locked is set to true and if it ever resets.

The modifier sets locked to true only after the function body runs, but never resets it to false. This means once locked, the guard never unlocks, blocking all future calls.

📝 Syntax

advanced

Which option correctly implements a reentrancy guard modifier in Solidity?

Choose the correct Solidity code for a reentrancy guard modifier that prevents reentrant calls.

A

modifier noReentrant() {
    require(!locked, "No reentrancy");
    locked = true;
    _;
    locked = false;
}

B

modifier noReentrant() {
    locked = true;
    require(!locked, "No reentrancy");
    _;
    locked = false;
}

C

modifier noReentrant() {
    require(locked, "No reentrancy");
    locked = true;
    _;
    locked = false;
}

D

modifier noReentrant() {
    require(!locked, "No reentrancy");
    _;
    locked = true;
    locked = false;
}

💡 Hint

The guard must check locked before setting it to true and running the function body.

Option A correctly checks locked is false, sets it true before the function runs, then resets it to false after. Others either check after setting or have wrong conditions.

🚀 Application

expert

How many times will the fallback function be called in this contract during a reentrant attack?

Given this contract snippet, how many times will the fallback function be called if an attacker tries to reenter during withdraw()?

Blockchain / Solidity

pragma solidity ^0.8.0;

contract Vulnerable {
    mapping(address => uint) public balances;
    bool private locked;

    modifier noReentrant() {
        require(!locked, "No reentrancy");
        locked = true;
        _;
        locked = false;
    }

    function deposit() public payable {
        balances[msg.sender] += msg.value;
    }

    function withdraw(uint amount) public noReentrant {
        require(balances[msg.sender] >= amount, "Insufficient balance");
        (bool success, ) = msg.sender.call{value: amount}("");
        require(success, "Transfer failed");
        balances[msg.sender] -= amount;
    }

    fallback() external payable {
        if (balances[msg.sender] > 0) {
            withdraw(balances[msg.sender]);
        }
    }
}

A The fallback function will be called multiple times until the balance is zero

B The fallback function will cause an infinite loop and run forever

C The fallback function will never be called due to the reentrancy guard

D The fallback function will be called exactly once

💡 Hint

Consider how the noReentrant modifier affects the recursive call inside fallback().

The noReentrant modifier blocks reentrant calls during withdraw(). So the fallback function can only be called once before the guard blocks further calls, preventing multiple reentries.