EIP-6780: Deactivate SELFDESTRUCT, except where it occurs in the same transaction in which a contract was created

EIPs Core EIPs
, ,
1

This thread is to discuss EIP-6780, which is another attempt at getting rid of the SELFDESTRUCT opcode in order to pave the road for statelessness.

This particular EIP preserves the opcode when SELFDESTRUCT is executed in the same transaction that a contract was deployed. This is possible because all the created storage can be held in memory during that time, so the problem of not knowing which storage to delete when it is dispersed as described in the current verkle implementation does not occur.

The reason for this is that contracts exist on mainnet that currently use SELFDESTRUCT to limit who can initiate a transaction with a contract – by destroying the contract in the same transaction so nobody has a chance to call it (one example of such a usage is Pine finance. This can be preserved using EIP-6780.

A previous attempt to preserve more functionality was EIP-6046, which however is deemed unsafe because it does not clear storage on SELFDESTRUCT and some contracts do depend on it. There is also EIP-6190, which implements full SELFDESTRUCT functionality in a stateless-compatible way using contract versioning. However, it is currently judged to be more complex to implement then the variant proposed here.

7 Likes
2

EthereumJS implementation: PR.

1 Like
3

Does it stop execution or not?

2 Likes
4

Just bumping the question above: can you clarify what happens to termination?

1 Like
5

Regardless of the “does it halt execution?” bit missing in the spec, I just wanted to say that imho the proposed solution feels extremely hacky, and although relevant for discussions I don’t think it should be added into production code.

1 Like
6

Hey!

Just want to point out, we use SELFDESTRUCT as well for our contracts at Socket.tech. We built a gas-efficient immutable proxy using it. We use self-destruct to essentially “pause” contracts if there is a need.

Using this method of pausing combined with create2 allows us to create a proxy which doesnt do any storage lookups.

While we were well aware of SELF-DESTRUCT going away while building this we went for this route for short-term gas-optimisation, we plan to pause the contracts before SELF-DESTRUCT goes away.

Just wanted to chime in here to share how we use it.

1 Like
7

EIP-6046 and EIP-6190 have the advantage that create2 reincarnations aren’t permanently broken.

An example where this could be very bad is quoted below:

Screen Shot 2023-05-01 at 5.50.05 PM
Screen Shot 2023-05-01 at 5.50.05 PM1910Ă—240 42.5 KB

Contracts meant to upgrade in this way are not intended to be final. Finalizing them with a hard fork can freeze assets. Their assumption that they can replace their code later should not be violated.

1 Like
8

Dedaub have performed an impact analysis of this EIP, which can be found here, along with summary slides

Some concerns with the report, by @wjmelements: Include SETCODE when you remove SELFDESTRUCT - Google Docs

and a response to it by @yoavw: SETCODE (EIP-6913) security considerations - HackMD

2 Likes
9

From the EIP

  • Note that when verkle tries are implemented on Ethereum, the cleared storage will be marked as having been written before but empty. This leads to no observable differences in EVM execution, but a contract having been created and deleted will lead to different state roots compared to the action not happening.

I am an absolute novice in verkle tries. What happens if we do a pattern where we redeploy these contracts (like a CREATE2 → Selfdestruct → CREATE2 pattern) and at some point we actually /do/ create the contract (also with storage). Would this lead to problems in the verkle trie?

11

This eip is not “improving” but worsening ethereum, it’s just breaking stuff

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.

If it’s not possible with the fking Verkle tree, it should not be implemented on mainnet at all, why not just start a new layer 1 and implement it, instead of just breaking old contracts

Smart contracts are expected to be immutable, and now you guys are arbitrarily changing how smart contracts with selfdestruct behave, that warning for deprecation of selfdestruct previously is useless, many smart contract has already deployed before that and it can’t be changed anymore

Also, it breaks upgradability to the same address, what if some contracts need it and breaking it may cause users losing their funds, even it support that within the same transaction, it still break contracts that need upgradability to the same address in different transaction, and could potentially result in users losing their funds.

This also create inconsistency between other evm compatible chain, and the same evm code can behaves differently on different evm compatible chain, just like the previous PUSH0, many evm chains aren’t going to support it but at least that’s not gonna break stuff, but this eip is even worse and it’s going to break shit and causing users losing their funds

This eip is potentially causing users losing their funds and you motherfkers are just saying “I don’t fking care if others lose their funds, as long as I don’t lose my fund and I’m not affected then it’s fine”

If this is implemented, in the future, people will just think all opcodes can be modified anytime and smart contracts on ethereum can suddenly break in a change and they can potentially lose their fund, it’s nothing more than harming ethereum’s reputation and user base

1 Like
12

This solution was discussed but they were worried that existing patterns may rely on the storage removal. A new opcode such as SETCODE is the better way forward.

13

There is a PR for EIP-6780 in Geth here.

I am also working on adding state test coverage: execution spec tests PR here .