diff --git a/pages/operators/chain-operators/deploy/genesis.mdx b/pages/operators/chain-operators/deploy/genesis.mdx index 50f733b73..ddf752265 100644 --- a/pages/operators/chain-operators/deploy/genesis.mdx +++ b/pages/operators/chain-operators/deploy/genesis.mdx @@ -75,16 +75,6 @@ Once you have `genesis.json` and `rollup.json`: 2. Configure op-node with rollup.json. 3. Set up additional off-chain infrastructure as needed (block explorer, indexers, etc.). For more on architecture, see [Architecture overview](/operators/chain-operators/architecture). -### Step 3: Get data - -Now that you have your `genesis.json` and `rollup.json` you can spin up a node on your network. -You can also use the following inspect subcommands to get additional data: - -```bash -./bin/op-deployer inspect l1 --workdir .deployer # outputs all L1 contract addresses for an L2 chain -./bin/op-deployer inspect deploy-config --workdir .deployer # outputs the deploy config for an L2 chain -``` - ## Legacy method: using foundry script The following guide shows you how to generate the L2 genesis file `genesis.json`. This is a JSON @@ -147,7 +137,7 @@ DEPLOY_CONFIG_PATH= \ STATE_DUMP_PATH= \ forge script scripts/L2Genesis.s.sol:L2Genesis \ --sig 'runWithStateDump()' -```` + ``` ## Subcommand (op-node genesis l2) diff --git a/pages/operators/chain-operators/deploy/smart-contracts.mdx b/pages/operators/chain-operators/deploy/smart-contracts.mdx index 9b357c6e7..778e3b7be 100644 --- a/pages/operators/chain-operators/deploy/smart-contracts.mdx +++ b/pages/operators/chain-operators/deploy/smart-contracts.mdx @@ -4,7 +4,7 @@ lang: en-US description: Learn how to deploy the OP Stack L1 smart contracts. --- -import { Callout } from 'nextra/components' +import { Callout, Steps } from 'nextra/components' # OP Stack smart contract deployment @@ -15,14 +15,10 @@ For the latest recommended method, use [op-deployer](/operators/chain-operators/ The following guide shows you how to deploy the OP Stack L1 smart contracts. The primary development branch is `develop`, however **you should only deploy -official contract releases**. You can visit the see the [smart contract overview](/stack/smart-contracts#official-releases) +official contract releases**. You can visit the [smart contract overview](/stack/smart-contracts#official-releases) for the official release versions. Changes to the smart contracts are generally not considered backwards compatible. - - Standard OP Stack chains should use the latest governance approved and audited versions of the smart contract code. - - ## Deployment configuration Deploying your OP Stack contracts requires creating a deployment configuration @@ -31,17 +27,29 @@ monorepo subdirectory: [packages/contracts-bedrock/deploy-config](https://github For the full set of deployment configuration options and their meanings, you can see the [rollup deployment configuration page](/operators/chain-operators/configuration/rollup). -## Deployment script +For a detailed explanation of the configuration options and their meanings, refer to the [rollup deployment configuration page](/operators/chain-operators/configuration/rollup). + +## Using `op-deployer` + +The recommended way to deploy the L1 smart contracts is with the `op-deployer` tool. +Follow the steps in this [section](/operators/chain-operators/tutorials/create-l2-rollup#using-op-deployer) to learn how it works. + + +## Deployment script (Legacy method) + + + The following deployment information outlines the legacy method for deploying the OP Stack L1 contracts. + This method is not recommended and is provided only for historical context. + -The smart contracts are deployed using [foundry](https://github.com/foundry-rs) -and you can find the script's source code in the monorepo at +The legacy method for deploying smart contracts uses [foundry](https://github.com/foundry-rs) and the deployment script located in the monorepo at [packages/contracts-bedrock/scripts/deploy/Deploy.s.sol](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/scripts/deploy/Deploy.s.sol). ### State diff -Before deploying the contracts, you can verify the state diff by using the `runWithStateDiff()` function signature in the deployment script, which produces -the outputs inside [`snapshots/state-diff/`](https://github.com/ethereum-optimism/optimism/tree/develop/packages/contracts-bedrock/snapshots/state-diff). -Run the deployment with state diffs by executing: +You can verify the state diff before deploying the contracts by using the `runWithStateDiff()` function in the deployment script. +This produces outputs in [`snapshots/state-diff/`](https://github.com/ethereum-optimism/optimism/tree/develop/packages/contracts-bedrock/snapshots/state-diff). +Run the deployment with state diffs using the following command: ```bash forge script -vvv scripts/deploy/Deploy.s.sol:Deploy --sig 'runWithStateDiff()' --rpc-url $ETH_RPC_URL --broadcast --private-key $PRIVATE_KEY @@ -92,8 +100,7 @@ enabled. Starting with permissioned fault proofs gives chain operators time to get comfortable running the additional infrastructure requirements: [op-challenger](https://github.com/ethereum-optimism/optimism/tree/develop/op-challenger) and [monitoring](https://github.com/ethereum-optimism/monitorism/tree/main). There are also -additional changes to the economics of operating a permissionless fault proof that chain -operators should have a firm understanding of. +additional changes to the economics of operating a permissionless fault proof that chain operators should fully understand. ## Next steps diff --git a/pages/operators/chain-operators/tools/op-deployer.mdx b/pages/operators/chain-operators/tools/op-deployer.mdx index a4f89714f..636065ef3 100644 --- a/pages/operators/chain-operators/tools/op-deployer.mdx +++ b/pages/operators/chain-operators/tools/op-deployer.mdx @@ -28,10 +28,17 @@ The base use case for `op-deployer` is deploying new OP Chains. This process is To get started with `op-deployer`, create an intent file that defines your desired chain configuration. Use the built-in `op-deployer` utility to generate this file: + + op-deployer uses a declarative intent file to determine how a new chain should be configured. + Then, it runs through a deployment pipeline to actually deploy the chain. + + ``` ./bin/op-deployer init --l1-chain-id 11155111 --l2-chain-ids --workdir .deployer ``` +Replace `` with the exact value. + This command will create a directory called `.deployer` in your current working directory containing the intent file and an empty `state.json` file. `state.json` is populated with the results of your deployment, and never needs to be edited directly. Your intent file will need to be modified to your parameters, but it will initially look something like this: @@ -43,39 +50,40 @@ Your intent file will need to be modified to your parameters, but it will initia ```toml -deploymentStrategy = "live" # Deploying a chain to a live network i.e. Sepolia -l1ChainID = 11155111 # The chain ID of the L1 chain you'll be deploying to +configType = "standard-overrides" +l1ChainID = 11155111 # The chain ID of Sepolia (L1) you'll be deploying to. fundDevAccounts = true # Whether or not to fund dev accounts using the test... junk mnemonic on L2. -l1ContractsLocator = "tag://op-contracts/v1.6.0" # L1 smart contracts versions +l1ContractsLocator = "tag://op-contracts/v1.8.0-rc.4" # L1 smart contracts versions l2ContractsLocator = "tag://op-contracts/v1.7.0-beta.1+l2-contracts" # L2 smart contracts versions # Delete this table if you are using the shared Superchain contracts on the L1 # If you are deploying your own SuperchainConfig and ProtocolVersions contracts, fill in these details [superchainRoles] - proxyAdminOwner = "0xb9cdf788704088a4c0191d045c151fcbe2db14a4" - protocolVersionsOwner = "0x85d646ed26c3f46400ede51236d8d7528196849b" - guardian = "0x8c7e4a51acb17719d225bd17598b8a94b46c8767" + proxyAdminOwner = "0x1eb2ffc903729a0f03966b917003800b145f56e2" + protocolVersionsOwner = "0x79add5713b383daa0a138d3c4780c7a1804a8090" + guardian = "0x7a50f00e8d05b95f98fe38d8bee366a7324dcf7e" # List of L2s to deploy. op-deployer can deploy multiple L2s at once [[chains]] # Your chain's ID, encoded as a 32-byte hex string - id = "0x0000000000000000000000000000000000000000000000000000000000003039" + id = "0x00000000000000000000000000000000000000000000000000000a25406f3e60" # Update the fee recipient contract - baseFeeVaultRecipient = "0x0000000000000000000000000000000000000000" - l1FeeVaultRecipient = "0x0000000000000000000000000000000000000000" - sequencerFeeVaultRecipient = "0x0000000000000000000000000000000000000000" + baseFeeVaultRecipient = "0x100f829718B5Be38013CC7b29c5c62a08D00f1ff" + l1FeeVaultRecipient = "0xbAEaf33e883068937aB4a50871f2FD52e241013A" + sequencerFeeVaultRecipient = "0xd0D5D18F0ebb07B7d728b14AAE014eedA814d6BD" + eip1559DenominatorCanyon = 250 eip1559Denominator = 50 eip1559Elasticity = 6 # Various ownership roles for your chain. When you use op-deployer init, these roles are generated using the # test... junk mnemonic. You should replace these with your own addresses for production chains. [chains.roles] - l1ProxyAdminOwner = "0x1a66b55a4f0139c32eddf4f8c60463afc3832e76" - l2ProxyAdminOwner = "0x7759a8a43aa6a7ee9434ddb597beed64180c40fd" - systemConfigOwner = "0x8e35d9523a0c4c9ac537d254079c2398c6f3b35f" - unsafeBlockSigner = "0xbb19dce4ce51f353a98dbab31b5fa3bc80dc7769" - batcher = "0x0e9c62712ab826e06b16b2236ce542f711eaffaf" - proposer = "0x86dfafe0689e20685f7872e0cb264868454627bc" - challenger = "0xf1658da627dd0738c555f9572f658617511c49d5" + l1ProxyAdminOwner = "0xdf5a644aed1b5d6cE0DA2aDd778bc5f39d97Ac88" + l2ProxyAdminOwner = "0xC40445CD88dDa2A410F86F6eF8E00fd52D8381FD" + systemConfigOwner = "0xB32296E6929F2507dB8153A64b036D175Ac6E89e" + unsafeBlockSigner = "0xA53526b516df4eEe3791734CE85311569e0eAD78" + batcher = "0x8680d36811420359093fd321ED386a6e76BE2AF3" + proposer = "0x41b3B204099771aDf857F826015703A1030b6675" + challenger = "0x7B51A480dAeE699CA3a4F68F9AAA434452112eF7" ``` @@ -96,10 +104,12 @@ You can also do chain by chain configurations in the `chains` table. Now that you've created your intent file, you can apply it to your chain to deploy the L1 smart contracts: -``` -op-deployer apply --workdir .deployer --l1-rpc-url --private-key +```bash +./bin/op-deployer apply --workdir .deployer --l1-rpc-url --private-key ``` +* Replace `` with your `L1_RPC_URL` and `` with your private key + This command will deploy the OP Stack to L1. It will deploy all L2s specified in the intent file. Superchain configuration will be set to the Superchain-wide defaults - i.e., your chain will be opted into the [Superchain pause](https://specs.optimism.io/protocol/superchain-config.html#pausability) and will use the same [protocol versions](https://github.com/ethereum-optimism/specs/blob/main/specs/protocol/superchain-upgrades.md) @@ -113,17 +123,17 @@ address as other chains on the Superchain. Inspect the `state.json` file by navigating to your working directory. With the contracts deployed, generate the genesis and rollup configuration files by running the following commands: -``` -op-deployer inspect genesis --workdir .deployer > .deployer/genesis.json -op-deployer inspect rollup --workdir .deployer > .deployer/rollup.json +```bash +./bin/op-deployer inspect genesis --workdir .deployer > .deployer/genesis.json +./bin/op-deployer inspect rollup --workdir .deployer > .deployer/rollup.json ``` -Now that you have your `genesis.json` and `rollup.json` you can spin up a node on your network. You can also use the following inspect subcommands to get additional data: +Now that you have your `genesis.json` and `rollup.json` you can spin up a node on your network. You can also use the following inspect subcommands to get additional chain artifacts: -``` -op-deployer inspect l1 --workdir .deployer # outputs all L1 contract addresses for an L2 chain -op-deployer inspect deploy-config --workdir .deployer # outputs the deploy config for an L2 chain -op-deployer inspect l2-semvers --workdir .deployer # outputs the semvers for all L2 chains +```bash +./bin/op-deployer inspect l1 --workdir .deployer # outputs all L1 contract addresses for an L2 chain +./bin/op-deployer inspect deploy-config --workdir .deployer # outputs the deploy config for an L2 chain +./bin/op-deployer inspect l2-semvers --workdir .deployer # outputs the semvers for all L2 chains ``` diff --git a/pages/operators/chain-operators/tutorials/create-l2-rollup.mdx b/pages/operators/chain-operators/tutorials/create-l2-rollup.mdx index 94d7acf3e..c4118bc68 100644 --- a/pages/operators/chain-operators/tutorials/create-l2-rollup.mdx +++ b/pages/operators/chain-operators/tutorials/create-l2-rollup.mdx @@ -10,8 +10,6 @@ import { WipCallout } from '@/components/WipCallout' # Creating your own L2 rollup testnet - - Please **be prepared to set aside approximately one hour** to get everything running properly and **make sure to read through the guide carefully**. You don't want to miss any important steps that might cause issues down the line. @@ -419,74 +417,75 @@ cast codesize 0x4e59b44847b379578588920cA78FbF26c0B4956C --rpc-url $L1_RPC_URL Once you've configured your network, it's time to deploy the L1 contracts necessary for the functionality of the chain. - +## Using `op-deployer` -{

Deploy the L1 contracts

} +The `op-deployer` tool simplifies the creation of genesis and rollup configuration files (`genesis.json` and `rollup.json`). +These files are crucial for initializing the execution client (`op-geth`) and consensus client (`op-node`) for your network. -```bash -forge script scripts/Deploy.s.sol:Deploy --private-key $GS_ADMIN_PRIVATE_KEY --broadcast --rpc-url $L1_RPC_URL --slow -``` +The recommended flow for creating a genesis file and rollup configuration file on the OP Stack is as follows: - -If you see a nondescript error that includes `EvmError: Revert` and `Script failed` then you likely need to change the `IMPL_SALT` environment variable. -This variable determines the addresses of various smart contracts that are deployed via [CREATE2](https://eips.ethereum.org/EIPS/eip-1014). -If the same `IMPL_SALT` is used to deploy the same contracts twice, the second deployment will fail. -**You can generate a new `IMPL_SALT` by running `direnv allow` anywhere in the Optimism Monorepo.** +1. **Deploy the L1 contracts** using [op-deployer](/operators/chain-operators/tools/op-deployer). +2. **Generate** both the L2 genesis file (`genesis.json`) and the rollup configuration file (`rollup.json`) using op-deployer's `inspect` commands. +3. **Initialize** your off-chain components (e.g., execution client, consensus client). + + +Using op-deployer for chain initialization is a requirement for all chains intending to be for chains who intend to be standard and join the superchain. +This ensures standardization and compatibility across the OP Stack ecosystem. - +### Prerequisites -## Generate the L2 config files +1. You have installed the `op-deployer` binary following the instructions in [deployer docs](/operators/chain-operators/tools/op-deployer#installation). + After installation, extract the `op-deployer` into your `PATH` and `cd op-deployer`. -Now that you've set up the L1 smart contracts you can automatically generate several configuration files that are used within the Consensus Client and the Execution Client. +2. You have created and customized an intent file in a `.deployer` directory, typically by running: -You need to generate three important files: + ```bash + ./bin/op-deployer init --l1-chain-id --l2-chain-ids --workdir .deployer + ``` -1. `genesis.json` includes the genesis state of the chain for the Execution Client. -2. `rollup.json` includes configuration information for the Consensus Client. -3. `jwt.txt` is a [JSON Web Token](https://jwt.io/introduction) that allows the Consensus Client and the Execution Client to communicate securely (the same mechanism is used in Ethereum clients). + Replace `` and `` with their respective values, see a list of [`chainIds`](https://chainid.network/). - +3. You have edited that intent file to your liking (roles, addresses, etc.). + +### Step 1: Deploy the L1 contracts -{

Navigate to the op-node package

} +To deploy your chain to L1, run: ```bash -cd ~/optimism/op-node +./bin/op-deployer apply --workdir .deployer \ + --l1-rpc-url \ + --private-key ``` -{

Create genesis files

} +* Replace `` with the L1 RPC URL. +* Replace `` with the private key of the account used for deployment. -Now you'll generate the `genesis.json` and `rollup.json` files within the `op-node` folder: +This command: -```bash -go run cmd/main.go genesis l2 \ - --deploy-config ../packages/contracts-bedrock/deploy-config/getting-started.json \ - --l1-deployments ../packages/contracts-bedrock/deployments/getting-started/.deploy \ - --outfile.l2 genesis.json \ - --outfile.rollup rollup.json \ - --l1-rpc $L1_RPC_URL -``` +* Reads your intent file in `.deployer/.` +* Deploys the OP Stack contracts to the specified L1. +* Updates a local `state.json` file with the results of the deployment. -{

Create an authentication key

} +### Step 2: Generate your L2 genesis file and rollup file -Next you'll create a [JSON Web Token](https://jwt.io/introduction) that will be used to authenticate the Consensus Client and the Execution Client. -This token is used to ensure that only the Consensus Client and the Execution Client can communicate with each other. -You can generate a JWT with the following command: +After your L1 contracts have been deployed, generate the L2 genesis and rollup configuration files by inspecting the deployer's `state.json.` ```bash -openssl rand -hex 32 > jwt.txt +./bin/op-deployer inspect genesis --workdir .deployer > .deployer/genesis.json +./bin/op-deployer inspect rollup --workdir .deployer > .deployer/rollup.json ``` -{

Copy genesis files into the op-geth directory

} +* genesis.json is the file you will provide to your execution client (e.g. op-geth). +* rollup.json is the file you will provide to your consensus client (e.g. op-node). -Finally, you'll need to copy the `genesis.json` file and `jwt.txt` file into `op-geth` so you can use it to initialize and run `op-geth`: +### Step 3: Initialize your off-chain components -```bash -cp genesis.json ~/op-geth -cp jwt.txt ~/op-geth -``` +Once you have `genesis.json` and `rollup.json`: - +1. Initialize op-geth using genesis.json. +2. Configure op-node with rollup.json. +3. Set up additional off-chain infrastructure as needed (block explorer, indexers, etc.). For more on architecture, see [Architecture overview](/operators/chain-operators/architecture). ## Initialize `op-geth`