Correctly handle self-destruct #1717
Conversation
| T::AccountProvider::remove_account(&account_id); | ||
| } | ||
| let account_id = T::AddressMapping::into_account_id(*address); | ||
| T::AccountProvider::remove_account(&account_id); |
There was a problem hiding this comment.
What's the reason to remove the if branch?
There was a problem hiding this comment.
When we destroy the contract inside the constructor, the AccountCode is not yet set.
|
Is EIP-6780 implemented at this moment? From my look, it doesn't seem so yet: frontier/frame/evm/src/runner/stack.rs Line 413 in 54140ae |
It was added in this PR: #1588 |
sorpaas
left a comment
sorpaas
left a comment
There was a problem hiding this comment.
In #1588 there's one scenario I'm not sure if it's considered -- a contract that is being created can still write a large number of storage values, and upon self-destruct, clear_suffix will still need to delete a lot of values from the changeset.
But I think this is safe as this is purely a in-memory operation with no merkle involved.
* test: self-destruct functionality after cancun upgrade * fix self-destruct logic
What does it do?
Adds a test to ensure that when a contract is created with
CREATE2andSelf Destructedin the same transaction, it can be created again.The behaviour of
SELFDESTRUCTwas changed in Cancun hard-fork, where it will recover all funds to the target but not delete the account, except when called in the same transaction as creation.References:
https://eips.ethereum.org/EIPS/eip-6780