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.

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

BEP-344: Implement EIP-6780: SELFDESTRUCT only in same transaction #344

Merged
merged 1 commit into from
Jan 17, 2024
Merged
Changes from all commits
Commits
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
93 changes: 93 additions & 0 deletions BEPs/BEP-344.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,93 @@
<pre>
BEP: 344
Title: Implement EIP-6780: SELFDESTRUCT only in same transaction
Status: Draft
Type: Standards
Created: 2024-01-15
</pre>


# BEP-344: Implement EIP-6780: SELFDESTRUCT only in same transaction

- [BEP-344: Implement EIP-6780: SELFDESTRUCT only in same transaction](#bep-344-implement-eip-6780-selfdestruct-only-in-same-transaction)
- [1. Summary](#1-summary)
- [2. Abstract](#2-abstract)
- [3. Motivation](#3-motivation)
- [4. Specification](#4-specification)
- [5. Rationale](#5-rationale)
- [6. Backwards Compatibility](#6-backwards-compatibility)
- [7. Security Considerations](#7-security-considerations)
- [8. License](#8-license)
- [9. Reference](#9-reference)


## 1. Summary
As part of Cancun upgrade, Implement EIP-6780: SELFDESTRUCT only in same transaction is required to be implemented to BSC.

## 2. Abstract

This EIP changes the functionality of the `SELFDESTRUCT` opcode. The new functionality will be only to send all Ether in the account to the target, except that the current behaviour is preserved when `SELFDESTRUCT` is called in the same transaction a contract was created.

## 3. 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.

This EIP implements this change. Applications that only use `SELFDESTRUCT` to retrieve funds will still work. Applications that only use `SELFDESTRUCT` in the same transaction as they created a contract will also continue to work without any changes.

## 4. Specification

The behaviour of `SELFDESTRUCT` is changed in the following way:

1. When `SELFDESTRUCT` is executed in a transaction that is not the same as the contract calling `SELFDESTRUCT` was created:

- The current execution frame halts.
- `SELFDESTRUCT` does not delete any data (including storage keys, code, or the account itself).
- `SELFDESTRUCT` transfers the entire account balance to the target.
- Note that if the target is the same as the contract calling `SELFDESTRUCT` there is no net change in balances. Unlike the prior specification, Ether will not be burnt in this case.
- Note that no refund is given since [EIP-3529](./BEP212.md).
- Note that the rules of [EIP-2929](./BEP-230.md) regarding `SELFDESTRUCT` remain unchanged.

2. When `SELFDESTRUCT` is executed in the same transaction as the contract was created:

- `SELFDESTRUCT` continues to behave as it did prior to this EIP, this includes the following actions
- The current execution frame halts.
- `SELFDESTRUCT` deletes data as previously specified.
- `SELFDESTRUCT` transfers the entire account balance to the target
- The account balance of the contact calling `SELFDESTRUCT` is set to `0`.
- Note that if the target is the same as the contract calling `SELFDESTRUCT` that Ether will be burnt.
- Note that no refund is given since [EIP-3529](./BEP212.md).
- Note that the rules of [EIP-2929](./BEP-230.md) regarding `SELFDESTRUCT` remain unchanged.

A contract is considered created at the beginning of a create transaction or when a CREATE series operation begins execution (CREATE, CREATE2, and other operations that deploy contracts in the future). If a balance exists at the contract's new address it is still considered to be a contract creation.

The `SELFDESTRUCT` opcode remains deprecated as specified in [EIP-6049](./BEP-312.md). Any use in newly deployed contracts is strongly discouraged even if this new behaviour is taken into account, and future changes to the EVM might further reduce the functionality of the opcode.

## 5. Rationale

Getting rid of the `SELFDESTRUCT` opcode has been considered in the past, and there are currently no strong reasons to use it. This EIP implements a behavior that will attempt to leave some common uses of `SELFDESTRUCT` working, while reducing the complexity of the change on EVM implementations that would come from contract versioning.

Handling the account creation and contract creation as two distinct and possibly separate events is needed for use cases such as counterfactual accounts. By allowing the `SELFDESTRUCT` to delete the account at contract creation time it will not result in stubs of counterfactually instantiated contracts that never had any on-chain state other than a balance prior to the contract creation. These accounts would never have any storage and thus the trie updates to delete the account would be limited to the account node, which is the same impact a regular transfer of ether would have.

## 6. Backwards Compatibility

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

Contracts that depended on re-deploying contracts at the same address using `CREATE2` (after a `SELFDESTRUCT`) will no longer function properly if the created contract does not call `SELFDESTRUCT` within the same transaction.

Previously it was possible to burn ether by calling `SELFDESTRUCT` targeting the executing contract as the beneficiary. If the contract existed prior to the transaction the ether will not be burned. If the contract was newly created in the transaction the ether will be burned, as before.

## 7. Security Considerations

The following applications of `SELFDESTRUCT` will be broken and applications that use it in this way are not safe anymore:

1. Where `CREATE2` is used to redeploy a contract in the same place in order to make a contract upgradable. This is not supported anymore and [ERC-2535](https://github.com/ethereum/ERCs/blob/master/ERCS/erc-2535.md) or other types of proxy contracts should be used instead.

2. Where a contract depended on burning Ether via a `SELFDESTRUCT` with the contract as beneficiary, in a contract not created within the same transaction.

## 8. License

The content is licensed under [CC0](https://creativecommons.org/publicdomain/zero/1.0/).

## 9. Reference

Guillaume Ballet (@gballet), Vitalik Buterin (@vbuterin), Dankrad Feist (@dankrad), "EIP-6780: SELFDESTRUCT only in same transaction [DRAFT]," Ethereum Improvement Proposals, no. 6780, March 2023. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-6780.