主页EIPs
EIPsEIP-7705
EIP-7705

NONREENTRANT and REENTRANT opcodes

Opcodes to mark a contract as nonreentrant
DraftStandards Track: Core
创建时间: 2024-05-09
Charles Cooper (@charles-cooper)
社区讨论原文链接编辑
1 分钟了解
欢迎补充好内容
去提交
相关视频
欢迎补充好内容
去提交
正文

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 and related rights waived via CC0.

扩展阅读
欢迎补充好内容
去提交
相关项目
欢迎补充好内容
去提交

不想错过最新的 EIP 动态?

订阅 EIPs Fun 周刊以跟进相关更新,建⽴你与 EIP 之间的连接 ,更好地建设以太坊。

详情
支持以太坊贡献者,推动生态建设
资源
GitHub
支持社区