🔨Mitigating Read-Only Reentrancy

Book an audit with Zokyo

In the landscape of smart contracts and decentralized finance (DeFi), a variety of exploits have been identified, including the read-only reentrancy attack. This type of attack reenters a view function that is typically unguarded due to its non-state-modifying nature, leading to potential unintended actions if the state is inconsistent. Below are strategies to help mitigate such vulnerabilities:

1. Recognize Vulnerable Patterns

Understanding the conditions under which read-only reentrancy attacks occur is the first step to prevention. A vulnerable situation typically arises when there is an external call to another contract before the state of the current contract is fully updated. Understanding this pattern can help developers in identifying potential risks during the design and development of their smart contracts.

2. Reentrancy Guards

While traditional reentrancy guards that block state-modifying functions are not applicable for read-only reentrancy, it is possible to employ a variant of these guards. Even if a function does not change the state, it should be protected from reentrancy if it is accessed during intermediate stages of a transaction before the contract’s state is fully updated. This can be achieved by using a semaphore that locks the contract state for the duration of a transaction, preventing reentry.

Example:

pragma solidity ^0.8.7;

contract ReentrancyGuard {
    bool internal _notEntered = true;

    modifier nonReentrant() {
        require(_notEntered, "ReentrancyGuard: reentrant call");
        _notEntered = false;
        _;
        _notEntered = true;
    }
}

contract MyContract is ReentrancyGuard {
    uint256 public balance = 0;

    function deposit() external payable nonReentrant {
        balance += msg.value;
    }

    function withdraw(uint256 amount) external nonReentrant {
        require(amount <= balance, "Insufficient funds");
        balance -= amount;
        payable(msg.sender).transfer(amount);
    }
}

In the above code, the nonReentrant modifier ensures that while a function with this modifier is being executed, it can't be called again until it finishes, preventing reentrancy.

3. Use of Checks-Effects-Interactions Pattern

Follow the Checks-Effects-Interactions pattern to prevent reentrancy attacks. This pattern ensures that the state of the contract is updated before interacting with external contracts. Any state variables that affect execution flow or can be accessed through external calls should be updated prior to those calls.

1. Checks: Perform all the checks (e.g., require statements).

2. Effects: Update any state variables.

3. Interactions: Interact with other contracts.

By following this order, even if a called contract attempts a reentrancy attack, the state of the original contract will already be updated, rendering the attack ineffective.