Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

EIP-4758: Deactivate selfdestruct #4758

Merged
merged 8 commits into from
Mar 28, 2022
Merged

EIP-4758: Deactivate selfdestruct #4758

Changes from 3 commits
Commits
Show all changes
8 commits
Select commit Hold shift + click to select a range
58fc77b
Deactivate selfdestruct initial commit
dankrad Feb 3, 2022
686be81
Add discussions-to
dankrad Feb 3, 2022
cc8cd8d
Remove erroneous brackets in category
dankrad Feb 3, 2022
ef55cbe
Update EIPS/eip-4758.md
dankrad Feb 8, 2022
5b5511c
Move discussion to Ethereum Magicians
dankrad Mar 25, 2022
c13051d
Fix header, add security considerations and other fixes
dankrad Mar 25, 2022
939b444
Fix typo
dankrad Mar 25, 2022
556948a
Remove external link
dankrad Mar 26, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
39 changes: 39 additions & 0 deletions EIPS/eip-4758.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,39 @@
---
eip: 4758
title: Deactivate SELFDESTRUCT
description: Deactivate SELFDESTRUCT by changing it to SENDALL, which does recover all funds to the caller but does not delete any contract code or storage.
dankrad marked this conversation as resolved.
Show resolved Hide resolved
author: Guillaume Ballet (@gballet), Vitalik Buterin (@vbuterin), Dankrad Feist (@dankrad)
discussions-to: https://github.com/ethereum/EIPs/issues/4759
dankrad marked this conversation as resolved.
Show resolved Hide resolved
status: Draft
type: Standards Track
category: Core
created: 2022-02-03
requires:
dankrad marked this conversation as resolved.
Show resolved Hide resolved
---

# Deactivating SELFDESTRUCT
dankrad marked this conversation as resolved.
Show resolved Hide resolved

## Summary

This EIP renames the `SELFDESCRUCT` opcode to `SENDALL`, and replaces its functionality. The new functionality will be only to send all Ether in the account to the caller.
dankrad marked this conversation as resolved.
Show resolved Hide resolved

## Motivation

The `SELFDESTRUCT` opcode requires large changes to the state of an account, in particular removing all code and storage. This will not be possible in the future with Verkle trees: Each account will be stored in many different account keys, which will not be obviously connected to the root account (see [Verkle tree EIP](https://notes.ethereum.org/5HDhQXstTaKtVqVbS7S9yw)).
dankrad marked this conversation as resolved.
Show resolved Hide resolved

This EIP implements this change. Applications that only use SELFDESTRUCT to retrieve funds will still work.

## Specification

* The `SELFDESTRUCT` opcode is renamed to `SENDALL`, and now only immediately moves all ETH in the account to the target; it no longer destroys code or storage or alters the nonce
dankrad marked this conversation as resolved.
Show resolved Hide resolved
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You forgot to mention that SENDALL still terminates execution.

* All refunds related to `SELFDESTRUCT` are removed
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

They were already removed in London. Is there a reason to mention this here?


## Rationale

Getting rid of the `SELFDESTRUCT` opcode has been considered in the past (for arguments see [here](https://hackmd.io/@vbuterin/selfdestruct)), and there are currently no strong reasons to use it. Disabling it will be a requirement for statelessness.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please include the rationale inline here, not in an external link. You don't need to provide a complete argument/essay, just the key talking points about alternative options like having it become a no-op, or having it become a hard error. A couple sentences is probably fine in this case.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This still needs to be addressed.


## Backward-Compatibility

This EIP requires a hard fork, since it modifies consensus rules.

Few applications are affected by this change. The only use that breaks is where a contract is re-created at the same address using `CREATE2` (after a `SELFDESTRUCT`). An analysis of the contracts where this happens has been made available [here](https://hackmd.io/@albus/rkAbjAsWF). The only application that is significantly affected (and where code can be analyzed) is able to switch to a different model, and should have ample time to do so.
dankrad marked this conversation as resolved.
Show resolved Hide resolved