EIP-7705: NONREENTRANT and REENTRANT opcodes
Opcodes to mark a contract as nonreentrant
| Authors | Charles Cooper (@charles-cooper) |
|---|---|
| Created | 2024-05-09 |
| Discussion Link | https://ethereum-magicians.org/t/eip-7705-nonreentrant-opcodes/19957 |
Table of Contents
Abstract
Add two opcodes, NONREENTRANT and REENTRANT, which set and clear a contract’s reentrancy status. After invoking NONREENTRANT, a contract cannot be CALLed (or STATICCALLed, or DELEGATECALLed) until REENTRANT is invoked.
Motivation
Reentrancy attacks account for a substantial portion of user funds stolen on EVM chains, including the famous “DAO hack”. However, due to the cost of preventing against reentrancy attacks in application code, developers often opt-out of reentrancy protection. This cost has come down with the advent of transient storage (EIP-1153), but it is still not cheap enough where it is a “no-brainer” to use it by default. This EIP proposes opcodes which make it cheaper to protect against reentrancy in application code.
Specification
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119 and RFC 8174.
Two new opcodes are introduced, NONREENTRANT (0xF6) and REENTRANT (0xF7), which set and clear a contract’s nonreentrancy flag. The effect of invoking NONREENTRANT is that a contract can no longer have execution context transferred to it (via any of the *CALL opcodes), until REENTRANT is invoked. CALLing a contract which has the nonreentrancy flag set is equivalent to executing a single REVERT opcode.
Both NONREENTRANT and REENTRANT are idempotent; that is, invoking NONREENTRANT when a contract already has nonreentrant status is a no-op, and likewise for REENTRANT.
The scope of the nonreentrant flag is limited to the current transaction. That is, nonreentrant flags are cleared at the end of every transaction. In the presence of reversion (REVERT or exceptional halt), the contract’s nonreentrancy flag reverts to whatever its value was before the call.
The cost of NONREENTRANT and REENTRANT are both set at 5 (G_mid).
Rationale
The computational cost of pushing the current value to the call stack (for handling reverts) is accounted for in the overhead cost of the *CALL opcodes.
An alternative design could be considered which only introduces one opcode. This opcode, NONREENTRANT, would take a single stack item and set the nonreentrancy flag based on its value. This alternative design can be considered based on feedback.
Backwards Compatibility
No backward compatibility issues found.
Test Cases
Reference Implementation
Security Considerations
TBD
Copyright
Copyright and related rights waived via CC0.
Citation
Please cite this document as:
Charles Cooper (@charles-cooper), "EIP-7705: NONREENTRANT and REENTRANT opcodes [DRAFT]," Ethereum Improvement Proposals, no. 7705, May 2024. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-7705.