Zircuit
  • Introduction
  • Frequently Asked Questions (FAQ)
  • Tokenomics
    • Zircuit Token (ZRC)
    • Bridging ZRC to Zircuit
  • Build on Zircuit
    • Quick Start
    • Deploy on Zircuit
    • Zircuit LST/LRT Liquidity Hub
  • Architecture and Concepts
    • Architecture
      • Modular Prover Design
      • Template Proofs
      • Versions and Updates
    • Concepts
    • Sequencer Level Security (SLS)
    • Gas Pricing and Transaction Fees
    • Transaction Statuses
    • Supported Transaction Types
  • Research
    • Research
    • Publications and Grants
    • Talks and Panels
  • Dev Tools
    • Block Explorer
    • RPC Endpoints
    • Bridge
    • Verifying Contracts
    • ERC20 Tokens with Zircuit Canonical Bridge
    • Development Frameworks
    • CREATE2 Deployments
    • Oracles
    • Indexing and Subgraph
    • Relayers
    • Unsupported Opcodes
    • Precompiles
    • L1 Data Fee Calculation
  • Smart Contracts
    • L1 Contracts
    • L2 Contracts
    • Contract Addresses
    • Bridged Token Addresses
  • Security
    • Security
    • Privileged Roles
    • Bug Bounty
    • Audit Reports
  • Garfield Testnet
    • Garfield Testnet Quick Start
    • Garfield Testnet Bridging Prerequisites
      • Adding the Sepolia Network To Metamask
      • Adding The Zircuit Garfield Testnet Network To Metamask
      • Connecting Metamask To Zircuit’s Bridge
    • Deploy on the Zircuit Garfield Testnet
    • RPC Endpoints
    • Block Explorer
    • Verifying Contracts
    • Bridge
    • Faucet
    • Differences & Limitations
    • Contract Addresses
  • Testnet Legacy
    • Legacy Testnet Quick Start
    • Legacy Testnet Bridging Prerequisites
      • Adding The Sepolia Network To Metamask
      • Adding The Zircuit Legacy Testnet Network To Metamask
      • Connecting Metamask To Zircuit’s Bridge
    • Deploy on the Legacy Zircuit Testnet
    • RPC Endpoints
    • Block Explorer
    • Verifying Contracts
    • Bridge
    • Faucet
    • Contract Addresses
  • Bridging Step-by-Step
    • Prequisites
      • Adding The Zircuit Network To Metamask
    • Bridging From Sepolia To Zircuit
    • Bridging From Zircuit To Sepolia
    • Completing Withdrawals From Zircuit
    • Bridging ERC20 Tokens Manually
    • Binance Web3 Wallet Task Tutorial
      • Binance Web3 Wallet Tutorial: Bridging back to Ethereum
Powered by GitBook
On this page
  1. Dev Tools

CREATE2 Deployments

PreviousDevelopment FrameworksNextOracles

Last updated 2 months ago

In the Ethereum Virtual Machine, CREATE2 is an opcode that allows for the deployment of smart contracts with deterministic addresses. This is particularly useful in complex decentralized applications (dApps) where the ability to predict the address of a contract before it is deployed can simplify interactions between multiple contracts and improve security.

It is especially valuable in the context of L2, as it enables consistent contract addresses across L1 and L2, simplifying cross-layer interactions.

To facilitate safe usage of the CREATE2 opcode, there is a create2deployer Preinstall deployed on Zircuit, which can be used for deterministic deployment addresses of smart contracts. The Preinstalls are accessible on the addresses specified on Contract Addresses.

provides two functions. computeAddress(bytes32 salt, bytes32 codeHash) returns the address where a contract will be stored if deployed through the deploy function. The salt is a 32-byte value used to add additional entropy to the contract creation process and prevent collisions with the default CREATE opcode. The codeHash is the keccak256 hash of the contract's bytecode that will be deployed. This includes the compiled bytecode of the contract itself, potentially combined with any constructor arguments encoded into it. Any change in salt or codeHash will result in a new address. After computing the address, the deploy(uint256 value, bytes32 salt, bytes memory code) function can be used to deploy the contract on the address computed before. The value field in the deploy function is used to specify the amount of Ether (in wei) that should be sent along with the contract deployment transaction. This parameter serves several purposes:

  1. Funding the new contract: If the contract being deployed needs initial Ether to function, this value will be transferred to the new contract's balance upon creation.

  2. Payable constructors: If the contract being deployed has a payable constructor, this value can be used to send Ether to the constructor function during deployment.

The code parameter in the deploy function should be the complete bytecode including encoded constructor arguments.

Apart from this, some smart contract development tools like Foundry automatically make use of a CREATE2 Proxy like this and the steps above do not have to be done manually necessarily.

create2deployer