Reentrancy guard pattern in Blockchain / Solidity - Step-by-Step Execution

Concept Flow - Reentrancy guard pattern

Function call starts

↓

Check if locked?

Yes→Reject call

No↓

Set locked = true

↓

Execute function body

↓

Set locked = false

↓

Function call ends

This flow shows how the reentrancy guard prevents a function from being called again before the first call finishes by using a lock flag.

Execution Sample

Blockchain / Solidity

bool locked = false;

function withdraw() public {
  require(!locked, "Reentrant call");
  locked = true;
  // send funds
  locked = false;
}

This code prevents reentrant calls by locking the function during execution.

Execution Table

Step	locked	Condition (!locked)	Action	Result
1	false	true	Enter function, set locked = true	locked = true, function proceeds
2	true	false	Reentrant call detected, revert	Call rejected with error
3	true	false	Function body executes	Funds sent
4	true	false	Set locked = false	locked = false
5	false	true	Function call ends	Ready for next call

💡 Reentrant call rejected at step 2 because locked is true

Variable Tracker

Variable	Start	After Step 1	After Step 3	After Step 4	Final
locked	false	true	true	false	false

Key Moments - 3 Insights

Why does the function reject the second call when locked is true?

Because the reentrancy guard checks the locked flag before running. If locked is true (step 2 in execution_table), it means the function is already running, so it rejects to prevent reentrancy.

Why do we set locked = true before executing the function body?

Setting locked = true (step 1) marks the function as busy. This prevents any nested or repeated calls from entering until the first call finishes and resets locked.

What happens if we forget to set locked = false at the end?

If locked stays true, all future calls will be rejected forever, blocking the function. Step 4 resets locked to false to allow new calls.

Visual Quiz - 3 Questions

Look at the execution_table, what is the value of locked after step 1?

A true

B false

C undefined

D null

💡 Hint

Check the 'locked' column in row for step 1 in execution_table

At which step does the function reject a reentrant call?

A Step 1

B Step 2

C Step 3

D Step 5

💡 Hint

Look for the row where Condition (!locked) is false and Action is 'Reentrant call detected'

If we remove 'locked = false' at step 4, what happens to future calls?

A They succeed normally

B They cause an error only once

C They are rejected forever

D They skip the lock check

💡 Hint

Refer to key_moments about resetting locked to false after function execution

Concept Snapshot

Reentrancy guard pattern:
- Use a boolean 'locked' flag
- Check 'locked' at function start
- If false, set 'locked = true' and proceed
- After function body, set 'locked = false'
- Prevents nested calls during execution

Full Transcript

The reentrancy guard pattern uses a boolean flag called 'locked' to prevent a function from being called again before the first call finishes. When the function starts, it checks if 'locked' is false. If so, it sets 'locked' to true and runs the function body. If 'locked' is true, it rejects the call to prevent reentrancy. After the function finishes, it resets 'locked' to false to allow future calls. This pattern protects against attacks where a function is called repeatedly before finishing, which can cause unexpected behavior or theft of funds.