DCIPs/EIPS/eip-2936.md

61 lines
3.0 KiB
Markdown
Raw Normal View History

---
eip: 2936
title: EXTCLEAR Opcode For SELFDESTRUCTed contracts
author: William Morriss (@wjmelements)
discussions-to: https://ethereum-magicians.org/t/eip-2936-extclear-for-selfdestruct/4569
status: Stagnant
type: Standards Track
category: Core
created: 2020-09-03
---
## Simple Summary
Enable new opcode to clear storage for `SELFDESTRUCTED`ed contracts.
## Abstract
Changes `SELFDESTRUCT` (`0xff`) to not clear any storage and adds a new `EXTCLEAR` (`0x5c`) opcode that will clear a specific storage slot for a contract that has previously been self destructed.
## Motivation
`SELFDESTRUCT` (`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 `SELFDESTRUCT`s.
Further, contracts can be re-initialized using `CREATE2` (`0xF5`), and then `SLOAD` (`0x54`) prior storage.
Therefore, several ethereum clients do not clear storage at all, and just check if the contract was initiated since `SSTORE` (`0x55`) during `SLOAD`.
`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 `SLOAD` and `SELFDESTRUCT`.
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.
## Specification
After `FORK_BLOCK_NUM`, a new opcode, `EXTCLEAR`, is enabled at `0x5C` to clear storage for `SELFDESTRUCT`ed contracts.
`EXTCLEAR`:
* 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 `EXTCODEHASH` (`0x3F`)
* otherwise, if the storage is zero, charge the same gas as `EXTCODEHASH` plus `SLOAD`
* otherwise, the destroyed contract's slot is reset to 0, charging the same gas as `EXTCODEHASH` and `SSTORE` when resetting storage, while also refunding the amount specified in `SSTORE`.
`SELFDESTRUCT` is modified to not clear contract storage.
This change also works retroactively: all prior destroyed contracts can be cleaned up.
## Rationale
`0x5C` is available in the same range as `SSTORE` and `SLOAD`.
## Backwards Compatibility
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.
## Test Cases
TODO
## Implementation
Implementation is required on all major clients to add the opcode.
## Security Considerations
A reincarnated contract that does not expect its state to be cleared by malicious actors SHOULD reinitialize itself to avoid antagonistic `EXTCLEAR`.
## Copyright
Copyright and related rights waived via [CC0](../LICENSE.md).