Abstract

This EIP causes contract creation to throw an error when attemted at an address with pre-existing code. This prevents an attack consisting of deploying contract code and later changing the code arbitrarily by "creating" an account at that existing address.

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, or a nonzero code length, 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.

Rationale

One of the core tenants of smart contracts is that its code will not change. However with sufficient computing power an attacker can change the code stored in an address to any other code, steal funds or execute other malicious activity.

Backwards Compatibility

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

Test Cases

Given a genesis allocation of

Address : 0xd0bBEc6D2c628b7e2E6D5556daA14a5181b604C5,
Balance : 1000000000000000000, // 1 ether
Nonce   : 0,
code    : "",

Address : 0x7658771dc6Af74a3d2F8499D349FF9c1a0DF8826,
Balance : 0,
Nonce   : 1,
Code    : "0xB0B0FACE",

A contract created in the first transaction from EOA 0xd0bBEc6... (227bcc6959669226360814723ed739f1214201584b6a27409dfb8228b8be5f59), with no salt, should revert.

Security Considerations

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

Copyright

Copyright and related rights waived via CC0.