At its core, read-only reentrancy is a misleading return value from a view-only function due to an unupdated state. It occurs in smart contracts where external functions are being invoked whenever the contract is in an unupdated state and the view functions, which are supposed to read the state, return values based on the old, unupdated state.
This can lead to inaccurate or false information being displayed, even though no actual state change or transaction occurs as a result of calling these view functions.
When can this happen?
This issue can arise in scenarios where there's a risk of reentrancy in a contract, particularly when external functions are executed. Even if the primary function that alters the state is safeguarded against reentrancy attacks, with a ReentrancyGuard, a malicious actor can still exploit the contract by reentering through a view-only function. This exploitation results in the view function returning data that inaccurately reflects the contract's current state.
Example Scenario:
Consider a simple staking contract where users can deposit a staking token and earn rewards. When a user deposits, the pool is updated and the pending reward is calculated and transferred out. However, if the rewardDebt (the variable tracking how much reward has been accounted for each user) isn't updated before the transfer, there's a window for exploitation. The function itself is guarded with a ReentrancyGuard.
A malicious user could call the getPendingRewards function right after receiving the pending rewards but before the rewardDebt is updated. This would result in getPendingRewards showing the old reward amount, even though it has already been transferred out. The user sees an inflated reward value that doesn't truly reflect their pending rewards after the deposit.
How to Prevent Read-Only Reentrancy?
The key to preventing read-only reentrancy lies in adhering to the well-established "checks-effects-interactions" pattern in smart contract development. In a separate post i will describe this pattern in detail.
This can lead to inaccurate or false information being displayed, even though no actual state change or transaction occurs as a result of calling these view functions.
When can this happen?
This issue can arise in scenarios where there's a risk of reentrancy in a contract, particularly when external functions are executed. Even if the primary function that alters the state is safeguarded against reentrancy attacks, with a ReentrancyGuard, a malicious actor can still exploit the contract by reentering through a view-only function. This exploitation results in the view function returning data that inaccurately reflects the contract's current state.
Example Scenario:
Consider a simple staking contract where users can deposit a staking token and earn rewards. When a user deposits, the pool is updated and the pending reward is calculated and transferred out. However, if the rewardDebt (the variable tracking how much reward has been accounted for each user) isn't updated before the transfer, there's a window for exploitation. The function itself is guarded with a ReentrancyGuard.
A malicious user could call the getPendingRewards function right after receiving the pending rewards but before the rewardDebt is updated. This would result in getPendingRewards showing the old reward amount, even though it has already been transferred out. The user sees an inflated reward value that doesn't truly reflect their pending rewards after the deposit.
How to Prevent Read-Only Reentrancy?
The key to preventing read-only reentrancy lies in adhering to the well-established "checks-effects-interactions" pattern in smart contract development. In a separate post i will describe this pattern in detail.
