CREATE2 is an Ethereum opcode for creating smart contracts that was introduced as part of Ethereum Improvement Proposal (EIP) 1014 and implemented during the Constantinople upgrade (February 2019). This opcode provides an alternative to the CREATE opcode and integrates new capabilities, such as the ability to deploy or redeploy smart contracts at a deterministically calculated address.
The introduction of the CREATE2 opcode has many different use cases for the Ethereum blockchain, including state channels and upgradeable smart contracts. However, it must also be used carefully to protect against potential exploitation.
How Does CREATE2 Work?
The CREATE2 opcode functions similarly to the original CREATE opcode. With it, developers can deploy smart contracts that users can interact with on the Ethereum blockchain.
The main difference between CREATE and CREATE2 is how the address of the new smart contract is generated. In the case of CREATE, the address is based on the deployer’s address and the number of transactions that the address has performed to date. This means that the deployer has no control over the address used for the smart contract.
With CREATE2, the new address is calculated based on the deployer’s address, a provided salt, and the Keccak256 hash of the contract’s initialization code. All of this information can be computed in advance, and the salt value is a 32-bit number selected by the deployer. This provides some control over the smart contract’s deployment address, similar to how Proof of Work (PoW) miners modify a nonce to find a block whose header hash meets the current difficulty target.
Use Cases for CREATE2
The CREATE2 opcode provides the ability to deterministically calculate the deployment address of a smart contract. Some of the most significant applications of this functionality include:
Upgradeable Smart Contracts: Unlike the CREATE opcode, CREATE2 allows smart contracts to be redeployed at the same address. This enables contract code to be upgraded to add functionality or fix vulnerabilities while retaining the same address.
Streamlined Contract Deployment: With CREATE2, developers can predict where a smart contract will be located in Ethereum’s address space. This helps with deployment automation since the address can be automatically precalculated and included in other smart contracts that need it.
State Channels: State channels are designed to improve blockchain scalability, transaction speed, and fees by moving transactions off-chain. With the CREATE2 opcode, a counterfactual smart contract — which is created off-chain at a deterministic address but never actually deployed — can be created and used by the channel participants but only actually deployed if needed. This design improves efficiency and prevents unneeded contracts from being deployed to the blockchain.
Security Implications of CREATE2
The CREATE2 opcode introduced new capabilities with numerous potential use cases. However, these also come with significant security risks, such as:
Contract Frontrunning: The CREATE2 opcode makes it possible to predict the deployment address of a smart contract, enabling the developers to advertise this address or build additional smart contracts using it before actually deploying it. This creates the risk that an attacker could create and deploy another, malicious smart contract to the address first, potentially resulting in users or other smart contracts trusting and interacting with the malicious contract.
Deployment Denial of Service (DoS): Address predictability enables the process of smart contract deployment to be automated and potentially built into a smart contract. If an attacker frontruns contract creation and a smart contract depends on the ability to deploy code to that address, then the smart contract may become stuck in an invalid state.
Malicious Contract Updates: The CREATE2 opcode allows smart contracts to be upgraded by redeploying contracts to the same address. This could allow a malicious deployer or attacker to upgrade code to perform their attacks. Users of the smart contract may be unaware of the upgrade, causing them to interact with a malicious contract at the same address as a previously-trusted one.
Smart Contract Interactions: The ability to upgrade smart contracts also has significant implications for other smart contracts that interact with a contract and make assumptions about its functionality. Changes that introduce malicious code or change the functionality of a contract may render other contracts that interact with it vulnerable to exploitation or inoperable.
State Tracking: With the CREATE opcode, a contract deployed at a particular address could be relied upon to have immutable code. With CREATE2, automated smart contract development and deployment tools need to track both contract addresses and the bytecode deployed at them to ensure that no changes have been made to the code.
Managing the Security Risks of CREATE2
The CREATE2 opcode has numerous benefits for Ethereum smart contract developers, but it also introduces several major security risks. Some best practices for managing these include the following:
Smart Contract Auditing: Smart contracts deployed using CREATE2 can be upgraded while retaining the same address. Any smart contract that is deployed this way or that interacts with one that was should be carefully audited to minimize the potential impacts of future upgrades.
Clear Upgrade Processes: The ability to upgrade smart contracts deployed with CREATE2 can be invaluable. However, this action should be managed by clearly documented processes that avoid surprising users and other smart contracts that depend on them.
Deployer Management: The address used to deploy a smart contract via CREATE2 is more powerful than with CREATE due to the potential for upgrades. Control over this address — or contract-deploying functionality in a smart contract — should be managed via a multi-signature wallet or decentralized governance algorithm.
Change Monitoring: The bytecode and functionality of smart contracts created via CREATE2 can be changed at any time. Users, applications, and smart contracts that interact with these contracts should monitor for changes before using them.
Access Management: Privileged functions such as selfdestruct in these smart contracts can have dangerous effects and should be managed with strict access controls.
As with any smart contract, contracts created with CREATE2 should undergo a comprehensive security audit before launch and be managed by a robust security strategy. For help in ensuring the security of your smart contracts, get in touch with Halborn.