Why are selfdestructs used in contract programming?

Question

I'm reading bits and pieces that selfdestructs within contracts are a good thing. Can someone explain what the benefits are of doing a contract selfdestruct when it comes to Ethereum programming? Is there a difference if you're using different clients or implementations, or languages?

Answer 1

Selfdestructs in Ethereum are an operation (an OPCODE actually) at the EVM level, independent of what language or client you are using.

For example, calling selfdestruct(address) sends all of the contract's current balance to address.

This is useful when you are finished with a contract, because it costs far less gas than just sending the balance with address.send(this.balance).

In fact, the SELFDESTRUCT opcode uses negative gas because the operation frees up space on the blockchain by clearing all of the contract's data.

This negative gas deducts from the total gas cost of the transaction, so if you're doing some clean-up operations first, SELFDESTRUCT can reduce your gas costs.

Answer 2

Note: this question originally asked about the suicide opcode, which has become selfdestruct in the meantime as per EIP6.

selfdestruct is the encouraged term and may be found in newer Solidity and Serpent code. It is the same API and behavior, as described in the other answers, and is an alias for suicide.

EIP6 describes the motivation:

The primary reason for us to change the term suicide is to show that people matter more than code and Ethereum is a mature enough of a project to recognize the need for a change. Suicide is a heavy subject and we should make every effort possible to not affect those in our development community who suffer from depression or who have recently lost someone to suicide.

Answer 3

The selfdestruct() function and the relative OPCODE are used when you have a contract that has a bug or an unwanted behaviour and you want to get rid of it.

The selfdestruct(address) is a better version as @tjaden-hess pointed out, when you have a payable contracts (contracts that receive ethers) the ethers will be redirected to address which is a big win.

When you interact with a selfdestructed contract NOTE this: If you send a transaction and/or funds to it then your funds are LOST. Be sure to not send funds or other transactions to it after self-destructing a contract.

That's an issue you always have to keep in mind when developing apps that use contracts with a selfdestruct function, be sure the address of the contract is removed from your app after selfdestruct() has been called on the contract, maybe you can always call a getter method to see if the contract responds with a valid value before sending a transaction and/or transferring ethers to it.

Update

The name of the method is now selfdestruct. We have some description of it in the new solidity docs.

Here's a post from r/ethereum about suicide with more infos and a small discussion about it.

Answer 4

IMHO selfdestruct is a bad thing that should never be introduced. It breaks contract's immutability principle and introduces many problems:

1. It allows successfully sending ether to contract that tries to disallow incoming ether transfer (have no payable functions)
2. If allows sending ether to a contract that tries to actively react on incoming ether transfers, in such a way that the contract will not notice the transfer
3. While it does send all the ether from contract's balance to specified address, it does not sent tokens and other assets
4. Assets sent to a contract after selfdestruct are lost in most cases, checking that contract is not selfdestructed before the transfer does not help much, because transfer may be frontrunned with selfdestruct
5. It allows modifying bytecode of a deployed smart contract (EIP-1014)

Answer 5

Why are selfdestructs used in contract programming

Once a contract is created on the Ethereum blockchain it cannot be modified.

1. Each block in the blockchain commits to all of the transactions in the block and the order that they are in. It does this by including the hash of all of the transactions in the block header, which is then part of the data that is hashed for the proof of work.
2. Modifying a smart contract in a block will change the hash of all of the transactions which ultimately changes the hash of the block header. This will likely make the block header's hash have an invalid proof of work. Thus in order to modify the transaction, you would have to redo the block's proof of work, i.e. remine the block.
3. Furthermore, the block header includes the hash of the previous block. So if you want to change a transaction which would contain the smart contract eventually , you will need to also remine all of the blocks following the block which contains the transaction(smart contract) you modified. Lastly, your set of modified blocks are actually a blockchain fork. In order to get it to be accepted by the rest of the network, your fork will need to have more cumulative work than the current blockchain, which effectively means that your fork needs to be longer than the current blockchain.

BENEFITS OF USING SELFDESTRUCT

+-----------------+---------------------------------------------------------------------------------------+
|     Benefit     |                                       Reasoning                                       |
+-----------------+---------------------------------------------------------------------------------------+
| Stop Execution  | If you no longer want the contract running, you can selfdestruct it to “turn it off”. |
| Eliminate Bugs  | (Similar to above). You can kill off smart contracts that are buggy.                  |
| Lower Gas Price | It costs less gas to selfdestruct a contract.                                         |
+-----------------+---------------------------------------------------------------------------------------+