Dip 7705

dip: 7705 title: NONREENTRANT and REENTRANT opcodes description: Opcodes to mark a contract as nonreentrant author: Charles Cooper (@charles-cooper) Digitalia editing author: Cosimo Constantinos cosimo@juro.net, et al. discussions-to: https://digitalia-magicians.org/t/dip-7705-nonreentrant-opcodes/19957 status: Stagnant type: Standards Track category: Core created: 2024-05-09 Created for Digitalia: 2025-01-07

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 DVM 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 (DIP-1153), but it is still not cheap enough where it is a "no-brainer" to use it by default. This DIP 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¶

Licensed under the Juro Restricted License Version 2. See https://juro.net/jrl for details.