Reentrancy Lock

A reentrancy lock (or mutex) is a boolean state variable that acts as a flag. When a function is entered, it checks if the lock is false (unlocked), sets it to true (locked), executes the critical logic, and then sets it back to false. This prevents any nested call from re-entering the same function path.

• Key Variable: Typically a bool private locked = false;
• Check-Effects-Interaction: The lock enforces this pattern by ensuring state changes happen before any external calls that could trigger reentrancy.

The most common implementation is a modifier, popularized by OpenZeppelin's ReentrancyGuard contract. This modifier wraps the function logic, providing a reusable and audited lock.

solidityCopy
modifier nonReentrant() {
    require(!locked, "Reentrant call");
    locked = true;
    _;
    locked = false;
}

Using nonReentrant on functions that perform external calls (e.g., transfer, call) is a critical best practice.

While a basic lock prevents single-function reentrancy, developers must be aware of its scope:

• Cross-Function Reentrancy: A lock on withdraw() doesn't protect transfer() if they share state. Use a single lock for all functions sharing critical state.
• Cross-Contract Reentrancy: A lock in Contract A doesn't protect a state read from Contract B that A interacts with.
• nonReentrant Ordering: The modifier must be placed first in the modifier list to lock before any other conditional checks.

The definitive pattern for secure function design:

1. Lock: Apply the reentrancy guard (e.g., nonReentrant modifier).
2. Effects: Perform all internal state updates (e.g., reducing a user's balance).
3. Interaction: Make the external call (e.g., sending ETH).

This ensures the contract's state is finalized and consistent before relinquishing control via an external call, which is the potential point of re-entry. This pattern is more robust than the older Checks-Effects-Interactions as it explicitly starts with the lock.

The 2016 attack on The DAO was the seminal reentrancy attack that resulted in the loss of 3.6 million ETH and led to the Ethereum hard fork. The vulnerable splitDAO function:

• Sent ETH to the attacker before updating the attacker's internal token balance.
• The attacker's fallback function recursively called back into splitDAO, draining funds in a loop.

This event cemented reentrancy locks and the Checks-Effects-Interactions pattern as mandatory security knowledge.

Reentrancy locks work alongside other critical patterns:

• Pull-over-Push Payments: Instead of pushing funds (which can be re-entered), let users withdraw them (pull), removing reentrancy risk from the core logic.
• State Machine Patterns: Using explicit states (e.g., Locked, Unlocked) can provide more granular control for complex workflows.
• Gas Limits: While not a defense, being aware that reentrancy attacks consume gas can inform risk assessment for functions with strict gas stipends.

A reentrancy lock (or mutex) is a boolean state variable that acts as a flag. When a function is entered, it checks if the lock is false (unlocked), sets it to true (locked), executes the critical logic, and then resets it to false. This prevents any external contract from re-entering the function while the initial call is still in progress, blocking the classic reentrancy attack vector.

• Key Variable: Often named locked, _notEntered, or _status.
• Check-Effects-Interactions: The lock enforces this pattern by ensuring state changes happen before any external calls.

A simple lock on a single function may not protect against cross-function reentrancy, where an attacker re-enters a different function that shares state with the vulnerable one. Mitigations include:

• Single Lock for Entire Contract: Using one global lock for all sensitive functions (though this reduces composability).
• Granular Locks: Implementing separate locks for different state variables or user balances.
• Careful State Isolation: Ensuring functions do not share intermediate state vulnerable to interference.

While essential, reentrancy locks introduce specific trade-offs:

• Gas Overhead: Adds a small gas cost for the state variable check and write.
• Composability Reduction: A global lock can block legitimate, nested calls from other contracts, breaking certain DeFi composability patterns.
• Not a Silver Bullet: Does not protect against other vulnerabilities like flash loan price manipulation or logic errors. It must be part of a broader security strategy including the checks-effects-interactions pattern.

The critical importance of reentrancy locks was demonstrated by The DAO hack in 2016, which led to the loss of 3.6 million ETH. The vulnerable contract's splitDAO function sent ETH before updating the user's internal token balance. An attacker's fallback function repeatedly re-entered splitDAO, draining funds. This event was the direct catalyst for the Ethereum network hard fork (creating Ethereum Classic) and established reentrancy protection as the foremost smart contract security lesson.

Reentrancy locks work alongside other critical security patterns and standards:

• Checks-Effects-Interactions: The foundational code ordering pattern the lock enforces.
• Pull-over-Push Payments: Mitigates reentrancy by having users withdraw funds themselves.
• ERC-20 / ERC-721: Token standards with their own transfer hooks that require careful integration with locks.
• Static Analysis Tools: Tools like Slither and MythX can automatically detect potential reentrancy vulnerabilities.

A reentrancy attack is an exploit where a malicious contract recursively calls back into a vulnerable function before its state updates are finalized. The classic example is The DAO hack, where an attacker drained funds by repeatedly calling a withdraw function. The attack flow is:

• Attacker calls vulnerable function.
• Contract sends Ether before updating balance.
• Attacker's fallback function re-enters the original function.
• Process repeats until funds are exhausted.

The Checks-Effects-Interactions (CEI) pattern is a coding best practice that structurally prevents reentrancy by ordering operations:

1. Checks: Validate all conditions (e.g., balances, permissions).
2. Effects: Update all internal state variables (e.g., deduct balance).
3. Interactions: Perform external calls to other contracts or addresses. By performing state changes before external calls, the contract's internal ledger is updated, making subsequent reentrant calls fail the initial checks.

A nonReentrant modifier is a concrete implementation of a reentrancy lock, typically using a boolean state variable. Popularized by OpenZeppelin's ReentrancyGuard library, it works by:

• Setting a lock flag (_status = _ENTERED) at function entry.
• Checking the flag is not already set.
• Resetting the flag (_status = _NOT_ENTERED) only after the function completes. This ensures the function cannot be called recursively for the same contract instance during execution.

Cross-function reentrancy occurs when an attacker exploits two or more functions that share the same state variable. Even if a withdraw function has a lock, an attacker might call a separate transfer function that reads the same, not-yet-updated balance. Mitigation requires:

• Using a single reentrancy guard for all functions sharing sensitive state.
• Strict adherence to the CEI pattern across the entire contract.
• Understanding that locks are often contract-wide, not just per-function.

This design philosophy impacts reentrancy risk. A push architecture sends funds directly (e.g., address.send()), which triggers external code and creates reentrancy risk. A pull architecture requires users to withdraw funds themselves, separating the state update from the transfer. Key differences:

• Push: Contract initiates payment. Simpler UX, higher risk.
• Pull: User initiates withdrawal. Shifts gas cost to user, eliminates reentrancy in core logic. Many secure systems use pull payments for obligations.

Understanding the EVM execution context is key to reentrancy. The msg.sender for a reentrant call is the attacking contract's address, not the original EOA. However, the address(this).balance and storage state are read live. Critical points:

• Reentrancy exploits the gap between a contract's perceived state and its actual updated state.
• call, send, and transfer can trigger fallback functions.
• Low-level .call{value: x}('') is the most permissive and dangerous method for sending Ether, as it forwards all remaining gas.