OpenZeppelin SDK

The OpenZeppelin CLI does not use the name of the network entry from your networks.js file to name the JSON configuration file. Instead, it uses the canonical network ID associated with that entry.

• Public Networks: The CLI uses web3.network.getVersion() to identify the network and determine the filename (e.g., ropsten.json).
• Local Networks: Since local networks lack canonical names, the CLI generates files named dev-<network_id>.json (e.g., dev-1540303312049.json).

Example mapping from networks.js: If you have geth_ropsten and parity_ropsten both configured with network_id: 3, running oz push --network geth_ropsten or oz push --network parity_ropsten will both result in a ropsten.json file.

// networks.js
module.exports = {
  networks: {
     geth_ropsten: {
      host: 'localhost',
      port: 8555,
      network_id: 3
    },
     parity_ropsten: {
      host: 'localhost',
      port: 8565,
      network_id: 3
    },
     local: {
      host: 'localhost',
      port: 8545,
      network_id: *
    }
  }
};

Smart contracts can be deployed using two different flows, which result in different address calculation methods:

CREATE flow

Addresses are computed as a function of the sender's address and a nonce: new_address = hash(sender, nonce)

Because nonces are sequential and increase with every transaction or contract creation, the address of the next contract is predictable only if no other transactions occur in the interim. This makes it unsuitable for counterfactual systems.

CREATE2 flow

Addresses are computed using a constant, the sender's address, a salt, and the contract bytecode: new_address = hash(0xFF, sender, salt, bytecode)

This makes the resulting address independent of future events (like nonces). As long as the same sender, salt, and bytecode are used, the contract will always deploy to the same new_address. This allows for 'counterfactual' deployments where users can interact with an address before the contract actually exists.

The ProxyAdmin contract acts as a central administrator for all proxies in your project. It is used to implement the Transparent Proxy Pattern, preventing administrative functions from clashing with proxy logic.

Key behaviors:

• Deployment: It is automatically deployed during your first oz deploy or oz create2 command. You can force deployment using oz push --deploy-proxy-admin.
• Management: It is responsible for upgrading contracts and transferring ownership of proxies.
• Upgrades: When you run oz upgrade, the CLI calls the ProxyAdmin.upgrade method.
• Inspection: You can check the current implementation of a proxy using ProxyAdmin.getProxyImplementation.

You can find your ProxyAdmin address in your local configuration file: .openzeppelin/<network>.json.

// .openzeppelin/<network>.json
"proxyAdmin": {
   "address": <proxyAdmin-address>
}