Reentrancy guard pattern in Blockchain / Solidity - Mini Project: Build & Apply

Reentrancy Guard Pattern in Solidity

📖 Scenario: You are building a simple smart contract for a wallet where users can deposit and withdraw Ether. To keep the contract safe, you need to prevent reentrancy attacks, which happen when a malicious contract repeatedly calls the withdraw function before the first call finishes.

🎯 Goal: Build a Solidity contract that uses a reentrancy guard pattern to protect the withdraw function from reentrancy attacks.

📋 What You'll Learn

Create a contract named SafeWallet with a mapping balances to track user deposits.

Add a boolean variable locked to act as a reentrancy guard.

Implement a deposit function to allow users to send Ether and update their balance.

Implement a withdraw function protected by the reentrancy guard to safely send Ether back to users.

Use the locked variable to prevent reentrant calls in withdraw.

💡 Why This Matters

🌍 Real World

Reentrancy attacks have caused major losses in real blockchain projects. Using a reentrancy guard is a simple and effective way to protect smart contracts that send Ether or tokens.

💼 Career

Understanding and implementing security patterns like the reentrancy guard is essential for blockchain developers to write safe smart contracts and avoid vulnerabilities.

1

Create the contract and balances mapping

Create a Solidity contract named SafeWallet and inside it, declare a public mapping called balances that maps address to uint.

Blockchain / Solidity

contract SafeWallet {
    // Your code here
}

Hint

Use mapping(address => uint) public balances; inside the contract.

2

Add the reentrancy guard variable

Inside the SafeWallet contract, add a private boolean variable named locked and initialize it to false.

Blockchain / Solidity

pragma solidity ^0.8.0;

contract SafeWallet {
    mapping(address => uint) public balances;
    // Your code here
}

Hint

Declare bool private locked = false; inside the contract.

3

Add deposit and protected withdraw functions

Add a public payable function deposit that increases the sender's balance by msg.value. Then add a public function withdraw that takes a uint amount parameter. In withdraw, first check that locked is false, then set locked to true. Next, check that the sender has enough balance, reduce their balance by amount, send amount Ether to the sender, and finally set locked back to false.

Blockchain / Solidity

pragma solidity ^0.8.0;

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

    // Your code here
}

Hint

Use require(!locked) and set locked = true at the start of withdraw, then reset locked = false at the end.

4

Test the contract by depositing and withdrawing

Write a comment line that shows how to deposit 1 Ether by calling deposit with msg.value 1 Ether, and then write a comment line showing how to withdraw 0.5 Ether by calling withdraw with amount 0.5 Ether. Then print a message "Deposit and withdrawal executed safely" using an event or comment (since Solidity does not have print).

Blockchain / Solidity

pragma solidity ^0.8.0;

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

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

    function withdraw(uint amount) public {
        require(!locked, "Reentrant call detected");
        locked = true;

        require(balances[msg.sender] >= amount, "Insufficient balance");
        balances[msg.sender] -= amount;

        (bool success, ) = msg.sender.call{value: amount}("");
        require(success, "Transfer failed");

        locked = false;
    }

    // Your code here
}

Hint

Use comments to show example deposit and withdraw calls and a success message.

Practice

1.

What is the main purpose of the reentrancy guard pattern in blockchain smart contracts?

easy

A. To prevent a function from being called again before it finishes execution

B. To speed up the execution of smart contracts

C. To allow multiple users to access a function simultaneously

D. To reduce the gas cost of transactions

Solution

1. Step 1: Understand the problem reentrancy causes

   Reentrancy happens when a function is called again before the first call finishes, causing unexpected behavior or exploits.

2. Step 2: Identify the role of the reentrancy guard

   The reentrancy guard uses a lock to block repeated calls until the first call completes, preventing reentrancy attacks.

3. Final Answer:

   To prevent a function from being called again before it finishes execution -> Option A

4. Quick Check:

   Reentrancy guard = prevent repeated calls [OK]

Hint: Reentrancy guard stops repeated calls during execution [OK]

Common Mistakes:

• Thinking it speeds up contract execution
• Believing it allows simultaneous access
• Confusing it with gas optimization

2.

Which of the following is the correct way to declare a reentrancy guard variable in Solidity?

contract Example {
    // Fill in the blank
    _____ private locked = false;
}

easy

A. string

B. bool

C. int

D. address

Solution

1. Step 1: Identify the variable type for a lock

   The lock variable is used as a flag to indicate if the function is running, so it should be a boolean (true/false).

2. Step 2: Match the correct Solidity type

   In Solidity, bool is the type for true/false values, suitable for a lock variable.

3. Final Answer:

   bool -> Option B

4. Quick Check:

   Lock variable type = bool [OK]

Hint: Lock variables are boolean flags in Solidity [OK]

Common Mistakes:

• Using int instead of bool for lock
• Using string or address types incorrectly
• Forgetting to initialize the variable

3.

Consider this Solidity function using a reentrancy guard:

bool private locked = false;

function withdraw(uint amount) public {
    require(!locked, "Reentrant call detected");
    locked = true;
    (bool success, ) = msg.sender.call{value: amount}("");
    require(success, "Transfer failed");
    locked = false;
}

What happens if msg.sender.call triggers a fallback that calls withdraw again?

medium

A. The second call is blocked by the lock and reverts

B. The second call succeeds and causes reentrancy

C. The contract runs out of gas and fails

D. The lock variable resets before the second call

Solution

1. Step 1: Analyze the lock status during the first call

   When withdraw is called, locked is set to true before sending funds.

2. Step 2: Understand the effect on reentrant call

   If msg.sender.call triggers a fallback that calls withdraw again, the require(!locked) check fails because locked is true, blocking the call.

3. Final Answer:

   The second call is blocked by the lock and reverts -> Option A

4. Quick Check:

   Lock true blocks reentrant call [OK]

Hint: Lock true means no reentrant calls allowed [OK]

Common Mistakes:

• Assuming reentrancy still happens
• Thinking lock resets before second call
• Confusing gas failure with reentrancy

4.

Identify the bug in this reentrancy guard implementation:

bool private locked = false;

function withdraw(uint amount) public {
    require(!locked, "Reentrant call detected");
    (bool success, ) = msg.sender.call{value: amount}("");
    require(success, "Transfer failed");
    locked = true;
    locked = false;
}

medium

A. The require statement is missing

B. The lock variable is never set to true

C. The lock is set after the external call, allowing reentrancy

D. The call to msg.sender is incorrect syntax

Solution

1. Step 1: Check when the lock is set

   The lock is set to true only after the external call, which means the function is not protected during the call.

2. Step 2: Understand reentrancy risk

   Because the lock is set too late, a reentrant call can happen during the external call, causing vulnerability.

3. Final Answer:

   The lock is set after the external call, allowing reentrancy -> Option C

4. Quick Check:

   Lock must be set before external calls [OK]

Hint: Set lock before external calls to prevent reentrancy [OK]

Common Mistakes:

• Setting lock after external call
• Forgetting to set lock at all
• Misplacing require statements

5.

You want to protect a function that updates user balances and sends Ether. Which is the best way to apply the reentrancy guard pattern?

function safeWithdraw(uint amount) public {
    // Your code here
    balances[msg.sender] -= amount;
    (bool success, ) = msg.sender.call{value: amount}("");
    require(success, "Transfer failed");
}

hard

A. Update balances after sending Ether without any lock

B. Do not use any lock, just rely on require statements

C. Use a lock variable but set it after sending Ether

D. Set a lock variable before updating balances and sending Ether, then release it after

Solution

1. Step 1: Understand the order of operations for safety

   To prevent reentrancy, set a lock before any state changes and external calls, then release it after.

2. Step 2: Apply the reentrancy guard pattern correctly

   Set the lock variable to true before updating balances and sending Ether, then set it back to false after the transfer completes.

3. Final Answer:

   Set a lock variable before updating balances and sending Ether, then release it after -> Option D

4. Quick Check:

   Lock before state change and external call [OK]

Hint: Lock before balance update and transfer, unlock after [OK]

Common Mistakes:

• Setting lock after sending Ether
• Updating balances after external call
• Not using any lock at all