61 lines
3.0 KiB
Markdown
61 lines
3.0 KiB
Markdown
---
|
|
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).
|