You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When a contract self-destructs, it marks itself as dead. If a subsequent transaction calls EXTCODEHASH, we return whatever the EVM actor returned from GetBytecodeHash. For dead contracts, this is the EMPTY hash. I believe we modelled this after EIP-1052.
However, we have reports from the community saying that this behaviour diverges from Ethereum, who returns 0 when calling EXTCODEHASH on a self-destructed contract on a subsequent transaction.
Well, sort of. The EVM returns 0 until funds are first sent to the address, after which it returns EMPTY. We could introduce an "if dead and balance is 0" check, but any code relying on that fact is likely broken anyways.
Well, I guess it could be doing this as a short-cut to avoid calling the BALANCE instruction?
When a contract self-destructs, it marks itself as dead. If a subsequent transaction calls EXTCODEHASH, we return whatever the EVM actor returned from
GetBytecodeHash
. For dead contracts, this is theEMPTY
hash. I believe we modelled this after EIP-1052.However, we have reports from the community saying that this behaviour diverges from Ethereum, who returns 0 when calling EXTCODEHASH on a self-destructed contract on a subsequent transaction.
Apprently this is the result of both https://eips.ethereum.org/EIPS/eip-161 and https://eips.ethereum.org/EIPS/eip-1052.
The text was updated successfully, but these errors were encountered: