HomeEIPsNewsletter
EIPsEIP-6190
EIP-6190

Verkle-compatible SELFDESTRUCT

Changes SELFDESTRUCT to only cause a finite number of state changes
StagnantStandards Track: Core
Created: 2022-12-20
Requires: EIP-2929, EIP-6188, EIP-6189
Gavin John (@Pandapip1)
DiscussionsOriginal linkEdit
1 min read

The EIP-6190 proposal aims to change the behavior of the SELFDESTRUCT instruction in Ethereum to only cause a finite number of state changes. Currently, SELFDESTRUCT has a fixed price but is unbounded in storage/account changes, which has been a concern for some time. With Verkle trees, accounts will be organized differently, making it challenging to support SELFDESTRUCT. Therefore, this proposal is a step towards supporting SELFDESTRUCT in Verkle trees. The proposal suggests that instead of destroying the contract at the end of the transaction, the contract's code will be set to 0x1, and its nonce will be set to 2^64-1. This proposal requires the use of EIP-6188 and EIP-6189 to function correctly. On the other hand, the EIP-6049 proposal aims to deprecate the SELFDESTRUCT opcode and warns against its use. It suggests that a breaking change to this functionality is likely to come in the future. The motivation behind this proposal is ongoing discussions about how to change SELFDESTRUCT, and there is a strong consensus that something will change. This proposal updates non-normative text in the Yellow Paper and does not require any changes to clients.

Video
Anyone may contribute to propose contents.
Go propose
Original

Abstract

Changes SELFDESTRUCT to only cause a finite number of state changes.

Motivation

The SELFDESTRUCT instruction has a fixed price, but is unbounded in storage/account changes (it needs to delete all keys). This has been an outstanding concern for some time.

Furthermore, with Verkle trees accounts will be organised differently. Account properties, including storage, would have individual keys. It would not be possible to traverse and find all used keys. This makes SELFDESTRUCT very challenging to support in Verkle trees. This EIP is a step towards supporting SELFDESTRUCT in Verkle trees.

Specification

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119 and RFC 8174.

Prerequisites

EIP-6188 and EIP-6189 must be used for this EIP to function correctly.

SELFDESTRUCT Behaviour

Instead of destroying the contract at the end of the transaction, instead, the following will occur at the end of the transaction in which it is invoked:

  1. The contract's code is set to 0x1, and its nonce is set to 2^64-1.
  2. The contract's 0th storage slot is set to the address that would be issued if the contract used the CREATE opcode (keccak256(contractAddress, nonce)). Note that the nonce is always 2^64-1.
  3. If the contract was self-destructed after the call being forwarded by one or more alias contracts, the alias contract's 0th storage slot is set to the address calculated in step 2.
  4. The contract's balance is transferred, in its entirety, to the address on the top of the stack.
  5. The top of the stack is popped.

Gas Cost of SELFDESTRUCT

The base gas cost of SELFDESTRUCT is set to 5000. The gas cost of SELFDESTRUCT is increased by 5000 for each alias contract that forwarded to the contract being self-destructed. Finally, the EIP-2929 gas cost increase is applied.

Rationale

This EIP is designed to be a step towards supporting SELFDESTRUCT in Verkle trees while making the minimum amount of changes.

The 5000 base gas cost and additional alias contracts represents the cost of setting the account nonce and first storage slot. The EIP-2929 gas cost increase is preserved for the reasons mentioned in said EIP's Rationale.

The nonce of 2^64-1 was chosen since it is the nonce protected by EIP-6188. The account code of 0x1 was chosen since it was the code specified in EIP-6189.

The address being the same as the one created by CREATE is designed to reduce possible attack vectors by not introducing a new mechanism by which accounts can be created at specific addresses.

Backwards Compatibility

This EIP requires a protocol upgrade, since it modifies consensus rules.

Security Considerations

Needs discussion.

Copyright and related rights waived via CC0.

Further reading
Anyone may contribute to propose contents.
Go propose
Adopted by projects
Anyone may contribute to propose contents.
Go propose

Not miss a beat of EIPs' update?

Subscribe EIPs Fun to receive the latest updates of EIPs Good for Buidlers to follow up.

View all
Serve Ethereum Builders, Scale the Community.
Resources
GitHub
Supported by