4

According to solidity.readthedocs.io (Link) here is the definition of Self-destruct:

"Definition: The only way to remove code from the blockchain is when a contract at that address performs the Selfdestruct operation. The remaining Ether stored at that address is sent to a designated target and then the storage and code is removed from the state."

While this definition sounds allowing possibility of erasure feature (that is one of the main challenges of incompatibility of GDPR (General Data Protection Regulation) with the blockchain. (Link to Right to erasure in GDPR)); however after definition of Self-destruct , there are following Note and Warning:

"Note: Even if a contract’s code does not contain a call to Selfdestruct, it can still perform that operation using delegatecall or callcode."

"Warning: Even if a contract is removed by Selfdestruct, it is still part of the history of the blockchain and probably retained by most Ethereum nodes. So using Selfdestruct is not the same as deleting data from a hard disk."

What does exactly Self-destruct give us and how can it help us ?

3

First, a small correction. Everything is not reversible, you can't reverse a self-destruct. The quote simply means that the data still exists in the blockchain history even if the contract wouldn't exist anymore in the latest block. So no data is ever removed from the blockchain (history).

I can think of at least a few use cases for self-destruct:

1) When a contract is no longer needed, you can self-destruct it. This way you can be sure nobody can send transactions to it and nobody can interact with it. Even if the contract itself is rendered useless by code (by updating some status variable for example), there may be for example security holes left in it.

2) Force the contracts' users to start using a new contract as the old one simply doesn't exist anymore. For example when you are switching from an old token contract to a new one.

3) A "last resort" backdoor to a contract. If the contract doesn't work as you thought it would and you have included functionality for selfdestruct, you can just remove it and create a better one.

0
2

There's a possibly unintended usage of selfdestruct, which can be handy at times or possibly a security flaw (if you don't account for it): you can use it to send ether to a contract that doesn't have a fallback/receive function.

One use-case I have found this handy for is during testing; you can use a liquidity pool that contains a large number of tokens you would like to use and impersonate its address (allowed by frameworks like Truffle or Hardhat). However, before you can use the pool address to send tokens, you need to fund it with ETH, which will typically be reverted due to lack of fallback/receive. You can do this by deploying a custom contract designed for this purpose -- it will selfdestruct and send its ETH to a recipient address.

0

Self-destruct (which invokes the SUICIDE opcode) is a way to call a contract to stop working. It doesn't delete the code, it just makes it not usable (sort of like commenting out code). All calls before a SUICIDE call are still valid, all calls afterward are not unless they are simply Ether transactions (By before and after, I mean the height at which the transaction is placed, not any sort of nonce).

Self-destruct in Solidity takes a single argument of type address.

If a contract has 50 Ether and selfdestruct is invoked like the following:

selfdestruct(0xDeaDbeefdEAdbeefdEadbEEFdeadbeEFdEaDbeeF)

The contract is now null and all 50 ETH is sent to 0xDeaDbeefdEAdbeefdEadbEEFdeadbeEFdEaDbeeF minus "expended" gas. Technically, some of this expenditure is negative, so the total gas of sending (21000) is reduced by 19000 (the cost is 5000 for the operation but it refunds 24000, leaving 19000 in saved gas), therefore only costing a net of 2000 gas to destroy a contract. The address can be anything, so make sure that if it is a contract, it is payable (the fallback function, made payable, should suffice).

This is useful for defunct contracts, such as ICOs that have their own mainnet and are already frozen.

1
  • a contract doesn't have to have a payable fallback in order to receive ETH from selfdestruct. in fact, selfdestruct is one of the ways to force a contract to receive ether. Jan 5 at 20:59
0

I guess the owner can use it to make a system of smart contracts/dapps trustless. It's enough to selfdestruct the smart contract that recognizes an EOA account address as the owner, leaving the rest of the smart contracts intact.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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