From 70ecb8fb81f45e81cbc217d99309d1f7f66d3345 Mon Sep 17 00:00:00 2001 From: Gary Rong Date: Fri, 2 Feb 2024 16:35:53 +0800 Subject: [PATCH 1/6] Add EIP: Revert creation in case of non-empty storage --- EIPS/eip-tbd.md | 47 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 47 insertions(+) create mode 100644 EIPS/eip-tbd.md diff --git a/EIPS/eip-tbd.md b/EIPS/eip-tbd.md new file mode 100644 index 00000000000000..69459cbb788286 --- /dev/null +++ b/EIPS/eip-tbd.md @@ -0,0 +1,47 @@ +--- +eip: TBD +title: Revert creation in case of non-empty storage +description: Revert contract creation if address already has the non-empty storage +author: Gary Rong (@rjl493456442), Martin Holst Swende (@holiman) +discussions-to: TBD +status: Draft +type: Standards Track +category: Core +created: 2024-2-2 +--- + +## 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 the 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 with one extra condition, requiring empty storage for contract deployment. + +## 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 EIP158 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. + +## Test Cases + +There exists quite a number of tests in the ethereum reference [tests](https://github.com/ethereum/tests) aswell 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). \ No newline at end of file From 29c83f66ad3175d683c19e4ae30a190edb5eb182 Mon Sep 17 00:00:00 2001 From: Gary Rong Date: Fri, 2 Feb 2024 19:10:24 +0800 Subject: [PATCH 2/6] Add ethereum-magicians link --- EIPS/eip-tbd.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/EIPS/eip-tbd.md b/EIPS/eip-tbd.md index 69459cbb788286..0d5fff1a8947f5 100644 --- a/EIPS/eip-tbd.md +++ b/EIPS/eip-tbd.md @@ -3,7 +3,7 @@ eip: TBD title: Revert creation in case of non-empty storage description: Revert contract creation if address already has the non-empty storage author: Gary Rong (@rjl493456442), Martin Holst Swende (@holiman) -discussions-to: TBD +discussions-to: https://ethereum-magicians.org/t/eip-revert-creation-in-case-of-non-empty-storage/18452 status: Draft type: Standards Track category: Core @@ -44,4 +44,4 @@ This EIP is a security upgrade: it enforces the imutability of deployed code. ## Copyright -Copyright and related rights waived via [CC0](../LICENSE.md). \ No newline at end of file +Copyright and related rights waived via [CC0](../LICENSE.md). From bdfd33bddf3a9680085ce7f52f91c3f731d22b8a Mon Sep 17 00:00:00 2001 From: Gary Rong Date: Fri, 2 Feb 2024 19:19:54 +0800 Subject: [PATCH 3/6] fix format --- EIPS/eip-tbd.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/EIPS/eip-tbd.md b/EIPS/eip-tbd.md index 0d5fff1a8947f5..1e8af84b9b288d 100644 --- a/EIPS/eip-tbd.md +++ b/EIPS/eip-tbd.md @@ -7,7 +7,7 @@ discussions-to: https://ethereum-magicians.org/t/eip-revert-creation-in-case-of- status: Draft type: Standards Track category: Core -created: 2024-2-2 +created: 2024-02-02 --- ## Abstract @@ -20,11 +20,11 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "S 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 the 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 with one extra condition, requiring empty storage for contract deployment. +This EIP amends [EIP-684](./eip-684.md) with one extra condition, requiring empty storage for contract deployment. ## 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 EIP158 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. +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. @@ -34,7 +34,7 @@ This is an execution layer upgrade, and so it requires a hard fork. ## Test Cases -There exists quite a number of tests in the ethereum reference [tests](https://github.com/ethereum/tests) aswell 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. +There exists quite a number of tests in the ethereum tests repo aswell 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. From 8903f8277c2f99a492f148bca4fbe78f49005c00 Mon Sep 17 00:00:00 2001 From: Gary Rong Date: Fri, 2 Feb 2024 21:09:01 +0800 Subject: [PATCH 4/6] Assign EIP number --- EIPS/{eip-tbd.md => eip-7610.md} | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) rename EIPS/{eip-tbd.md => eip-7610.md} (99%) diff --git a/EIPS/eip-tbd.md b/EIPS/eip-7610.md similarity index 99% rename from EIPS/eip-tbd.md rename to EIPS/eip-7610.md index 1e8af84b9b288d..e14d0046869e3b 100644 --- a/EIPS/eip-tbd.md +++ b/EIPS/eip-7610.md @@ -1,5 +1,5 @@ --- -eip: TBD +eip: 7610 title: Revert creation in case of non-empty storage description: Revert contract creation if address already has the non-empty storage author: Gary Rong (@rjl493456442), Martin Holst Swende (@holiman) From 797f08d8985658a2c8ae806945078557b6154598 Mon Sep 17 00:00:00 2001 From: rjl493456442 Date: Tue, 2 Apr 2024 20:27:44 +0800 Subject: [PATCH 5/6] Update EIPS/eip-7610.md Co-authored-by: Guillaume Ballet <3272758+gballet@users.noreply.github.com> --- EIPS/eip-7610.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-7610.md b/EIPS/eip-7610.md index e14d0046869e3b..0fd65709024de7 100644 --- a/EIPS/eip-7610.md +++ b/EIPS/eip-7610.md @@ -18,7 +18,7 @@ This EIP causes contract creation to throw an error when attempted at an address 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 the 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. +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. From cf2e790d0588b0d7571eb518a28e6c211f1f0f81 Mon Sep 17 00:00:00 2001 From: rjl493456442 Date: Tue, 2 Apr 2024 20:27:58 +0800 Subject: [PATCH 6/6] Update EIPS/eip-7610.md Co-authored-by: Sam Wilson <57262657+SamWilsn@users.noreply.github.com> --- EIPS/eip-7610.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-7610.md b/EIPS/eip-7610.md index 0fd65709024de7..80ef48d0bbb5a4 100644 --- a/EIPS/eip-7610.md +++ b/EIPS/eip-7610.md @@ -34,7 +34,7 @@ This is an execution layer upgrade, and so it requires a hard fork. ## Test Cases -There exists quite a number of tests in the ethereum tests repo aswell 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. +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.