1.7 KiB
| eip | title | author | category | type | status | created |
|---|---|---|---|---|---|---|
| 1014 | Skinny CREATE2 | Vitalik Buterin (@vbuterin) | Core | Standards Track | Draft | 2018-04-20 |
Specification
Adds a new opcode at 0xf5, which takes 4 stack arguments: endowment, memory_start, memory_length, salt. Behaves identically to CREATE, except using keccak256(msg.sender ++ salt ++ init_code)[12:] instead of the usual sender-and-nonce-hash as the address where the contract is initialized at.
The coredev-call at 2018-08-10 decided to use option 3.
Motivation
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. Important for state-channel use cases that involve counterfactual interactions with contracts.
Option 2
Use keccak256(0xff ++ msg.sender ++ salt ++ init_code)[12:]
Rationale: ensures that addresses created with this scheme cannot collide with addresses created using the traditional keccak256(rlp([sender, nonce])) formula, as 0xff can only be a starting byte for RLP for data many petabytes long.
Option 3
Use sha3( 0xff ++ msg.sender ++ salt ++ sha3(init_code)))
Rationale:
- Ensures that addresses created with this scheme cannot collide with addresses created using the traditional
keccak256(rlp([sender, nonce]))formula, as0xffcan only be a starting byte for RLP for data many petabytes long. - Ensures that the hash preimage has a fixed size,
This also has the side-effect of being able to possibly reuse the sha3(init_code) from earlier calculation, either within a client or via EXTCODEHASH if the init-code is deployed on-chain.