Temporarily Restricting Solidity Smart Contract Interactions

TL;DR

The paper addresses the problem of temporarily restricting Solidity smart contract interactions to mitigate reentrancy-related exploits. It surveys standard reentrancy defenses and extends the discussion to restricting entire sets of functions, including read-only ones, and time- or block-based constraints; it also analyzes cross-chain execution differences. Key contributions include a taxonomy of restriction techniques (within the same execution, within a transaction, and within time/blocks) and a deep dive into read-only reentrancy and multi-function guards, illustrated by case studies from 2023 DeFi incidents. The findings underscore the potential to prevent large losses, while also highlighting trade-offs in security versus composability, gas costs, and cross-chain semantics, calling for careful, context-aware deployment and further study.

Abstract

In this work we explore ways to restrict the ability to call Solidity smart contract functions for a specified duration. We describe methods to restrict functions from being called twice in the same transaction, block, or time period. This is related to the notion of non-reentrant functions, which are functions that can be called within a previous execution. These methods can be used to restrict interactions with entire sets of functions of smart contracts. We are motivated to revisit this topic for two reasons. First, we note that sixteen real-world smart contracts exploits in 2023 resulting in over $136M USD lost or stolen that could have been prevented by restricting function calls. As part of this survey, we dissect a new class of exploit that involves so-called read-only reentrancy: exploits that re-enter read-only functions to make smart contract state inconsistent in order to enable their exploitation. Second, while some of these approaches are simple, they may not always behave the same across different blockchains that support Solidity.

Figures (5)

• Figure 1: Preventing smart contract access through shared variables.
• Figure 2: The Sentiment incident, illustrated. The entire exploit takes place during a single transaction on Arbitrum. The view function getPrice is entered more than once during this duration and is used to compute values when an invariant does not hold within another execution being performed by the Balancer contract.
• Figure 3: Functions which cannot be called twice within some number of blocks (or a given time frame) cannot be done so even if they they do not directly modify function; similarly, such functions cannot be re-entered. Functions which cannot be entered twice in the same transaction also cannot be reentered before their completion.
• Figure 4: A modifier that allows multiple function calls within the same Ethereum block, but no more than once per transaction. Modified functions can only be called once per transaction, leveraging the fact that the gas cost is different when the balance of an address is accessed again within the same transaction. For the sake of simplification, the value 2631 is hardcoded and includes some overhead for other necessary operations performed by the modifier.
• Figure 5: Preventing access using timestamps. A function is initially not entered as the default mapping value in Solidity is 0 (line 3). The function can only be called if the message sender has waited a sufficient amount of time with their last interaction with the contract (lines 5-7). The latestEntry variable is set to the timestamp of the bock when the function is called (lines 8-9) for the caller of the function. In this case, guarded functions cannot be reentered until after _DELTA time passes by each Ethereum account.