66 lines
3.7 KiB
Markdown
66 lines
3.7 KiB
Markdown
|
---
|
||
|
|
eip: 6046
|
||
|
|
title: Replace SELFDESTRUCT with DEACTIVATE
|
||
|
|
description: Change SELFDESTRUCT to not delete storage keys and use a special value in the account nonce to signal deactivation
|
||
|
|
author: Alex Beregszaszi (@axic)
|
||
|
|
discussions-to: https://ethereum-magicians.org/t/almost-self-destructing-selfdestruct-deactivate/11886
|
||
|
|
status: Draft
|
||
|
|
type: Standards Track
|
||
|
|
category: Core
|
||
|
|
created: 2022-11-25
|
||
|
|
requires: 2681, 2929, 3529
|
||
|
|
---
|
||
|
|
|
||
|
|
## Abstract
|
||
|
|
|
||
|
|
Change `SELFDESTRUCT` to not delete all storage keys, and to use a special value in the account nonce to signal *deactivated* accounts. Because the semantics of revival change (storage keys may exists), we also rename the instruction to `DEACTIVATE`.
|
||
|
|
|
||
|
|
## Motivation
|
||
|
|
|
||
|
|
The `SELFDESTRUCT` instruction currently has a fixed price, but is unbounded in terms of how many storage/account changes it performs (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, will have individual keys. It will not be possible to traverse and find all used keys. This makes `SELFDESTRUCT` very challenging to support in Verkle trees.
|
||
|
|
|
||
|
|
## Specification
|
||
|
|
|
||
|
|
1. Change the rules introduced by [EIP-2681](./eip-2681.md) such that regular nonce increase is bound by `2^64-2` instead of `2^64-1`. This applies from genesis.
|
||
|
|
|
||
|
|
2. The behaviour of `SELFDESTRUCT` is changed such that:
|
||
|
|
|
||
|
|
- Does not delete any storage keys and also leave the account in place.
|
||
|
|
- Transfer the account balance to the target **and** set account balance to `0.`
|
||
|
|
- Set the account nonce to `2^64-1`.
|
||
|
|
- Note that no refund is given since [EIP-3529](./eip-3529.md).
|
||
|
|
- Note that the rules of [EIP-2929](./eip-2929.md) regarding `SELFDESTRUCT` remain unchanged.
|
||
|
|
|
||
|
|
2. Modify account execution (triggered both via external transactions or CALL* instructions), such that execution succeeds and returns an empty buffer if the nonce equals `2^64-1`.
|
||
|
|
|
||
|
|
- Note that the account can still receive non-executable value transfers (such as coinbase transactions or other `SELFDESTRUCT`s).
|
||
|
|
|
||
|
|
3. Modify `CREATE2` such that it allows account creation if the nonce equals `2^64-1`.
|
||
|
|
|
||
|
|
- Note that the account (especially code and storage) might not be empty prior to `CREATE2`.
|
||
|
|
- Note that a successful `CREATE2` will change the account code, nonce and potentially balance.
|
||
|
|
|
||
|
|
4. Rename the `SELFDESTRUCT` instruction to `DEACTIVATE`, because the semantics of "account revival" are changed: the old storage items will remain, and newly deployed code must be aware of this.
|
||
|
|
|
||
|
|
## Rationale
|
||
|
|
|
||
|
|
There have been various proposals of removing `SELFDESTRUCT` and many would just outright remove the deletion capability. This breaks certain usage patterns, which the *deactivation* option leaves intact, albeit with minor changes. This only affects *newly* deployed code, and not existing one.
|
||
|
|
|
||
|
|
All the proposals would leave data in the state, but this proposal provides the flexibility to reuse or remove storage slots one-by-one should the revived contract choose to do so.
|
||
|
|
|
||
|
|
## Backwards Compatibility
|
||
|
|
|
||
|
|
This EIP requires a protocol upgrade, since it modifies consensus rules. The further restriction of nonce should not have an effect on accounts, as `2^64-2` is an unfeasibly high limit.
|
||
|
|
|
||
|
|
Contracts using the revival pattern will still work, but the code deployed during revival may need to be made aware that storage keys can already exist in the account.
|
||
|
|
|
||
|
|
## Security Considerations
|
||
|
|
|
||
|
|
The new behaviour of preserving storage has a potential effect on security. Contract authors must be aware and design contracts accordingly. There may be an effect on existing deployed code performing autonomous destruction and revival.
|
||
|
|
|
||
|
|
## Copyright
|
||
|
|
|
||
|
|
Copyright and related rights waived via [CC0](../LICENSE.md).
|