2. EIP-1014: CREATE2 Opcode

This EIP adds a new opcode at 0xf5 for CREATE2 instruction, which takes 4 stack arguments: endowment, memory_start, memory_length and salt. It behaves identical to CREATE instruction but for the address of the new contract being created, it uses keccak256( 0xff ++ sender_address ++ salt ++ keccak256(init_code)))[12:] instead of keccak256(RLP(sender_address, nonce))[12:] .

The key differences in the address computation of CREATE2 are the absence of the nonce (used in CREATE ) and the presence of init_code . Nonce , if we recall, is associated both with Externally-Owned-Account (EOA) and contract account, and is incremented on every transaction made from the EOA account or when a new contract is created by a contract account. Avoiding the use of nonce in contract address generation makes it independent of the temporal state of the sender/creator.

Init_code , if we recall, is EVM bytecode which when executed by the EVM produces (1) contract’s bytecode which will be placed into the account state and (2) any initialisations to be executed during contract creation i.e. the constructor functionality in Solidity. The used of init_code in address generation binds the contract address to the semantics of the contract logic implemented.

The use of the salt (which is controlled by the creator contract) in address generation formula is presumably to allow creating multiple contract addresses which have the same init_code but with potentially different commitments as encoded in the salt ’s value. The use of 0xff is apparently to avoid potential collisions with addresses generated by the CREATE instruction, which uses RLP encoding in its formula and where the encoding data needs to be petabytes in size to get 0xff as the first encoded byte.

The motivation, as explained, is that:

“(this) allows interactions to (actually or counterfactually in channels) be made with addresses that do not exist yet on-chain but can be relied on to only possibly eventually contain code that has been created by a particular piece of init code.”

State Channels

The expected usage of this opcode seems to be mainly in state channels (as explained here and slide 40 of this presentation) which need this capability and are currently using a roundabout way of achieving this using a ‘global registry contract’. CREATE2 will make this simpler with improved performance.

“Counterfactual instantiation means to instantiate a contract without actually deploying it on-chain. When a contract is counterfactually instantiated, all parties in the channel act as though it has been deployed, even though it has not. This technique lets us move almost all channel logic off-chain.”

Security and Usability

There are also applications to enhanced security and usability being considered as explained here and here. The core idea is that this new opcode will let users deposit/receive/hold funds in yet-to-be-deployed contracts. Such wallet contracts may implement security features such as key recovery and multi-device support which is much better than safeguarding funds held only in a key pair.

“ CREATE2 provides an alternative solution that allows the user to start with storing funds in a contract. This empowers the user with finer-grained account access controls because key access is now programmable. Not only does this pave the way for a more secure multi-device support scenario because private keys are never exposed, it also allows the user a wide variety of recovery options. Keys should only provide access, not hold funds.”

Front-running

There is also a proposal to use this functionality to solve the security problem of front-running or transaction-order-dependence. The solution termed “submarine sends” lets a sender conceal a transaction by committing to it and later resurfacing it by revealing the details. CREATE2 is used to commit to a “Forwarder” contract (as described below) which later forwards the transaction to the receiver specified in it.