This EIP reduces the complexity of SELFDESTRUCT by deferring the clearing of storage. Instead storage is cleared by a new opcode, EXTCLEAR.
I am interested to know whether or not the SELFDESTRUCT change would be easier to implement retroactively or not. I do not care either way; complexity is what matters.
Random question: could this be used to “cleanup” all the storage of a “not self destructed” smart contract.
Example: I want to repurpose a proxy to delegate to a new contract with incompatible memory layout, can I EXTCLEAR to remove the contract storage, keep the contract code, an just write the new delegation address (to an otherwize empty storage) ?
1 Like
No, this only allows cleanup of storage corresponding to accounts currently with codesize zero. This supports the non-proxy CREATE2 reincarnation upgrade pattern, and if your proxy was created with CREATE and not CREATE2 you would not be able to reincarnate it.
Could u clarify this sentence from the EIP:
"and just check if the contract was initiated since SSTORE ( 0x55 ) during SLOAD"