4

SELFDESTRUCT-ing a Smart Contract requires effectively removing the EVM storage of that contract from the Ethereum database.

What would happen if a newly-submitted tx would lead to the SELFDESTRUCT-ion of a Smart Contract having a storage that is too big (e.g. USDT) to be processed in a timely manner (i.e. until the chain has already been extended with another block)?

Is this a potential DoS attack vector for Ethereum?

P.S. I suspect that this might've only been a problem back when the Ethereum block production was PoW-based.

1 Answer 1

5

It's a fairly complex question, but here it goes:

First up. With the Dencun update, SELFDESTRUCT was removed, specifically because it was a thorny opcode from various points of view. So on Ethereum mainnet, this is moot. That said...

Before the Dencun update, deleting the items was not obviously DOSable.

In the original data representation of Ethereum, each node just stored the MPT trie as is and used that for access. When new trie nodes were added to the data structure, you just shoved more to disk. When you deleted something, you essentially just shoved again new ones (empty root trie nodes) to disk and didn't care about the old one, accumulating junk. This was the achilles heel of Geth for a long time. But this was not DOSable.

Now, accumulating junk till infinity is an issue, so every client tried to add its own version of pruning. For Geth itself for example, that is the new PathDB database layout. This layout - among others - stores only 1 persistent trie on disk and keeps mutating that (backwards and forwards). Now in this case, SELFDESTRUCT does become a DoS issue specifically for the reason you mentioned: given a big enough contract, deleting it takes forever. What's worse, you also need to be able to resurrect if there's a reorg, so it's a double whammy.

What Geth did to avoid this DoS vector until Dencun was to have a cap on the maximum size it permitted to be deleted for a contract. We set it to 500MB. If the contract was larger, we just tombstoned it on disk and "yolo, that's wasted space now". With Dencun here, Geth 1.14 removed that hack.

So, if your client operates on hash tries, there's no worry, but also no pruning. If your client has pruning or snapshot (flat) data layout, then it is a DoS before Dencun (unless the client has some special code to handle it).

P.S. This is unrelated to PoW.

P.P.S. The reason SELFDESTRUCT was gutted is specifically because it was this one opcode where you had a fixed cost for a dynamic resource consumption. The opcode relied on legacy client implementations and hand-waved away the semantic elephant in the room.

2
  • 2
    An awesome answer. Thanks! Commented Apr 29 at 13:50
  • @péter-szilágyi, thank you very much for the detailed answer!
    – Iaroslav
    Commented May 1 at 16:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.