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

Add EIP: Revert creation in case of non-empty storage #8161

Merged
merged 6 commits into from
Apr 8, 2024
Merged

Add EIP: Revert creation in case of non-empty storage #8161

Changes from all commits
Commits
Show all changes
6 commits
Select commit Hold shift + click to select a range
70ecb8f
Add EIP: Revert creation in case of non-empty storage
rjl493456442 Feb 2, 2024
29c83f6
Add ethereum-magicians link
rjl493456442 Feb 2, 2024
bdfd33b
fix format
rjl493456442 Feb 2, 2024
8903f82
Assign EIP number
rjl493456442 Feb 2, 2024
797f08d
Update EIPS/eip-7610.md
rjl493456442 Apr 2, 2024
cf2e790
Update EIPS/eip-7610.md
rjl493456442 Apr 2, 2024
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
47 changes: 47 additions & 0 deletions EIPS/eip-7610.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,47 @@
---
eip: 7610
title: Revert creation in case of non-empty storage
description: Revert contract creation if address already has the non-empty storage
Copy link

Choose a reason for hiding this comment

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

Avoid restating the title in the description. Maybe include why this is important to do.

author: Gary Rong (@rjl493456442), Martin Holst Swende (@holiman)
discussions-to: https://ethereum-magicians.org/t/eip-revert-creation-in-case-of-non-empty-storage/18452
status: Draft
type: Standards Track
category: Core
created: 2024-02-02
---

## Abstract

This EIP causes contract creation to throw an error when attempted at an address with pre-existing storage.

## Specification

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

If a contract creation is attempted due to a creation transaction, the `CREATE` opcode, the `CREATE2` opcode, or any other reason, and the destination address already has either a nonzero nonce, a nonzero code length, or non-empty storage, then the creation MUST throw as if the first byte in the init code were an invalid opcode. This change MUST apply retroactively for all existing blocks.

This EIP amends [EIP-684](./eip-684.md) with one extra condition, requiring empty storage for contract deployment.
Copy link
Contributor

Choose a reason for hiding this comment

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

could you explain or write pesudo code of how this check will be done? storageRoot? and how it will be addressed in verkle (i am guessing this check only applies on the merkle structure, but EIP should address the scenario)

Copy link

Choose a reason for hiding this comment

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

I assume you are rite or I don't understand


## Rationale

EIP-684 defines two conditions for contract deployment: the destination address must have zero nonce and zero code length. Unfortunately, this is not sufficient. Before [EIP-158](./eip-158.md) was applied, the nonce of a newly deployed contract remained set to zero. Therefore, it was entirely possible to create a contract with a zero nonce and zero code length but with non-empty storage, if slots were set in the constructor. There exists 28 such contracts on Ethereum mainnet at this time.

As one of the core tenets of smart contracts is that its code will not change, even if the code is zero length. The contract creation must be rejected in such instanace.

## Backwards Compatibility

This is an execution layer upgrade, and so it requires a hard fork.
Copy link
Contributor

Choose a reason for hiding this comment

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

Does this actually require a hard fork?

Copy link
Member Author

Choose a reason for hiding this comment

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

https://eips.ethereum.org/EIPS/eip-684 uses the same terminology.

Copy link
Contributor

Choose a reason for hiding this comment

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

Given we are "retroactively activating" this from genesis, it may be worth being a bit more specific here @rjl493456442


## Test Cases

There exists quite a number of tests in the ethereum tests repo as well as in the execution spec tests, which test the scenario of deployment to targets with non-empty storage. These tests have been considered problematic in the past; Reth and EELS both intentionally implement a version of the account reset solely to pass the tests. Py-evm declared the situation impossible and never implemented account reset.

Refilling the existing tests will provide sufficient coverage for this EIP.

## Security Considerations

This EIP is a security upgrade: it enforces the imutability of deployed code.

## Copyright

Copyright and related rights waived via [CC0](../LICENSE.md).
Loading