EXTCLEAR Opcode For SELFDESTRUCTed contracts
EIP-2936 proposes a new opcode, EXTCLEAR, to clear storage for SELFDESTRUCTed contracts. Currently, when a contract is self-destructed, its storage is also cleared. However, this proposal suggests deferring the time of storage cleanup and leaving the storage in place, which reduces the complexity of SLOAD and SELFDESTRUCT. The new opcode, EXTCLEAR, will clear a specific storage slot for a contract that has previously been self-destructed. This empowers the CREATE2 reincarnation proxy pattern by retaining storage during upgrade, which would otherwise have to be reset again. The proposal also modifies the SELFDESTRUCT opcode to not clear contract storage. This change works retroactively, meaning all prior destroyed contracts can be cleaned up. The proposal also includes information on gas costs and security considerations. Implementation is required on all major clients to add the opcode. Overall, this proposal aims to improve the efficiency and flexibility of contract upgrades by allowing for the retention of storage during upgrades.
Enable new opcode to clear storage for
0xff) to not clear any storage and adds a new
0x5c) opcode that will clear a specific storage slot for a contract that has previously been self destructed.
0xFF) is unnecessarily complex because it clears an unbounded amount of contract storage.
It is computationally expensive for nodes to track all of the storage used in every contract in case the contract
Further, contracts can be re-initialized using
0xF5), and then
0x54) prior storage.
Therefore, several ethereum clients do not clear storage at all, and just check if the contract was initiated since
CREATE2 was not intended to complicate
SLOAD, and this change reverts that complexity.
Also, bugs in this implementation could split the network.
Instead this defers the time of storage cleanup, and leaves the storage in-place, which reduces the complexity of
This empowers the
CREATE2 reincarnation proxy pattern by retaining storage during upgrade, which would otherwise have to be reset again.
An atomic reincarnation upgrade could clear a subset of storage during the upgrade, while the contract is destroyed, before reinstating it.
FORK_BLOCK_NUM, a new opcode,
EXTCLEAR, is enabled at
0x5C to clear storage for
- does not push any words onto the stack
- pops two words off the stack: the destroyed contract address and a storage address
- if the contract exists, charge the same gas cost as
- otherwise, if the storage is zero, charge the same gas as
- otherwise, the destroyed contract's slot is reset to 0, charging the same gas as
SSTOREwhen resetting storage, while also refunding the amount specified in
SELFDESTRUCT is modified to not clear contract storage.
This change also works retroactively: all prior destroyed contracts can be cleaned up.
0x5C is available in the same range as
A reincarnation upgrade mechanism that expects all internal storage to be cleared might break, but such an upgrade mechanism would allow adaptation to this new behavior.
Implementation is required on all major clients to add the opcode.
A reincarnated contract that does not expect its state to be cleared by malicious actors SHOULD reinitialize itself to avoid antagonistic
Copyright and related rights waived via CC0.
Adopted by projects
Not miss a beat of EIPs' update?
Subscribe EIPs Fun to receive the latest updates of EIPs Good for Buidlers to follow up.View all