Prevent overwriting contracts
vbuterin opened this issue · 6 comments
Specification
If a contract creation is attempted, due to either a creation transaction or the CREATE (or future CREATE2) opcode, and the destination address already has either nonzero nonce, or nonempty code, then the creation throws immediately, with exactly the same behavior as would arise if the first byte in the init code were an invalid opcode. This applies retroactively starting from genesis.
Rationale
This is the most correct approach for handling the case where a contract is created in a slot where a contract already exists, as the current behavior of overwriting contract code is highly unintuitive and dangerous.
Currently this is not an issue because there is no way to create a contract with the same address twice without spending >2^80 computational effort to find an address collision, but with #86 this will change. Hence it is important to have correct behavior for this situation in the long term. This can be safely applied retroactively for simplicity, because currently creating a contract with the same address twice is computationally infeasible.
Possible corner case and request for discussion ethereum/pm#21 (comment). Bug in my code, disregard.
Perhaps it is not a question of great practical importance, but how does this relate to EIP-161? I.e. what if under the newly created address there exists an empty account (according to EIP-161 rules). Should it still result in an error, or should the empty account be considered inexistent (hence no conflict) and contract creation should proceed normally?
destination address already has either nonzero nonce, or nonempty code
Nevermind, this wording actually answers my question
Does this proposal means that if a ᴄʀᴇᴀᴛᴇ2 operations fails with the a stupid error like out of gas (because the creator forgot to include enough gas) that even in that case (no contract deployed) it’s impossible to rerun the same ᴄʀᴇᴀᴛᴇ2 operation (but with enough gas) ?
There has been no activity on this issue for two months. It will be closed in a week if no further activity occurs. If you would like to move this EIP forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.
This issue was closed due to inactivity. If you are still pursuing it, feel free to reopen it and respond to any feedback or request a review in a comment.