EIP-1014 Skinny CREATE2
Final · EVM & execution · EIP status Final · created 2018-04-20
Adds a new opcode, CREATE2 (0xf5), that computes a contract's address from a salt and the hash of the init code instead of the sending account's nonce. This lets the address be determined before deployment.
Why it is needed
In the existing scheme, a contract's address is determined by combining the address of the creating account with that account's transaction count (nonce). Because the nonce changes with every transaction sent, it is hard to pin down the address of a contract that has not yet been deployed. However, use cases such as state channels, which make off-chain commitments in advance and only post to chain when needed, require a guarantee that a given address, even though it does not yet exist on chain, can only ever be occupied by a contract created from a specific init code. This EIP solves the problem by adding a new opcode that computes the address from fixed ingredients rather than the nonce: the creating account's address, a salt, and the hash of the init code.
What changes
Today
- A contract's address is determined by the creating account's address and its nonce
- Because the nonce keeps changing, it is hard to fix an address before deployment
- It is hard to make off-chain commitments against a contract address that does not yet exist
After EIP-1014
- The CREATE2 opcode computes the address from the creating account, a salt, and the init code hash
- The address can be precomputed and used before deployment
- Only a contract created from the fixed init code can ever occupy that address
Who is affected
- Wallet & app developers: This enables designs where a contract's address is precomputed and used before deployment. The source document cites counterfactual interactions in state channels as the primary use case.
- Client teams: Implementations must add the new opcode 0xf5 and an additional gas cost (hashcost) for hashing the init code.
- Users: There is no directly perceptible change, but it underpins services that make off-chain commitments first and only deploy when needed.
In depth
The new opcode CREATE2 (0xf5) and its address formula
CREATE2 is an opcode added at 0xf5 that takes four stack arguments (endowment, memory_start, memory_length, salt). It behaves the same as CREATE (0xf0), except the address at which the contract is initialized is computed as keccak256(0xff ++ address ++ salt ++ keccak256(init_code))[12:] instead of the existing hash of the sender address and nonce. Since 0xff is 1 byte, address is always 20 bytes, and salt is always 32 bytes (a stack item), the preimage of the final hash is always fixed at exactly 85 bytes.
Gas cost and hashcost
CREATE2 uses the same gas schedule as CREATE, but adds a hashcost of GSHA3WORD * ceil(len(init_code) / 32) for the hashing needed to compute the address. This cost is deducted at the same point as the memory expansion gas and CreateGas, that is, before the resulting address is computed and init_code is executed. Because address computation depends on hashing init_code while memory expansion cost is only paid once, clients could be exposed to a DoS attack that forces repeated hashing of large init_code. For this reason, a per-word cost identical to the SHA3 opcode is applied.
Why it starts with 0xff
Setting the first byte of the preimage to 0xff makes it impossible to collide with addresses produced by the existing formula keccak256(rlp([sender, nonce])), because for 0xff to be the leading byte of RLP-encoded data, the data would need to be petabytes long. The address is also fixed at 20 bytes and the salt at 32 bytes, so the hash preimage size is always constant.
Behavior on address collision
This EIP makes it possible to attempt creation again at the same address, causing a collision. EIP-684 defines the behavior on collision. Whether via a creation transaction or a CREATE (or CREATE2) opcode, if the target address already has a nonzero nonce or non-empty code, creation fails immediately. This behaves identically to the case where the first byte of init_code is an invalid opcode, and applies retroactively from genesis. Also, per EIP-161, the nonce is incremented by 1 at creation time before init_code executes, so once a contract is created within a transaction its nonce immediately becomes nonzero, and any collision attempted within init_code in the same transaction always fails. Because SELFDESTRUCT (0xff) does not immediately affect the nonce or code, a contract cannot be destroyed and recreated within a single transaction.
Meaning of init_code and example vectors
init_code is code that, when executed, produces the runtime bytecode that gets placed into state; in higher-level languages it is typically used to implement the constructor. The source document includes 7 test vectors. For example, with address 0x0000000000000000000000000000000000000000, salt 0, and init_code 0x00, the gas is 32006 (assuming no memory expansion), and the resulting address is 0x4D1A2e2bB4F88F0250f26Ffff098B0b30B26BF38. If init_code is empty (0x), the gas is 32000.
Status and call decision
The status of this EIP is Final, meaning the specification is settled and will not change further. The source document records that the address formula above was decided at the 2018-08-10 coredev call.