EIP-7610: Revert creation in case of non-empty storage

EIPs
21

This has been implemented in evmone: Implement EIP-7610 (non-empty storage create collision) and upgrade execution-tests by chfast · Pull Request #816 · ethereum/evmone · GitHub

22

7702 introduces a way to create accounts with storage (although these have nonzero nonce). I believe that the way this EIP is written currently is sufficient, since you thus cannot (if you find a hash collision) now set the code of a previously-delegated EOA to some code. This makes it unable to delegate again because of rule (5):

  1. Verify the code of authority is empty or already delegated.

This test case should be checked if it is already in the execution-specs though. Note that rule 5 seems to imply that if you “deploy” a normal contract at an EOA, it thus seems it cannot be delegated or cleared again because it does not follow 5’s rule: it’s not delegated and it’s also not empty. So, a test case would be setting an EOA to be delegated by 7702, fill storage, and then by some means attempt to create a contract there. When I’m writing this I realize this is practically not possible, because you need the EOA to be the target of a contract creation AND because it is an EOA we thus have the key.

Note: I am proposing this for Glamsterdam because it is not clear to me if this EIP is already the part of the protocol/spec (it is already “forked in”) or not.

23

I noticed that the spec says:

This change MUST apply retroactively for all existing blocks.

It also notes:

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

I don’t think you can both fork and also apply them to all existing blocks. And actually, on mainnet we can’t do this, because we did state clearing in EIP-161 and before that accounts with empty code, zero nonce, but non-empty storage did exist as far as I know.

I think the EIP should be changed to require EIP-684 and to note that the EIP-684 will be amended such that we also apply the collision check for non-empty storage. Via this route we activate this rule on a certain fork, which means we do not have to prove that in all existing blocks this rule held. This would thus have to prove no accounts were created at accounts which had zero nonce, empty code, but non-empty storage. This change allows either EIP-684 and this EIP to be activated together, or to activate this EIP at a later point after EIP-684.