EXTCLEAR opcode for SELFDESTRUCT (#2936)

This introduces the `EXTCLEAR` opcode which reduces the complexity of `SELFDESTRUCT`.

EIPS/eip-2936.md

@@ -0,0 +1,61 @@
+---
+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: Draft
+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
+<!--Test cases for an implementation are mandatory for EIPs that are affecting consensus changes. Other EIPs can choose to include links to test cases if applicable.-->
+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](https://creativecommons.org/publicdomain/zero/1.0/).