From 3867c9285f2277e88201eddd0cd49abafa8f2c63 Mon Sep 17 00:00:00 2001 From: Bradley Camacho <42678939+bradleycamacho@users.noreply.github.com> Date: Wed, 24 Sep 2025 08:46:36 -0700 Subject: [PATCH 1/3] Content migration --- pages/app-developers/_meta.json | 37 - pages/app-developers/bridging.mdx | 35 - .../{ => guides}/bridging/_meta.json | 0 .../{ => guides}/bridging/basics.mdx | 0 .../{ => guides}/bridging/custom-bridge.mdx | 0 .../{ => guides}/bridging/messaging.mdx | 0 .../app-developers/guides/bridging/meta.json | 6 + .../{ => guides}/bridging/standard-bridge.mdx | 0 .../{ => guides}/building-apps.mdx | 0 .../interoperability}/estimate-costs.mdx | 0 .../guides/interoperability}/get-started.mdx | 0 .../{ => guides/interoperability}/interop.mdx | 0 .../interoperability}/message-expiration.mdx | 0 .../interoperability}/message-passing.mdx | 0 .../guides/interoperability/meta.json | 9 + .../guides/interoperability}/reading-logs.mdx | 0 .../guides/interoperability}/reorg.mdx | 0 pages/app-developers/guides/meta.json | 5 + .../guides}/superchain.mdx | 0 .../{ => guides}/testing-apps.mdx | 0 .../{ => guides}/transactions/_meta.json | 0 .../{ => guides}/transactions/estimates.mdx | 0 .../{ => guides}/transactions/fees.mdx | 0 .../guides/transactions/meta.json | 7 + .../{ => guides}/transactions/parameters.mdx | 0 .../{ => guides}/transactions/statuses.mdx | 0 .../transactions/troubleshooting.mdx | 0 .../first-app.mdx} | 0 .../quickstarts/interop-app.mdx} | 0 pages/app-developers/quickstarts/meta.json | 5 + .../token-starter-kit.mdx} | 0 .../reference/contracts/interop/meta.json | 3 + .../contracts}/interop/predeploy.mdx | 0 pages/app-developers/reference/meta.json | 4 + .../{tools/connect => reference}/networks.mdx | 0 .../connect => reference}/rpc-providers.mdx | 0 .../supersim/chain-env.mdx | 0 .../supersim/chain-env/_meta.json | 0 .../supersim/chain-env/chain-a.mdx | 0 .../supersim/chain-env/chain-b.mdx | 0 .../supersim/chain-env/included-contracts.mdx | 0 .../reference/supersim/chain-env/meta.json | 5 + .../reference/supersim/meta.json | 3 + .../supersim/reference/_meta.json | 0 .../supersim/reference/fork.mdx | 0 .../reference/supersim/reference/meta.json | 4 + .../supersim/reference/vanilla.mdx | 0 .../reference/tokens/compatibility.mdx} | 0 .../app-developers/reference/tokens/meta.json | 4 + .../reference/tokens}/tokenlist.mdx | 0 pages/app-developers/tools.mdx | 80 -- pages/app-developers/tools/_meta.json | 10 - pages/app-developers/tools/build.mdx | 50 -- pages/app-developers/tools/build/_meta.json | 25 - .../app-developers/tools/build/nft-tools.mdx | 69 -- pages/app-developers/tools/connect.mdx | 26 - pages/app-developers/tools/connect/_meta.json | 4 - .../tools/data-and-dashboards.mdx | 33 - .../tools/data-and-dashboards/_meta.json | 3 - .../data-and-dashboards/data-glossary.mdx | 119 --- .../analytics.mdx} | 0 pages/app-developers/tools/data/meta.json | 4 + .../tools/{build => data}/oracles.mdx | 0 .../ecosystem-overview.mdx => ecosystem.mdx} | 0 .../explorers} | 0 pages/app-developers/tools/meta.json | 4 + pages/app-developers/tools/supersim.mdx | 75 +- .../tools/testing}/devnet.mdx | 0 .../tools/{build => testing}/faucets.mdx | 13 +- pages/app-developers/tools/testing/meta.json | 4 + .../account-abstraction.mdx | 0 pages/app-developers/tools/wallets/meta.json | 3 + pages/app-developers/transactions.mdx | 30 - pages/app-developers/tutorials.mdx | 63 -- pages/app-developers/tutorials/_meta.json | 6 - pages/app-developers/tutorials/bridging.mdx | 28 - .../tutorials/bridging/_meta.json | 7 - .../bridging}/bridge-crosschain-eth.mdx | 0 .../deposit-transactions.mdx | 0 .../tutorials/bridging/meta.json | 9 + .../supersim}/first-steps.mdx | 0 .../supersim/getting-started.mdx | 0 .../supersim}/installation.mdx | 0 .../tutorials/development/supersim/meta.json | 5 + pages/app-developers/tutorials/interop.mdx | 29 - .../tutorials/interop/_meta.json | 8 - .../interop/bridge-crosschain-eth.mdx | 18 - .../tutorials/interop/contract-calls.mdx | 19 - .../interop/deploy-superchain-erc20.mdx | 20 - .../tutorials/interop/event-contests.mdx | 19 - .../tutorials/interop/event-reads.mdx | 19 - .../interop/transfer-superchainERC20.mdx | 22 - .../interoperability}/contract-calls.mdx | 0 .../interoperability}/custom-bridge.mdx | 2 +- .../custom-superchain-erc20.mdx | 0 .../deploy-superchain-erc20.mdx | 0 .../interoperability}/event-contests.mdx | 0 .../interoperability}/event-reads.mdx | 0 .../interoperability}/manual-relay.mdx | 0 .../interoperability}/message-passing.mdx | 0 .../tutorials/interoperability/meta.json | 12 + .../transfer-superchainERC20.mdx | 0 .../interoperability}/verify-messages.mdx | 0 pages/app-developers/tutorials/supersim.mdx | 37 - .../tutorials/supersim/_meta.json | 6 - .../supersim/getting-started/_meta.json | 4 - .../tutorials/supersim/reference.mdx | 25 - .../app-developers/tutorials/transactions.mdx | 27 - .../tutorials/transactions/_meta.json | 5 - .../tutorials/transactions/meta.json | 5 + pages/chain-operators/concepts/meta.json | 3 + .../concepts}/superchain-upgrades.mdx | 0 .../chain-operators/features/alt-da-mode.mdx | 0 .../features/bridged-usdc-standard.mdx | 0 pages/chain-operators/features/meta.json | 6 + .../chain-operators/features/preinstalls.mdx | 0 .../chain-operators/features/span-batches.mdx | 0 .../guides}/best-practices.mdx | 0 .../guides}/configuration/batcher.mdx | 0 .../guides/configuration/meta.json | 6 + .../guides}/configuration/overview.mdx | 0 .../guides}/configuration/proposer.mdx | 0 .../guides}/configuration/rollup.mdx | 0 .../guides/deployment}/genesis.mdx | 0 .../guides/deployment/meta.json | 8 + .../guides/deployment}/overview.mdx | 0 .../deployment}/proposer-setup-guide.mdx | 6 +- .../guides/deployment/sequencer-node.mdx | 594 ++++++++++++++ .../guides/deployment}/spin-batcher.mdx | 215 ++++- .../deployment}/validate-deployment.mdx | 0 .../guides/features}/alt-da-mode.mdx | 0 .../chain-operators/guides/features/meta.json | 3 + .../guides}/management/blobs.mdx | 0 .../guides}/management/key-management.mdx | 0 .../guides/management/meta.json | 7 + .../guides}/management/operations.mdx | 0 .../guides}/management/snap-sync.mdx | 0 .../guides}/management/troubleshooting.mdx | 0 pages/chain-operators/guides/meta.json | 3 + .../guides/smart-contracts/meta.json | 7 + .../smart-contracts/op-deployer-upgrade.mdx | 0 .../guides/smart-contracts/overview.mdx} | 0 .../smart-contracts}/smart-contracts.mdx | 0 .../smart-contracts/superchain-ops-guide.mdx | 44 +- .../upgrade-op-contracts-1-3-1-8.mdx | 0 pages/chain-operators/quickstarts/meta.json | 3 + .../quickstarts}/self-hosted.mdx | 3 - .../reference}/architecture.mdx | 7 +- .../reference/components/meta.json | 3 + .../reference/components}/op-supervisor.mdx | 0 pages/chain-operators/reference/meta.json | 7 + .../reference}/opcm.mdx | 0 .../reference}/privileged-roles.mdx | 0 .../reference/rpc/conditional-txs.mdx} | 0 pages/chain-operators/reference/rpc/meta.json | 3 + .../reference}/superchain-explainer.mdx | 0 .../reference}/superchain-registry.mdx | 0 .../tools/chain-monitoring.mdx | 0 .../chain-operators/tools/explorer.mdx | 0 .../chain-operators/tools/fee-calculator.mdx | 0 pages/chain-operators/tools/meta.json | 11 + pages/chain-operators/tools/op-challenger.mdx | 234 ++++++ .../chain-operators/tools/op-conductor.mdx | 0 .../chain-operators/tools/op-deployer.mdx | 60 +- .../chain-operators/tools/op-txproxy.mdx | 0 .../chain-operators/tools/op-validator.mdx | 0 .../chain-operators/tools/proxyd.mdx | 0 .../tutorials/absolute-prestate.mdx | 4 +- .../adding-derivation-attributes.mdx | 0 .../tutorials/adding-precompiles.mdx | 12 +- .../tutorials/chain-dev-net.mdx | 41 +- .../tutorials/create-l2-rollup.mdx | 776 ++++++++++++++++++ .../tutorials/dispute-games.mdx | 0 .../tutorials/integrating-da-layer.mdx | 0 pages/chain-operators/tutorials/meta.json | 11 + .../tutorials/migrating-permissionless.mdx | 0 .../tutorials/modifying-predeploys.mdx | 0 .../architecture}/fault-proofs/cannon.mdx | 0 .../architecture}/fault-proofs/challenger.mdx | 2 +- .../architecture/fault-proofs/components.mdx} | 0 .../architecture}/fault-proofs/explainer.mdx | 10 +- .../architecture/fault-proofs/meta.json | 6 + .../rollups}/derivation-pipeline.mdx | 0 pages/concepts/architecture/rollups/meta.json | 5 + .../architecture/rollups}/outages.mdx | 0 .../architecture/rollups}/overview.mdx | 2 +- .../bridging}/cross-domain.mdx | 0 pages/concepts/bridging/meta.json | 3 + .../interoperability/getting-started.mdx} | 0 pages/concepts/interoperability/meta.json | 6 + .../interoperability/overview.mdx} | 0 .../interoperability}/superchain-erc20.mdx | 0 .../interoperability/superchain-eth.mdx} | 0 .../research/block-time.mdx} | 0 pages/concepts/research/meta.json | 3 + .../security/audits-report.mdx | 0 .../security/faq-sec-model.mdx | 0 pages/{stack => concepts}/security/faq.mdx | 0 .../security}/fp-security.mdx | 0 .../security}/interop-security.mdx | 0 pages/concepts/security/meta.json | 9 + pages/{stack => concepts}/security/pause.mdx | 0 .../security/security-policy.mdx | 0 pages/{ => concepts}/stack/beta-features.mdx | 0 .../stack/design-principles.mdx | 0 pages/{ => concepts}/stack/differences.mdx | 0 pages/{ => concepts}/stack/fact-sheet.mdx | 0 pages/concepts/stack/meta.json | 9 + .../stack}/network-upgrades.mdx | 0 .../stack}/op-stack.mdx | 0 .../stack/overview} | 0 .../{ => concepts}/stack/smart-contracts.mdx | 0 .../transactions/deposit-flow.mdx | 0 .../{stack => concepts}/transactions/fees.mdx | 0 .../transactions/forced-transaction.mdx | 0 pages/concepts/transactions/meta.json | 8 + .../transactions/transaction-finality.mdx | 0 .../transactions/transaction-flow.mdx | 0 .../transactions/withdrawal-flow.mdx | 0 pages/connect/_meta.json | 9 - pages/connect/contribute.mdx | 30 - pages/connect/contribute/_meta.json | 5 - pages/connect/resources/_meta.json | 8 - .../getting-started/meta.json | 3 + .../getting-started}/stack-contribute.mdx | 0 .../guides/documentation.mdx} | 0 pages/core-contributers/guides/meta.json | 3 + pages/core-contributers/reference/meta.json | 4 + .../reference}/mips.mdx | 0 .../reference}/style-guide.mdx | 0 pages/developers/testing/meta.json | 3 + .../testing}/public-devnets.mdx | 0 pages/generate-meta.sh | 105 +++ pages/get-started/_meta.json | 34 - .../blockspace-charter.mdx | 0 pages/governance/meta.json | 3 + pages/index.mdx | 2 +- pages/interop/_meta.json | 26 - pages/interop/tools.mdx | 29 - pages/interop/tools/_meta.json | 4 - pages/interop/tools/supersim.mdx | 25 - pages/interop/tutorials.mdx | 41 - pages/interop/tutorials/_meta.json | 12 - .../tutorials/message-passing/_meta.json | 3 - .../tutorials/upgrade-to-superchain-erc20.mdx | 58 -- .../upgrade-to-superchain-erc20/_meta.json | 4 - .../contract-upgrade.mdx | 328 -------- .../upgrade-to-superchain-erc20/lockbox.mdx | 369 --------- pages/meta.json | 5 + .../guides/configuration/base.mdx} | 0 .../guides/configuration/consensus.mdx} | 0 .../guides/configuration/execution.mdx} | 0 .../guides/configuration/meta.json | 5 + .../guides/management/meta.json | 7 + .../guides}/management/metrics.mdx | 0 .../guides}/management/regenesis-history.mdx | 0 .../guides}/management/snap-sync.mdx | 0 .../guides}/management/snapshots.mdx | 0 .../guides}/management/troubleshooting.mdx | 0 .../reference/architecture/overview.mdx} | 0 .../reference/architecture}/rollup-node.mdx | 0 pages/node-operators/reference/meta.json | 6 + .../reference}/releases.mdx | 0 .../reference/rpc} | 0 .../tutorials/docker-node.mdx} | 0 pages/node-operators/tutorials/meta.json | 5 + .../tutorials/node-from-source.mdx | 0 .../tutorials/source-node.mdx} | 0 pages/notices/_meta.json | 12 - pages/notices/{ => archive}/blob-fee-bug.mdx | 0 .../archive/custom-gas-tokens-deprecation.mdx | 69 ++ .../{ => archive}/holocene-changes.mdx | 0 pages/notices/archive/meta.json | 12 + .../notices/{ => archive}/pectra-changes.mdx | 0 pages/notices/{ => archive}/pectra-fees.mdx | 0 .../superchain-withdrawal-pause-test.mdx | 0 pages/notices/{ => archive}/upgrade-13.mdx | 0 pages/notices/{ => archive}/upgrade-14.mdx | 0 pages/notices/{ => archive}/upgrade-15.mdx | 2 +- pages/notices/{ => archive}/upgrade-16.mdx | 8 +- pages/notices/upgrade-16a.mdx | 129 --- pages/operators/_meta.json | 22 - pages/operators/chain-operators.mdx | 46 -- pages/operators/chain-operators/_meta.json | 10 - .../chain-operators/configuration.mdx | 35 - .../chain-operators/configuration/_meta.json | 6 - pages/operators/chain-operators/deploy.mdx | 47 -- .../chain-operators/deploy/_meta.json | 11 - .../chain-operators/deploy/op-challenger.mdx | 636 -------------- .../chain-operators/deploy/sequencer-node.mdx | 589 ------------- pages/operators/chain-operators/features.mdx | 36 - .../chain-operators/features/_meta.json | 7 - .../chain-operators/features/flashblocks.mdx | 30 - .../features/flashblocks/_meta.json | 4 - .../features/flashblocks/apps.mdx | 244 ------ .../features/flashblocks/chain-operators.mdx | 153 ---- .../operators/chain-operators/management.mdx | 42 - .../chain-operators/management/_meta.json | 8 - pages/operators/chain-operators/tools.mdx | 42 - .../chain-operators/tools/_meta.json | 11 - pages/operators/chain-operators/tutorials.mdx | 53 -- .../chain-operators/tutorials/_meta.json | 11 - .../tutorials/create-l2-rollup.mdx | 196 ----- .../tutorials/create-l2-rollup/_meta.json | 8 - .../create-l2-rollup/op-batcher-setup.mdx | 422 ---------- .../create-l2-rollup/op-challenger-setup.mdx | 628 -------------- .../create-l2-rollup/op-deployer-setup.mdx | 400 --------- .../create-l2-rollup/op-geth-setup.mdx | 580 ------------- .../create-l2-rollup/op-proposer-setup.mdx | 467 ----------- pages/operators/node-operators.mdx | 43 - pages/operators/node-operators/_meta.json | 10 - .../node-operators/configuration.mdx | 35 - .../node-operators/configuration/_meta.json | 5 - pages/operators/node-operators/management.mdx | 39 - .../node-operators/management/_meta.json | 8 - .../node-operators/management/blobs.mdx | 133 --- pages/operators/node-operators/tutorials.mdx | 36 - .../node-operators/tutorials/_meta.json | 5 - pages/{superchain => reference}/addresses.mdx | 0 .../resources => reference}/glossary.mdx | 0 pages/reference/meta.json | 6 + pages/{superchain => reference}/networks.mdx | 0 pages/{connect => reference}/resources.mdx | 0 pages/scaner.sh | 159 ++++ pages/stack/_meta.json | 30 - pages/stack/beta-features/_meta.json | 3 - pages/stack/components.mdx | 123 --- pages/stack/fault-proofs.mdx | 39 - pages/stack/fault-proofs/_meta.json | 8 - pages/stack/features.mdx | 26 - pages/stack/features/_meta.json | 3 - pages/stack/research.mdx | 25 - pages/stack/research/_meta.json | 4 - pages/stack/rollup.mdx | 34 - pages/stack/rollup/_meta.json | 5 - pages/stack/security.mdx | 37 - pages/stack/security/_meta.json | 5 - pages/stack/smart-contracts/_meta.json | 6 - pages/stack/transactions.mdx | 48 -- pages/stack/transactions/_meta.json | 9 - pages/stack/transactions/flashblocks.mdx | 244 ------ pages/superchain/_meta.json | 15 - pages/superchain/standard-configuration.mdx | 128 --- 343 files changed, 2553 insertions(+), 8044 deletions(-) delete mode 100644 pages/app-developers/_meta.json delete mode 100644 pages/app-developers/bridging.mdx rename pages/app-developers/{ => guides}/bridging/_meta.json (100%) rename pages/app-developers/{ => guides}/bridging/basics.mdx (100%) rename pages/app-developers/{ => guides}/bridging/custom-bridge.mdx (100%) rename pages/app-developers/{ => guides}/bridging/messaging.mdx (100%) create mode 100644 pages/app-developers/guides/bridging/meta.json rename pages/app-developers/{ => guides}/bridging/standard-bridge.mdx (100%) rename pages/app-developers/{ => guides}/building-apps.mdx (100%) rename pages/{interop => app-developers/guides/interoperability}/estimate-costs.mdx (100%) rename pages/{interop => app-developers/guides/interoperability}/get-started.mdx (100%) rename pages/app-developers/{ => guides/interoperability}/interop.mdx (100%) rename pages/{interop => app-developers/guides/interoperability}/message-expiration.mdx (100%) rename pages/{interop => app-developers/guides/interoperability}/message-passing.mdx (100%) create mode 100644 pages/app-developers/guides/interoperability/meta.json rename pages/{interop => app-developers/guides/interoperability}/reading-logs.mdx (100%) rename pages/{interop => app-developers/guides/interoperability}/reorg.mdx (100%) create mode 100644 pages/app-developers/guides/meta.json rename pages/{get-started => app-developers/guides}/superchain.mdx (100%) rename pages/app-developers/{ => guides}/testing-apps.mdx (100%) rename pages/app-developers/{ => guides}/transactions/_meta.json (100%) rename pages/app-developers/{ => guides}/transactions/estimates.mdx (100%) rename pages/app-developers/{ => guides}/transactions/fees.mdx (100%) create mode 100644 pages/app-developers/guides/transactions/meta.json rename pages/app-developers/{ => guides}/transactions/parameters.mdx (100%) rename pages/app-developers/{ => guides}/transactions/statuses.mdx (100%) rename pages/app-developers/{ => guides}/transactions/troubleshooting.mdx (100%) rename pages/app-developers/{get-started.mdx => quickstarts/first-app.mdx} (100%) rename pages/{interop/starter-kit.mdx => app-developers/quickstarts/interop-app.mdx} (100%) create mode 100644 pages/app-developers/quickstarts/meta.json rename pages/app-developers/{starter-kit.mdx => quickstarts/token-starter-kit.mdx} (100%) create mode 100644 pages/app-developers/reference/contracts/interop/meta.json rename pages/{ => app-developers/reference/contracts}/interop/predeploy.mdx (100%) create mode 100644 pages/app-developers/reference/meta.json rename pages/app-developers/{tools/connect => reference}/networks.mdx (100%) rename pages/app-developers/{tools/connect => reference}/rpc-providers.mdx (100%) rename pages/app-developers/{tutorials => reference}/supersim/chain-env.mdx (100%) rename pages/app-developers/{tutorials => reference}/supersim/chain-env/_meta.json (100%) rename pages/app-developers/{tutorials => reference}/supersim/chain-env/chain-a.mdx (100%) rename pages/app-developers/{tutorials => reference}/supersim/chain-env/chain-b.mdx (100%) rename pages/app-developers/{tutorials => reference}/supersim/chain-env/included-contracts.mdx (100%) create mode 100644 pages/app-developers/reference/supersim/chain-env/meta.json create mode 100644 pages/app-developers/reference/supersim/meta.json rename pages/app-developers/{tutorials => reference}/supersim/reference/_meta.json (100%) rename pages/app-developers/{tutorials => reference}/supersim/reference/fork.mdx (100%) create mode 100644 pages/app-developers/reference/supersim/reference/meta.json rename pages/app-developers/{tutorials => reference}/supersim/reference/vanilla.mdx (100%) rename pages/{interop/compatible-tokens.mdx => app-developers/reference/tokens/compatibility.mdx} (100%) create mode 100644 pages/app-developers/reference/tokens/meta.json rename pages/{superchain => app-developers/reference/tokens}/tokenlist.mdx (100%) delete mode 100644 pages/app-developers/tools.mdx delete mode 100644 pages/app-developers/tools/_meta.json delete mode 100644 pages/app-developers/tools/build.mdx delete mode 100644 pages/app-developers/tools/build/_meta.json delete mode 100644 pages/app-developers/tools/build/nft-tools.mdx delete mode 100644 pages/app-developers/tools/connect.mdx delete mode 100644 pages/app-developers/tools/connect/_meta.json delete mode 100644 pages/app-developers/tools/data-and-dashboards.mdx delete mode 100644 pages/app-developers/tools/data-and-dashboards/_meta.json delete mode 100644 pages/app-developers/tools/data-and-dashboards/data-glossary.mdx rename pages/app-developers/tools/{build/analytics-tools.mdx => data/analytics.mdx} (100%) create mode 100644 pages/app-developers/tools/data/meta.json rename pages/app-developers/tools/{build => data}/oracles.mdx (100%) rename pages/app-developers/tools/{build/ecosystem-overview.mdx => ecosystem.mdx} (100%) rename pages/app-developers/tools/{build/block-explorers.mdx => infrastructure/explorers} (100%) create mode 100644 pages/app-developers/tools/meta.json rename pages/{interop/tools => app-developers/tools/testing}/devnet.mdx (100%) rename pages/app-developers/tools/{build => testing}/faucets.mdx (96%) create mode 100644 pages/app-developers/tools/testing/meta.json rename pages/app-developers/tools/{build => wallets}/account-abstraction.mdx (100%) create mode 100644 pages/app-developers/tools/wallets/meta.json delete mode 100644 pages/app-developers/transactions.mdx delete mode 100644 pages/app-developers/tutorials.mdx delete mode 100644 pages/app-developers/tutorials/_meta.json delete mode 100644 pages/app-developers/tutorials/bridging.mdx delete mode 100644 pages/app-developers/tutorials/bridging/_meta.json rename pages/{interop/tutorials => app-developers/tutorials/bridging}/bridge-crosschain-eth.mdx (100%) rename pages/app-developers/tutorials/{supersim => bridging}/deposit-transactions.mdx (100%) create mode 100644 pages/app-developers/tutorials/bridging/meta.json rename pages/app-developers/tutorials/{supersim/getting-started => development/supersim}/first-steps.mdx (100%) rename pages/app-developers/tutorials/{ => development}/supersim/getting-started.mdx (100%) rename pages/app-developers/tutorials/{supersim/getting-started => development/supersim}/installation.mdx (100%) create mode 100644 pages/app-developers/tutorials/development/supersim/meta.json delete mode 100644 pages/app-developers/tutorials/interop.mdx delete mode 100644 pages/app-developers/tutorials/interop/_meta.json delete mode 100644 pages/app-developers/tutorials/interop/bridge-crosschain-eth.mdx delete mode 100644 pages/app-developers/tutorials/interop/contract-calls.mdx delete mode 100644 pages/app-developers/tutorials/interop/deploy-superchain-erc20.mdx delete mode 100644 pages/app-developers/tutorials/interop/event-contests.mdx delete mode 100644 pages/app-developers/tutorials/interop/event-reads.mdx delete mode 100644 pages/app-developers/tutorials/interop/transfer-superchainERC20.mdx rename pages/{interop/tutorials => app-developers/tutorials/interoperability}/contract-calls.mdx (100%) rename pages/{interop/tutorials/upgrade-to-superchain-erc20 => app-developers/tutorials/interoperability}/custom-bridge.mdx (99%) rename pages/{interop/tutorials => app-developers/tutorials/interoperability}/custom-superchain-erc20.mdx (100%) rename pages/{interop/tutorials => app-developers/tutorials/interoperability}/deploy-superchain-erc20.mdx (100%) rename pages/{interop/tutorials => app-developers/tutorials/interoperability}/event-contests.mdx (100%) rename pages/{interop/tutorials => app-developers/tutorials/interoperability}/event-reads.mdx (100%) rename pages/{interop/tutorials/message-passing => app-developers/tutorials/interoperability}/manual-relay.mdx (100%) rename pages/{interop/tutorials => app-developers/tutorials/interoperability}/message-passing.mdx (100%) create mode 100644 pages/app-developers/tutorials/interoperability/meta.json rename pages/{interop/tutorials => app-developers/tutorials/interoperability}/transfer-superchainERC20.mdx (100%) rename pages/{interop/tutorials => app-developers/tutorials/interoperability}/verify-messages.mdx (100%) delete mode 100644 pages/app-developers/tutorials/supersim.mdx delete mode 100644 pages/app-developers/tutorials/supersim/_meta.json delete mode 100644 pages/app-developers/tutorials/supersim/getting-started/_meta.json delete mode 100644 pages/app-developers/tutorials/supersim/reference.mdx delete mode 100644 pages/app-developers/tutorials/transactions.mdx delete mode 100644 pages/app-developers/tutorials/transactions/_meta.json create mode 100644 pages/app-developers/tutorials/transactions/meta.json create mode 100644 pages/chain-operators/concepts/meta.json rename pages/{superchain => chain-operators/concepts}/superchain-upgrades.mdx (100%) rename pages/{operators => }/chain-operators/features/alt-da-mode.mdx (100%) rename pages/{operators => }/chain-operators/features/bridged-usdc-standard.mdx (100%) create mode 100644 pages/chain-operators/features/meta.json rename pages/{operators => }/chain-operators/features/preinstalls.mdx (100%) rename pages/{operators => }/chain-operators/features/span-batches.mdx (100%) rename pages/{operators/chain-operators/management => chain-operators/guides}/best-practices.mdx (100%) rename pages/{operators/chain-operators => chain-operators/guides}/configuration/batcher.mdx (100%) create mode 100644 pages/chain-operators/guides/configuration/meta.json rename pages/{operators/chain-operators => chain-operators/guides}/configuration/overview.mdx (100%) rename pages/{operators/chain-operators => chain-operators/guides}/configuration/proposer.mdx (100%) rename pages/{operators/chain-operators => chain-operators/guides}/configuration/rollup.mdx (100%) rename pages/{operators/chain-operators/deploy => chain-operators/guides/deployment}/genesis.mdx (100%) create mode 100644 pages/chain-operators/guides/deployment/meta.json rename pages/{operators/chain-operators/deploy => chain-operators/guides/deployment}/overview.mdx (100%) rename pages/{operators/chain-operators/deploy => chain-operators/guides/deployment}/proposer-setup-guide.mdx (98%) create mode 100644 pages/chain-operators/guides/deployment/sequencer-node.mdx rename pages/{operators/chain-operators/deploy => chain-operators/guides/deployment}/spin-batcher.mdx (54%) rename pages/{operators/chain-operators/deploy => chain-operators/guides/deployment}/validate-deployment.mdx (100%) rename pages/{stack/beta-features => chain-operators/guides/features}/alt-da-mode.mdx (100%) create mode 100644 pages/chain-operators/guides/features/meta.json rename pages/{operators/chain-operators => chain-operators/guides}/management/blobs.mdx (100%) rename pages/{operators/chain-operators => chain-operators/guides}/management/key-management.mdx (100%) create mode 100644 pages/chain-operators/guides/management/meta.json rename pages/{operators/chain-operators => chain-operators/guides}/management/operations.mdx (100%) rename pages/{operators/chain-operators => chain-operators/guides}/management/snap-sync.mdx (100%) rename pages/{operators/chain-operators => chain-operators/guides}/management/troubleshooting.mdx (100%) create mode 100644 pages/chain-operators/guides/meta.json create mode 100644 pages/chain-operators/guides/smart-contracts/meta.json rename pages/{stack => chain-operators/guides}/smart-contracts/op-deployer-upgrade.mdx (100%) rename pages/{stack/smart-contracts/smart-contracts.mdx => chain-operators/guides/smart-contracts/overview.mdx} (100%) rename pages/{operators/chain-operators/deploy => chain-operators/guides/smart-contracts}/smart-contracts.mdx (100%) rename pages/{stack => chain-operators/guides}/smart-contracts/superchain-ops-guide.mdx (51%) rename pages/{stack => chain-operators/guides}/smart-contracts/upgrade-op-contracts-1-3-1-8.mdx (100%) create mode 100644 pages/chain-operators/quickstarts/meta.json rename pages/{operators/chain-operators => chain-operators/quickstarts}/self-hosted.mdx (98%) rename pages/{operators/chain-operators => chain-operators/reference}/architecture.mdx (95%) create mode 100644 pages/chain-operators/reference/components/meta.json rename pages/{interop => chain-operators/reference/components}/op-supervisor.mdx (100%) create mode 100644 pages/chain-operators/reference/meta.json rename pages/{stack => chain-operators/reference}/opcm.mdx (100%) rename pages/{superchain => chain-operators/reference}/privileged-roles.mdx (100%) rename pages/{stack/features/send-raw-transaction-conditional.mdx => chain-operators/reference/rpc/conditional-txs.mdx} (100%) create mode 100644 pages/chain-operators/reference/rpc/meta.json rename pages/{superchain => chain-operators/reference}/superchain-explainer.mdx (100%) rename pages/{superchain => chain-operators/reference}/superchain-registry.mdx (100%) rename pages/{operators => }/chain-operators/tools/chain-monitoring.mdx (100%) rename pages/{operators => }/chain-operators/tools/explorer.mdx (100%) rename pages/{operators => }/chain-operators/tools/fee-calculator.mdx (100%) create mode 100644 pages/chain-operators/tools/meta.json create mode 100644 pages/chain-operators/tools/op-challenger.mdx rename pages/{operators => }/chain-operators/tools/op-conductor.mdx (100%) rename pages/{operators => }/chain-operators/tools/op-deployer.mdx (95%) rename pages/{operators => }/chain-operators/tools/op-txproxy.mdx (100%) rename pages/{operators => }/chain-operators/tools/op-validator.mdx (100%) rename pages/{operators => }/chain-operators/tools/proxyd.mdx (100%) rename pages/{operators => }/chain-operators/tutorials/absolute-prestate.mdx (98%) rename pages/{operators => }/chain-operators/tutorials/adding-derivation-attributes.mdx (100%) rename pages/{operators => }/chain-operators/tutorials/adding-precompiles.mdx (91%) rename pages/{operators => }/chain-operators/tutorials/chain-dev-net.mdx (89%) create mode 100644 pages/chain-operators/tutorials/create-l2-rollup.mdx rename pages/{operators => }/chain-operators/tutorials/dispute-games.mdx (100%) rename pages/{operators => }/chain-operators/tutorials/integrating-da-layer.mdx (100%) create mode 100644 pages/chain-operators/tutorials/meta.json rename pages/{operators => }/chain-operators/tutorials/migrating-permissionless.mdx (100%) rename pages/{operators => }/chain-operators/tutorials/modifying-predeploys.mdx (100%) rename pages/{stack => concepts/architecture}/fault-proofs/cannon.mdx (100%) rename pages/{stack => concepts/architecture}/fault-proofs/challenger.mdx (99%) rename pages/{stack/fault-proofs/fp-components.mdx => concepts/architecture/fault-proofs/components.mdx} (100%) rename pages/{stack => concepts/architecture}/fault-proofs/explainer.mdx (93%) create mode 100644 pages/concepts/architecture/fault-proofs/meta.json rename pages/{stack/rollup => concepts/architecture/rollups}/derivation-pipeline.mdx (100%) create mode 100644 pages/concepts/architecture/rollups/meta.json rename pages/{stack/rollup => concepts/architecture/rollups}/outages.mdx (100%) rename pages/{stack/rollup => concepts/architecture/rollups}/overview.mdx (97%) rename pages/{stack/transactions => concepts/bridging}/cross-domain.mdx (100%) create mode 100644 pages/concepts/bridging/meta.json rename pages/{get-started/interop.mdx => concepts/interoperability/getting-started.mdx} (100%) create mode 100644 pages/concepts/interoperability/meta.json rename pages/{interop/explainer.mdx => concepts/interoperability/overview.mdx} (100%) rename pages/{interop => concepts/interoperability}/superchain-erc20.mdx (100%) rename pages/{interop/superchain-eth-bridge.mdx => concepts/interoperability/superchain-eth.mdx} (100%) rename pages/{stack/research/block-time-research.mdx => concepts/research/block-time.mdx} (100%) create mode 100644 pages/concepts/research/meta.json rename pages/{stack => concepts}/security/audits-report.mdx (100%) rename pages/{stack => concepts}/security/faq-sec-model.mdx (100%) rename pages/{stack => concepts}/security/faq.mdx (100%) rename pages/{stack/fault-proofs => concepts/security}/fp-security.mdx (100%) rename pages/{interop => concepts/security}/interop-security.mdx (100%) create mode 100644 pages/concepts/security/meta.json rename pages/{stack => concepts}/security/pause.mdx (100%) rename pages/{stack => concepts}/security/security-policy.mdx (100%) rename pages/{ => concepts}/stack/beta-features.mdx (100%) rename pages/{ => concepts}/stack/design-principles.mdx (100%) rename pages/{ => concepts}/stack/differences.mdx (100%) rename pages/{ => concepts}/stack/fact-sheet.mdx (100%) create mode 100644 pages/concepts/stack/meta.json rename pages/{operators/node-operators => concepts/stack}/network-upgrades.mdx (100%) rename pages/{get-started => concepts/stack}/op-stack.mdx (100%) rename pages/{stack/getting-started.mdx => concepts/stack/overview} (100%) rename pages/{ => concepts}/stack/smart-contracts.mdx (100%) rename pages/{stack => concepts}/transactions/deposit-flow.mdx (100%) rename pages/{stack => concepts}/transactions/fees.mdx (100%) rename pages/{stack => concepts}/transactions/forced-transaction.mdx (100%) create mode 100644 pages/concepts/transactions/meta.json rename pages/{stack => concepts}/transactions/transaction-finality.mdx (100%) rename pages/{stack => concepts}/transactions/transaction-flow.mdx (100%) rename pages/{stack => concepts}/transactions/withdrawal-flow.mdx (100%) delete mode 100644 pages/connect/_meta.json delete mode 100644 pages/connect/contribute.mdx delete mode 100644 pages/connect/contribute/_meta.json delete mode 100644 pages/connect/resources/_meta.json create mode 100644 pages/core-contributers/getting-started/meta.json rename pages/{connect/contribute => core-contributers/getting-started}/stack-contribute.mdx (100%) rename pages/{connect/contribute/docs-contribute.mdx => core-contributers/guides/documentation.mdx} (100%) create mode 100644 pages/core-contributers/guides/meta.json create mode 100644 pages/core-contributers/reference/meta.json rename pages/{stack/fault-proofs => core-contributers/reference}/mips.mdx (100%) rename pages/{connect/contribute => core-contributers/reference}/style-guide.mdx (100%) create mode 100644 pages/developers/testing/meta.json rename pages/{stack => developers/testing}/public-devnets.mdx (100%) create mode 100755 pages/generate-meta.sh delete mode 100644 pages/get-started/_meta.json rename pages/{superchain => governance}/blockspace-charter.mdx (100%) create mode 100644 pages/governance/meta.json delete mode 100644 pages/interop/_meta.json delete mode 100644 pages/interop/tools.mdx delete mode 100644 pages/interop/tools/_meta.json delete mode 100644 pages/interop/tools/supersim.mdx delete mode 100644 pages/interop/tutorials.mdx delete mode 100644 pages/interop/tutorials/_meta.json delete mode 100644 pages/interop/tutorials/message-passing/_meta.json delete mode 100644 pages/interop/tutorials/upgrade-to-superchain-erc20.mdx delete mode 100644 pages/interop/tutorials/upgrade-to-superchain-erc20/_meta.json delete mode 100644 pages/interop/tutorials/upgrade-to-superchain-erc20/contract-upgrade.mdx delete mode 100644 pages/interop/tutorials/upgrade-to-superchain-erc20/lockbox.mdx create mode 100644 pages/meta.json rename pages/{operators/node-operators/configuration/base-config.mdx => node-operators/guides/configuration/base.mdx} (100%) rename pages/{operators/node-operators/configuration/consensus-config.mdx => node-operators/guides/configuration/consensus.mdx} (100%) rename pages/{operators/node-operators/configuration/execution-config.mdx => node-operators/guides/configuration/execution.mdx} (100%) create mode 100644 pages/node-operators/guides/configuration/meta.json create mode 100644 pages/node-operators/guides/management/meta.json rename pages/{operators/node-operators => node-operators/guides}/management/metrics.mdx (100%) rename pages/{operators/node-operators => node-operators/guides}/management/regenesis-history.mdx (100%) rename pages/{operators/node-operators => node-operators/guides}/management/snap-sync.mdx (100%) rename pages/{operators/node-operators => node-operators/guides}/management/snapshots.mdx (100%) rename pages/{operators/node-operators => node-operators/guides}/management/troubleshooting.mdx (100%) rename pages/{operators/node-operators/architecture.mdx => node-operators/reference/architecture/overview.mdx} (100%) rename pages/{operators/node-operators => node-operators/reference/architecture}/rollup-node.mdx (100%) create mode 100644 pages/node-operators/reference/meta.json rename pages/{operators/node-operators => node-operators/reference}/releases.mdx (100%) rename pages/{operators/node-operators/json-rpc.mdx => node-operators/reference/rpc} (100%) rename pages/{operators/node-operators/tutorials/node-from-docker.mdx => node-operators/tutorials/docker-node.mdx} (100%) create mode 100644 pages/node-operators/tutorials/meta.json rename pages/{operators => }/node-operators/tutorials/node-from-source.mdx (100%) rename pages/{operators/node-operators/tutorials/run-node-from-source.mdx => node-operators/tutorials/source-node.mdx} (100%) delete mode 100644 pages/notices/_meta.json rename pages/notices/{ => archive}/blob-fee-bug.mdx (100%) create mode 100644 pages/notices/archive/custom-gas-tokens-deprecation.mdx rename pages/notices/{ => archive}/holocene-changes.mdx (100%) create mode 100644 pages/notices/archive/meta.json rename pages/notices/{ => archive}/pectra-changes.mdx (100%) rename pages/notices/{ => archive}/pectra-fees.mdx (100%) rename pages/notices/{ => archive}/superchain-withdrawal-pause-test.mdx (100%) rename pages/notices/{ => archive}/upgrade-13.mdx (100%) rename pages/notices/{ => archive}/upgrade-14.mdx (100%) rename pages/notices/{ => archive}/upgrade-15.mdx (99%) rename pages/notices/{ => archive}/upgrade-16.mdx (98%) delete mode 100644 pages/notices/upgrade-16a.mdx delete mode 100644 pages/operators/_meta.json delete mode 100644 pages/operators/chain-operators.mdx delete mode 100644 pages/operators/chain-operators/_meta.json delete mode 100644 pages/operators/chain-operators/configuration.mdx delete mode 100644 pages/operators/chain-operators/configuration/_meta.json delete mode 100644 pages/operators/chain-operators/deploy.mdx delete mode 100644 pages/operators/chain-operators/deploy/_meta.json delete mode 100644 pages/operators/chain-operators/deploy/op-challenger.mdx delete mode 100644 pages/operators/chain-operators/deploy/sequencer-node.mdx delete mode 100644 pages/operators/chain-operators/features.mdx delete mode 100644 pages/operators/chain-operators/features/_meta.json delete mode 100644 pages/operators/chain-operators/features/flashblocks.mdx delete mode 100644 pages/operators/chain-operators/features/flashblocks/_meta.json delete mode 100644 pages/operators/chain-operators/features/flashblocks/apps.mdx delete mode 100644 pages/operators/chain-operators/features/flashblocks/chain-operators.mdx delete mode 100644 pages/operators/chain-operators/management.mdx delete mode 100644 pages/operators/chain-operators/management/_meta.json delete mode 100644 pages/operators/chain-operators/tools.mdx delete mode 100644 pages/operators/chain-operators/tools/_meta.json delete mode 100644 pages/operators/chain-operators/tutorials.mdx delete mode 100644 pages/operators/chain-operators/tutorials/_meta.json delete mode 100644 pages/operators/chain-operators/tutorials/create-l2-rollup.mdx delete mode 100644 pages/operators/chain-operators/tutorials/create-l2-rollup/_meta.json delete mode 100644 pages/operators/chain-operators/tutorials/create-l2-rollup/op-batcher-setup.mdx delete mode 100644 pages/operators/chain-operators/tutorials/create-l2-rollup/op-challenger-setup.mdx delete mode 100644 pages/operators/chain-operators/tutorials/create-l2-rollup/op-deployer-setup.mdx delete mode 100644 pages/operators/chain-operators/tutorials/create-l2-rollup/op-geth-setup.mdx delete mode 100644 pages/operators/chain-operators/tutorials/create-l2-rollup/op-proposer-setup.mdx delete mode 100644 pages/operators/node-operators.mdx delete mode 100644 pages/operators/node-operators/_meta.json delete mode 100644 pages/operators/node-operators/configuration.mdx delete mode 100644 pages/operators/node-operators/configuration/_meta.json delete mode 100644 pages/operators/node-operators/management.mdx delete mode 100644 pages/operators/node-operators/management/_meta.json delete mode 100644 pages/operators/node-operators/management/blobs.mdx delete mode 100644 pages/operators/node-operators/tutorials.mdx delete mode 100644 pages/operators/node-operators/tutorials/_meta.json rename pages/{superchain => reference}/addresses.mdx (100%) rename pages/{connect/resources => reference}/glossary.mdx (100%) create mode 100644 pages/reference/meta.json rename pages/{superchain => reference}/networks.mdx (100%) rename pages/{connect => reference}/resources.mdx (100%) create mode 100755 pages/scaner.sh delete mode 100644 pages/stack/_meta.json delete mode 100644 pages/stack/beta-features/_meta.json delete mode 100644 pages/stack/components.mdx delete mode 100644 pages/stack/fault-proofs.mdx delete mode 100644 pages/stack/fault-proofs/_meta.json delete mode 100644 pages/stack/features.mdx delete mode 100644 pages/stack/features/_meta.json delete mode 100644 pages/stack/research.mdx delete mode 100644 pages/stack/research/_meta.json delete mode 100644 pages/stack/rollup.mdx delete mode 100644 pages/stack/rollup/_meta.json delete mode 100644 pages/stack/security.mdx delete mode 100644 pages/stack/security/_meta.json delete mode 100644 pages/stack/smart-contracts/_meta.json delete mode 100644 pages/stack/transactions.mdx delete mode 100644 pages/stack/transactions/_meta.json delete mode 100644 pages/stack/transactions/flashblocks.mdx delete mode 100644 pages/superchain/_meta.json delete mode 100644 pages/superchain/standard-configuration.mdx diff --git a/pages/app-developers/_meta.json b/pages/app-developers/_meta.json deleted file mode 100644 index 6f78a38a2..000000000 --- a/pages/app-developers/_meta.json +++ /dev/null @@ -1,37 +0,0 @@ -{ - "--- App Devs": { - "title": "App Developers", - "type": "separator" - }, - "get-started": "Getting started", - "starter-kit": "SuperchainERC20 starter kit", - "interop": "Superchain interoperability", - "building-apps": "Building apps on the Superchain", - "testing-apps": "Testing apps for the Superchain", - "bridging": "Bridging", - "transactions": "Transactions", - "+++ Tutorials": { - "title": "", - "type": "separator" - }, - "--- Tutorials": { - "title": "Tutorials", - "type": "separator" - }, - "tutorials": { - "title": "Tutorials", - "display": "children" - }, - "+++ DevTools": { - "title": "", - "type": "separator" - }, - "--- DevTools": { - "title": "Developer tools", - "type": "separator" - }, - "tools": { - "title": "Developer tools", - "display": "children" - } -} diff --git a/pages/app-developers/bridging.mdx b/pages/app-developers/bridging.mdx deleted file mode 100644 index 4720e5250..000000000 --- a/pages/app-developers/bridging.mdx +++ /dev/null @@ -1,35 +0,0 @@ ---- -title: Bridging guides -description: >- - Learn about bridging basics, custom bridges, data transmission between L1 and - L2, and using the standard bridge in OP Stack. -lang: en-US -content_type: guide -topic: bridging-guides -personas: - - app-developer -categories: - - cross-chain-messaging - - standard-bridge - - mainnet -is_imported_content: 'false' ---- - -import { Card, Cards } from 'nextra/components' - -# Bridging guides - -Looking to build an application that sends ETH, tokens, or data between OP Mainnet and Ethereum? -You'll find some useful guides and tutorials in this area of the docs. -For instance, if you want to learn how to bridge a token from Ethereum to OP Mainnet (or vice versa!), you should check out the [Standard Token Bridge](bridging/standard-bridge). - -If you're looking for something more advanced, take a look at the guide on [sending data between L1 and L2](bridging/messaging). -Contracts on one chain can trigger contract functions on the other chain, which is pretty cool! -The Standard Token Bridge for OP Mainnet even uses this same message-passing infrastructure under the hood. - - - } /> - } /> - } /> - } /> - diff --git a/pages/app-developers/bridging/_meta.json b/pages/app-developers/guides/bridging/_meta.json similarity index 100% rename from pages/app-developers/bridging/_meta.json rename to pages/app-developers/guides/bridging/_meta.json diff --git a/pages/app-developers/bridging/basics.mdx b/pages/app-developers/guides/bridging/basics.mdx similarity index 100% rename from pages/app-developers/bridging/basics.mdx rename to pages/app-developers/guides/bridging/basics.mdx diff --git a/pages/app-developers/bridging/custom-bridge.mdx b/pages/app-developers/guides/bridging/custom-bridge.mdx similarity index 100% rename from pages/app-developers/bridging/custom-bridge.mdx rename to pages/app-developers/guides/bridging/custom-bridge.mdx diff --git a/pages/app-developers/bridging/messaging.mdx b/pages/app-developers/guides/bridging/messaging.mdx similarity index 100% rename from pages/app-developers/bridging/messaging.mdx rename to pages/app-developers/guides/bridging/messaging.mdx diff --git a/pages/app-developers/guides/bridging/meta.json b/pages/app-developers/guides/bridging/meta.json new file mode 100644 index 000000000..295883dc5 --- /dev/null +++ b/pages/app-developers/guides/bridging/meta.json @@ -0,0 +1,6 @@ +{ + "basics": "Bridging basics", + "custom-bridge": "Custom bridges", + "messaging": "Sending data between L1 and L2", + "standard-bridge": "Using the Standard Bridge" +} diff --git a/pages/app-developers/bridging/standard-bridge.mdx b/pages/app-developers/guides/bridging/standard-bridge.mdx similarity index 100% rename from pages/app-developers/bridging/standard-bridge.mdx rename to pages/app-developers/guides/bridging/standard-bridge.mdx diff --git a/pages/app-developers/building-apps.mdx b/pages/app-developers/guides/building-apps.mdx similarity index 100% rename from pages/app-developers/building-apps.mdx rename to pages/app-developers/guides/building-apps.mdx diff --git a/pages/interop/estimate-costs.mdx b/pages/app-developers/guides/interoperability/estimate-costs.mdx similarity index 100% rename from pages/interop/estimate-costs.mdx rename to pages/app-developers/guides/interoperability/estimate-costs.mdx diff --git a/pages/interop/get-started.mdx b/pages/app-developers/guides/interoperability/get-started.mdx similarity index 100% rename from pages/interop/get-started.mdx rename to pages/app-developers/guides/interoperability/get-started.mdx diff --git a/pages/app-developers/interop.mdx b/pages/app-developers/guides/interoperability/interop.mdx similarity index 100% rename from pages/app-developers/interop.mdx rename to pages/app-developers/guides/interoperability/interop.mdx diff --git a/pages/interop/message-expiration.mdx b/pages/app-developers/guides/interoperability/message-expiration.mdx similarity index 100% rename from pages/interop/message-expiration.mdx rename to pages/app-developers/guides/interoperability/message-expiration.mdx diff --git a/pages/interop/message-passing.mdx b/pages/app-developers/guides/interoperability/message-passing.mdx similarity index 100% rename from pages/interop/message-passing.mdx rename to pages/app-developers/guides/interoperability/message-passing.mdx diff --git a/pages/app-developers/guides/interoperability/meta.json b/pages/app-developers/guides/interoperability/meta.json new file mode 100644 index 000000000..8f85619d3 --- /dev/null +++ b/pages/app-developers/guides/interoperability/meta.json @@ -0,0 +1,9 @@ +{ + "estimate-costs": "Estimating the cost of interop messages", + "get-started": "Build interoperable apps on Superchain devnet", + "interop": "Getting started with Interop", + "message-expiration": "Message expiration", + "message-passing": "Interop message passing overview", + "reading-logs": "Reading Logs with Superchain Interop", + "reorg": "Interop reorg awareness" +} diff --git a/pages/interop/reading-logs.mdx b/pages/app-developers/guides/interoperability/reading-logs.mdx similarity index 100% rename from pages/interop/reading-logs.mdx rename to pages/app-developers/guides/interoperability/reading-logs.mdx diff --git a/pages/interop/reorg.mdx b/pages/app-developers/guides/interoperability/reorg.mdx similarity index 100% rename from pages/interop/reorg.mdx rename to pages/app-developers/guides/interoperability/reorg.mdx diff --git a/pages/app-developers/guides/meta.json b/pages/app-developers/guides/meta.json new file mode 100644 index 000000000..594bb5857 --- /dev/null +++ b/pages/app-developers/guides/meta.json @@ -0,0 +1,5 @@ +{ + "building-apps": "Building apps on the Superchain", + "superchain": "Superchain explainer", + "testing-apps": "Testing apps for the Superchain" +} diff --git a/pages/get-started/superchain.mdx b/pages/app-developers/guides/superchain.mdx similarity index 100% rename from pages/get-started/superchain.mdx rename to pages/app-developers/guides/superchain.mdx diff --git a/pages/app-developers/testing-apps.mdx b/pages/app-developers/guides/testing-apps.mdx similarity index 100% rename from pages/app-developers/testing-apps.mdx rename to pages/app-developers/guides/testing-apps.mdx diff --git a/pages/app-developers/transactions/_meta.json b/pages/app-developers/guides/transactions/_meta.json similarity index 100% rename from pages/app-developers/transactions/_meta.json rename to pages/app-developers/guides/transactions/_meta.json diff --git a/pages/app-developers/transactions/estimates.mdx b/pages/app-developers/guides/transactions/estimates.mdx similarity index 100% rename from pages/app-developers/transactions/estimates.mdx rename to pages/app-developers/guides/transactions/estimates.mdx diff --git a/pages/app-developers/transactions/fees.mdx b/pages/app-developers/guides/transactions/fees.mdx similarity index 100% rename from pages/app-developers/transactions/fees.mdx rename to pages/app-developers/guides/transactions/fees.mdx diff --git a/pages/app-developers/guides/transactions/meta.json b/pages/app-developers/guides/transactions/meta.json new file mode 100644 index 000000000..02088ac64 --- /dev/null +++ b/pages/app-developers/guides/transactions/meta.json @@ -0,0 +1,7 @@ +{ + "estimates": "Estimating transaction fees on OP Mainnet", + "fees": "TransactionFees", + "parameters": "Setting transaction gas parameters on OP Mainnet", + "statuses": "Transaction statuses on OP Mainnet", + "troubleshooting": "Troubleshooting transactions" +} diff --git a/pages/app-developers/transactions/parameters.mdx b/pages/app-developers/guides/transactions/parameters.mdx similarity index 100% rename from pages/app-developers/transactions/parameters.mdx rename to pages/app-developers/guides/transactions/parameters.mdx diff --git a/pages/app-developers/transactions/statuses.mdx b/pages/app-developers/guides/transactions/statuses.mdx similarity index 100% rename from pages/app-developers/transactions/statuses.mdx rename to pages/app-developers/guides/transactions/statuses.mdx diff --git a/pages/app-developers/transactions/troubleshooting.mdx b/pages/app-developers/guides/transactions/troubleshooting.mdx similarity index 100% rename from pages/app-developers/transactions/troubleshooting.mdx rename to pages/app-developers/guides/transactions/troubleshooting.mdx diff --git a/pages/app-developers/get-started.mdx b/pages/app-developers/quickstarts/first-app.mdx similarity index 100% rename from pages/app-developers/get-started.mdx rename to pages/app-developers/quickstarts/first-app.mdx diff --git a/pages/interop/starter-kit.mdx b/pages/app-developers/quickstarts/interop-app.mdx similarity index 100% rename from pages/interop/starter-kit.mdx rename to pages/app-developers/quickstarts/interop-app.mdx diff --git a/pages/app-developers/quickstarts/meta.json b/pages/app-developers/quickstarts/meta.json new file mode 100644 index 000000000..b6e0bc90c --- /dev/null +++ b/pages/app-developers/quickstarts/meta.json @@ -0,0 +1,5 @@ +{ + "first-app": "Build interoperable apps on Superchain devnet", + "interop-app": "Deploying a SuperchainERC20 (Starter Kit)", + "token-starter-kit": "Deploying a SuperchainERC20 (Starter Kit)" +} diff --git a/pages/app-developers/starter-kit.mdx b/pages/app-developers/quickstarts/token-starter-kit.mdx similarity index 100% rename from pages/app-developers/starter-kit.mdx rename to pages/app-developers/quickstarts/token-starter-kit.mdx diff --git a/pages/app-developers/reference/contracts/interop/meta.json b/pages/app-developers/reference/contracts/interop/meta.json new file mode 100644 index 000000000..2cf82ed9c --- /dev/null +++ b/pages/app-developers/reference/contracts/interop/meta.json @@ -0,0 +1,3 @@ +{ + "predeploy": "Interoperability predeploys" +} diff --git a/pages/interop/predeploy.mdx b/pages/app-developers/reference/contracts/interop/predeploy.mdx similarity index 100% rename from pages/interop/predeploy.mdx rename to pages/app-developers/reference/contracts/interop/predeploy.mdx diff --git a/pages/app-developers/reference/meta.json b/pages/app-developers/reference/meta.json new file mode 100644 index 000000000..91d821092 --- /dev/null +++ b/pages/app-developers/reference/meta.json @@ -0,0 +1,4 @@ +{ + "networks": "Networks", + "rpc-providers": "Superchain RPC directory" +} diff --git a/pages/app-developers/tools/connect/networks.mdx b/pages/app-developers/reference/networks.mdx similarity index 100% rename from pages/app-developers/tools/connect/networks.mdx rename to pages/app-developers/reference/networks.mdx diff --git a/pages/app-developers/tools/connect/rpc-providers.mdx b/pages/app-developers/reference/rpc-providers.mdx similarity index 100% rename from pages/app-developers/tools/connect/rpc-providers.mdx rename to pages/app-developers/reference/rpc-providers.mdx diff --git a/pages/app-developers/tutorials/supersim/chain-env.mdx b/pages/app-developers/reference/supersim/chain-env.mdx similarity index 100% rename from pages/app-developers/tutorials/supersim/chain-env.mdx rename to pages/app-developers/reference/supersim/chain-env.mdx diff --git a/pages/app-developers/tutorials/supersim/chain-env/_meta.json b/pages/app-developers/reference/supersim/chain-env/_meta.json similarity index 100% rename from pages/app-developers/tutorials/supersim/chain-env/_meta.json rename to pages/app-developers/reference/supersim/chain-env/_meta.json diff --git a/pages/app-developers/tutorials/supersim/chain-env/chain-a.mdx b/pages/app-developers/reference/supersim/chain-env/chain-a.mdx similarity index 100% rename from pages/app-developers/tutorials/supersim/chain-env/chain-a.mdx rename to pages/app-developers/reference/supersim/chain-env/chain-a.mdx diff --git a/pages/app-developers/tutorials/supersim/chain-env/chain-b.mdx b/pages/app-developers/reference/supersim/chain-env/chain-b.mdx similarity index 100% rename from pages/app-developers/tutorials/supersim/chain-env/chain-b.mdx rename to pages/app-developers/reference/supersim/chain-env/chain-b.mdx diff --git a/pages/app-developers/tutorials/supersim/chain-env/included-contracts.mdx b/pages/app-developers/reference/supersim/chain-env/included-contracts.mdx similarity index 100% rename from pages/app-developers/tutorials/supersim/chain-env/included-contracts.mdx rename to pages/app-developers/reference/supersim/chain-env/included-contracts.mdx diff --git a/pages/app-developers/reference/supersim/chain-env/meta.json b/pages/app-developers/reference/supersim/chain-env/meta.json new file mode 100644 index 000000000..198fc6293 --- /dev/null +++ b/pages/app-developers/reference/supersim/chain-env/meta.json @@ -0,0 +1,5 @@ +{ + "chain-a": "OPChainA (chainID 901)", + "chain-b": "OPChainB (chainID 902)", + "included-contracts": "Included contracts" +} diff --git a/pages/app-developers/reference/supersim/meta.json b/pages/app-developers/reference/supersim/meta.json new file mode 100644 index 000000000..144ba3fb5 --- /dev/null +++ b/pages/app-developers/reference/supersim/meta.json @@ -0,0 +1,3 @@ +{ + "chain-env": "Chain environment tutorials" +} diff --git a/pages/app-developers/tutorials/supersim/reference/_meta.json b/pages/app-developers/reference/supersim/reference/_meta.json similarity index 100% rename from pages/app-developers/tutorials/supersim/reference/_meta.json rename to pages/app-developers/reference/supersim/reference/_meta.json diff --git a/pages/app-developers/tutorials/supersim/reference/fork.mdx b/pages/app-developers/reference/supersim/reference/fork.mdx similarity index 100% rename from pages/app-developers/tutorials/supersim/reference/fork.mdx rename to pages/app-developers/reference/supersim/reference/fork.mdx diff --git a/pages/app-developers/reference/supersim/reference/meta.json b/pages/app-developers/reference/supersim/reference/meta.json new file mode 100644 index 000000000..c9eff8a15 --- /dev/null +++ b/pages/app-developers/reference/supersim/reference/meta.json @@ -0,0 +1,4 @@ +{ + "fork": "Fork mode", + "vanilla": "Vanilla mode" +} diff --git a/pages/app-developers/tutorials/supersim/reference/vanilla.mdx b/pages/app-developers/reference/supersim/reference/vanilla.mdx similarity index 100% rename from pages/app-developers/tutorials/supersim/reference/vanilla.mdx rename to pages/app-developers/reference/supersim/reference/vanilla.mdx diff --git a/pages/interop/compatible-tokens.mdx b/pages/app-developers/reference/tokens/compatibility.mdx similarity index 100% rename from pages/interop/compatible-tokens.mdx rename to pages/app-developers/reference/tokens/compatibility.mdx diff --git a/pages/app-developers/reference/tokens/meta.json b/pages/app-developers/reference/tokens/meta.json new file mode 100644 index 000000000..2fd9546bc --- /dev/null +++ b/pages/app-developers/reference/tokens/meta.json @@ -0,0 +1,4 @@ +{ + "compatibility": "Superchain interop compatible tokens", + "tokenlist": "Bridged token addresses" +} diff --git a/pages/superchain/tokenlist.mdx b/pages/app-developers/reference/tokens/tokenlist.mdx similarity index 100% rename from pages/superchain/tokenlist.mdx rename to pages/app-developers/reference/tokens/tokenlist.mdx diff --git a/pages/app-developers/tools.mdx b/pages/app-developers/tools.mdx deleted file mode 100644 index ec079a27d7..000000000 --- a/pages/app-developers/tools.mdx +++ /dev/null @@ -1,80 +0,0 @@ ---- -title: App developer tools -description: Learn about app developer tools for the OP Stack. -lang: en-US -content_type: guide -topic: app-developer-tools -personas: - - app-developer -categories: - - cross-chain-messaging - - standard-bridge - - mainnet -is_imported_content: 'false' ---- - -import { Card, Cards } from 'nextra/components' - -# App developer tools - -Welcome to the app developer tools! - -If you are already familiar with [building on the OP Stack](/stack/getting-started) and just need the tools to get cracking, you are in the right place! - -## Connecting - - - } /> - - } /> - - } /> - - -## Building - - - } /> - - } /> - - } /> - - } /> - - } /> - - } /> - - } /> - - } /> - - } /> - - } /> - - } /> - - } /> - - } /> - - } /> - - } /> - - -## Data and dashboards - - - } /> - - } /> - - } /> - - } /> - - } /> - diff --git a/pages/app-developers/tools/_meta.json b/pages/app-developers/tools/_meta.json deleted file mode 100644 index 9b60290b9..000000000 --- a/pages/app-developers/tools/_meta.json +++ /dev/null @@ -1,10 +0,0 @@ -{ - "console": { - "title": "Superchain Dev Console", - "href": "https://console.optimism.io/?utm_source=op-docs&utm_medium=docs", - "newWindow": true - }, - "supersim": "Supersim Multichain Dev Env", - "connect": "Connecting", - "build": "Building" -} diff --git a/pages/app-developers/tools/build.mdx b/pages/app-developers/tools/build.mdx deleted file mode 100644 index 6ada1a1c7..000000000 --- a/pages/app-developers/tools/build.mdx +++ /dev/null @@ -1,50 +0,0 @@ ---- -title: Build tools -description: >- - This guide provides detailed information and resources about building in the - Optimism ecosystem. -lang: en-US -content_type: guide -topic: build-tools -personas: - - app-developer -categories: - - infrastructure - - devops-tooling - - testnet-tooling -is_imported_content: 'false' ---- - -import { Card, Cards } from 'nextra/components' - -# Build tools - -This section provides information on account abstraction, block explorers, testnet faucets, OP Mainnet NFT tools and oracles. You'll find guides, reference, tool, API to help you understand and work with these topics. - - - - } /> - - } /> - - } /> - - } /> - - } /> - - } /> - - } /> - - } /> - - } /> - - } /> - - } /> - - } /> - - diff --git a/pages/app-developers/tools/build/_meta.json b/pages/app-developers/tools/build/_meta.json deleted file mode 100644 index 54220648f..000000000 --- a/pages/app-developers/tools/build/_meta.json +++ /dev/null @@ -1,25 +0,0 @@ -{ - "faucets": "Faucets", - "oracles": "Oracles", - "nft-tools": "NFT tools", - "block-explorers": "Block explorers", - "account-abstraction": "Account abstraction", - "ecosystem-overview": "Ecosystem Repo", - "analytics-tools": "Analytics Tools", - "bridge": { - "title": "Superchain bridges", - "href": "https://app.optimism.io/bridge/?utm_source=op-docs&utm_medium=docs", - "newWindow": true - }, - "gas": { - "title": "Gas tracker", - "type": "page", - "href": "https://optimistic.grafana.net/public-dashboards/c84a5a9924fe4e14b270a42a8651ceb8?orgId=1&refresh=5m", - "newWindow": true - }, - "block-explorer": { - "title": "OP Mainnet explorer", - "href": "https://explorer.optimism.io/", - "newWindow": true - } -} \ No newline at end of file diff --git a/pages/app-developers/tools/build/nft-tools.mdx b/pages/app-developers/tools/build/nft-tools.mdx deleted file mode 100644 index 66e7db469..000000000 --- a/pages/app-developers/tools/build/nft-tools.mdx +++ /dev/null @@ -1,69 +0,0 @@ ---- -title: OP Mainnet NFT tools -description: Learn the basics of creating an NFT on OP Mainnet. -lang: en-US -content_type: guide -topic: op-mainnet-nft-tools -personas: - - app-developer -categories: - - monitoring - - analytics - - mainnet -is_imported_content: 'false' ---- - -import { Callout } from 'nextra/components' - -# OP Mainnet NFT tools - -## The OP Mainnet NFT ecosystem - -![The OP Mainnet NFT ecosystem page.](/img/guides/app-developers/OP-NFT-Ecosystem.jpg) - -## Statistics - -[Click here for statistics about NFTs on OP Mainnet](https://dune.com/oplabspbc/optimism-nft-secondary-marketplaces) - -## Creator tools - -These tools are available on OP Mainnet: - -* [NiftyKit](https://niftykit.com/) -* [nft-inator](https://nft-inator.com/) -* [Unlock](https://unlock-protocol.com/) (time-bound NFTs for membership) -* [thirdweb](https://thirdweb.com/?utm_source=opdocs\&utm_medium=docs) -* [Crossmint](https://crossmint.com/?utm_source=backlinks\&utm_medium=docs\&utm_campaign=optimism) - -## Feature comparison - - - This list was last updated early February 2024, but new features are implemented all the time. - - -| | NiftyKit | NFT-Inator | Mintplex | Zero Code NFT | thirdweb | Crossmint | -| ------------------ | -------------------------------------------------------------------------- | ------------------------------------------------------------------------- | ------------------------------------------------------------- | ------------------------------------- | ------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Multi-chain | 3 | 5 | 6 | 11 | 2500+ [(all EVM chains)](https://thirdweb.com/dashboard/infrastructure/rpc-edge?utm_source=opdocs\&utm_medium=docs) | 9 | -| Generator | ❌ | ✅ | ❌ | ❌ | ❌ | ❌ | -| ERC-20 support | ❌ | ❌ | ✅ | ✅ | ✅ | ❌ | -| ERC-721A support | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | -| ERC-1155 support | ❌ | ❌ | ✅ | ❌ | ✅ | ✅ | -| DAO support | ❌ | ❌ | ❌ | ✅ | ✅ | ❌ | -| No Code deployment | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | -| Pricing / Fee | [Flat membership fee plus 2.5%-10% of the sales](https://app.niftykit.com) | 2% commission on primary sales | Paywall for premium features | Test for free, $499 for OpenSea setup | See the [pricing page](https://thirdweb.com/pricing) for more details | [Mint API Pricing](https://docs.crossmint.com/docs/pricing?utm_source=backlinks\&utm_medium=docs\&utm_campaign=optimism). NFT Checkouts free for seller (Unlimited transactions). | -| Image Hosting | [NFT storage](https://nft.storage/) / [Pinata](https://www.pinata.cloud/) | [NFT storage](https://nft.storage/) / [Pinata](https://www.pinata.cloud/) | Up to creators. Recommend [Pinata](https://www.pinata.cloud/) | [IPFS](https://ipfs.tech/) | [IPFS](https://ipfs.tech/) | [IPFS](https://ipfs.tech/) and [Arweave](https://www.arweave.org/). | - -## NFT data APIs - -* [Moralis](https://docs.moralis.io/web3-data-api/evm/reference/nft-api?utm_source=op-docs\&utm_medium=partner-docs) -* [Alchemy](https://docs.alchemy.com/reference/nft-api-quickstart) -* [SimpleHash](https://simplehash.com/) -* [QuickNode](https://www.quicknode.com/nft-api) -* [Reservoir](https://docs.reservoir.tools/reference/optimism) -* [NFTScan](https://docs.nftscan.com/reference/evm/get-nfts-by-account) - -## Marketplaces - -* [OpenSea](https://opensea.io/rankings?chain=optimism) -* [Tofu](https://tofunft.com/optimism) -* [Circular Art](https://www.circularart.xyz/) diff --git a/pages/app-developers/tools/connect.mdx b/pages/app-developers/tools/connect.mdx deleted file mode 100644 index 2a1d2b358..000000000 --- a/pages/app-developers/tools/connect.mdx +++ /dev/null @@ -1,26 +0,0 @@ ---- -title: Connect tools -description: Learn about connect in the Optimism ecosystem. This guide provides detailed information and resources about connect. -lang: en-US -content_type: guide -topic: tools -personas: - - app-developer -categories: - - infrastructure - - mainnet - - testnet -is_imported_content: 'false' ---- - -import { Card, Cards } from 'nextra/components' - -# Connect tools - -This section provides information on networks and RPC & node providers. You'll find reference to help you understand and work with these topics. - - - } /> - - } /> - diff --git a/pages/app-developers/tools/connect/_meta.json b/pages/app-developers/tools/connect/_meta.json deleted file mode 100644 index 89f7b7a14..000000000 --- a/pages/app-developers/tools/connect/_meta.json +++ /dev/null @@ -1,4 +0,0 @@ -{ - "networks": "Networks and RPC endpoints", - "rpc-providers": "Superchain RPC directory" -} \ No newline at end of file diff --git a/pages/app-developers/tools/data-and-dashboards.mdx b/pages/app-developers/tools/data-and-dashboards.mdx deleted file mode 100644 index fe13e1191..000000000 --- a/pages/app-developers/tools/data-and-dashboards.mdx +++ /dev/null @@ -1,33 +0,0 @@ ---- -title: Data and Dashboards -description: >- - Learn about various data and dashboard tools -lang: en-US -content_type: guide -topic: data -personas: - - app-developer -categories: - - data-and-dashboards -is_imported_content: 'false' ---- - -import { Card, Cards } from 'nextra/components' - -# Data and Dashboards - -Learn about various dashboards and terms to explore various Superchain metrics: - -* *Data Glossary*: Definitions, methodology, and calculation notes for key metrics -* *Superchain Health Dashboard*: High-Level metrics across the Superchain -* *Superchain Strategic Focus Dashboard*: In-depth metrics with chain-level splits and industry benchmarks -* *Optimism Superchain Raw Onchain Data*: Raw Blocks, Logs, Transactions, Traces data for chains in the Superchain, updated daily. -* *Optimism Superchain 4337 Account Abstraction Data:* Decoded account abstraction UserOps across the Superchain. - - - } /> - } /> - } /> - } /> - } /> - diff --git a/pages/app-developers/tools/data-and-dashboards/_meta.json b/pages/app-developers/tools/data-and-dashboards/_meta.json deleted file mode 100644 index d617b2c21..000000000 --- a/pages/app-developers/tools/data-and-dashboards/_meta.json +++ /dev/null @@ -1,3 +0,0 @@ -{ - "data-glossary": "Data glossary" -} \ No newline at end of file diff --git a/pages/app-developers/tools/data-and-dashboards/data-glossary.mdx b/pages/app-developers/tools/data-and-dashboards/data-glossary.mdx deleted file mode 100644 index d9d6ecf0c..000000000 --- a/pages/app-developers/tools/data-and-dashboards/data-glossary.mdx +++ /dev/null @@ -1,119 +0,0 @@ ---- -title: Data glossary -description: >- - This glossary explains various data terms. -lang: en-US -content_type: guide -topic: data-glossary -personas: - - app-developer -categories: - - data-glossary -is_imported_content: 'false' ---- - -# Data glossary - -This glossary is a living document and will be updated over time as new metrics emerge or definitions evolve. - -## Measure Demand - -### Transaction Fees Paid - -**Metric:** Real Economic Value (REV) - -**Definition:** The total fees paid to execute a transaction onchain. This includes both the traditional gas fees required for inclusion onchain and additional fees paid to transaction execution services (e.g., Jito, Flashbots, Timeboost). - -**Calculation:** Gas Fees + Out-of-Protocol Tips (e.g., Jito, Flashbots, Timeboost) - -* Out-of-Protocol Tips can be sourced from Defillama's MEV category - -**Why it matters:** - -* REV is a topline metric that "measures the monetary demand to transact onchain" (Blockworks). -* It's used as a proxy for users' willingness to pay, capturing all transaction fees to better reflect real demand (excludes app-level fees like DEX swap costs). - -### Revenue - -**Metric:** Estimated Optimism Collective Revenue (Collective Revenue) - -**Definition:** The amount of ETH expected to be earned by the Optimism Collective from revenue sharing. - -**Calculation:** For each chain, take the greater of (a) 2.5% of Chain Revenue or (b) 15% of Net Onchain Profit. OP Mainnet contributes 100% of Net Onchain Profit. - -**Key Components:** - -* **Net Onchain Profit:** Chain Revenue - L1 Gas Fees -* **Chain Revenue:** Sum of the L1 Data Fee + L2 Base Fee + L2 Priority Fee + L2 Operator Fee (Also includes any additional fee types added in the future.) -* *L1 Gas Fees:*\* Total gas fees spent by the chain on L1 in transaction batches (including blob costs) and state output submissions or dispute games. -* **Transaction Batches:** All transactions where the transaction from address is the `batcherHash` address and the transaction to address is the `batchInbox` as defined in the chains' `SystemConfigProxy` contract. -* **State Output Submissions or Dispute Games:** All transactions where the transaction from address is the `Proposer` and the transaction to address is either the `outputOracleProxy` or the `disputeGameFactoryProxy` as defined in the chains' `SystemConfigProxy` contract. -* Each chain's `SystemConfigProxy` contract can be found in the Superchain Registry. -* **Resolving Dispute Games:** All transactions sent to dispute game contracts created by the `disputeGameFactoryProxy`, where the transaction's method id (function call) is either `Resolve`, `ResolveClaim`, or `ClaimCredit`. - -**Why it matters:** - -* This is what the Optimism Collective earns by operating the Superchain, which can be directed by governance to support ecosystem growth. -* See How (and why) the Superchain drives fees to the Optimism Collective (Optimism blog, Aug 2024) - -## Onchain Signals - -### Value Onchain - -**Metric:** Total Value Locked (TVL) - -**Definition:** "Value of all coins held in smart contracts of the protocol" (Defillama). - -**Calculation:** The sum of all USD value of assets locked in applications, as reported by DefiLlama. - -* TVL can be priced in USD or a crypto asset like ETH, but both are subject to price volatility. USD is often used because it's easier to interpret and consistent across the broader crypto ecosystem. - -**Why it Matters:** TVL represents the supply side of onchain economic activity for use in protocols such as Decentralized Exchanges (DEXs) and lending markets. Strong TVL in the right places may enable greater onchain demand. - -#### How to Measure Growth: Net TVL Flows - -Because TVL is influenced by market fluctuations, it can be misleading when trying to measure true growth or user behavior. Net TVL Flows can adjust for this by tracking the net change in token balances, valued at current prices. - -**Calculation:** ( `# of Tokens on Day N` - `# of Tokens on Day 0` ) \* `Price of Tokens on Day N` - -**Example:** If an app has 100,000 ETH locked on Day 0 when ETH/USD is $2,000, and 90,000 ETH locked at $3,000 on Day N: - -* Net TVL Flows = −10,000 ETH × $3,000 = $30 million in net outflows -* Naive TVL change would suggest growth: $200 million → $270 million - -## Network Usage & Infrastructure - -**Metric:** Gas Used per Second (gas/s) - -**Definition:** "Gas refers to the unit that measures the amount of computational effort required to execute specific operations on Ethereum" (ethereum.org). Gas Used is tracked as an average rate per second for simplicity. - -**Why it Matters:** Gas, sometimes referred to as blockspace, is the limited resource that blockchains provide. Gas used shows how much of that resource is actually being consumed. - -**Caution:** Gas is only comparable across chains that use Ethereum-equivalent gas units. - -### User Experience (UX) - -**Metric:** Median Transaction Fee (USD) - -**Definition:** The median gas fee paid to submit a transaction, expressed in USD for simplicity and easier comparison across ecosystems. - -**Calculation:** Median of all transaction fees over a period of time, marked at the USD price at the time of the transaction. - -**Why it Matters:** This metric serves as a proxy for the cost to transact. Lower median fees enable broader usage by reducing friction, lowering breakeven costs, and unlocking use cases that would otherwise be cost-prohibitive. - -## Market Share - -**Definition:** The Superchain's share of a broader market segment for any measure (e.g., L2s, total crypto). - -**Calculation:** Superchain Metric Value / Total Market Metric Value - -**Why it Matters:** Market share helps isolate whether growth is driven by the Superchain itself, or is simply part of a broader market trend. A rising share signals outperformance, while a declining share suggests that other ecosystems are growing faster. - -| Metric | What It Measures | Why It Matters | -| ------------------------- | ---------------------------------------------------------------- | ----------------------------------------------------------------- | -| Real Economic Value (REV) | Fees paid by users to transact (txn fees + out-of-protocol tips) | Captures users' willingness to pay for onchain activity | -| Collective Revenue | ETH earned by the Optimism Collective | Revenue can be directed by governance to support ecosystem growth | -| Total Value Locked (TVL) | Tokens locked in DeFi protocols and other apps | Supply side of the DeFi ecosystem | -| Gas Used per Second | Average compute consumed onchain | Measures throughput and execution load | -| Median Transaction Fee | Typical cost for a user to transact | Lower fees reduce friction and may unlock broader usage | -| Market Share | Superchain's share of activity vs. the broader crypto industry | Tracks relative performance against L2s or the broader market | diff --git a/pages/app-developers/tools/build/analytics-tools.mdx b/pages/app-developers/tools/data/analytics.mdx similarity index 100% rename from pages/app-developers/tools/build/analytics-tools.mdx rename to pages/app-developers/tools/data/analytics.mdx diff --git a/pages/app-developers/tools/data/meta.json b/pages/app-developers/tools/data/meta.json new file mode 100644 index 000000000..dbe2ac839 --- /dev/null +++ b/pages/app-developers/tools/data/meta.json @@ -0,0 +1,4 @@ +{ + "analytics": "Analytics tools", + "oracles": "Oracles" +} diff --git a/pages/app-developers/tools/build/oracles.mdx b/pages/app-developers/tools/data/oracles.mdx similarity index 100% rename from pages/app-developers/tools/build/oracles.mdx rename to pages/app-developers/tools/data/oracles.mdx diff --git a/pages/app-developers/tools/build/ecosystem-overview.mdx b/pages/app-developers/tools/ecosystem.mdx similarity index 100% rename from pages/app-developers/tools/build/ecosystem-overview.mdx rename to pages/app-developers/tools/ecosystem.mdx diff --git a/pages/app-developers/tools/build/block-explorers.mdx b/pages/app-developers/tools/infrastructure/explorers similarity index 100% rename from pages/app-developers/tools/build/block-explorers.mdx rename to pages/app-developers/tools/infrastructure/explorers diff --git a/pages/app-developers/tools/meta.json b/pages/app-developers/tools/meta.json new file mode 100644 index 000000000..62cfea75f --- /dev/null +++ b/pages/app-developers/tools/meta.json @@ -0,0 +1,4 @@ +{ + "ecosystem": "Superchain Ecosystem repo", + "supersim": "Supersim" +} diff --git a/pages/app-developers/tools/supersim.mdx b/pages/app-developers/tools/supersim.mdx index 735f54051..f5706793c 100644 --- a/pages/app-developers/tools/supersim.mdx +++ b/pages/app-developers/tools/supersim.mdx @@ -1,70 +1,25 @@ --- -title: Supersim Multichain Development Environment -description: Learn how to use the Supersim local dev environment tool designed to simulate the Optimism Superchain. +title: Supersim +description: >- + Learn how to use the Supersim local dev environment tool designed to simulate + the Optimism Superchain. lang: en-US content_type: guide -topic: tools +topic: supersim personas: + - protocol-developer - app-developer categories: - - protocol - - devops-tooling + - devnet + - local-devnet + - testing + - interoperability + - cross-chain-messaging - supersim -is_imported_content: 'false' + - protocol +is_imported_content: 'true' --- -import { Callout } from 'nextra/components' - -# Supersim Multichain Development Environment - - - Interop is currently in active development and not yet ready for production use. The information provided here may change. Check back regularly for the most up-to-date information. - - -[Supersim](https://github.com/ethereum-optimism/Supersim) is a local development environment tool designed to simulate the Optimism Superchain for developers building multi-chain applications. It provides a simplified way to test and develop applications that interact with multiple chains within the Superchain ecosystem. - -## Supersim workflow - -```mermaid -graph LR - A[Write Smart Contracts] --> B[Deploy on Supersim] - B --> C[Test Cross-Chain Interactions] - C --> D[Debug and Refine] - D --> B - C --> E[Ready for Production] -``` - -This diagram illustrates the typical workflow for developers using supersim, from writing smart contracts to testing and refining cross-chain interactions. - -## Features and benefits - -* Simulates multiple OP Stack chains locally (e.g., chain 901, 902) -* Supports testing of cross-chain messaging and interactions -* Includes pre-deployed interoperability contracts -* Offers a CLI interface for starting and managing Supersim instances -* Provides local JSON-RPC endpoints for each simulated chain -* Allows for custom configuration of chain parameters -* Facilitates testing of Superchain-specific features like SuperchainERC20 tokens -* Easy to use with common Ethereum development tools -* Supports chain forking - -## Supersim CLI interaction - -```mermaid -graph TD - A[Developer] --> B[Supersim CLI] - B --> C[Chain 901] - B --> D[Chain 902] - B --> E[...] - C --> F[JSON-RPC Endpoint] - D --> G[JSON-RPC Endpoint] - E --> H[JSON-RPC Endpoint] -``` - -This diagram illustrates how developers interact with Supersim through the CLI, which simulates OP Stack specific features (specifically interop) on locally run chains, each with its own JSON-RPC endpoint and pre-deployed interoperability contracts. - -## Next steps +import Supersim from '@/pages/app-developers/tools/supersim.mdx' -* Build a [revolutionary app](/app-developers/get-started) that uses multiple blockchains within the Superchain -* Deploy a [SuperchainERC20](/interop/tutorials/deploy-superchain-erc20) to the Superchain -* View more [Supersim tutorials](/app-developers/tutorials/supersim) + diff --git a/pages/interop/tools/devnet.mdx b/pages/app-developers/tools/testing/devnet.mdx similarity index 100% rename from pages/interop/tools/devnet.mdx rename to pages/app-developers/tools/testing/devnet.mdx diff --git a/pages/app-developers/tools/build/faucets.mdx b/pages/app-developers/tools/testing/faucets.mdx similarity index 96% rename from pages/app-developers/tools/build/faucets.mdx rename to pages/app-developers/tools/testing/faucets.mdx index 23489d203..e764af9de 100644 --- a/pages/app-developers/tools/build/faucets.mdx +++ b/pages/app-developers/tools/testing/faucets.mdx @@ -44,17 +44,16 @@ The Superchain Faucet is a great place to start if you're looking for testnet ET | Faucet Name | Supported Networks | | ------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | | [Alchemy Faucet](https://sepoliafaucet.com) | Sepolia | -| [Chain Platform Faucet](https://faucet.chainplatform.co/faucets/ethereum-sepolia/) | Sepolia | -| [Ethereum Ecosystem Faucets](https://www.ethereum-ecosystem.com/faucets) | Sepolia, OP Sepolia, Base Sepolia | -| [ETHGlobal Testnet Faucet](https://ethglobal.com/faucet) | Sepolia, OP Sepolia, Base Sepolia, Zora Sepolia, Holesky | -| [Farcaster Frame Faucet by LearnWeb3](https://warpcast.com/haardikkk/0x28f4237d) | Sepolia, OP Sepolia | | [Infura Faucet](https://www.infura.io/faucet/sepolia) | Sepolia | +| [QuickNode Faucet](https://faucet.quicknode.com/optimism/) | Sepolia, OP Sepolia | +| [Farcaster Frame Faucet by LearnWeb3](https://warpcast.com/haardikkk/0x28f4237d) | Sepolia, OP Sepolia | | [LearnWeb3 Web App Faucet](https://learnweb3.io/faucets) | Sepolia, OP Sepolia | | [Native USDC Faucet](https://faucet.circle.com/) | Sepolia, OP Sepolia | -| [QuickNode Faucet](https://faucet.quicknode.com/optimism/) | Sepolia, OP Sepolia | -| [Tenderly Unlimited Faucet](https://docs.tenderly.co/virtual-testnets/unlimited-faucet?mtm_campaign=ext-docs\&mtm_kwd=optimism) | OP Sepolia, OP Mainnet, and [85+ other networks](https://docs.tenderly.co/supported-networks?mtm_campaign=ext-docs\&mtm_kwd=optimism) | -| [thirdweb OP Sepolia Faucet](https://thirdweb.com/op-sepolia-testnet?utm_source=opdocs\&utm_medium=docs) | OP Sepolia | +| [ETHGlobal Testnet Faucet](https://ethglobal.com/faucet) | Sepolia, OP Sepolia, Base Sepolia, Zora Sepolia, Holesky | +| [Ethereum Ecosystem Faucets](https://www.ethereum-ecosystem.com/faucets) | Sepolia, OP Sepolia, Base Sepolia | | [thirdweb Sepolia Faucet](https://thirdweb.com/sepolia?utm_source=opdocs\&utm_medium=docs) | Sepolia | +| [thirdweb OP Sepolia Faucet](https://thirdweb.com/op-sepolia-testnet?utm_source=opdocs\&utm_medium=docs) | OP Sepolia | +| [Tenderly Unlimited Faucet](https://docs.tenderly.co/virtual-testnets/unlimited-faucet?mtm_campaign=ext-docs\&mtm_kwd=optimism) | OP Sepolia, OP Mainnet, and [85+ other networks](https://docs.tenderly.co/supported-networks?mtm_campaign=ext-docs\&mtm_kwd=optimism) | ## Bridge from Sepolia diff --git a/pages/app-developers/tools/testing/meta.json b/pages/app-developers/tools/testing/meta.json new file mode 100644 index 000000000..bb6f6cc4d --- /dev/null +++ b/pages/app-developers/tools/testing/meta.json @@ -0,0 +1,4 @@ +{ + "devnet": "Superchain interop devnet", + "faucets": "Testnet faucets" +} diff --git a/pages/app-developers/tools/build/account-abstraction.mdx b/pages/app-developers/tools/wallets/account-abstraction.mdx similarity index 100% rename from pages/app-developers/tools/build/account-abstraction.mdx rename to pages/app-developers/tools/wallets/account-abstraction.mdx diff --git a/pages/app-developers/tools/wallets/meta.json b/pages/app-developers/tools/wallets/meta.json new file mode 100644 index 000000000..6ee225d69 --- /dev/null +++ b/pages/app-developers/tools/wallets/meta.json @@ -0,0 +1,3 @@ +{ + "account-abstraction": "Account abstraction" +} diff --git a/pages/app-developers/transactions.mdx b/pages/app-developers/transactions.mdx deleted file mode 100644 index e38926b58..000000000 --- a/pages/app-developers/transactions.mdx +++ /dev/null @@ -1,30 +0,0 @@ ---- -title: Transaction guides -description: >- - Guide to understanding and working with transactions on OP Stack, including - fee estimation, gas parameters, and troubleshooting. -lang: en-US -content_type: guide -topic: transaction-guides -personas: - - app-developer -categories: - - mainnet - - transactions - - gas -is_imported_content: 'false' ---- - -import { Card, Cards } from 'nextra/components' - -# Transaction guides - -This section provides information on transactions in OP Mainnet, including fee estimation, gas parameters, transaction statuses, and troubleshooting. You'll find guides to help you understand and work with these topics. - - - } /> - } /> - } /> - } /> - } /> - diff --git a/pages/app-developers/tutorials.mdx b/pages/app-developers/tutorials.mdx deleted file mode 100644 index 987c1c352..000000000 --- a/pages/app-developers/tutorials.mdx +++ /dev/null @@ -1,63 +0,0 @@ ---- -title: App dev tutorials -description: >- - A collection of tutorials for app developers building on OP Stack, covering - topics such as bridging tokens, deploying contracts, and estimating - transaction costs. -lang: en-US -content_type: landing-page -topic: app-dev-tutorials -personas: - - app-developer -categories: - - mainnet - - testnet -is_imported_content: 'false' ---- - -import { Card, Cards } from 'nextra/components' - -# App dev tutorials - -If you're a bit more familiar with the OP Stack and Ethereum, you can try walking through one of the tutorials put together by the Optimism community. They'll help you get a head start when building your first Optimistic project. - -## Bridging - - } /> - } /> - } /> - } /> - } /> - } /> - - -## Transactions - - } /> - } /> - } /> - } /> - - -## Supersim - - } /> - } /> - } /> - } /> - } /> - } /> - } /> - } /> - } /> - - -## Interop - - } /> - } /> - } /> - } /> - - -You can also [suggest a new tutorial](https://github.com/ethereum-optimism/docs/issues/new?assignees=\&labels=tutorial%2Cdocumentation%2Ccommunity-request\&projects=\&template=suggest_tutorial.yaml\&title=%5BTUTORIAL%5D+Add+PR+title) if you have something specific in mind. We'd love to grow this list! diff --git a/pages/app-developers/tutorials/_meta.json b/pages/app-developers/tutorials/_meta.json deleted file mode 100644 index 2a0f94f98..000000000 --- a/pages/app-developers/tutorials/_meta.json +++ /dev/null @@ -1,6 +0,0 @@ -{ -"bridging": "Bridging tutorials", -"transactions": "Transaction tutorials", -"supersim": "Supersim tutorials", -"interop": "Interop tutorials" -} diff --git a/pages/app-developers/tutorials/bridging.mdx b/pages/app-developers/tutorials/bridging.mdx deleted file mode 100644 index fd57707fc..000000000 --- a/pages/app-developers/tutorials/bridging.mdx +++ /dev/null @@ -1,28 +0,0 @@ ---- -title: Bridging tutorials -description: A collection of app developer tutorials focused on bridging. -lang: en-US -content_type: tutorial -topic: bridging-tutorials -personas: - - app-developer -categories: - - cross-chain-messaging - - standard-bridge - - devnets -is_imported_content: 'false' ---- - -import { Card, Cards } from 'nextra/components' - -# Bridging tutorials - -This is a collection of app developer tutorials focused on bridging. - - - } /> - } /> - } /> - } /> - } /> - diff --git a/pages/app-developers/tutorials/bridging/_meta.json b/pages/app-developers/tutorials/bridging/_meta.json deleted file mode 100644 index 2aefbf0fc..000000000 --- a/pages/app-developers/tutorials/bridging/_meta.json +++ /dev/null @@ -1,7 +0,0 @@ -{ - "cross-dom-solidity": "Communicating between chains in Solidity", - "cross-dom-bridge-eth": "Bridging ETH with viem", - "cross-dom-bridge-erc20": "Bridging ERC-20 tokens with viem", - "standard-bridge-custom-token": "Bridging your custom ERC-20 token to OP Mainnet", - "standard-bridge-standard-token": "Bridging your standard ERC-20 token to OP Mainnet" -} \ No newline at end of file diff --git a/pages/interop/tutorials/bridge-crosschain-eth.mdx b/pages/app-developers/tutorials/bridging/bridge-crosschain-eth.mdx similarity index 100% rename from pages/interop/tutorials/bridge-crosschain-eth.mdx rename to pages/app-developers/tutorials/bridging/bridge-crosschain-eth.mdx diff --git a/pages/app-developers/tutorials/supersim/deposit-transactions.mdx b/pages/app-developers/tutorials/bridging/deposit-transactions.mdx similarity index 100% rename from pages/app-developers/tutorials/supersim/deposit-transactions.mdx rename to pages/app-developers/tutorials/bridging/deposit-transactions.mdx diff --git a/pages/app-developers/tutorials/bridging/meta.json b/pages/app-developers/tutorials/bridging/meta.json new file mode 100644 index 000000000..4d933499a --- /dev/null +++ b/pages/app-developers/tutorials/bridging/meta.json @@ -0,0 +1,9 @@ +{ + "bridge-crosschain-eth": "Transferring ETH", + "cross-dom-bridge-erc20": "Bridging ERC-20 tokens to OP Mainnet", + "cross-dom-bridge-eth": "Bridging ETH to OP Mainnet with Viem", + "cross-dom-solidity": "Communicating between OP Stack and Ethereum in Solidity", + "deposit-transactions": "Deposit transactions", + "standard-bridge-custom-token": "Bridging your custom ERC-20 token using the Standard Bridge", + "standard-bridge-standard-token": "Bridging Your Standard ERC-20 Token Using the Standard Bridge" +} diff --git a/pages/app-developers/tutorials/supersim/getting-started/first-steps.mdx b/pages/app-developers/tutorials/development/supersim/first-steps.mdx similarity index 100% rename from pages/app-developers/tutorials/supersim/getting-started/first-steps.mdx rename to pages/app-developers/tutorials/development/supersim/first-steps.mdx diff --git a/pages/app-developers/tutorials/supersim/getting-started.mdx b/pages/app-developers/tutorials/development/supersim/getting-started.mdx similarity index 100% rename from pages/app-developers/tutorials/supersim/getting-started.mdx rename to pages/app-developers/tutorials/development/supersim/getting-started.mdx diff --git a/pages/app-developers/tutorials/supersim/getting-started/installation.mdx b/pages/app-developers/tutorials/development/supersim/installation.mdx similarity index 100% rename from pages/app-developers/tutorials/supersim/getting-started/installation.mdx rename to pages/app-developers/tutorials/development/supersim/installation.mdx diff --git a/pages/app-developers/tutorials/development/supersim/meta.json b/pages/app-developers/tutorials/development/supersim/meta.json new file mode 100644 index 000000000..4f9fa7cf9 --- /dev/null +++ b/pages/app-developers/tutorials/development/supersim/meta.json @@ -0,0 +1,5 @@ +{ + "first-steps": "First steps", + "getting-started": "Getting started guides", + "installation": "Installation" +} diff --git a/pages/app-developers/tutorials/interop.mdx b/pages/app-developers/tutorials/interop.mdx deleted file mode 100644 index 5e15bc68b..000000000 --- a/pages/app-developers/tutorials/interop.mdx +++ /dev/null @@ -1,29 +0,0 @@ ---- -title: Interop tutorials -description: A collection of app developer tutorials focused on interop. -lang: en-US -content_type: tutorial -topic: interop-tutorials -personas: - - app-developer -categories: - - cross-chain-messaging - - standard-bridge - - devnets -is_imported_content: 'false' ---- - -import { Card, Cards } from 'nextra/components' - -# Interop tutorials - -This is a collection of app developer tutorials focused on interop. - - - } /> - } /> - } /> - } /> - } /> - } /> - diff --git a/pages/app-developers/tutorials/interop/_meta.json b/pages/app-developers/tutorials/interop/_meta.json deleted file mode 100644 index 159197e8b..000000000 --- a/pages/app-developers/tutorials/interop/_meta.json +++ /dev/null @@ -1,8 +0,0 @@ -{ - "transfer-superchainERC20": "Transferring a SuperchainERC20", - "deploy-superchain-erc20": "Deploying a SuperchainERC20", - "bridge-crosschain-eth": "Bridging native cross-chain ETH transfers", - "contract-calls": "Making crosschain contract calls (ping pong)", - "event-reads": "Making crosschain event reads (tic-tac-toe)", - "event-contests": "Deploying crosschain event composability (contests)" -} diff --git a/pages/app-developers/tutorials/interop/bridge-crosschain-eth.mdx b/pages/app-developers/tutorials/interop/bridge-crosschain-eth.mdx deleted file mode 100644 index 8e3ae0325..000000000 --- a/pages/app-developers/tutorials/interop/bridge-crosschain-eth.mdx +++ /dev/null @@ -1,18 +0,0 @@ ---- -title: Bridge Crosschain Eth -description: Learn how to bridge native cross-chain ETH transfers. -lang: en-US -content_type: tutorial -topic: bridge-crosschain-eth -personas: - - app-developer -categories: - - cross-chain-messaging - - standard-bridge - - devnets -is_imported_content: 'true' ---- - -import CrosschainETH from '@/pages/interop/tutorials/bridge-crosschain-eth.mdx' - - diff --git a/pages/app-developers/tutorials/interop/contract-calls.mdx b/pages/app-developers/tutorials/interop/contract-calls.mdx deleted file mode 100644 index c1e86060f..000000000 --- a/pages/app-developers/tutorials/interop/contract-calls.mdx +++ /dev/null @@ -1,19 +0,0 @@ ---- -title: Contract Calls -description: Learn how to make crosschain contract calls using ping pong. -lang: en-US -content_type: tutorial -topic: contract-calls -personas: - - app-developer - - protocol-developer -categories: - - cross-chain-messaging - - infrastructure - - devnets -is_imported_content: 'true' ---- - -import ContractCalls from '@/pages/interop/tutorials/contract-calls.mdx' - - diff --git a/pages/app-developers/tutorials/interop/deploy-superchain-erc20.mdx b/pages/app-developers/tutorials/interop/deploy-superchain-erc20.mdx deleted file mode 100644 index 59a54a845..000000000 --- a/pages/app-developers/tutorials/interop/deploy-superchain-erc20.mdx +++ /dev/null @@ -1,20 +0,0 @@ ---- -title: Deploy Superchain Erc20 -description: Learn how to issue assets on SuperchainERC20. -lang: en-US -content_type: tutorial -topic: deploy-superchain-erc20 -personas: - - app-developer - - protocol-developer -categories: - - cross-chain-messaging - - infrastructure - - devnets - - standard-bridge -is_imported_content: 'true' ---- - -import DeploySuperERC20 from '@/pages/interop/tutorials/deploy-superchain-erc20.mdx' - - diff --git a/pages/app-developers/tutorials/interop/event-contests.mdx b/pages/app-developers/tutorials/interop/event-contests.mdx deleted file mode 100644 index 20522fae9..000000000 --- a/pages/app-developers/tutorials/interop/event-contests.mdx +++ /dev/null @@ -1,19 +0,0 @@ ---- -title: Event Contests -description: Learn how to deploy crosschain event composability using contests. -lang: en-US -content_type: tutorial -topic: event-contests -personas: - - app-developer - - protocol-developer -categories: - - cross-chain-messaging - - infrastructure - - devnets -is_imported_content: 'true' ---- - -import EventContests from '@/pages/interop/tutorials/event-contests.mdx' - - diff --git a/pages/app-developers/tutorials/interop/event-reads.mdx b/pages/app-developers/tutorials/interop/event-reads.mdx deleted file mode 100644 index 1907c4b36..000000000 --- a/pages/app-developers/tutorials/interop/event-reads.mdx +++ /dev/null @@ -1,19 +0,0 @@ ---- -title: Event Reads -description: Learn how to make crosschain event reads using tic-tac-toe. -lang: en-US -content_type: tutorial -topic: event-reads -personas: - - app-developer - - protocol-developer -categories: - - cross-chain-messaging - - infrastructure - - devnets -is_imported_content: 'true' ---- - -import EventReads from '@/pages/interop/tutorials/event-reads.mdx' - - diff --git a/pages/app-developers/tutorials/interop/transfer-superchainERC20.mdx b/pages/app-developers/tutorials/interop/transfer-superchainERC20.mdx deleted file mode 100644 index c0295a427..000000000 --- a/pages/app-developers/tutorials/interop/transfer-superchainERC20.mdx +++ /dev/null @@ -1,22 +0,0 @@ ---- -title: Transfer SuperchainERC20 -description: >- - Learn how to transfer a SuperchainERC20 between chains using - L2ToL2CrossDomainMessenger. -lang: en-US -content_type: tutorial -topic: transfer-superchainerc20 -personas: - - app-developer - - protocol-developer -categories: - - cross-chain-messaging - - infrastructure - - devnets - - standard-bridge -is_imported_content: 'true' ---- - -import TransferSuperERC20 from '@/pages/interop/tutorials/transfer-superchainERC20.mdx' - - diff --git a/pages/interop/tutorials/contract-calls.mdx b/pages/app-developers/tutorials/interoperability/contract-calls.mdx similarity index 100% rename from pages/interop/tutorials/contract-calls.mdx rename to pages/app-developers/tutorials/interoperability/contract-calls.mdx diff --git a/pages/interop/tutorials/upgrade-to-superchain-erc20/custom-bridge.mdx b/pages/app-developers/tutorials/interoperability/custom-bridge.mdx similarity index 99% rename from pages/interop/tutorials/upgrade-to-superchain-erc20/custom-bridge.mdx rename to pages/app-developers/tutorials/interoperability/custom-bridge.mdx index 30f07a954..4262d38d6 100644 --- a/pages/interop/tutorials/upgrade-to-superchain-erc20/custom-bridge.mdx +++ b/pages/app-developers/tutorials/interoperability/custom-bridge.mdx @@ -212,7 +212,7 @@ Some steps depend on whether you want to deploy on [Supersim](/interop/tools/sup 1. Create a file, `src/InteropToken.sol`. - ```solidity file=/public/tutorials/InteropToken.sol hash=007791836635608fdeb9c70c1b368f25 filename="src/InteropToken.sol" + ```solidity file=/public/tutorials/InteropToken.sol hash=5e728534c265028c94d60dcb6550699d filename="src/InteropToken.sol" ``` 2. This `src/InteropToken.sol` is used for contract upgrades when the ERC20 contracts are at the same address. diff --git a/pages/interop/tutorials/custom-superchain-erc20.mdx b/pages/app-developers/tutorials/interoperability/custom-superchain-erc20.mdx similarity index 100% rename from pages/interop/tutorials/custom-superchain-erc20.mdx rename to pages/app-developers/tutorials/interoperability/custom-superchain-erc20.mdx diff --git a/pages/interop/tutorials/deploy-superchain-erc20.mdx b/pages/app-developers/tutorials/interoperability/deploy-superchain-erc20.mdx similarity index 100% rename from pages/interop/tutorials/deploy-superchain-erc20.mdx rename to pages/app-developers/tutorials/interoperability/deploy-superchain-erc20.mdx diff --git a/pages/interop/tutorials/event-contests.mdx b/pages/app-developers/tutorials/interoperability/event-contests.mdx similarity index 100% rename from pages/interop/tutorials/event-contests.mdx rename to pages/app-developers/tutorials/interoperability/event-contests.mdx diff --git a/pages/interop/tutorials/event-reads.mdx b/pages/app-developers/tutorials/interoperability/event-reads.mdx similarity index 100% rename from pages/interop/tutorials/event-reads.mdx rename to pages/app-developers/tutorials/interoperability/event-reads.mdx diff --git a/pages/interop/tutorials/message-passing/manual-relay.mdx b/pages/app-developers/tutorials/interoperability/manual-relay.mdx similarity index 100% rename from pages/interop/tutorials/message-passing/manual-relay.mdx rename to pages/app-developers/tutorials/interoperability/manual-relay.mdx diff --git a/pages/interop/tutorials/message-passing.mdx b/pages/app-developers/tutorials/interoperability/message-passing.mdx similarity index 100% rename from pages/interop/tutorials/message-passing.mdx rename to pages/app-developers/tutorials/interoperability/message-passing.mdx diff --git a/pages/app-developers/tutorials/interoperability/meta.json b/pages/app-developers/tutorials/interoperability/meta.json new file mode 100644 index 000000000..26dcd0d23 --- /dev/null +++ b/pages/app-developers/tutorials/interoperability/meta.json @@ -0,0 +1,12 @@ +{ + "contract-calls": "Making crosschain contract calls (ping pong)", + "custom-bridge": "Building a custom bridge", + "custom-superchain-erc20": "Custom SuperchainERC20 tokens", + "deploy-superchain-erc20": "Deploying a SuperchainERC20", + "event-contests": "Deploying crosschain event composability (contests)", + "event-reads": "Making cross-chain event reads (tic-tac-toe)", + "manual-relay": "Relay transactions manually", + "message-passing": "Interop message passing tutorial", + "transfer-superchainERC20": "Transferring a SuperchainERC20", + "verify-messages": "Verifying log entries" +} diff --git a/pages/interop/tutorials/transfer-superchainERC20.mdx b/pages/app-developers/tutorials/interoperability/transfer-superchainERC20.mdx similarity index 100% rename from pages/interop/tutorials/transfer-superchainERC20.mdx rename to pages/app-developers/tutorials/interoperability/transfer-superchainERC20.mdx diff --git a/pages/interop/tutorials/verify-messages.mdx b/pages/app-developers/tutorials/interoperability/verify-messages.mdx similarity index 100% rename from pages/interop/tutorials/verify-messages.mdx rename to pages/app-developers/tutorials/interoperability/verify-messages.mdx diff --git a/pages/app-developers/tutorials/supersim.mdx b/pages/app-developers/tutorials/supersim.mdx deleted file mode 100644 index d48fa17b4..000000000 --- a/pages/app-developers/tutorials/supersim.mdx +++ /dev/null @@ -1,37 +0,0 @@ ---- -title: Supersim guides and tutorials -description: A collection of guides and tutorials to understanding and working with Supersim. -lang: en-US -content_type: tutorial -topic: supersim-guides-and-tutorials -personas: app-developer -categories: ['supersim', 'devnets', 'cli'] -is_imported_content: 'false' ---- - -import { Card, Cards } from 'nextra/components' - -# Supersim guides and tutorials - -This is a collection of guides and tutorials to understanding and working with Supersim, including getting started, CLI reference, and chain environment. - -## General - - } /> - } /> - } /> - } /> - - - -## Tutorials - - } /> - } /> - } /> - } /> - } /> - } /> - } /> - } /> - diff --git a/pages/app-developers/tutorials/supersim/_meta.json b/pages/app-developers/tutorials/supersim/_meta.json deleted file mode 100644 index f0aad865e..000000000 --- a/pages/app-developers/tutorials/supersim/_meta.json +++ /dev/null @@ -1,6 +0,0 @@ -{ - "getting-started": "Getting started", - "reference": "CLI reference", - "chain-env": "Chain environment", - "deposit-transactions": "Deposit transactions" -} \ No newline at end of file diff --git a/pages/app-developers/tutorials/supersim/getting-started/_meta.json b/pages/app-developers/tutorials/supersim/getting-started/_meta.json deleted file mode 100644 index 551335a15..000000000 --- a/pages/app-developers/tutorials/supersim/getting-started/_meta.json +++ /dev/null @@ -1,4 +0,0 @@ -{ - "installation": "Installation", - "first-steps": "First steps" -} \ No newline at end of file diff --git a/pages/app-developers/tutorials/supersim/reference.mdx b/pages/app-developers/tutorials/supersim/reference.mdx deleted file mode 100644 index c31b7a550..000000000 --- a/pages/app-developers/tutorials/supersim/reference.mdx +++ /dev/null @@ -1,25 +0,0 @@ ---- -title: CLI reference guides -description: A collection of guides for using the Superchain CLI with Supersim. -lang: en-US -content_type: tutorial -topic: cli-reference-guides -personas: - - app-developer -categories: - - supersim - - devnets -is_imported_content: 'false' ---- - -import { Card, Cards } from 'nextra/components' - -# CLI reference guides - -This is a collection of guides for using the Superchain CLI with Supersim. - - - } /> - - } /> - diff --git a/pages/app-developers/tutorials/transactions.mdx b/pages/app-developers/tutorials/transactions.mdx deleted file mode 100644 index cc14d04a5..000000000 --- a/pages/app-developers/tutorials/transactions.mdx +++ /dev/null @@ -1,27 +0,0 @@ ---- -title: Transaction tutorials -description: A collection of app developer tutorials focused on transactions. -lang: en-US -content_type: tutorial -topic: transaction-tutorials -personas: - - app-developer -categories: - - transactions - - mainnet - - testnet - - devnets -is_imported_content: 'false' ---- - -import { Card, Cards } from 'nextra/components' - -# Transaction tutorials - -This is a collection of app developer tutorials focused on transactions. - - - } /> - } /> - } /> - diff --git a/pages/app-developers/tutorials/transactions/_meta.json b/pages/app-developers/tutorials/transactions/_meta.json deleted file mode 100644 index 56184691a..000000000 --- a/pages/app-developers/tutorials/transactions/_meta.json +++ /dev/null @@ -1,5 +0,0 @@ -{ - "sdk-trace-txns": "Tracing deposits and withdrawals", - "sdk-estimate-costs": "Estimating transaction costs", - "send-tx-from-eth": "Triggering OP Mainnet transactions from Ethereum" -} \ No newline at end of file diff --git a/pages/app-developers/tutorials/transactions/meta.json b/pages/app-developers/tutorials/transactions/meta.json new file mode 100644 index 000000000..b95c54ade --- /dev/null +++ b/pages/app-developers/tutorials/transactions/meta.json @@ -0,0 +1,5 @@ +{ + "sdk-estimate-costs": "Estimating transaction costs on OP Stack", + "sdk-trace-txns": "Tracing deposits and withdrawals", + "send-tx-from-eth": "Triggering OP Stack transactions from Ethereum" +} diff --git a/pages/chain-operators/concepts/meta.json b/pages/chain-operators/concepts/meta.json new file mode 100644 index 000000000..7b64c88c7 --- /dev/null +++ b/pages/chain-operators/concepts/meta.json @@ -0,0 +1,3 @@ +{ + "superchain-upgrades": "Superchain upgrades" +} diff --git a/pages/superchain/superchain-upgrades.mdx b/pages/chain-operators/concepts/superchain-upgrades.mdx similarity index 100% rename from pages/superchain/superchain-upgrades.mdx rename to pages/chain-operators/concepts/superchain-upgrades.mdx diff --git a/pages/operators/chain-operators/features/alt-da-mode.mdx b/pages/chain-operators/features/alt-da-mode.mdx similarity index 100% rename from pages/operators/chain-operators/features/alt-da-mode.mdx rename to pages/chain-operators/features/alt-da-mode.mdx diff --git a/pages/operators/chain-operators/features/bridged-usdc-standard.mdx b/pages/chain-operators/features/bridged-usdc-standard.mdx similarity index 100% rename from pages/operators/chain-operators/features/bridged-usdc-standard.mdx rename to pages/chain-operators/features/bridged-usdc-standard.mdx diff --git a/pages/chain-operators/features/meta.json b/pages/chain-operators/features/meta.json new file mode 100644 index 000000000..a919ce43a --- /dev/null +++ b/pages/chain-operators/features/meta.json @@ -0,0 +1,6 @@ +{ + "alt-da-mode": "How to run an Alt-DA mode chain", + "bridged-usdc-standard": "Bridged USDC Standard on OP Stack", + "preinstalls": "OP Stack preinstalls", + "span-batches": "Span Batches" +} diff --git a/pages/operators/chain-operators/features/preinstalls.mdx b/pages/chain-operators/features/preinstalls.mdx similarity index 100% rename from pages/operators/chain-operators/features/preinstalls.mdx rename to pages/chain-operators/features/preinstalls.mdx diff --git a/pages/operators/chain-operators/features/span-batches.mdx b/pages/chain-operators/features/span-batches.mdx similarity index 100% rename from pages/operators/chain-operators/features/span-batches.mdx rename to pages/chain-operators/features/span-batches.mdx diff --git a/pages/operators/chain-operators/management/best-practices.mdx b/pages/chain-operators/guides/best-practices.mdx similarity index 100% rename from pages/operators/chain-operators/management/best-practices.mdx rename to pages/chain-operators/guides/best-practices.mdx diff --git a/pages/operators/chain-operators/configuration/batcher.mdx b/pages/chain-operators/guides/configuration/batcher.mdx similarity index 100% rename from pages/operators/chain-operators/configuration/batcher.mdx rename to pages/chain-operators/guides/configuration/batcher.mdx diff --git a/pages/chain-operators/guides/configuration/meta.json b/pages/chain-operators/guides/configuration/meta.json new file mode 100644 index 000000000..1a679cd94 --- /dev/null +++ b/pages/chain-operators/guides/configuration/meta.json @@ -0,0 +1,6 @@ +{ + "batcher": "Batcher configuration", + "overview": "Chain Operator Configurations", + "proposer": "Proposer Configuration", + "rollup": "Rollup deployment configuration" +} diff --git a/pages/operators/chain-operators/configuration/overview.mdx b/pages/chain-operators/guides/configuration/overview.mdx similarity index 100% rename from pages/operators/chain-operators/configuration/overview.mdx rename to pages/chain-operators/guides/configuration/overview.mdx diff --git a/pages/operators/chain-operators/configuration/proposer.mdx b/pages/chain-operators/guides/configuration/proposer.mdx similarity index 100% rename from pages/operators/chain-operators/configuration/proposer.mdx rename to pages/chain-operators/guides/configuration/proposer.mdx diff --git a/pages/operators/chain-operators/configuration/rollup.mdx b/pages/chain-operators/guides/configuration/rollup.mdx similarity index 100% rename from pages/operators/chain-operators/configuration/rollup.mdx rename to pages/chain-operators/guides/configuration/rollup.mdx diff --git a/pages/operators/chain-operators/deploy/genesis.mdx b/pages/chain-operators/guides/deployment/genesis.mdx similarity index 100% rename from pages/operators/chain-operators/deploy/genesis.mdx rename to pages/chain-operators/guides/deployment/genesis.mdx diff --git a/pages/chain-operators/guides/deployment/meta.json b/pages/chain-operators/guides/deployment/meta.json new file mode 100644 index 000000000..6b03e43bc --- /dev/null +++ b/pages/chain-operators/guides/deployment/meta.json @@ -0,0 +1,8 @@ +{ + "genesis": "Chain artifacts creation", + "overview": "Deployment overview", + "proposer-setup-guide": "Spinning up the proposer", + "sequencer-node": "Spinning up the sequencer", + "spin-batcher": "Spinning up the batcher", + "validate-deployment": "Validate your contract deployment" +} diff --git a/pages/operators/chain-operators/deploy/overview.mdx b/pages/chain-operators/guides/deployment/overview.mdx similarity index 100% rename from pages/operators/chain-operators/deploy/overview.mdx rename to pages/chain-operators/guides/deployment/overview.mdx diff --git a/pages/operators/chain-operators/deploy/proposer-setup-guide.mdx b/pages/chain-operators/guides/deployment/proposer-setup-guide.mdx similarity index 98% rename from pages/operators/chain-operators/deploy/proposer-setup-guide.mdx rename to pages/chain-operators/guides/deployment/proposer-setup-guide.mdx index 9304936e1..734d9771a 100644 --- a/pages/operators/chain-operators/deploy/proposer-setup-guide.mdx +++ b/pages/chain-operators/guides/deployment/proposer-setup-guide.mdx @@ -71,7 +71,7 @@ just ``` - This uses `op-proposer/v1.10.0` which is compatible with op-node/v1.13.3 and op-geth/v1.101511.1 from [spinning up the sequencer guide](/operators/chain-operators/deploy/sequencer-node). + This uses `op-proposer/v1.10.0` which is compatible with op-node/v1.13.3 and op-geth/v1.101511.0 from [spinning up the sequencer guide](/operators/chain-operators/deploy/sequencer-node). Always check the [release notes](https://github.com/ethereum-optimism/optimism/releases) for compatibility. @@ -111,7 +111,7 @@ cd proposer-node cp ../.deployer/state.json . # Extract the DisputeGameFactory address -GAME_FACTORY_ADDRESS=$(cat state.json | jq -r '.opChainDeployments[0].DisputeGameFactoryProxy') +GAME_FACTORY_ADDRESS=$(cat state.json | jq -r '.opChainDeployments[0].disputeGameFactoryProxyAddress') echo "DisputeGameFactory Address: $GAME_FACTORY_ADDRESS" ``` @@ -137,7 +137,7 @@ ROLLUP_RPC_URL=http://localhost:8547 GAME_FACTORY_ADDRESS=YOUR_ACTUAL_GAME_FACTORY_ADDRESS # Private key - Replace with your actual private key -PRIVATE_KEY=YOUR_ACTUAL_PRIVATE_KEY +PRIVATE_KEY=0xYOUR_ACTUAL_PRIVATE_KEY # Proposer configuration PROPOSAL_INTERVAL=3600s diff --git a/pages/chain-operators/guides/deployment/sequencer-node.mdx b/pages/chain-operators/guides/deployment/sequencer-node.mdx new file mode 100644 index 000000000..5aa70cd7f --- /dev/null +++ b/pages/chain-operators/guides/deployment/sequencer-node.mdx @@ -0,0 +1,594 @@ +--- +title: Spinning up the sequencer +lang: en-US +description: Spin up a single sequencer node after verifying L1 smart-contract deployment. +content_type: tutorial +topic: spinning sequencer +personas: + - chain-operator + - node-operator + - protocol-developer +categories: + - chain-operation + - chain-deployment + - node-management + - sequencer-configuration + - op-stack +is_imported_content: 'false' +--- + +import { Callout, Steps } from 'nextra/components' + +## Overview + +This guide provides step-by-step instructions for spinning up a sequencer node after deploying L1 smart contracts for your OP Stack chain with [`op-deployer`](/operators/chain-operators/tools/op-deployer). + +A sequencer node consists of two core components: + +* **op-geth**: Execution layer that processes transactions and maintains state +* **op-node**: Consensus layer that orders transactions and creates L2 blocks + +The sequencer is responsible for: + +* Ordering transactions from users +* Building L2 blocks +* Signing blocks on the P2P network + +## Prerequisites + +### Essential requirements + +Before spinning up your sequencer, complete the following steps: + +**1. Successful L1 contract deployment:** + +* Deployed L1 contracts using [`op-deployer apply`](/operators/chain-operators/tools/op-deployer#apply-deploy-your-chain) command. +* Generated genesis and rollup configuration files using: + ```bash + op-deployer inspect genesis --workdir .deployer > .deployer/genesis.json + op-deployer inspect rollup --workdir .deployer > .deployer/rollup.json + ``` + +**2. Required configuration files:** + +* `genesis.json` - L2 genesis file for initializing op-geth +* `rollup.json` - Rollup configuration file for op-node +* Access to your deployment `state.json` file from op-deployer + +**3. L1 network access:** + +* L1 RPC endpoint (Ethereum, Sepolia, etc.) +* L1 Beacon node endpoint + +### Software requirements + +* Git (for cloning repositories) +* Go 1.21+ (if building from source) +* Docker and Docker Compose (optional but recommended) +* OpenSSL for JWT secret generation + +### Finding the current stable releases + +To ensure you're using the latest compatible versions of OP Stack components, always check the official releases page: + +**[release page](https://github.com/ethereum-optimism/optimism/releases)** + +The main components you'll need for sequencer deployment are: + +* **op-node**: Look for the latest `op-node/v*` release +* **op-geth**: Look for the latest `op-geth/v*` [release](https://github.com/ethereum-optimism/op-geth/releases) + + +The versions used in this guide (**op-node/v1.13.3** and **op-geth/v1.101511.0**) are verified compatible versions. + +According to the **op-node v1.13.3** [release notes](https://github.com/ethereum-optimism/optimism/releases/tag/op-node%2Fv1.13.3), this op-node version specifically corresponds to **op-geth v1.101511.0**. +Always check the release notes to ensure you're using compatible versions. + + +## Software installation + +For spinning up a sequencer, we recommend **building from source** as it provides better control, and helps with debugging. +In this guide, a Docker alternative is also provided. + +### Build from source (Recommended) + +Building from source gives you full control over the binaries and is the preferred approach for this guide. + +#### 1. Clone and build op-node + +```bash +# Clone the optimism monorepo +git clone https://github.com/ethereum-optimism/optimism.git +cd optimism + +# Checkout the latest release tag +git checkout op-node/v1.13.3 + +# Build op-node +cd op-node +just + +# Binary will be available at ./bin/op-node +``` + +#### 2. Clone and build op-geth + +```bash +# Clone op-geth repository (in a separate directory) +git clone https://github.com/ethereum-optimism/op-geth.git +cd op-geth + +# Checkout to this release tag +git checkout v1.101511.0 + +# Build op-geth +make geth + +# Binary will be available at ./build/bin/geth +``` + +### Verify installation + +Check that you have properly installed the needed components. + +```bash +# Make sure you're in the right directory +./bin/op-node --version +./build/bin/geth version +``` + +## Configuration setup + +### 1. Organize your workspace + +After building the binaries, you should have the following directory structure: + +``` +~/ +├── optimism/ # Optimism monorepo +│ └── op-node/ +│ └── bin/ +│ └── op-node # Built binary +├── op-geth/ # OP-Geth repository +│ └── build/ +│ └── bin/ +│ └── geth # Built binary +└── .deployer/ # From op-deployer + ├── genesis.json + └── rollup.json +``` + +Now create your sequencer working directory. We recommend creating it at the same level for easy path references: + +```bash +# Create sequencer directory at the root level +mkdir ~/sequencer-node +cd ~/sequencer-node +``` + +
+ Alternative: Copy binaries to sequencer directory + + If you prefer to keep binaries close to your configuration, you can copy them: + + ```bash + mkdir ~/sequencer-node/bin + cp ~/optimism/op-node/bin/op-node ~/sequencer-node/bin/ + cp ~/op-geth/build/bin/geth ~/sequencer-node/bin/ + + # Then update scripts to use: + # ./bin/geth + # ./bin/op-node + ``` +
+ +### 2. Generate JWT secret + +```bash +# Generate JWT secret in the sequencer directory +openssl rand -hex 32 > jwt.txt + +# Set appropriate permissions +chmod 600 jwt.txt +``` + +### 3. Set up directory structure and copy files + +In this guide, we're going to be using the binaries from their original build locations, we only need to create directories for configuration files and scripts. + +```bash +# Create scripts directory +mkdir scripts + +# Copy configuration files from op-deployer +cp ~/.deployer/genesis.json . +cp ~/.deployer/rollup.json . +``` + +Your final directory structure should look like: + +```bash +~/sequencer-node/ +├── jwt.txt +├── genesis.json +├── rollup.json +└── scripts/ + ├── start-op-geth.sh # (to be created) + └── start-op-node.sh # (to be created) +``` + +### 4. Environment variables + +You'll need to gather several pieces of information before creating your configuration. Here's where to get each value: + +### Get L1 network access + +You need access to the L1 network (Ethereum mainnet or Sepolia testnet) and its beacon node: + +**L1 RPC URL options:** + +* **Infura**: [infura.io](https://infura.io) - Requires an API key from a project +* **Alchemy**: [alchemy.com](https://alchemy.com) - Requires an API key from an app + +**L1 Beacon URL options:** + +* **Public beacon APIs**: `https://ethereum-sepolia-beacon-api.publicnode.com` (Sepolia) or `https://ethereum-beacon-api.publicnode.com` (Mainnet) +* **Infura beacon**: `https://sepolia.infura.io/v3/YOUR_KEY` (if your Infura plan includes beacon access) + +### Get private key from your wallet + +For this basic sequencer setup, you only need a private key during op-node initialization. + +### Get your public IP address + +```bash +# Find your public IP address, once you get it, update the P2P_ADVERTISE_IP in your .env +curl ifconfig.me +# or +curl ipinfo.io/ip +``` + +### Choose your ports + +The default ports are standard but can be changed if needed: + +* `8545`: op-geth HTTP RPC (standard Ethereum RPC port) +* `8546`: op-geth WebSocket RPC +* `8551`: op-geth Auth RPC (for op-node communication) +* `8547`: op-node RPC +* `9222`: P2P networking (must be open on firewall) + + + +Now create your `.env` file with the actual values: + +```bash +# Create .env file with your actual values +# L1 Configuration - Replace with your actual RPC URLs +L1_RPC_URL=https://sepolia.infura.io/v3/YOUR_ACTUAL_INFURA_KEY +L1_BEACON_URL=https://ethereum-sepolia-beacon-api.publicnode.com + +# Sequencer configuration +SEQUENCER_ENABLED=true +SEQUENCER_STOPPED=false + +# Private keys +PRIVATE_KEY=0xYOUR_ACTUAL_PRIVATE_KEY + +# P2P configuration - Replace with your actual public IP +P2P_LISTEN_PORT=9222 +P2P_ADVERTISE_IP=YOUR_ACTUAL_PUBLIC_IP + +# RPC configuration (can customize ports if needed) +OP_NODE_RPC_PORT=8547 +OP_GETH_HTTP_PORT=8545 +OP_GETH_WS_PORT=8546 +OP_GETH_AUTH_PORT=8551 + +# JWT secret location +JWT_SECRET=./jwt.txt +``` + +**Important**: Replace ALL placeholder values (`YOUR_ACTUAL_*`) with your real configuration values. + +## Sequencer specific configuration + +### op-geth configuration for sequencer + +Create `scripts/start-op-geth.sh`: + +```bash +#!/bin/bash +source .env + +# Path to the op-geth binary we built +../op-geth/build/bin/geth \ + --datadir=./op-geth-data \ + --http \ + --http.addr=0.0.0.0 \ + --http.port=$OP_GETH_HTTP_PORT \ + --http.vhosts="*" \ + --http.corsdomain="*" \ + --http.api=eth,net,web3,debug,txpool,admin \ + --ws \ + --ws.addr=0.0.0.0 \ + --ws.port=$OP_GETH_WS_PORT \ + --ws.origins="*" \ + --ws.api=eth,net,web3,debug,txpool,admin \ + --authrpc.addr=0.0.0.0 \ + --authrpc.port=$OP_GETH_AUTH_PORT \ + --authrpc.vhosts="*" \ + --authrpc.jwtsecret=$JWT_SECRET \ + --syncmode=full \ + --gcmode=archive \ + --rollup.disabletxpoolgossip=true \ + --rollup.sequencerhttp=http://localhost:$OP_NODE_RPC_PORT +``` + +### op-node configuration for sequencer + +Create `scripts/start-op-node.sh`: + +```bash +#!/bin/bash + +source .env + +# Path to the op-node binary we built +../optimism/op-node/bin/op-node \ + --l1=$L1_RPC_URL \ + --l1.beacon=$L1_BEACON_URL \ + --l2=http://localhost:$OP_GETH_AUTH_PORT \ + --l2.jwt-secret=$JWT_SECRET \ + --rollup.config=./rollup.json \ + --sequencer.enabled=$SEQUENCER_ENABLED \ + --sequencer.stopped=$SEQUENCER_STOPPED \ + --sequencer.max-safe-lag=3600 \ + --verifier.l1-confs=4 \ + --p2p.listen.ip=0.0.0.0 \ + --p2p.listen.tcp=$P2P_LISTEN_PORT \ + --p2p.listen.udp=$P2P_LISTEN_PORT \ + --p2p.advertise.ip=$P2P_ADVERTISE_IP \ + --p2p.advertise.tcp=$P2P_LISTEN_PORT \ + --p2p.advertise.udp=$P2P_LISTEN_PORT \ + --p2p.sequencer.key=$PRIVATE_KEY \ + --rpc.addr=0.0.0.0 \ + --rpc.port=$OP_NODE_RPC_PORT \ + --rpc.enable-admin \ + --log.level=info \ + --log.format=json +``` + +## Initializing and starting the sequencer + + + +### Initialize op-geth with your genesis file + +```bash +# Make sure you're in the sequencer-node directory +cd ~/sequencer-node + +# Initialize op-geth with your genesis file +../op-geth/build/bin/geth init --datadir=./op-geth-data --state.scheme=hash ./genesis.json +``` + +### Start op-geth + +```bash +# Make scripts executable +chmod +x scripts/start-op-geth.sh +chmod +x scripts/start-op-node.sh + +# Start op-geth in the background or in a separate terminal +./scripts/start-op-geth.sh +``` + +**Note**: You should see output indicating that op-geth is starting and listening on the configured ports. + +### Start op-node + +```bash +# In a separate terminal, navigate to the sequencer directory +cd ~/sequencer-node + +# Start op-node +./scripts/start-op-node.sh +``` + +### Verify sequencer is running + +Once both services are running, verify they're working correctly: + +```bash +# Check op-geth is responding, do this in another terminal +curl -X POST -H "Content-Type: application/json" \ + --data '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}' \ + http://localhost:8545 + +# Check sequencer status +curl -X POST -H "Content-Type: application/json" \ + --data '{"jsonrpc":"2.0","method":"admin_sequencerActive","params":[],"id":1}' \ + http://localhost:8547 +``` + + + +Your sequencer node is now operational and ready to process transactions. + +### Docker alternative (For containerized environments) + +If you prefer containerized deployment, you can use the official Docker images. + +### Complete Docker setup guide + +
+ Complete Docker setup guide + + If you choose the Docker approach, you'll need to: + + 1. **Set up directory structure and copy configuration files:** + + ```bash + # Create your sequencer working directory + mkdir ~/sequencer-node + cd ~/sequencer-node + + # Copy configuration files from op-deployer output + # Note: Adjust the path if your .deployer directory is located elsewhere + cp ~/.deployer/genesis.json . + cp ~/.deployer/rollup.json . + + # Generate JWT secret + openssl rand -hex 32 > jwt.txt + chmod 600 jwt.txt + ``` + + 2. **Create environment variables file:** + + ```bash + # Create .env file with your actual values + cat > .env << 'EOF' + # L1 Configuration - Replace with your actual RPC URLs + L1_RPC_URL=https://sepolia.infura.io/v3/YOUR_ACTUAL_INFURA_KEY + L1_BEACON_URL=https://ethereum-sepolia-beacon-api.publicnode.com + + # Private keys - Replace with your actual private key + PRIVATE_KEY=0xYOUR_ACTUAL_PRIVATE_KEY + + # (Run `curl ifconfig.me` in a separate shell to obtain the value, then paste it below) + + # P2P configuration - Replace with your actual public IP + P2P_ADVERTISE_IP=YOUR_ACTUAL_PUBLIC_IP + + EOF + ``` + + **Important**: Replace ALL placeholder values (`YOUR_ACTUAL_*`) with your real configuration values. + + 3. **Create docker-compose.yml:** + + ```yaml +version: '3.8' + +services: + op-geth: + image: us-docker.pkg.dev/oplabs-tools-artifacts/images/op-geth:v1.101511.0 + volumes: + # Mount entire directory to avoid file mounting issues + - .:/workspace + working_dir: /workspace + ports: + - "8545:8545" + - "8546:8546" + - "8551:8551" + command: + - "--datadir=/workspace/op-geth-data" + - "--http" + - "--http.addr=0.0.0.0" + - "--http.port=8545" + - "--ws" + - "--ws.addr=0.0.0.0" + - "--ws.port=8546" + - "--authrpc.addr=0.0.0.0" + - "--authrpc.port=8551" + - "--authrpc.jwtsecret=/workspace/jwt.txt" + - "--syncmode=full" + - "--gcmode=archive" + - "--rollup.disabletxpoolgossip=true" + - "--rollup.sequencerhttp=http://op-node:8547" + - "--http.vhosts=*" + - "--http.corsdomain=*" + - "--http.api=eth,net,web3,debug,txpool,admin" + - "--ws.origins=*" + - "--ws.api=eth,net,web3,debug,txpool,admin" + - "--authrpc.vhosts=*" + + op-node: + image: us-docker.pkg.dev/oplabs-tools-artifacts/images/op-node:v1.13.3 + depends_on: + - op-geth + volumes: + - .:/workspace + working_dir: /workspace + ports: + - "8547:8547" + - "9222:9222" + environment: + - L1_RPC_URL=${L1_RPC_URL} + - L1_BEACON_URL=${L1_BEACON_URL} + - PRIVATE_KEY=${PRIVATE_KEY} + - P2P_ADVERTISE_IP=${P2P_ADVERTISE_IP} + command: + - "op-node" + - "--l1=${L1_RPC_URL}" + - "--l1.beacon=${L1_BEACON_URL}" + - "--l2=http://op-geth:8551" + - "--l2.jwt-secret=/workspace/jwt.txt" + - "--rollup.config=/workspace/rollup.json" + - "--sequencer.enabled=true" + - "--sequencer.stopped=false" + - "--sequencer.max-safe-lag=3600" + - "--verifier.l1-confs=4" + - "--p2p.listen.ip=0.0.0.0" + - "--p2p.listen.tcp=9222" + - "--p2p.listen.udp=9222" + - "--p2p.advertise.ip=${P2P_ADVERTISE_IP}" + - "--p2p.advertise.tcp=9222" + - "--p2p.advertise.udp=9222" + - "--p2p.sequencer.key=${PRIVATE_KEY}" + - "--rpc.addr=0.0.0.0" + - "--rpc.port=8547" + - "--rpc.enable-admin" + - "--log.level=info" + - "--log.format=json" + ``` + + 4. **Initialize op-geth with Docker:** + + ```bash + # Make sure you're in the sequencer-node directory with all files copied + cd ~/sequencer-node + + # Initialize op-geth using Docker + docker run --rm \ + -v $(pwd):/workspace \ + -w /workspace \ + us-docker.pkg.dev/oplabs-tools-artifacts/images/op-geth:v1.101511.0 \ + init --datadir=./op-geth-data --state.scheme=hash ./genesis.json + ``` + + 5. **Start the services:** + + ```bash + # Start both services + docker-compose up -d + + # View logs + docker-compose logs -f + ``` + + 6. **Final directory structure:** + + ```bash + ~/sequencer-node/ + ├── jwt.txt # Generated JWT secret + ├── genesis.json # Copied from ~/.deployer/ + ├── rollup.json # Copied from ~/.deployer/ + ├── .env # Environment variables + ├── docker-compose.yml # Docker configuration + └── op-geth-data/ # Created by Docker during initialization + ├── geth/ # Geth data + └── keystore/ # Key files + ``` + +
+ +Your sequencer node is now operational and ready to process transactions. + +## Next steps + +* Discover how to [deploy chains with op-deployer](/operators/chain-operators/tools/op-deployer) for standardized OP Stack deployments. +* Learn how to configure and deploy the [batcher](/operators/chain-operators/configuration/batcher) to submit transaction data to L1. +* Set up the [proposer](/operators/chain-operators/configuration/proposer) to submit output roots for withdrawals. +* Explore chain operator [best practices](/operators/chain-operators/management/best-practices) for production deployments. diff --git a/pages/operators/chain-operators/deploy/spin-batcher.mdx b/pages/chain-operators/guides/deployment/spin-batcher.mdx similarity index 54% rename from pages/operators/chain-operators/deploy/spin-batcher.mdx rename to pages/chain-operators/guides/deployment/spin-batcher.mdx index 2e499319f..92b27e69b 100644 --- a/pages/operators/chain-operators/deploy/spin-batcher.mdx +++ b/pages/chain-operators/guides/deployment/spin-batcher.mdx @@ -113,7 +113,7 @@ If you prefer containerized deployment, you can use the official Docker images. cp ~/.deployer/state.json . # Extract the BatchInbox address - BATCH_INBOX_ADDRESS=$(cat state.json | jq -r '.opChainDeployments[0].SystemConfigProxy') + BATCH_INBOX_ADDRESS=$(cat state.json | jq -r '.opChainDeployments[0].systemConfigProxyAddress') echo "BatchInbox Address: $BATCH_INBOX_ADDRESS" ``` @@ -126,14 +126,14 @@ If you prefer containerized deployment, you can use the official Docker images. L1_RPC_URL=https://sepolia.infura.io/v3/YOUR_ACTUAL_INFURA_KEY # L2 Configuration - Should match your sequencer setup - L2_RPC_URL=http://op-geth:8545 - ROLLUP_RPC_URL=http://op-node:8547 + L2_RPC_URL=http://sequencer-node:8545 + ROLLUP_RPC_URL=http://sequencer-node:8547 # Contract addresses - Extract from your op-deployer output BATCH_INBOX_ADDRESS=YOUR_ACTUAL_BATCH_INBOX_ADDRESS # Private key - Replace with your actual private key - BATCHER_PRIVATE_KEY=YOUR_ACTUAL_PRIVATE_KEY + BATCHER_PRIVATE_KEY=0xYOUR_ACTUAL_PRIVATE_KEY # Batcher configuration POLL_INTERVAL=1s @@ -158,6 +158,7 @@ If you prefer containerized deployment, you can use the official Docker images. ```yaml + version: '3.8' services: op-batcher: @@ -231,6 +232,212 @@ services: If you chose Docker, refer to the collapsible section. +## Configuration setup + +### 1. Organize your workspace + +Create your batcher working directory: + +```bash +# Create batcher directory at the same level as your sequencer +mkdir batcher-node +cd batcher-node + +# Create scripts directory +mkdir scripts +``` + +Your final directory structure should look like: + +```bash +~/ +├── optimism/ # Contains op-batcher binary +├── sequencer-node/ # Your sequencer setup +├── proposer-node/ # Your proposer setup +├── .deployer/ # From op-deployer +│ └── state.json +└── batcher-node/ # Your batcher working directory + ├── state.json # Copied from .deployer + ├── .env + └── scripts/ + └── start-batcher.sh +``` + +### 2. Extract `BatchInbox` address + +Extract the `BatchInbox` contract address from your op-deployer output: + +```bash +# Navigate to batcher directory +cd ~/batcher-node + +# Copy the deployment state file from op-deployer +# Update the path if your .deployer directory is located elsewhere +cp ../.deployer/state.json . + +# Extract the BatchInbox address +BATCH_INBOX_ADDRESS=$(cat state.json | jq -r '.opChainDeployments[0].systemConfigProxyAddress') +echo "BatchInbox Address: $BATCH_INBOX_ADDRESS" +``` + + + The batcher submits transaction batches to the `BatchInbox` contract on L1. This contract is responsible for accepting and storing L2 transaction data. + + +### 3. Set up environment variables + +Create your `.env` file with the actual values: + +```bash +# Create .env file with your actual values +# L1 Configuration - Replace with your actual RPC URL +L1_RPC_URL=https://sepolia.infura.io/v3/YOUR_ACTUAL_INFURA_KEY + +# L2 Configuration - Should match your sequencer setup +L2_RPC_URL=http://localhost:8545 +ROLLUP_RPC_URL=http://localhost:8547 + +# Contract addresses - Extract from your op-deployer output +BATCH_INBOX_ADDRESS=YOUR_ACTUAL_BATCH_INBOX_ADDRESS + +# Private key - Replace with your actual private key +BATCHER_PRIVATE_KEY=0xYOUR_ACTUAL_PRIVATE_KEY + +# Batcher configuration +POLL_INTERVAL=1s +SUB_SAFETY_MARGIN=6 +NUM_CONFIRMATIONS=1 +SAFE_ABORT_NONCE_TOO_LOW_COUNT=3 +RESUBMISSION_TIMEOUT=30s +MAX_CHANNEL_DURATION=25 + +# RPC configuration +BATCHER_RPC_PORT=8548 +``` + +**Important**: Replace ALL placeholder values (`YOUR_ACTUAL_*`) with your real configuration values! + +### 4. Get your private key + +Get a private key from your wallet that will be used for submitting batches to L1. This account needs sufficient ETH to pay for L1 gas costs. + + + The batcher account needs to be funded with ETH on L1 to pay for batch submission transactions. Monitor this account's balance regularly as it will consume ETH for each batch submission. + + +## Batcher configuration + +Create `scripts/start-batcher.sh`: + +```bash +#!/bin/bash + +source .env + +# Path to the op-batcher binary we built +../optimism/op-batcher/bin/op-batcher \ + --l2-eth-rpc=$L2_RPC_URL \ + --rollup-rpc=$ROLLUP_RPC_URL \ + --poll-interval=$POLL_INTERVAL \ + --sub-safety-margin=$SUB_SAFETY_MARGIN \ + --num-confirmations=$NUM_CONFIRMATIONS \ + --safe-abort-nonce-too-low-count=$SAFE_ABORT_NONCE_TOO_LOW_COUNT \ + --resubmission-timeout=$RESUBMISSION_TIMEOUT \ + --rpc.addr=0.0.0.0 \ + --rpc.port=$BATCHER_RPC_PORT \ + --rpc.enable-admin \ + --max-channel-duration=$MAX_CHANNEL_DURATION \ + --l1-eth-rpc=$L1_RPC_URL \ + --private-key=$BATCHER_PRIVATE_KEY \ + --batch-type=1 \ + --data-availability-type=blobs \ + --compress \ + --log.level=info +``` + +### Batcher parameters explained + +* **`--poll-interval`**: How frequently the batcher checks for new L2 blocks to batch +* **`--sub-safety-margin`**: Number of confirmations to wait before considering L1 transactions safe +* **`--max-channel-duration`**: Maximum time (in L1 blocks) to keep a channel open +* **`--batch-type`**: Type of batch encoding (1 for span batches, 0 for singular batches) +* **`--data-availability-type`**: Whether to use blobs or calldata for data availability +* **`--compress`**: Enable compression to reduce L1 data costs + +## Starting the batcher + +### 1. Verify prerequisites + +Ensure your sequencer and rollup node are running: + + + ### Test L1 connectivity + + ```bash + # Note: Make sure you have exported these environment variables to your current shell session: + # export L1_RPC_URL="https://sepolia.infura.io/v3/YOUR_KEY" + # export L2_RPC_URL="http://localhost:8545" + # export ROLLUP_RPC_URL="http://localhost:8547" + + curl -X POST -H "Content-Type: application/json" \ + --data '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}' \ + $L1_RPC_URL + ``` + + ### Test L2 connectivity + + ```bash + curl -X POST -H "Content-Type: application/json" \ + --data '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}' \ + $L2_RPC_URL + ``` + + ### Test rollup node connectivity + + ```bash + curl -X POST -H "Content-Type: application/json" \ + --data '{"jsonrpc":"2.0","method":"optimism_syncStatus","params":[],"id":1}' \ + $ROLLUP_RPC_URL + ``` + + +### 2. Start the batcher + +```bash +# Make the script executable +chmod +x scripts/start-batcher.sh + +# Start the batcher +./scripts/start-batcher.sh +``` + +## Verification + +Verify your batcher is working correctly: + +### Check batcher status + +```bash +# Check batcher RPC is responding +curl -X POST -H "Content-Type: application/json" \ + --data '{"jsonrpc":"2.0","method":"admin_startBatcher","params":[],"id":1}' \ + http://localhost:8548 + +# Monitor batch submission activity (check L1 for recent transactions from your batcher address) +# Replace with your actual batcher address +curl -X POST -H "Content-Type: application/json" \ + --data '{"jsonrpc":"2.0","method":"eth_getTransactionCount","params":["0xYOUR_BATCHER_ADDRESS","latest"],"id":1}' \ + $L1_RPC_URL + +# Check if your batcher address has enough ETH for gas +curl -X POST -H "Content-Type: application/json" \ + --data '{"jsonrpc":"2.0","method":"eth_getBalance","params":["0xYOUR_BATCHER_ADDRESS","latest"],"id":1}' \ + $L1_RPC_URL +``` + + + For detailed cost analysis and optimization strategies, refer to the [Fee calculation tools](/operators/chain-operators/tools/fee-calculator). + ## Next steps diff --git a/pages/operators/chain-operators/deploy/validate-deployment.mdx b/pages/chain-operators/guides/deployment/validate-deployment.mdx similarity index 100% rename from pages/operators/chain-operators/deploy/validate-deployment.mdx rename to pages/chain-operators/guides/deployment/validate-deployment.mdx diff --git a/pages/stack/beta-features/alt-da-mode.mdx b/pages/chain-operators/guides/features/alt-da-mode.mdx similarity index 100% rename from pages/stack/beta-features/alt-da-mode.mdx rename to pages/chain-operators/guides/features/alt-da-mode.mdx diff --git a/pages/chain-operators/guides/features/meta.json b/pages/chain-operators/guides/features/meta.json new file mode 100644 index 000000000..591075190 --- /dev/null +++ b/pages/chain-operators/guides/features/meta.json @@ -0,0 +1,3 @@ +{ + "alt-da-mode": "Alt-DA Mode Explainer" +} diff --git a/pages/operators/chain-operators/management/blobs.mdx b/pages/chain-operators/guides/management/blobs.mdx similarity index 100% rename from pages/operators/chain-operators/management/blobs.mdx rename to pages/chain-operators/guides/management/blobs.mdx diff --git a/pages/operators/chain-operators/management/key-management.mdx b/pages/chain-operators/guides/management/key-management.mdx similarity index 100% rename from pages/operators/chain-operators/management/key-management.mdx rename to pages/chain-operators/guides/management/key-management.mdx diff --git a/pages/chain-operators/guides/management/meta.json b/pages/chain-operators/guides/management/meta.json new file mode 100644 index 000000000..a626f5456 --- /dev/null +++ b/pages/chain-operators/guides/management/meta.json @@ -0,0 +1,7 @@ +{ + "blobs": "Using Blobs", + "key-management": "Key management", + "operations": "Rollup operations", + "snap-sync": "Using snap sync for chain operators", + "troubleshooting": "Troubleshooting chain operations" +} diff --git a/pages/operators/chain-operators/management/operations.mdx b/pages/chain-operators/guides/management/operations.mdx similarity index 100% rename from pages/operators/chain-operators/management/operations.mdx rename to pages/chain-operators/guides/management/operations.mdx diff --git a/pages/operators/chain-operators/management/snap-sync.mdx b/pages/chain-operators/guides/management/snap-sync.mdx similarity index 100% rename from pages/operators/chain-operators/management/snap-sync.mdx rename to pages/chain-operators/guides/management/snap-sync.mdx diff --git a/pages/operators/chain-operators/management/troubleshooting.mdx b/pages/chain-operators/guides/management/troubleshooting.mdx similarity index 100% rename from pages/operators/chain-operators/management/troubleshooting.mdx rename to pages/chain-operators/guides/management/troubleshooting.mdx diff --git a/pages/chain-operators/guides/meta.json b/pages/chain-operators/guides/meta.json new file mode 100644 index 000000000..6d1b1e120 --- /dev/null +++ b/pages/chain-operators/guides/meta.json @@ -0,0 +1,3 @@ +{ + "best-practices": "Chain operator best practices" +} diff --git a/pages/chain-operators/guides/smart-contracts/meta.json b/pages/chain-operators/guides/smart-contracts/meta.json new file mode 100644 index 000000000..475533789 --- /dev/null +++ b/pages/chain-operators/guides/smart-contracts/meta.json @@ -0,0 +1,7 @@ +{ + "op-deployer-upgrade": "Upgrade L1 contracts using op-deployer", + "overview": "Smart Contract overview", + "smart-contracts": "Smart contract deployment", + "superchain-ops-guide": "Upgrade using superchain-ops", + "upgrade-op-contracts-1-3-1-8": "Upgrading Smart Contracts from v1.3.0 to v1.8.0" +} diff --git a/pages/stack/smart-contracts/op-deployer-upgrade.mdx b/pages/chain-operators/guides/smart-contracts/op-deployer-upgrade.mdx similarity index 100% rename from pages/stack/smart-contracts/op-deployer-upgrade.mdx rename to pages/chain-operators/guides/smart-contracts/op-deployer-upgrade.mdx diff --git a/pages/stack/smart-contracts/smart-contracts.mdx b/pages/chain-operators/guides/smart-contracts/overview.mdx similarity index 100% rename from pages/stack/smart-contracts/smart-contracts.mdx rename to pages/chain-operators/guides/smart-contracts/overview.mdx diff --git a/pages/operators/chain-operators/deploy/smart-contracts.mdx b/pages/chain-operators/guides/smart-contracts/smart-contracts.mdx similarity index 100% rename from pages/operators/chain-operators/deploy/smart-contracts.mdx rename to pages/chain-operators/guides/smart-contracts/smart-contracts.mdx diff --git a/pages/stack/smart-contracts/superchain-ops-guide.mdx b/pages/chain-operators/guides/smart-contracts/superchain-ops-guide.mdx similarity index 51% rename from pages/stack/smart-contracts/superchain-ops-guide.mdx rename to pages/chain-operators/guides/smart-contracts/superchain-ops-guide.mdx index 228af7676..b18b8399a 100644 --- a/pages/stack/smart-contracts/superchain-ops-guide.mdx +++ b/pages/chain-operators/guides/smart-contracts/superchain-ops-guide.mdx @@ -22,9 +22,9 @@ import { Callout } from 'nextra/components' # Upgrade using superchain-ops -This guide outlines the process for upgrading Optimism chains using the `superchain-ops` repository. It's intended primarily for chains that are part of the Superchain, those with the Foundation or Security Council as signers, and/or chains requiring a highly secure process. +This guide outlines the process for upgrading Optimism chains using the `superchain-ops` repository. It's intended primarily for chains that are part of the Superchain, those with the Foundation or Security Council as signers, and/or chains requiring a highly secure and manual process. -For chains that don't require the enhanced security of superchain-ops or security council signing, you can instead use [op-deployer](/stack/smart-contracts/op-deployer-upgrade) to upgrade your chain. +For chains that don't require a secure upgrade process or security council signing, you can instead use [op-deployer](/stack/smart-contracts/op-deployer-upgrade) to upgrade your chain. For non-Optimism governed chains, you can use [op-deployer](/stack/smart-contracts/op-deployer-upgrade) and your own tooling to upgrade your chain. @@ -38,7 +38,7 @@ For non-Optimism governed chains, you can use [op-deployer](/stack/smart-contrac 2. **Chains with Foundation or Security Council as signers**: If your chain has the Foundation multi-sig or Security Council as signers, your upgrade tasks should go through `superchain-ops`. -3. **Chains requiring a highly secure process**: For chains that prioritize security over automation, `superchain-ops` provides an intentionally manual workflow with thorough verification steps (e.g. EVM state diff inspection). +3. **Chains requiring a highly secure and manual process**: For chains that prioritize security over automation, `superchain-ops` provides an intentionally manual workflow with thorough verification steps. For chains that don't fall into these categories, you'll need to generate appropriate call data for upgrades through other means or develop your own upgrade process for non-OPCM upgrades. @@ -46,45 +46,44 @@ For chains that don't fall into these categories, you'll need to generate approp `superchain-ops` uses two key concepts: -* **Templates**: Define what the upgrade is and contain the code for specific upgrade paths (e.g., [`op-contracts/v1.8.0` to `op-contracts/v2.0.0`](https://github.com/ethereum-optimism/superchain-ops/blob/main/src/improvements/template/OPCMUpgradeV200.sol)). Templates are version-specific and live in the [/src/improvements/template](https://github.com/ethereum-optimism/superchain-ops/tree/main/src/improvements/template) directory. +* **Templates**: Define what the upgrade is and contain the code for specific upgrade paths (e.g., 1.8 to 2.0). Templates are version-specific and live in the [/src/improvements/template](https://github.com/ethereum-optimism/superchain-ops/tree/main/src/improvements/template) directory. -* **Tasks**: Use a template to define a specific upgrade transaction for a chain. Multiple tasks can use the same template. Tasks are organized by network (`eth` or `sep`) in the [/src/improvements/tasks](https://github.com/ethereum-optimism/superchain-ops/tree/main/src/improvements/tasks) directory. +* **Tasks**: Chain-specific implementations of templates. Multiple tasks can use the same template for different chains. Tasks are organized by network (mainnet or testnet) in the [/src/improvements/tasks](https://github.com/ethereum-optimism/superchain-ops/tree/main/src/improvements/tasks) directory. ## General upgrade process -The following process outlines how to upgrade a chain using `superchain-ops`, using the [`op-contracts/v1.8.0` to `op-contracts/v2.0.0`](https://github.com/ethereum-optimism/superchain-ops/blob/main/src/improvements/template/OPCMUpgradeV200.sol) upgrade as an example. This same pattern applies to other OPCM-based upgrades (like [`op-contracts/v2.0.0` to `op-contracts/v3.0.0`](https://github.com/ethereum-optimism/superchain-ops/blob/main/src/improvements/template/OPCMUpgradeV300.sol)). +The following process outlines how to upgrade a chain using `superchain-ops`, using the 1.8 to 2.0 upgrade as an example. This same pattern applies to other OPCM-based upgrades (like 2.0 to 3.0). ### Step 1: Clone the `superchain-ops` repository ```bash git clone https://github.com/ethereum-optimism/superchain-ops.git -cd superchain-ops/src/improvements +cd superchain-ops ``` -### Step 1a: One-time Install Dependencies Setup -Follow the 'Install Dependencies' instructions in the ['Quick Start'](https://github.com/ethereum-optimism/superchain-ops/blob/main/README.md#quick-start) section of the `README.md` file. - ### Step 2: Create a new task using the quick start ```bash +cd src/improvements/ just new task ``` -Follow the prompts to select the appropriate template (e.g., `OPCMUpgradeV200` for a `op-contracts/v1.8.0` to `op-contracts/v2.0.0` upgrade) and provide the necessary details. +Follow the prompts to select the appropriate template (e.g., `opcm-upgrade-v200` for a 1.8 to 2.0 upgrade) and provide the necessary details. This will create a new task directory containing a `config.toml` and `README` file. The config file will look like this: ```bash l2chains = [] # e.g. [{name = "OP Mainnet", chainId = 10}] templateName = "OPCMUpgradeV200" + ``` ### Step 3: Configure the task -You'll have to add additional properties to your `config.toml` file to fully configure your task. For example, when upgrading from `op-contracts/v1.8.0` to `op-contracts/v2.0.0`, you can look at a previous task for reference: [src/improvements/tasks/eth/002-opcm-upgrade-v200/config.toml](https://github.com/ethereum-optimism/superchain-ops/blob/main/src/improvements/tasks/eth/002-opcm-upgrade-v200/config.toml): +Look through other tasks in the directory to find the information necessary for your upgrade. For example, when upgrading from 1.8 to 2.0, you can look at the [src/improvements/tasks/eth/002-opcm-upgrade-v200/config.toml](https://github.com/ethereum-optimism/superchain-ops/blob/main/src/improvements/tasks/eth/002-opcm-upgrade-v200/config.toml) file to see that your config file should look like the following: - This is an example task. You must figure out which values you'll need for your own specific task. + Ensure you replace all addresses and other values in the example below ```bash @@ -101,7 +100,11 @@ absolutePrestates = [ [addresses] OPCM = "0x026b2F158255Beac46c1E7c6b8BbF29A4b6A7B76" +# Deployed March 27, 2025: https://etherscan.io/tx/0x902ce895f70a72110d40c9a734a26380b2e27c370aae90721cdfa1ac972cfff8 StandardValidatorV200 = "0xecabaeaa1d58261f1579232520c5b460ca58a164" +ChildSafe1 = "0xb0c4C487C5cf6d67807Bc2008c66fa7e2cE744EC" +ChildSafe2 = "0x847B5c174615B1B7fDF770882256e2D3E95b9D92" +ChildSafe3 = "0xc2819DC788505Aac350142A7A707BF9D03E3Bd03" ``` ### Step 5: Simulate the task @@ -109,14 +112,17 @@ StandardValidatorV200 = "0xecabaeaa1d58261f1579232520c5b460ca58a164" Before executing the upgrade, simulate it to ensure everything is configured correctly: ```bash -just --dotenv-path $(pwd)/.env simulate [child-safe-name-depth-1] [child-safe-name-depth-2] -# Both [child-safe-name-depth-1] and [child-safe-name-depth-2] are optional. You'll only need to specify -# [child-safe-name-depth-2] if it's a nested safe and [child-safe-name-depth-2] if it has multiple levels of nesting. -# Omit both arguments if it's a single safe. +just clean && just install +``` + +```bash +# Nested +SIMULATE_WITHOUT_LEDGER=1 just --dotenv-path $(pwd)/.env --justfile ../../../nested.just simulate +# Single +SIMULATE_WITHOUT_LEDGER=1 just --dotenv-path $(pwd)/.env --justfile ../../../single.just simulate ``` -This will run through the upgrade process without actually executing the transaction. -For more information on the simulate command, please reference the [README](https://github.com/ethereum-optimism/superchain-ops/blob/main/README.md#quick-start). +This will run through the upgrade process without actually executing the transactions. ### Step 6: Execute or submit for review diff --git a/pages/stack/smart-contracts/upgrade-op-contracts-1-3-1-8.mdx b/pages/chain-operators/guides/smart-contracts/upgrade-op-contracts-1-3-1-8.mdx similarity index 100% rename from pages/stack/smart-contracts/upgrade-op-contracts-1-3-1-8.mdx rename to pages/chain-operators/guides/smart-contracts/upgrade-op-contracts-1-3-1-8.mdx diff --git a/pages/chain-operators/quickstarts/meta.json b/pages/chain-operators/quickstarts/meta.json new file mode 100644 index 000000000..173bb826a --- /dev/null +++ b/pages/chain-operators/quickstarts/meta.json @@ -0,0 +1,3 @@ +{ + "self-hosted": "How to start a self-hosted chain" +} diff --git a/pages/operators/chain-operators/self-hosted.mdx b/pages/chain-operators/quickstarts/self-hosted.mdx similarity index 98% rename from pages/operators/chain-operators/self-hosted.mdx rename to pages/chain-operators/quickstarts/self-hosted.mdx index 39c8fb050..c7bc895a9 100644 --- a/pages/operators/chain-operators/self-hosted.mdx +++ b/pages/chain-operators/quickstarts/self-hosted.mdx @@ -18,9 +18,6 @@ is_imported_content: 'false' --- import { Callout, Steps } from 'nextra/components' -import { ChainOperatorsBanner } from '../../../components/ChainOperatorsBanner' - - # How to start a self-hosted chain diff --git a/pages/operators/chain-operators/architecture.mdx b/pages/chain-operators/reference/architecture.mdx similarity index 95% rename from pages/operators/chain-operators/architecture.mdx rename to pages/chain-operators/reference/architecture.mdx index 146537c9c..2a9d9a34d 100644 --- a/pages/operators/chain-operators/architecture.mdx +++ b/pages/chain-operators/reference/architecture.mdx @@ -20,10 +20,7 @@ is_imported_content: 'false' import Image from 'next/image' import { Callout } from 'nextra/components' -import {OpProposerDescriptionShort} from '@/content/index.js' -import { ChainOperatorsBanner } from '../../../components/ChainOperatorsBanner' - - +import {OpProposerDescriptionShort} from '@/content/index.js' # Chain architecture @@ -181,7 +178,7 @@ The [op-conductor](/operators/chain-operators/tools/op-conductor) RPC can act as ### op-challenger -The [op-challenger](/operators/chain-operators/deploy/op-challenger) verifies the correctness of the L2 state by challenging invalid state transitions. This ensures the network's security and validity. +The [op-challenger](/operators/chain-operators/tools/op-challenger) verifies the correctness of the L2 state by challenging invalid state transitions. This ensures the network's security and validity. ### Ethereum L1 nodes diff --git a/pages/chain-operators/reference/components/meta.json b/pages/chain-operators/reference/components/meta.json new file mode 100644 index 000000000..f4a81a950 --- /dev/null +++ b/pages/chain-operators/reference/components/meta.json @@ -0,0 +1,3 @@ +{ + "op-supervisor": "OP-Supervisor" +} diff --git a/pages/interop/op-supervisor.mdx b/pages/chain-operators/reference/components/op-supervisor.mdx similarity index 100% rename from pages/interop/op-supervisor.mdx rename to pages/chain-operators/reference/components/op-supervisor.mdx diff --git a/pages/chain-operators/reference/meta.json b/pages/chain-operators/reference/meta.json new file mode 100644 index 000000000..bc8c45fa7 --- /dev/null +++ b/pages/chain-operators/reference/meta.json @@ -0,0 +1,7 @@ +{ + "architecture": "Chain architecture", + "opcm": "OP Contracts Manager", + "privileged-roles": "Privileged Roles in OP Stack Chains", + "superchain-explainer": "Superchain explainer", + "superchain-registry": "The Superchain Registry" +} diff --git a/pages/stack/opcm.mdx b/pages/chain-operators/reference/opcm.mdx similarity index 100% rename from pages/stack/opcm.mdx rename to pages/chain-operators/reference/opcm.mdx diff --git a/pages/superchain/privileged-roles.mdx b/pages/chain-operators/reference/privileged-roles.mdx similarity index 100% rename from pages/superchain/privileged-roles.mdx rename to pages/chain-operators/reference/privileged-roles.mdx diff --git a/pages/stack/features/send-raw-transaction-conditional.mdx b/pages/chain-operators/reference/rpc/conditional-txs.mdx similarity index 100% rename from pages/stack/features/send-raw-transaction-conditional.mdx rename to pages/chain-operators/reference/rpc/conditional-txs.mdx diff --git a/pages/chain-operators/reference/rpc/meta.json b/pages/chain-operators/reference/rpc/meta.json new file mode 100644 index 000000000..c5857ad9d --- /dev/null +++ b/pages/chain-operators/reference/rpc/meta.json @@ -0,0 +1,3 @@ +{ + "conditional-txs": "SendRawTransactionConditional explainer" +} diff --git a/pages/superchain/superchain-explainer.mdx b/pages/chain-operators/reference/superchain-explainer.mdx similarity index 100% rename from pages/superchain/superchain-explainer.mdx rename to pages/chain-operators/reference/superchain-explainer.mdx diff --git a/pages/superchain/superchain-registry.mdx b/pages/chain-operators/reference/superchain-registry.mdx similarity index 100% rename from pages/superchain/superchain-registry.mdx rename to pages/chain-operators/reference/superchain-registry.mdx diff --git a/pages/operators/chain-operators/tools/chain-monitoring.mdx b/pages/chain-operators/tools/chain-monitoring.mdx similarity index 100% rename from pages/operators/chain-operators/tools/chain-monitoring.mdx rename to pages/chain-operators/tools/chain-monitoring.mdx diff --git a/pages/operators/chain-operators/tools/explorer.mdx b/pages/chain-operators/tools/explorer.mdx similarity index 100% rename from pages/operators/chain-operators/tools/explorer.mdx rename to pages/chain-operators/tools/explorer.mdx diff --git a/pages/operators/chain-operators/tools/fee-calculator.mdx b/pages/chain-operators/tools/fee-calculator.mdx similarity index 100% rename from pages/operators/chain-operators/tools/fee-calculator.mdx rename to pages/chain-operators/tools/fee-calculator.mdx diff --git a/pages/chain-operators/tools/meta.json b/pages/chain-operators/tools/meta.json new file mode 100644 index 000000000..d0ef8303b --- /dev/null +++ b/pages/chain-operators/tools/meta.json @@ -0,0 +1,11 @@ +{ + "chain-monitoring": "Chain monitoring options", + "explorer": "Block explorer", + "fee-calculator": "Fjord fee parameter calculator", + "op-challenger": "How to configure challenger for your chain", + "op-conductor": "Conductor", + "op-deployer": "Deployer", + "op-txproxy": "op-txproxy", + "op-validator": "op-validator", + "proxyd": "proxyd" +} diff --git a/pages/chain-operators/tools/op-challenger.mdx b/pages/chain-operators/tools/op-challenger.mdx new file mode 100644 index 000000000..7d7f8c025 --- /dev/null +++ b/pages/chain-operators/tools/op-challenger.mdx @@ -0,0 +1,234 @@ +--- +title: How to configure challenger for your chain +description: Learn how to configure challenger for your OP Stack chain. +lang: en-US +content_type: tutorial +topic: configure-challenger-for-your-chain +personas: + - chain-operator +categories: + - mainnet + - testnet + - fault-proofs + - op-challenger + - chain-configuration +is_imported_content: 'false' +--- + +import { Callout, Steps } from 'nextra/components' + +# How to configure challenger for your chain + +This guide provides a walkthrough of setting up the configuration and monitoring options for `op-challenger`. See the [OP-Challenger Explainer](/stack/fault-proofs/challenger) for a general overview of this fault proofs feature. + + + ### Build the executable + + * Clone the monorepo + + ```bash + git clone https://github.com/ethereum-optimism/optimism.git + ``` + + * Check out the [latest release of `op-challenger`](https://github.com/ethereum-optimism/optimism/releases) and use the commit to deploy. Alternatively, chain operators can use the prebuilt challenger docker images included in the release notes. + If a Docker image is used, it already comes with `op-program` server and an executable for Cannon embedded, so the Cannon bin doesn't need to be specified. + + ```bash + git checkout op-challenger/vX.Y.Z + ``` + + + Chain operators need to specify the arguments and `op-program` server if `op-challenger` is running outside of Docker, but there's a Cannon server option which points to `op-program`'s executable. + + + * Build challenger + + ```bash + cd optimism + pnpm install + make op-challenger + ``` + + ### Configure challenger + + * Configure challenger with the required flags. Tip: Use the `op-challenger --help` to view all subcommands, command line, and environment variable options. + * The example config file below shows the flags to configure in this step: + + ```docker + challenger: + user: "1000" + image: us-docker.pkg.dev/oplabs-tools-artifacts/images/op-challenger:v0.2.11 + command: + - "op-challenger" + - "--l1-eth-rpc=http://sepolia-el-1:8545" + - "--l1-beacon=http://sepolia-cl-1:5051" + - "--l2-eth-rpc=http://op-sepolia-el-1:8545" + - "--rollup-rpc=http://op-sepolia-cl-1:5051" + - "--selective-claim-resolution" + - "--private-key=...." + - "--network=..." + - "--datadir=/data" + - "--cannon-prestates-url=..." + volumes: + - "./challenger-data:/data" + ``` + + #### `--l1-eth-rpc` + + * This is the HTTP provider URL for a standard L1 node, can be a full node. `op-challenger` will be sending many requests, so chain operators need a node that is trusted and can easily handle many transactions. + * Note: Challenger has a lot of money, and it will spend it if it needs to interact with games. That might risk not defending games or challenging games correctly, so chain operators should really trust the nodes being pointed at Challenger. + + #### `--l1-beacon` + + * This is needed just to get blobs from. + * In some instances, chain operators might need a blob archiver or L1 consensus node configured not to prune blobs: + * If the chain is proposing regularly, a blob archiver isn't needed. There's only a small window in the blob retention period that games can be played. + * If the chain doesn't post a valid output root in 18 days, then a blob archiver running a challenge game is needed. If the actor gets pushed to the bottom of the game, it could lose if it's the only one protecting the chain. + + #### `--l2-eth-rpc` + + * This needs to be `op-geth` archive node, with `debug` enabled. + * Technically doesn't need to go to bedrock, but needs to have access to the start of any game that is still in progress. + + #### `--rollup-rpc` + + * This needs to be an `op-node` archive node because challenger needs access to output roots from back when the games start. See below for important configuration details: + + 1. Safe Head Database (SafeDB) Configuration for op-node: + + * The `op-node` behind the `op-conductor` must have the SafeDB enabled to ensure it is not stateless. + * To enable SafeDB, set the `--safedb.path` value in your configuration. This specifies the file path used to persist safe head update data. + * Example Configuration: + + ``` + --safedb.path # Replace with your actual path + ``` + + + If this path is not set, the SafeDB feature will be disabled. + + + 2. Ensuring Historical Data Availability: + + * Both `op-node` and `op-geth` must have data from the start of the games to maintain network consistency and allow nodes to reference historical state and transactions. + * For `op-node`: Configure it to maintain a sufficient history of blockchain data locally or use an archive node. + * For `op-geth`: Similarly, configure to store or access historical data. + * Example Configuration: + + ``` + op-node \ + --rollup-rpc \ + --safedb.path + ``` + + + Replace `` with the URL of your archive node and `` with the desired path for storing SafeDB data. + + + #### `--private-key` + + * Chain operators must specify a private key or use something else (like `op-signer`). + * This uses the same transaction manager arguments as `op-node` , batcher, and proposer, so chain operators can choose one of the following options: + * a mnemonic + * a private key + * `op-signer` endpoints + + #### `--network` + + * This identifies the L2 network `op-challenger` is running for, e.g., `op-sepolia` or `op-mainnet`. + * When using the `--network` flag, the `--game-factory-address` will be automatically pulled from the [`superchain-registry`](https://github.com/ethereum-optimism/superchain-registry/blob/main/chainList.json). + * When cannon is executed, challenger needs the roll-up config and the L2 Genesis, which is op-geth's Genesis file. Both files are automatically loaded when Cannon Network is used, but custom networks will need to specify both Cannon L2 Genesis and Cannon rollup config. + * For custom networks not in the [`superchain-registry`](https://github.com/ethereum-optimism/superchain-registry/blob/main/chainList.json), the `--game-factory-address` and rollup must be specified, as follows: + + ``` + --cannon-rollup-config rollup.json \ + --cannon-l2-genesis genesis-l2.json \ + # use this if running challenger outside of the docker image + --cannon-server ./op-program/bin/op-program \ + # json or url, version of op-program deployed on chain + # if you use the wrong one, you will lose the game + # if you deploy your own contracts, you specify the hash, the root of the json file + # op mainnet are tagged versions of op-program + # make reproducible prestate + # challenger verifies that onchain + --cannon-prestate ./op-program/bin/prestate.json \ + # load the game factory address from system config or superchain registry + # point the game factory address at the dispute game factory proxy + --game-factory-address + ``` + + + These options vary based on which `--network` is specified. Chain operators always need to specify a way to load prestates and must also specify the cannon-server whenever the docker image isn't being used. + + + #### `--datadir` + + * This is a directory that `op-challenger` can write to and store whatever data it needs. It will manage this directory to add or remove data as needed under that directory. + * If running in docker, it should point to a docker volume or mountpoint, so the data isn't lost on every restart. The data can be recreated if needed but particularly if challenger has executed cannon as part of responding to a game it may mean a lot of extra processing. + + #### `--cannon-prestates-url` + + The pre-state is effectively the version of `op-program` that is deployed on chain. And chain operators must use the right version. `op-challenger` will refuse to interact with games that have a different absolute prestate hash to avoid making invalid claims. If deploying your own contracts, chain operators must specify an absolute prestate hash taken from the `make reproducible-prestate` command during contract deployment, which will also build the required prestate json file. + + All governance approved releases use a tagged version of `op-program`. These can be rebuilt by checking out the version tag and running `make reproducible-prestate`. + + * There are two ways to specify the prestate to use: + * `--cannon-prestate`: specifies a path to a single Cannon pre-state Json file + * `--cannon-prestates-url`: specifies a URL to load pre-states from. This enables participating in games that use different prestates, for example due to a network upgrade. The prestates are stored in this directory named by their hash. + * Example final URL for a prestate: + * [https://example.com/prestates/0x031e3b504740d0b1264e8cf72b6dde0d497184cfb3f98e451c6be8b33bd3f808.json](https://example.com/prestates/0x031e3b504740d0b1264e8cf72b6dde0d497184cfb3f98e451c6be8b33bd3f808.json) + * This file contains the cannon memory state. + + + Challenger will refuse to interact with any games if it doesn't have the matching prestate. + + + ### Execute challenger + + The final step is to execute challenger with the required flags. It will look something like this (but with required flags added): + + ```bash + ./op-challenger/bin/op-challenger \ + --trace-type permissioned,cannon \ + --l1-eth-rpc http://localhost:8545 \ + --rollup-rpc http://localhost:9546 \ + --game-factory-address $DISPUTE_GAME_FACTORY \ + --datadir temp/challenger-data \ + --cannon-rollup-config .devnet/rollup.json \ + --cannon-l2-genesis .devnet/genesis-l2.json \ + --cannon-bin ./cannon/bin/cannon \ + --cannon-server ./op-program/bin/op-program \ + --cannon-prestate ./op-program/bin/prestate.json \ + --l2-eth-rpc http://localhost:9545 \ + --mnemonic "test test test test test test test test test test test junk" \ + --hd-path "m/44'/60'/0'/0/8" \ + ``` + + ### Test and debug challenger (optional) + + This is an optional step to use `op-challenger` subcommands, which allow chain operators to interact with the Fault Proof System onchain for testing and debugging purposes. For example, it is possible to test and explore the system in the following ways: + + * create games yourself, and it doesn't matter if the games are valid or invalid. + * perform moves in games and then claim and resolve things. + + Here's the list of op-challenger subcommands: + + | subcommand | description | + | --------------- | -------------------------------------------------------- | + | `list-games` | List the games created by a dispute game factory | + | `list-claims` | List the claims in a dispute game | + | `list-credits` | List the credits in a dispute game | + | `create-game` | Creates a dispute game via the factory | + | `move` | Creates and sends a move transaction to the dispute game | + | `resolve` | Resolves the specified dispute game if possible | + | `resolve-claim` | Resolves the specified claim if possible | + + Additionally, chain operators should consider running `op-dispute-mon`. It's an incredibly useful security monitoring service to keep an eye on games, basically giving chain operators visibility into all the status of the games for the last 28 days. + Chain operators can easily create their grafana dashboard for Dispute Monitor using the following json file: [Download the Dispute Monitor JSON](/resources/grafana/dispute-monitor-1718214549035.json). + + +## Next steps + +* Additional questions? See the FAQ section in the [OP Challenger Explainer](/stack/fault-proofs/challenger). +* For more detailed info on `op-challenger`, see the [specs](https://specs.optimism.io/fault-proof/stage-one/honest-challenger-fdg.html?utm_source=op-docs&utm_medium=docs). +* If you experience any problems, please reach out to [developer support](https://github.com/ethereum-optimism/developers/discussions). diff --git a/pages/operators/chain-operators/tools/op-conductor.mdx b/pages/chain-operators/tools/op-conductor.mdx similarity index 100% rename from pages/operators/chain-operators/tools/op-conductor.mdx rename to pages/chain-operators/tools/op-conductor.mdx diff --git a/pages/operators/chain-operators/tools/op-deployer.mdx b/pages/chain-operators/tools/op-deployer.mdx similarity index 95% rename from pages/operators/chain-operators/tools/op-deployer.mdx rename to pages/chain-operators/tools/op-deployer.mdx index 1c600e8fa..0c450d04c 100644 --- a/pages/operators/chain-operators/tools/op-deployer.mdx +++ b/pages/chain-operators/tools/op-deployer.mdx @@ -13,7 +13,7 @@ categories: is_imported_content: 'false' --- -import {Callout, Steps, Tabs} from 'nextra/components' +import {Callout, Steps} from 'nextra/components' # Deployer @@ -23,42 +23,40 @@ import {Callout, Steps, Tabs} from 'nextra/components' There are a couple of ways to install `op-deployer`: - - - To install from source, you will need [Go](https://go.dev/doc/install), `just`, and `git`. - After installing all of that, run following: +### Option 1: Build from source (Recommended) - ```bash +To install from source, you will need [Go](https://go.dev/doc/install), `just`, and `git`. +After installing all of that, run following: - git clone https://github.com/ethereum-optimism/optimism.git # you can skip this if you already have the repo - cd optimism/op-deployer - just build - cp ./bin/op-deployer /usr/local/bin/op-deployer # or any other directory in your $PATH +```bash - # Verify installation, run this command to verify that you have it installed. - op-deployer --version - ``` - +git clone https://github.com/ethereum-optimism/optimism.git # you can skip this if you already have the repo +cd optimism/op-deployer +just build +cp ./bin/op-deployer /usr/local/bin/op-deployer # or any other directory in your $PATH - - Another way to install `op-deployer`, is to download the latest release from the monorepo's [release page](https://github.com/ethereum-optimism/optimism/releases). +# Verify installation, run this command to verify that you have it installed. +op-deployer --version +``` - 1. Go to [https://github.com/ethereum-optimism/optimism/releases](https://github.com/ethereum-optimism/optimism/releases) - 2. Find the latest release that includes op-deployer - 3. Under **assets**, download the binary that matches your operating system: +### Option 2: Download pre-built binary - * `op-deployer-linux-amd64` for Linux - * `op-deployer-darwin-amd64` or `op-deployer-darwin-arm64` for macOS - * `op-deployer-windows-amd64.exe` for Windows +The recommended way to install `op-deployer` is to download the latest release from the monorepo's [release page](https://github.com/ethereum-optimism/optimism/releases). - 4. Extract the binary to a location on your system PATH - 5. Verify installation, run this command to verify that you have it installed. +1. Go to [https://github.com/ethereum-optimism/optimism/releases](https://github.com/ethereum-optimism/optimism/releases) +2. Find the latest release that includes op-deployer +3. Under **assets**, download the binary that matches your operating system: - ```bash - op-deployer --version - ``` - - +* `op-deployer-linux-amd64` for Linux +* `op-deployer-darwin-amd64` or `op-deployer-darwin-arm64` for macOS +* `op-deployer-windows-amd64.exe` for Windows + +4. Extract the binary to a location on your system PATH +5. Verify installation, run this command to verify that you have it installed. + +```bash +op-deployer --version +``` ## Deployment usage @@ -260,7 +258,7 @@ l1ContractsLocator = "file:///path/to/local/op-contracts/v1.8.0-rc.4/forge-artif l2ContractsLocator = "" ``` -By default, `op-deployer` will fill in all other configuration variables with those that match the [standard configuration](https://specs.optimism.io/protocol/configurability.html?utm_source=op-docs&utm_medium=docs). You can override these default settings by adding them to your intent file using the table below: +By default, `op-deployer` will fill in all other configuration variables with those that match the [standard configuration](https://specs.optimism.io/protocol/configurability.html?utm_source=op-docs\&utm_medium=docs). You can override these default settings by adding them to your intent file using the table below: ```toml [globalDeployOverrides] @@ -365,7 +363,7 @@ Unlike the `bootstrap` or `apply` commands, the `upgrade` command doesn't direct Chains that are several versions behind the latest can be upgraded by running multiple upgrade commands in sequence, with each command handling one version increment. The upgrade process requires you to be using the standard OP Contracts Manager and the standard shared SuperchainConfig contract for compatibility. -For detailed instructions on using the upgrade command, including configuration examples and step-by-step procedures, see the [upgrade documentation](/stack/smart-contracts/op-deployer-upgrade#using-upgrade). +For detailed instructions on using the upgrade command, including configuration examples and step-by-step procedures, see the [upgrade documentation](https://docs.optimism.io/stack/smart-contracts/op-deployer-upgrade#using-upgrade). ## Bootstrap usage diff --git a/pages/operators/chain-operators/tools/op-txproxy.mdx b/pages/chain-operators/tools/op-txproxy.mdx similarity index 100% rename from pages/operators/chain-operators/tools/op-txproxy.mdx rename to pages/chain-operators/tools/op-txproxy.mdx diff --git a/pages/operators/chain-operators/tools/op-validator.mdx b/pages/chain-operators/tools/op-validator.mdx similarity index 100% rename from pages/operators/chain-operators/tools/op-validator.mdx rename to pages/chain-operators/tools/op-validator.mdx diff --git a/pages/operators/chain-operators/tools/proxyd.mdx b/pages/chain-operators/tools/proxyd.mdx similarity index 100% rename from pages/operators/chain-operators/tools/proxyd.mdx rename to pages/chain-operators/tools/proxyd.mdx diff --git a/pages/operators/chain-operators/tutorials/absolute-prestate.mdx b/pages/chain-operators/tutorials/absolute-prestate.mdx similarity index 98% rename from pages/operators/chain-operators/tutorials/absolute-prestate.mdx rename to pages/chain-operators/tutorials/absolute-prestate.mdx index d42781828..6e1d988f0 100644 --- a/pages/operators/chain-operators/tutorials/absolute-prestate.mdx +++ b/pages/chain-operators/tutorials/absolute-prestate.mdx @@ -162,8 +162,8 @@ For these cases, follow these additional steps: ```bash # Replace 67865 with your actual chain ID - cp ../deployer/.deployer/rollup.json op-program/chainconfig/configs/67865-rollup.json - cp ../deployer/.deployer/genesis.json op-program/chainconfig/configs/67865-genesis-l2.json + cp /path/to/rollup.json op-program/chainconfig/configs/67865-rollup.json + cp /path/to/genesis.json op-program/chainconfig/configs/67865-genesis-l2.json ``` Note: The naming format is critical - the files must be named as: diff --git a/pages/operators/chain-operators/tutorials/adding-derivation-attributes.mdx b/pages/chain-operators/tutorials/adding-derivation-attributes.mdx similarity index 100% rename from pages/operators/chain-operators/tutorials/adding-derivation-attributes.mdx rename to pages/chain-operators/tutorials/adding-derivation-attributes.mdx diff --git a/pages/operators/chain-operators/tutorials/adding-precompiles.mdx b/pages/chain-operators/tutorials/adding-precompiles.mdx similarity index 91% rename from pages/operators/chain-operators/tutorials/adding-precompiles.mdx rename to pages/chain-operators/tutorials/adding-precompiles.mdx index 91cdf29ae..2f4e8557c 100644 --- a/pages/operators/chain-operators/tutorials/adding-precompiles.mdx +++ b/pages/chain-operators/tutorials/adding-precompiles.mdx @@ -35,10 +35,10 @@ To create a new precompile, the file to modify is [`op-geth/core/vm/contracts.go ### Add to `PrecompiledContractsBerlin` on line 82 (or a later fork, if the list of precompiles changes again) * add a structure named after your new precompile, and - * use an address that is unlikely to ever clash with a standard precompile and avoids the [EIP-7587](https://eips.ethereum.org/EIPS/eip-7587) reserved range (0x1337, for example): + * use an address that is unlikely to ever clash with a standard precompile (0x100, for example): ```go - common.BytesToAddress([]byte{0x13,0x37}): &retConstant{}, + common.BytesToAddress([]byte{1,0}): &retConstant{}, ``` ### Add the lines for the precompile @@ -80,8 +80,8 @@ To create a new precompile, the file to modify is [`op-geth/core/vm/contracts.go ### Run these commands to see the result of calling the precompile successfully, and the result of an error: ```bash - cast call 0x0000000000000000000000000000000000001337 "whatever()" - cast call 0x0000000000000000000000000000000000001337 "whatever(string)" "fail" + cast call 0x0000000000000000000000000000000000000100 "whatever()" + cast call 0x0000000000000000000000000000000000000100 "whatever(string)" "fail" ``` @@ -112,11 +112,11 @@ var PrecompiledContractsBerlin = map[common.Address]PrecompiledContract{ . . common.BytesToAddress([]byte{9}): &blake2F{}, - common.BytesToAddress([]byte{0x13,0x37}): &retConstant{}, + common.BytesToAddress([]byte{1,0}): &retConstant{}, } ``` -The key of the map is an address. You create those from bytes using `common.BytesToAddress([]byte{})`. In this case you have two bytes, `0x13` and `0x37`. Together you get the address `0x0…1337`. +The key of the map is an address. You create those from bytes using `common.BytesToAddress([]byte{})`. In this case you have two bytes, `0x01` and `0x00`. Together you get the address `0x0…0100`. The syntax for a precompiled contract interface is `&{}`. diff --git a/pages/operators/chain-operators/tutorials/chain-dev-net.mdx b/pages/chain-operators/tutorials/chain-dev-net.mdx similarity index 89% rename from pages/operators/chain-operators/tutorials/chain-dev-net.mdx rename to pages/chain-operators/tutorials/chain-dev-net.mdx index 1da8a7bf4..ca05f63c3 100644 --- a/pages/operators/chain-operators/tutorials/chain-dev-net.mdx +++ b/pages/chain-operators/tutorials/chain-dev-net.mdx @@ -1,6 +1,6 @@ --- title: Running a Local Development Environment -description: This tutorial walks you through spinning up local OP Stack chain for protocol development. +description: This tutorial walks you through spinning up an OP Stack devnet chain. lang: en-US content_type: tutorial topic: running-a-local-development-environment @@ -22,15 +22,14 @@ import {WipCallout} from '@/components/WipCallout' # Running a Local Development Environment -This tutorial is **designed for protocol developers** who want to contribute to the OP Stack -by spinning up a local OP Stack development environment running with [Kurtosis](https://www.kurtosis.com/). -You'll perform the full deployment process, and **you'll end up with your very own OP Stack devnet, with smart contracts and components that closely mirror what gets run in production**. - - This tutorial is intended for protocol developers. If you're looking to try out the OP Stack in a more lightweight way, - you can use the [`op-up`](https://localchain.dev) tool to deploy a local network in less than a minute. + This guide is currently under active development. If you run into any issues, please open an issue on + [Github](https://github.com/ethereum-optimism/optimism). +This tutorial is **designed for developers** who want to learn about the OP Stack by spinning up a local OP Stack devnet. +You'll perform the full deployment process, and **you'll end up with your very own OP Stack devnet**. + It's useful to understand what each of these components does before you start deploying your chain. To learn about the different components please read the [deployment overview page](/operators/chain-operators/deploy/overview). @@ -70,28 +69,14 @@ accepts a YAML file which configures how many network participants there are, wh the network's topology. An example YAML file is below: ```yaml -# Check https://github.com/ethpandaops/optimism-package for more details. - optimism_package: - # An array of L2 networks to run. - chains: - # Chains are keyed by their network name. - rollup-1: - # Specification of the optimism-participants in the network. - participants: - # Nodes are keyed by their name. - node0: - # EL(Execution Layer) Specific flags. - el: - type: op-geth - # CL(Consensus Layer) Specific flags - cl: - type: op-node - node1: - el: - type: op-reth - cl: - type: op-node + chains: # you can define multiple L2s, which will be deployed against the same L1 as a single Superchain + - participants: # each participant is a node in the network. here we've defined two, one running op-geth and one running op-reth + - el_type: op-geth # this node will be the sequencer since it's first in the list + - el_type: op-reth + network_params: + name: rollup-1 # can be anything as long as it is unique + network_id: 12345 # can be anything as long as it is unique ``` Save the above configuration to a file. For the rest of this tutorial, we'll assume you've saved it to `network-config.yaml`. diff --git a/pages/chain-operators/tutorials/create-l2-rollup.mdx b/pages/chain-operators/tutorials/create-l2-rollup.mdx new file mode 100644 index 000000000..0f7d88d13 --- /dev/null +++ b/pages/chain-operators/tutorials/create-l2-rollup.mdx @@ -0,0 +1,776 @@ +--- +title: Creating your own L2 rollup testnet +description: This tutorial walks you through spinning up an OP Stack testnet chain. +lang: en-US +content_type: tutorial +topic: creating-your-own-l2-rollup-testnet +personas: + - chain-operator +categories: + - mainnet + - testnet + - chain-deployment + - chain-configuration + - chain-operation + - node-management + - op-deployer +is_imported_content: 'false' +--- + +import { Callout, Steps } from 'nextra/components' +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. + + +This tutorial is **designed for developers** who want to learn about the OP Stack by spinning up an OP Stack testnet chain. +You'll walk through the full deployment process and teach you all of the components that make up the OP Stack, and **you'll end up with your very own OP Stack testnet**. + +It's useful to understand what each of these components does before +you start deploying your chain. To learn about the different components please +read the [deployment overview page](/operators/chain-operators/deploy/overview). + +You can use this testnet to experiment and perform tests, or you can choose to modify the chain to adapt it to your own needs. +**The OP Stack is free and open source software licensed entirely under the MIT license**. +You don't need permission from anyone to modify or deploy the stack in any configuration you want. + + +Modifications to the OP Stack may prevent a chain from being able to benefit from aspects of the [Optimism Superchain](/superchain/superchain-explainer). +Make sure to check out the [Superchain Explainer](/superchain/superchain-explainer) to learn more. + + +## Software dependencies + +| Dependency | Version | Version Check Command | +| ------------------------------------------------------------- | -------- | --------------------- | +| [git](https://git-scm.com/) | `^2` | `git --version` | +| [go](https://go.dev/) | `^1.21` | `go version` | +| [node](https://nodejs.org/en/) | `^20` | `node --version` | +| [pnpm](https://pnpm.io/installation) | `^8` | `pnpm --version` | +| [foundry](https://github.com/foundry-rs/foundry#installation) | `^0.2.0` | `forge --version` | +| [make](https://linux.die.net/man/1/make) | `^3` | `make --version` | +| [jq](https://github.com/jqlang/jq) | `^1.6` | `jq --version` | +| [direnv](https://direnv.net) | `^2` | `direnv --version` | + +### Notes on specific dependencies + +#### `node` + +We recommend using the latest LTS version of Node.js (currently v20). +[`nvm`](https://github.com/nvm-sh/nvm) is a useful tool that can help you manage multiple versions of Node.js on your machine. +You may experience unexpected errors on older versions of Node.js. + +#### `foundry` + +It's recommended to use the scripts in the monorepo's `package.json` for managing `foundry` to ensure you're always working with the correct version. This approach simplifies the installation, update, and version checking process. Make sure to clone the monorepo locally before proceeding. +#### `direnv` + +Parts of this tutorial use [`direnv`](https://direnv.net) as a way of loading environment variables from `.envrc` files into your shell. +This means you won't have to manually export environment variables every time you want to use them. +`direnv` only ever has access to files that you explicitly allow it to see. + +After [installing `direnv`](https://direnv.net/docs/installation.html), you will need to **make sure that [`direnv` is hooked into your shell](https://direnv.net/docs/hook.html)**. +Make sure you've followed [the guide on the `direnv` website](https://direnv.net/docs/hook.html), then **close your terminal and reopen it** so that the changes take effect (or `source` your config file if you know how to do that). + + +Make sure that you have correctly hooked `direnv` into your shell by modifying your shell configuration file (like `~/.bashrc` or `~/.zshrc`). +If you haven't edited a config file then you probably haven't configured `direnv` properly (and things might not work later). + + +## Get access to a sepolia node + +You'll be deploying a OP Stack Rollup chain that uses a Layer 1 blockchain to host and order transaction data. +The OP Stack Rollups were designed to use EVM Equivalent blockchains like Ethereum, OP Mainnet, or standard Ethereum testnets as their L1 chains. + +**This guide uses the Sepolia testnet as an L1 chain**. +We recommend that you also use Sepolia. +You can also use other EVM-compatible blockchains, but you may run into unexpected errors. +If you want to use an alternative network, make sure to carefully review each command and replace any Sepolia-specific values with the values for your network. + +Since you're deploying your OP Stack chain to Sepolia, you'll need to have access to a Sepolia node. +You can either use a node provider like [Alchemy](https://www.alchemy.com/) (easier) or run your own Sepolia node (harder). + +## Build the source code + +You're going to be spinning up your OP Stack chain directly from source code instead of using a container system like [Docker](https://www.docker.com/). +Although this adds a few extra steps, it means you'll have an easier time modifying the behavior of the stack if you'd like to do so. +If you want a summary of the various components you'll be using, take another look at the [What You're Going to Deploy](#what-youre-going-to-deploy) section above. + + +You're using the home directory `~/` as the work directory for this tutorial for simplicity. +You can use any directory you'd like but using the home directory will allow you to copy/paste the commands in this guide. +If you choose to use a different directory, make sure you're using the correct directory in the commands throughout this tutorial. + + +### Build the Optimism monorepo + + + +{

Clone the Optimism Monorepo

} + +```bash +cd ~ +git clone https://github.com/ethereum-optimism/optimism.git +``` + +{

Enter the Optimism Monorepo

} + +```bash +cd optimism +``` + +{

Check out the correct branch

} + + +You will be using the `tutorials/chain` branch of the Optimism Monorepo to deploy an OP Stack testnet chain during this tutorial. +This is a non-production branch that lags behind the `develop` branch. +You should **NEVER** use the `develop` or `tutorials/chain` branches in production. + + +```bash +git checkout tutorials/chain +``` + +{

Check your dependencies

} + + +Don't skip this step! Make sure you have all of the required dependencies installed before continuing. + + +Run the following script and double check that you have all of the required versions installed. +If you don't have the correct versions installed, you may run into unexpected errors. + +```bash +./packages/contracts-bedrock/scripts/getting-started/versions.sh +``` + +{

Install dependencies

} + +```bash +pnpm install +``` + +{

Build the various packages inside of the Optimism Monorepo

} + +```bash +make op-node op-batcher op-proposer +pnpm build +``` + + + +### Build `op-geth` + + + +{

Clone op-geth

} + +```bash +cd ~ +git clone https://github.com/ethereum-optimism/op-geth.git +``` + +{

Enter op-geth

} + +```bash +cd op-geth +``` + +{

Build op-geth

} + +```bash +make geth +``` + + + +## Fill out environment variables + +You'll need to fill out a few environment variables before you can start deploying your chain. + + + +{

Enter the Optimism Monorepo

} + +```bash +cd ~/optimism +``` + +{

Duplicate the sample environment variable file

} + +```bash +cp .envrc.example .envrc +``` + +{

Fill out the environment variable file

} + +Open up the environment variable file and fill out the following variables: + +| Variable Name | Description | +| ------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| `L1_RPC_URL` | URL for your L1 node (a Sepolia node in this case). | +| `L1_RPC_KIND` | Kind of L1 RPC you're connecting to, used to inform optimal transactions receipts fetching. Valid options: `alchemy`, `quicknode`, `infura`, `parity`, `nethermind`, `debug_geth`, `erigon`, `basic`, `any`. | + + + +## Generate addresses + +You'll need four addresses and their private keys when setting up the chain: + +* The `Admin` address has the ability to upgrade contracts. +* The `Batcher` address publishes Sequencer transaction data to L1. +* The `Proposer` address publishes L2 transaction results (state roots) to L1. +* The `Sequencer` address signs blocks on the p2p network. + + + +{

Enter the Optimism Monorepo

} + +```bash +cd ~/optimism +``` + +{

Generate new addresses

} + + +You should **not** use the `wallets.sh` tool for production deployments. +If you are deploying an OP Stack based chain into production, you should likely be using a combination of hardware security modules and hardware wallets. + + +```bash +./packages/contracts-bedrock/scripts/getting-started/wallets.sh +``` + +{

Check the output

} + +Make sure that you see output that looks something like the following: + +```text +Copy the following into your .envrc file: + +# Admin address +export GS_ADMIN_ADDRESS=0x9625B9aF7C42b4Ab7f2C437dbc4ee749d52E19FC +export GS_ADMIN_PRIVATE_KEY=0xbb93a75f64c57c6f464fd259ea37c2d4694110df57b2e293db8226a502b30a34 + +# Batcher address +export GS_BATCHER_ADDRESS=0xa1AEF4C07AB21E39c37F05466b872094edcf9cB1 +export GS_BATCHER_PRIVATE_KEY=0xe4d9cd91a3e53853b7ea0dad275efdb5173666720b1100866fb2d89757ca9c5a + +# Proposer address +export GS_PROPOSER_ADDRESS=0x40E805e252D0Ee3D587b68736544dEfB419F351b +export GS_PROPOSER_PRIVATE_KEY=0x2d1f265683ebe37d960c67df03a378f79a7859038c6d634a61e40776d561f8a2 + +# Sequencer address +export GS_SEQUENCER_ADDRESS=0xC06566E8Ec6cF81B4B26376880dB620d83d50Dfb +export GS_SEQUENCER_PRIVATE_KEY=0x2a0290473f3838dbd083a5e17783e3cc33c905539c0121f9c76614dda8a38dca +``` + +{

Save the addresses

} + +Copy the output from the previous step and paste it into your `.envrc` file as directed. + +{

Fund the addresses

} + +**You will need to send ETH to the `Admin`, `Proposer`, and `Batcher` addresses.** +The exact amount of ETH required depends on the L1 network being used. +**You do not need to send any ETH to the `Sequencer` address as it does not send transactions.** + +It's recommended to fund the addresses with the following amounts when using Sepolia: + +* `Admin` — 0.5 Sepolia ETH +* `Batcher` — 0.1 Sepolia ETH +* `Proposer` — 0.2 Sepolia ETH + +**To get the required Sepolia ETH to fund the addresses, we recommend using the [Superchain Faucet](https://console.optimism.io/faucet?utm_source=op-docs&utm_medium=docs)** together with [Coinbase verification](https://help.coinbase.com/en/coinbase/getting-started/getting-started-with-coinbase/id-doc-verification). + + + +## Load environment variables + +Now that you've filled out the environment variable file, you need to load those variables into your terminal. + + + +{

Enter the Optimism Monorepo

} + +```bash +cd ~/optimism +``` + +{

Load the variables with direnv

} + + +You're about to use `direnv` to load environment variables from the `.envrc` file into your terminal. +Make sure that you've [installed `direnv`](https://direnv.net/docs/installation.html) and that you've properly [hooked `direnv` into your shell](#configuring-direnv). + + +Next you'll need to allow `direnv` to read this file and load the variables into your terminal using the following command. + +```bash +direnv allow +``` + + +WARNING: `direnv` will unload itself whenever your `.envrc` file changes. +**You *must* rerun the following command every time you change the `.envrc` file.** + + +{

Confirm that the variables were loaded

} + +After running `direnv allow` you should see output that looks something like the following (the exact output will vary depending on the variables you've set, don't worry if it doesn't look exactly like this): + +```bash +direnv: loading ~/optimism/.envrc +direnv: export +DEPLOYMENT_CONTEXT +ETHERSCAN_API_KEY +GS_ADMIN_ADDRESS +GS_ADMIN_PRIVATE_KEY +GS_BATCHER_ADDRESS +GS_BATCHER_PRIVATE_KEY +GS_PROPOSER_ADDRESS +GS_PROPOSER_PRIVATE_KEY +GS_SEQUENCER_ADDRESS +GS_SEQUENCER_PRIVATE_KEY +IMPL_SALT +L1_RPC_KIND +L1_RPC_URL +PRIVATE_KEY +TENDERLY_PROJECT +TENDERLY_USERNAME +``` + +**If you don't see this output, you likely haven't [properly configured `direnv`](#configuring-direnv).** +Make sure you've configured `direnv` properly and run `direnv allow` again so that you see the desired output. + + + +## Configure your network + +Once you've built both repositories, you'll need to head back to the Optimism Monorepo to set up the configuration file for your chain. +Currently, chain configuration lives inside of the [`contracts-bedrock`](https://github.com/ethereum-optimism/optimism/tree/v1.1.4/packages/contracts-bedrock) package in the form of a JSON file. + + + +{

Enter the Optimism Monorepo

} + +```bash +cd ~/optimism +``` + +{

Move into the contracts-bedrock package

} + +```bash +cd packages/contracts-bedrock +``` + +{

Install Foundry dependencies

} + +```bash +forge install +``` + +{

Generate the configuration file

} + +Run the following script to generate the `getting-started.json` configuration file inside of the `deploy-config` directory. + +```bash +./scripts/getting-started/config.sh +``` + +{

Review the configuration file (Optional)

} + +If you'd like, you can review the configuration file that was just generated by opening up `deploy-config/getting-started.json` in your favorite text editor. +It's recommended to keep this file as-is for now so you don't run into any unexpected errors. + + + +## Deploy the Create2 factory (optional) + +If you're deploying an OP Stack chain to a network other than Sepolia, you may need to deploy a Create2 factory contract to the L1 chain. +This factory contract is used to deploy OP Stack smart contracts in a deterministic fashion. + + +This step is typically only necessary if you are deploying your OP Stack chain to custom L1 chain. +If you are deploying your OP Stack chain to Sepolia, you can safely skip this step. + + + + +{

Check if the factory exists

} + +The Create2 factory contract will be deployed at the address `0x4e59b44847b379578588920cA78FbF26c0B4956C`. +You can check if this contract has already been deployed to your L1 network with a block explorer or by running the following command: + +```bash +cast codesize 0x4e59b44847b379578588920cA78FbF26c0B4956C --rpc-url $L1_RPC_URL +``` + +If the command returns `0` then the contract has not been deployed yet. +If the command returns `69` then the contract has been deployed and you can safely skip this section. + +{

Fund the factory deployer

} + +You will need to send some ETH to the address that will be used to deploy the factory contract, `0x3fAB184622Dc19b6109349B94811493BF2a45362`. +This address can only be used to deploy the factory contract and will not be used for anything else. +Send at least 1 ETH to this address on your L1 chain. + +{

Deploy the factory

} + +Using `cast`, deploy the factory contract to your L1 chain: + +```bash +cast publish --rpc-url $L1_RPC_URL 0xf8a58085174876e800830186a08080b853604580600e600039806000f350fe7fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffe03601600081602082378035828234f58015156039578182fd5b8082525050506014600cf31ba02222222222222222222222222222222222222222222222222222222222222222a02222222222222222222222222222222222222222222222222222222222222222 +``` + +{

Wait for the transaction to be mined

} + +Make sure that the transaction is included in a block on your L1 chain before continuing. + +{

Verify that the factory was deployed

} + +Run the code size check again to make sure that the factory was properly deployed: + +```bash +cast codesize 0x4e59b44847b379578588920cA78FbF26c0B4956C --rpc-url $L1_RPC_URL +``` + + + +## Deploy the L1 contracts + +Once you've configured your network, it's time to deploy the L1 contracts necessary for the functionality of the chain. + +## Using `op-deployer` + +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. + +The recommended flow for creating a genesis file and rollup configuration file on the OP Stack is as follows: + + +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 + +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`. + +2. You have created and customized an intent file in a `.deployer` directory, typically by running: + + ```bash + ./bin/op-deployer init --l1-chain-id --l2-chain-ids --workdir .deployer + ``` + + 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 + +To deploy your chain to L1, run: + +```bash +./bin/op-deployer apply --workdir .deployer \ + --l1-rpc-url \ + --private-key +``` + +* Replace `` with the L1 RPC URL. +* Replace `` with the private key of the account used for deployment. + +This command: + +* 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. + +### Step 2: Generate your L2 genesis file and rollup file + +After your L1 contracts have been deployed, generate the L2 genesis and rollup configuration files by inspecting the deployer's `state.json.` + +```bash +./bin/op-deployer inspect genesis --workdir .deployer > .deployer/genesis.json +./bin/op-deployer inspect rollup --workdir .deployer > .deployer/rollup.json +``` + +* 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). + +### Step 3: Initialize your off-chain components + +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` + +You're almost ready to run your chain! +Now you just need to run a few commands to initialize `op-geth`. +You're going to be running a Sequencer node, so you'll need to import the `Sequencer` private key that you generated earlier. +This private key is what your Sequencer will use to sign new blocks. + + + +{

Navigate to the op-geth directory

} + +```bash +cd ~/op-geth +``` + +{

Create a data directory folder

} + +```bash +mkdir datadir +``` + +{

Build the op-geth binary

} + +```bash +make geth +``` + +{

Initialize op-geth

} + +```bash +build/bin/geth init --state.scheme=hash --datadir=datadir genesis.json +``` + + + +## Start `op-geth` + +Now you'll start `op-geth`, your Execution Client. +Note that you won't start seeing any transactions until you start the Consensus Client in the next step. + + + +{

Open up a new terminal

} + +You'll need a terminal window to run `op-geth` in. + +{

Navigate to the op-geth directory

} + +```bash +cd ~/op-geth +``` + +{

Run op-geth

} + + +You're using `--gcmode=archive` to run `op-geth` here because this node will act as your Sequencer. +It's useful to run the Sequencer in archive mode because the `op-proposer` requires access to the full state. +Feel free to run other (non-Sequencer) nodes in full mode if you'd like to save disk space. Just make sure at least one other archive node exists and the `op-proposer` points to it. + + + +It's important that you've already initialized the geth node at this point as per the previous section. Failure to do this will cause startup issues between `op-geth` and `op-node`. + + +```bash +./build/bin/geth \ + --datadir ./datadir \ + --http \ + --http.corsdomain="*" \ + --http.vhosts="*" \ + --http.addr=0.0.0.0 \ + --http.api=web3,debug,eth,txpool,net,engine \ + --ws \ + --ws.addr=0.0.0.0 \ + --ws.port=8546 \ + --ws.origins="*" \ + --ws.api=debug,eth,txpool,net,engine \ + --syncmode=full \ + --gcmode=archive \ + --nodiscover \ + --maxpeers=0 \ + --networkid=42069 \ + --authrpc.vhosts="*" \ + --authrpc.addr=0.0.0.0 \ + --authrpc.port=8551 \ + --authrpc.jwtsecret=./jwt.txt \ + --rollup.disabletxpoolgossip=true +``` + + + +## Start `op-node` + +Once you've got `op-geth` running you'll need to run `op-node`. +Like Ethereum, the OP Stack has a Consensus Client (`op-node`) and an Execution Client (`op-geth`). +The Consensus Client "drives" the Execution Client over the Engine API. + + + +{

Open up a new terminal

} + +You'll need a terminal window to run the `op-node` in. + +{

Navigate to the op-node directory

} + +```bash +cd ~/optimism/op-node +``` + +{

Run op-node

} + +```bash +./bin/op-node \ + --l2=http://localhost:8551 \ + --l2.jwt-secret=./jwt.txt \ + --sequencer.enabled \ + --sequencer.l1-confs=5 \ + --verifier.l1-confs=4 \ + --rollup.config=./rollup.json \ + --rpc.addr=0.0.0.0 \ + --p2p.disable \ + --rpc.enable-admin \ + --p2p.sequencer.key=$GS_SEQUENCER_PRIVATE_KEY \ + --l1=$L1_RPC_URL \ + --l1.rpckind=$L1_RPC_KIND +``` + +Once you run this command, you should start seeing the `op-node` begin to sync L2 blocks from the L1 chain. +Once the `op-node` has caught up to the tip of the L1 chain, it'll begin to send blocks to `op-geth` for execution. +At that point, you'll start to see blocks being created inside of `op-geth`. + + +**By default, your `op-node` will try to use a peer-to-peer to speed up the synchronization process.** +If you're using a chain ID that is also being used by others, like the default chain ID for this tutorial (42069), your `op-node` will receive blocks signed by other sequencers. +These requests will fail and waste time and network resources. +**To avoid this, this tutorial starts with peer-to-peer synchronization disabled (`--p2p.disable`).** + +Once you have multiple nodes, you may want to enable peer-to-peer synchronization. +You can add the following options to the `op-node` command to enable peer-to-peer synchronization with specific nodes: + +``` + --p2p.static= \ + --p2p.listen.ip=0.0.0.0 \ + --p2p.listen.tcp=9003 \ + --p2p.listen.udp=9003 \ +``` + +You can alternatively also remove the [--p2p.static](/operators/node-operators/configuration/consensus-config#p2pstatic) option, but you may see failed requests from other chains using the same chain ID. + + + + +## Start `op-batcher` + +The `op-batcher` takes transactions from the Sequencer and publishes those transactions to L1. +Once these Sequencer transactions are included in a finalized L1 block, they're officially part of the canonical chain. +The `op-batcher` is critical! + +It's best to give the `Batcher` address at least 1 Sepolia ETH to ensure that it can continue operating without running out of ETH for gas. +Keep an eye on the balance of the `Batcher` address because it can expend ETH quickly if there are a lot of transactions to publish. + + + +{

Open up a new terminal

} + +You'll need a terminal window to run the `op-batcher` in. + +{

Navigate to the op-batcher directory

} + +```bash +cd ~/optimism/op-batcher +``` + +{

Run op-batcher

} + +```bash +./bin/op-batcher \ + --l2-eth-rpc=http://localhost:8545 \ + --rollup-rpc=http://localhost:9545 \ + --poll-interval=1s \ + --sub-safety-margin=6 \ + --num-confirmations=1 \ + --safe-abort-nonce-too-low-count=3 \ + --resubmission-timeout=30s \ + --rpc.addr=0.0.0.0 \ + --rpc.port=8548 \ + --rpc.enable-admin \ + --max-channel-duration=25 \ + --l1-eth-rpc=$L1_RPC_URL \ + --private-key=$GS_BATCHER_PRIVATE_KEY +``` + + +The [`--max-channel-duration=n`](/operators/chain-operators/configuration/batcher#set-your--op_batcher_max_channel_duration) setting tells the batcher to write all the data to L1 every `n` L1 blocks. +When it is low, transactions are written to L1 frequently and other nodes can synchronize from L1 quickly. +When it is high, transactions are written to L1 less frequently and the batcher spends less ETH. +If you want to reduce costs, either set this value to 0 to disable it or increase it to a higher value. + + + + +## Start `op-proposer` + +Now start `op-proposer`, which proposes new state roots. + + + +{

Open up a new terminal

} + +You'll need a terminal window to run the `op-proposer` in. + +{

Navigate to the op-proposer directory

} + +```bash +cd ~/optimism/op-proposer +``` + +{

Run op-proposer

} + +```bash +./bin/op-proposer \ + --poll-interval=12s \ + --rpc.port=8560 \ + --rollup-rpc=http://localhost:9545 \ + --l2oo-address=$(cat ../packages/contracts-bedrock/deployments/getting-started/.deploy | jq -r .L2OutputOracleProxy) \ + --private-key=$GS_PROPOSER_PRIVATE_KEY \ + --l1-eth-rpc=$L1_RPC_URL +``` + + + +## Connect your wallet to your chain + +You now have a fully functioning OP Stack Rollup with a Sequencer node running on `http://localhost:8545`. +You can connect your wallet to this chain the same way you'd connect your wallet to any other EVM chain. +If you need an easy way to connect to your chain, just [click here](https://chainid.link?network=opstack-getting-started). + +## Get ETH on your chain + +Once you've connected your wallet, you'll probably notice that you don't have any ETH to pay for gas on your chain. +The easiest way to deposit Sepolia ETH into your chain is to send ETH directly to the `L1StandardBridge` contract. + + + +{

Navigate to the contracts-bedrock directory

} + +```bash +cd ~/optimism/packages/contracts-bedrock +``` + +{

Get the address of the L1StandardBridgeProxy contract

} + +```bash +cat deployments/getting-started/.deploy | jq -r .L1StandardBridgeProxy +``` + +{

Send some Sepolia ETH to the L1StandardBridgeProxy contract

} + +Grab the L1 bridge proxy contract address and, using the wallet that you want to have ETH on your Rollup, send that address a small amount of ETH on Sepolia (0.1 or less is fine). +This will trigger a deposit that will mint ETH into your wallet on L2. +It may take up to 5 minutes for that ETH to appear in your wallet on L2. + + + +## See your rollup in action + +You can interact with your Rollup the same way you'd interact with any other EVM chain. +Send some transactions, deploy some contracts, and see what happens! + +## Next steps + +* Check out the [protocol specs](https://specs.optimism.io/?utm_source=op-docs&utm_medium=docs) for more detail about the rollup protocol. +* If you run into any problems, please visit the [Chain Operators Troubleshooting Guide](/operators/chain-operators/management/troubleshooting) for help. diff --git a/pages/operators/chain-operators/tutorials/dispute-games.mdx b/pages/chain-operators/tutorials/dispute-games.mdx similarity index 100% rename from pages/operators/chain-operators/tutorials/dispute-games.mdx rename to pages/chain-operators/tutorials/dispute-games.mdx diff --git a/pages/operators/chain-operators/tutorials/integrating-da-layer.mdx b/pages/chain-operators/tutorials/integrating-da-layer.mdx similarity index 100% rename from pages/operators/chain-operators/tutorials/integrating-da-layer.mdx rename to pages/chain-operators/tutorials/integrating-da-layer.mdx diff --git a/pages/chain-operators/tutorials/meta.json b/pages/chain-operators/tutorials/meta.json new file mode 100644 index 000000000..9db55891c --- /dev/null +++ b/pages/chain-operators/tutorials/meta.json @@ -0,0 +1,11 @@ +{ + "absolute-prestate": "Generating absolute prestate and preimage files", + "adding-derivation-attributes": "Adding attributes to the derivation function", + "adding-precompiles": "Adding a precompile", + "chain-dev-net": "Running a Local Development Environment", + "create-l2-rollup": "Creating your own L2 rollup testnet", + "dispute-games": "Deploying new dispute games with OPCM", + "integrating-da-layer": "Integrating a new DA layer with Alt-DA", + "migrating-permissionless": "Migrating to permissionless fault proofs on OP Stack", + "modifying-predeploys": "Modifying predeployed contracts" +} diff --git a/pages/operators/chain-operators/tutorials/migrating-permissionless.mdx b/pages/chain-operators/tutorials/migrating-permissionless.mdx similarity index 100% rename from pages/operators/chain-operators/tutorials/migrating-permissionless.mdx rename to pages/chain-operators/tutorials/migrating-permissionless.mdx diff --git a/pages/operators/chain-operators/tutorials/modifying-predeploys.mdx b/pages/chain-operators/tutorials/modifying-predeploys.mdx similarity index 100% rename from pages/operators/chain-operators/tutorials/modifying-predeploys.mdx rename to pages/chain-operators/tutorials/modifying-predeploys.mdx diff --git a/pages/stack/fault-proofs/cannon.mdx b/pages/concepts/architecture/fault-proofs/cannon.mdx similarity index 100% rename from pages/stack/fault-proofs/cannon.mdx rename to pages/concepts/architecture/fault-proofs/cannon.mdx diff --git a/pages/stack/fault-proofs/challenger.mdx b/pages/concepts/architecture/fault-proofs/challenger.mdx similarity index 99% rename from pages/stack/fault-proofs/challenger.mdx rename to pages/concepts/architecture/fault-proofs/challenger.mdx index c9088135c..06f6e7d1a 100644 --- a/pages/stack/fault-proofs/challenger.mdx +++ b/pages/concepts/architecture/fault-proofs/challenger.mdx @@ -101,7 +101,7 @@ The `FaultDisputeGame` does not put a time cap on resolution - because of the li ## Next steps -* Ready to get started? Read our guide on how to [configure `op-challenger` on your OP Stack chain](/operators/chain-operators/deploy/op-challenger). +* Ready to get started? Read our guide on how to [configure `op-challenger` on your OP Stack chain](/operators/chain-operators/tools/op-challenger). * For more info about how `op-challenger` works under the hood, [check out the specs](https://specs.optimism.io/fault-proof/stage-one/honest-challenger-fdg.html?utm_source=op-docs&utm_medium=docs). ## FAQs diff --git a/pages/stack/fault-proofs/fp-components.mdx b/pages/concepts/architecture/fault-proofs/components.mdx similarity index 100% rename from pages/stack/fault-proofs/fp-components.mdx rename to pages/concepts/architecture/fault-proofs/components.mdx diff --git a/pages/stack/fault-proofs/explainer.mdx b/pages/concepts/architecture/fault-proofs/explainer.mdx similarity index 93% rename from pages/stack/fault-proofs/explainer.mdx rename to pages/concepts/architecture/fault-proofs/explainer.mdx index 19960474e..5960e3c11 100644 --- a/pages/stack/fault-proofs/explainer.mdx +++ b/pages/concepts/architecture/fault-proofs/explainer.mdx @@ -86,17 +86,11 @@ Due to the permissionless structure where many different actors can participate Users can complete the full withdrawal cycle without depending on any privileged action. The Guardian role can override the system by pausing withdrawals, blacklisting games, or reverting to a permissioned system. As a result, the trust assumption is reduced to requiring only that the Guardian role does not act to intervene, inline with the stage 1 requirements. - ### Since the roles of proposer and challenger will be open to everyone, are guides available outlining the best practices for running them? It's not expected that normal users run `op-proposer` to regularly propose output roots. -Users would generally just propose a single output root if they need to withdraw and the chain operator isn't proposing outputs for them via direct calls to the `DisputeGameFactory` via Etherscan. - - -The [`create-game`](https://github.com/ethereum-optimism/optimism/tree/develop/op-challenger#create-game) subcommand of `op-challenger` is **for testing purposes only** and should not be used in production environments. It is not intended as a replacement for proper `op-proposer` infrastructure. - - -For detailed guidance on running `op-challenger`, see the [OP-Challenger explainer](/stack/fault-proofs/challenger) and [how to configure challenger for your chain](/operators/chain-operators/deploy/op-challenger). +Users would generally just propose a single output root if they need to withdraw and the chain operator isn't proposing outputs for them via direct calls to the `DisputeGameFactory` via Etherscan or using the [`create-game`](https://github.com/ethereum-optimism/optimism/tree/develop/op-challenger#create-game) subcommand of `op-challenger`. +Documentation for `op-challenger` is forthcoming. ### How much ETH should a chain operator put aside to operate the Fault Proof System? diff --git a/pages/concepts/architecture/fault-proofs/meta.json b/pages/concepts/architecture/fault-proofs/meta.json new file mode 100644 index 000000000..e1510bc3e --- /dev/null +++ b/pages/concepts/architecture/fault-proofs/meta.json @@ -0,0 +1,6 @@ +{ + "cannon": "Fault proof VM: Cannon", + "challenger": "OP-Challenger explainer", + "components": "FP system components", + "explainer": "Fault proofs explainer" +} diff --git a/pages/stack/rollup/derivation-pipeline.mdx b/pages/concepts/architecture/rollups/derivation-pipeline.mdx similarity index 100% rename from pages/stack/rollup/derivation-pipeline.mdx rename to pages/concepts/architecture/rollups/derivation-pipeline.mdx diff --git a/pages/concepts/architecture/rollups/meta.json b/pages/concepts/architecture/rollups/meta.json new file mode 100644 index 000000000..54fd3c6b7 --- /dev/null +++ b/pages/concepts/architecture/rollups/meta.json @@ -0,0 +1,5 @@ +{ + "derivation-pipeline": "Derivation pipeline", + "outages": "Sequencer outages", + "overview": "Rollup protocol overview" +} diff --git a/pages/stack/rollup/outages.mdx b/pages/concepts/architecture/rollups/outages.mdx similarity index 100% rename from pages/stack/rollup/outages.mdx rename to pages/concepts/architecture/rollups/outages.mdx diff --git a/pages/stack/rollup/overview.mdx b/pages/concepts/architecture/rollups/overview.mdx similarity index 97% rename from pages/stack/rollup/overview.mdx rename to pages/concepts/architecture/rollups/overview.mdx index 82f74f330..8841e0081 100644 --- a/pages/stack/rollup/overview.mdx +++ b/pages/concepts/architecture/rollups/overview.mdx @@ -102,7 +102,7 @@ Withdrawals (the term is used for any OP Mainnet to Ethereum message) have three 1. You initialize withdrawals with an L2 transaction. -2. Wait for the next output root to be submitted to L1 and then submit the withdrawal proof using `proveWithdrawalTransaction`. +2. Wait for the next output root to be submitted to L1 (you can see this on [the SDK](https://sdk.optimism.io)) and then submit the withdrawal proof using `proveWithdrawalTransaction`. This new step enables offchain monitoring of the withdrawals, which makes it easier to identify incorrect withdrawals or output roots. This protects OP Mainnet users against a whole class of potential bridge vulnerabilities. diff --git a/pages/stack/transactions/cross-domain.mdx b/pages/concepts/bridging/cross-domain.mdx similarity index 100% rename from pages/stack/transactions/cross-domain.mdx rename to pages/concepts/bridging/cross-domain.mdx diff --git a/pages/concepts/bridging/meta.json b/pages/concepts/bridging/meta.json new file mode 100644 index 000000000..9fd0601d8 --- /dev/null +++ b/pages/concepts/bridging/meta.json @@ -0,0 +1,3 @@ +{ + "cross-domain": "Cross-Domain Overview" +} diff --git a/pages/get-started/interop.mdx b/pages/concepts/interoperability/getting-started.mdx similarity index 100% rename from pages/get-started/interop.mdx rename to pages/concepts/interoperability/getting-started.mdx diff --git a/pages/concepts/interoperability/meta.json b/pages/concepts/interoperability/meta.json new file mode 100644 index 000000000..fbfd54906 --- /dev/null +++ b/pages/concepts/interoperability/meta.json @@ -0,0 +1,6 @@ +{ + "getting-started": "Superchain Interoperability explainer", + "overview": "Superchain interoperability explainer", + "superchain-erc20": "SuperchainERC20", + "superchain-eth": "Superchain ETH Bridge" +} diff --git a/pages/interop/explainer.mdx b/pages/concepts/interoperability/overview.mdx similarity index 100% rename from pages/interop/explainer.mdx rename to pages/concepts/interoperability/overview.mdx diff --git a/pages/interop/superchain-erc20.mdx b/pages/concepts/interoperability/superchain-erc20.mdx similarity index 100% rename from pages/interop/superchain-erc20.mdx rename to pages/concepts/interoperability/superchain-erc20.mdx diff --git a/pages/interop/superchain-eth-bridge.mdx b/pages/concepts/interoperability/superchain-eth.mdx similarity index 100% rename from pages/interop/superchain-eth-bridge.mdx rename to pages/concepts/interoperability/superchain-eth.mdx diff --git a/pages/stack/research/block-time-research.mdx b/pages/concepts/research/block-time.mdx similarity index 100% rename from pages/stack/research/block-time-research.mdx rename to pages/concepts/research/block-time.mdx diff --git a/pages/concepts/research/meta.json b/pages/concepts/research/meta.json new file mode 100644 index 000000000..4acde2d19 --- /dev/null +++ b/pages/concepts/research/meta.json @@ -0,0 +1,3 @@ +{ + "block-time-research": "Block time research" +} diff --git a/pages/stack/security/audits-report.mdx b/pages/concepts/security/audits-report.mdx similarity index 100% rename from pages/stack/security/audits-report.mdx rename to pages/concepts/security/audits-report.mdx diff --git a/pages/stack/security/faq-sec-model.mdx b/pages/concepts/security/faq-sec-model.mdx similarity index 100% rename from pages/stack/security/faq-sec-model.mdx rename to pages/concepts/security/faq-sec-model.mdx diff --git a/pages/stack/security/faq.mdx b/pages/concepts/security/faq.mdx similarity index 100% rename from pages/stack/security/faq.mdx rename to pages/concepts/security/faq.mdx diff --git a/pages/stack/fault-proofs/fp-security.mdx b/pages/concepts/security/fp-security.mdx similarity index 100% rename from pages/stack/fault-proofs/fp-security.mdx rename to pages/concepts/security/fp-security.mdx diff --git a/pages/interop/interop-security.mdx b/pages/concepts/security/interop-security.mdx similarity index 100% rename from pages/interop/interop-security.mdx rename to pages/concepts/security/interop-security.mdx diff --git a/pages/concepts/security/meta.json b/pages/concepts/security/meta.json new file mode 100644 index 000000000..21f5190ee --- /dev/null +++ b/pages/concepts/security/meta.json @@ -0,0 +1,9 @@ +{ + "audits-report": "Audit reports", + "faq-sec-model": "OP Stack security model", + "faq": "OP Stack security FAQs", + "fp-security": "Fault proofs Mainnet security", + "interop-security": "Crosschain security measures for safe interoperability", + "pause": "Pausing the bridge", + "security-policy": "Security policy and bug bounty program" +} diff --git a/pages/stack/security/pause.mdx b/pages/concepts/security/pause.mdx similarity index 100% rename from pages/stack/security/pause.mdx rename to pages/concepts/security/pause.mdx diff --git a/pages/stack/security/security-policy.mdx b/pages/concepts/security/security-policy.mdx similarity index 100% rename from pages/stack/security/security-policy.mdx rename to pages/concepts/security/security-policy.mdx diff --git a/pages/stack/beta-features.mdx b/pages/concepts/stack/beta-features.mdx similarity index 100% rename from pages/stack/beta-features.mdx rename to pages/concepts/stack/beta-features.mdx diff --git a/pages/stack/design-principles.mdx b/pages/concepts/stack/design-principles.mdx similarity index 100% rename from pages/stack/design-principles.mdx rename to pages/concepts/stack/design-principles.mdx diff --git a/pages/stack/differences.mdx b/pages/concepts/stack/differences.mdx similarity index 100% rename from pages/stack/differences.mdx rename to pages/concepts/stack/differences.mdx diff --git a/pages/stack/fact-sheet.mdx b/pages/concepts/stack/fact-sheet.mdx similarity index 100% rename from pages/stack/fact-sheet.mdx rename to pages/concepts/stack/fact-sheet.mdx diff --git a/pages/concepts/stack/meta.json b/pages/concepts/stack/meta.json new file mode 100644 index 000000000..4ddaff06f --- /dev/null +++ b/pages/concepts/stack/meta.json @@ -0,0 +1,9 @@ +{ + "beta-features": "Beta Features", + "design-principles": "Design philosophy & design principles", + "differences": "Differences between Ethereum and OP Stack Chains", + "fact-sheet": "Overview", + "network-upgrades": "Network upgrades", + "op-stack": "Getting started with the OP Stack", + "smart-contracts": "Smart Contracts" +} diff --git a/pages/operators/node-operators/network-upgrades.mdx b/pages/concepts/stack/network-upgrades.mdx similarity index 100% rename from pages/operators/node-operators/network-upgrades.mdx rename to pages/concepts/stack/network-upgrades.mdx diff --git a/pages/get-started/op-stack.mdx b/pages/concepts/stack/op-stack.mdx similarity index 100% rename from pages/get-started/op-stack.mdx rename to pages/concepts/stack/op-stack.mdx diff --git a/pages/stack/getting-started.mdx b/pages/concepts/stack/overview similarity index 100% rename from pages/stack/getting-started.mdx rename to pages/concepts/stack/overview diff --git a/pages/stack/smart-contracts.mdx b/pages/concepts/stack/smart-contracts.mdx similarity index 100% rename from pages/stack/smart-contracts.mdx rename to pages/concepts/stack/smart-contracts.mdx diff --git a/pages/stack/transactions/deposit-flow.mdx b/pages/concepts/transactions/deposit-flow.mdx similarity index 100% rename from pages/stack/transactions/deposit-flow.mdx rename to pages/concepts/transactions/deposit-flow.mdx diff --git a/pages/stack/transactions/fees.mdx b/pages/concepts/transactions/fees.mdx similarity index 100% rename from pages/stack/transactions/fees.mdx rename to pages/concepts/transactions/fees.mdx diff --git a/pages/stack/transactions/forced-transaction.mdx b/pages/concepts/transactions/forced-transaction.mdx similarity index 100% rename from pages/stack/transactions/forced-transaction.mdx rename to pages/concepts/transactions/forced-transaction.mdx diff --git a/pages/concepts/transactions/meta.json b/pages/concepts/transactions/meta.json new file mode 100644 index 000000000..a39f8d877 --- /dev/null +++ b/pages/concepts/transactions/meta.json @@ -0,0 +1,8 @@ +{ + "deposit-flow": "Deposit flow", + "fees": "Transaction fees on OP Mainnet", + "forced-transaction": "Forced Transaction", + "transaction-finality": "Transaction finality", + "transaction-flow": "Transaction flow", + "withdrawal-flow": "Withdrawal flow" +} diff --git a/pages/stack/transactions/transaction-finality.mdx b/pages/concepts/transactions/transaction-finality.mdx similarity index 100% rename from pages/stack/transactions/transaction-finality.mdx rename to pages/concepts/transactions/transaction-finality.mdx diff --git a/pages/stack/transactions/transaction-flow.mdx b/pages/concepts/transactions/transaction-flow.mdx similarity index 100% rename from pages/stack/transactions/transaction-flow.mdx rename to pages/concepts/transactions/transaction-flow.mdx diff --git a/pages/stack/transactions/withdrawal-flow.mdx b/pages/concepts/transactions/withdrawal-flow.mdx similarity index 100% rename from pages/stack/transactions/withdrawal-flow.mdx rename to pages/concepts/transactions/withdrawal-flow.mdx diff --git a/pages/connect/_meta.json b/pages/connect/_meta.json deleted file mode 100644 index 4d04b9fe8..000000000 --- a/pages/connect/_meta.json +++ /dev/null @@ -1,9 +0,0 @@ -{ - "contribute": "Contribute", - "resources": "Resources", - "live-support": { - "title": "Get Launch Support", - "href": "https://share.hsforms.com/1yENj8CV9TzGYBASD0JC8_gqoshb", - "newWindow": true -} -} diff --git a/pages/connect/contribute.mdx b/pages/connect/contribute.mdx deleted file mode 100644 index 211af4798..000000000 --- a/pages/connect/contribute.mdx +++ /dev/null @@ -1,30 +0,0 @@ ---- -title: Contribute -description: >- - Documentation covering Docs Contribute, Stack Contribute, Style Guide in the - Contribute section of the OP Stack ecosystem. -lang: en-US -content_type: guide -topic: contribute -personas: - - app-developer - - protocol-developer - - chain-operator - - node-operator -categories: - - security-council - - blockspace-charters -is_imported_content: 'false' ---- - -import { Card, Cards } from 'nextra/components' - -# Contribute - -Documentation covering Docs Contribute, Stack Contribute, Style Guide in the Contribute section of the OP Stack ecosystem. - - - - - - diff --git a/pages/connect/contribute/_meta.json b/pages/connect/contribute/_meta.json deleted file mode 100644 index dbfae0745..000000000 --- a/pages/connect/contribute/_meta.json +++ /dev/null @@ -1,5 +0,0 @@ -{ - "docs-contribute": "Contribute to Optimism docs", - "stack-contribute": "Contribute to OP Stack", - "style-guide": "Docs style guide" -} \ No newline at end of file diff --git a/pages/connect/resources/_meta.json b/pages/connect/resources/_meta.json deleted file mode 100644 index 97804169a..000000000 --- a/pages/connect/resources/_meta.json +++ /dev/null @@ -1,8 +0,0 @@ -{ - "changelog": { - "title": "Changelog", - "href": "https://github.com/ethereum-optimism/optimism/releases", - "newWindow": true - }, - "glossary": "Glossary" -} \ No newline at end of file diff --git a/pages/core-contributers/getting-started/meta.json b/pages/core-contributers/getting-started/meta.json new file mode 100644 index 000000000..f3ecf053c --- /dev/null +++ b/pages/core-contributers/getting-started/meta.json @@ -0,0 +1,3 @@ +{ + "stack-contribute": "Contribute to the OP Stack" +} diff --git a/pages/connect/contribute/stack-contribute.mdx b/pages/core-contributers/getting-started/stack-contribute.mdx similarity index 100% rename from pages/connect/contribute/stack-contribute.mdx rename to pages/core-contributers/getting-started/stack-contribute.mdx diff --git a/pages/connect/contribute/docs-contribute.mdx b/pages/core-contributers/guides/documentation.mdx similarity index 100% rename from pages/connect/contribute/docs-contribute.mdx rename to pages/core-contributers/guides/documentation.mdx diff --git a/pages/core-contributers/guides/meta.json b/pages/core-contributers/guides/meta.json new file mode 100644 index 000000000..6a9eb21bc --- /dev/null +++ b/pages/core-contributers/guides/meta.json @@ -0,0 +1,3 @@ +{ + "documentation": "Contribute to Optimism Docs" +} diff --git a/pages/core-contributers/reference/meta.json b/pages/core-contributers/reference/meta.json new file mode 100644 index 000000000..a6ac0eab0 --- /dev/null +++ b/pages/core-contributers/reference/meta.json @@ -0,0 +1,4 @@ +{ + "mips": "Fault proof VM: MIPS.sol", + "style-guide": "Docs style guide" +} diff --git a/pages/stack/fault-proofs/mips.mdx b/pages/core-contributers/reference/mips.mdx similarity index 100% rename from pages/stack/fault-proofs/mips.mdx rename to pages/core-contributers/reference/mips.mdx diff --git a/pages/connect/contribute/style-guide.mdx b/pages/core-contributers/reference/style-guide.mdx similarity index 100% rename from pages/connect/contribute/style-guide.mdx rename to pages/core-contributers/reference/style-guide.mdx diff --git a/pages/developers/testing/meta.json b/pages/developers/testing/meta.json new file mode 100644 index 000000000..e1d27af25 --- /dev/null +++ b/pages/developers/testing/meta.json @@ -0,0 +1,3 @@ +{ + "public-devnets": "Overview" +} diff --git a/pages/stack/public-devnets.mdx b/pages/developers/testing/public-devnets.mdx similarity index 100% rename from pages/stack/public-devnets.mdx rename to pages/developers/testing/public-devnets.mdx diff --git a/pages/generate-meta.sh b/pages/generate-meta.sh new file mode 100755 index 000000000..680be8b5c --- /dev/null +++ b/pages/generate-meta.sh @@ -0,0 +1,105 @@ +#!/bin/bash + +# Script to generate meta.json files for each subdirectory in /pages/ +# Run this script from the /pages/ directory + +# Function to extract title from MDX file frontmatter +extract_title() { + local file="$1" + # Extract title from frontmatter using awk + awk ' + BEGIN { in_frontmatter = 0 } + /^---$/ { + if (in_frontmatter == 0) { + in_frontmatter = 1 + } else { + exit + } + next + } + in_frontmatter && /^title:/ { + # Extract everything after "title:" and remove leading/trailing whitespace and quotes + gsub(/^title:[ \t]*/, "") + gsub(/^["'"'"']|["'"'"']$/, "") + gsub(/^[ \t]+|[ \t]+$/, "") + print + exit + } + ' "$file" +} + +# Function to create meta.json for a directory +create_meta_json() { + local dir="$1" + local meta_file="$dir/meta.json" + + echo "Processing directory: $dir" + + # Start building the JSON object + echo "{" > "$meta_file" + + local first_entry=true + + # Find all .mdx files in the current directory (not subdirectories) + while IFS= read -r -d '' mdx_file; do + # Get the filename without extension + local basename=$(basename "$mdx_file" .mdx) + + # Extract title from the MDX file + local title=$(extract_title "$mdx_file") + + # If no title found, skip this file + if [[ -z "$title" ]]; then + echo " Warning: No title found in $mdx_file, skipping..." + continue + fi + + # Add comma if not the first entry + if [[ "$first_entry" != true ]]; then + echo "," >> "$meta_file" + fi + + # Add the entry to meta.json + printf ' "%s": "%s"' "$basename" "$title" >> "$meta_file" + first_entry=false + + echo " Added: $basename -> $title" + + done < <(find "$dir" -maxdepth 1 -name "*.mdx" -type f -print0 | sort -z) + + # Close the JSON object + echo "" >> "$meta_file" + echo "}" >> "$meta_file" + + # Only keep the meta.json file if it has actual content + if [[ "$first_entry" == true ]]; then + echo " No MDX files found in $dir, removing empty meta.json" + rm "$meta_file" + else + echo " Created: $meta_file" + fi +} + +# Main script execution +echo "Starting meta.json generation..." +echo "Current directory: $(pwd)" + +# Check if we're in the right place +if [[ ! -d "." ]]; then + echo "Error: Current directory doesn't exist" + exit 1 +fi + +# Find all directories (including current directory and subdirectories) +while IFS= read -r -d '' dir; do + # Skip if directory contains no .mdx files + if ! find "$dir" -maxdepth 1 -name "*.mdx" -type f | grep -q .; then + continue + fi + + create_meta_json "$dir" + echo "" + +done < <(find . -type d -print0 | sort -z) + +echo "meta.json generation complete!" \ No newline at end of file diff --git a/pages/get-started/_meta.json b/pages/get-started/_meta.json deleted file mode 100644 index 7aa86dc66..000000000 --- a/pages/get-started/_meta.json +++ /dev/null @@ -1,34 +0,0 @@ -{ - "--- GetStarted": { - "title": "Get Started", - "type": "separator" - }, - "superchain": "Superchain", - "op-stack": "OP Stack", - "interop": "Superchain interoperability", - "governance": { - "title": "Optimism Governance", - "href": "https://community.optimism.io/docs/governance/?utm_source=op-docs&utm_medium=docs", - "newWindow": true - }, - "+++ BuilderGuides": { - "title": "", - "type": "separator" - }, - "--- BuilderGuides": { - "title": "Builder Guides", - "type": "separator" - }, - "app-devs": { - "title": "App Developers", - "href": "/app-developers/get-started" - }, - "chain-ops": { - "title": "Chain Operators", - "href": "/operators/chain-operators/architecture" - }, - "node-ops": { - "title": "Node Operators", - "href": "/operators/node-operators/architecture" - } -} \ No newline at end of file diff --git a/pages/superchain/blockspace-charter.mdx b/pages/governance/blockspace-charter.mdx similarity index 100% rename from pages/superchain/blockspace-charter.mdx rename to pages/governance/blockspace-charter.mdx diff --git a/pages/governance/meta.json b/pages/governance/meta.json new file mode 100644 index 000000000..53af59afe --- /dev/null +++ b/pages/governance/meta.json @@ -0,0 +1,3 @@ +{ + "blockspace-charter": "The Blockspace and Standard Rollup Charters" +} diff --git a/pages/index.mdx b/pages/index.mdx index 80dcf7ef9..4eadb7c38 100644 --- a/pages/index.mdx +++ b/pages/index.mdx @@ -28,7 +28,7 @@ import { Cards, Card } from 'nextra/components' # Welcome to the Optimism Docs -Build with the OP Stack. Explore Optimism docs for tutorials, examples, and resources to build your chain or deploy apps. +Welcome to the Optimism Docs, the unified home of the [Optimism Collective's](/connect/resources/glossary#optimism-collective) technical documentation and information about the [OP Stack](/stack/getting-started). Information about the Optimism Collective's governance, community, and mission can be found on the [Optimism Community Hub](https://community.optimism.io/docs/governance/?utm_source=op-docs&utm_medium=docs). ## Grow your app with Superchain interoperability! diff --git a/pages/interop/_meta.json b/pages/interop/_meta.json deleted file mode 100644 index 003689cd5..000000000 --- a/pages/interop/_meta.json +++ /dev/null @@ -1,26 +0,0 @@ -{ - "--- Get started": { - "title": "Get started", - "type": "separator" - }, - "get-started": "Build interoperable apps on Superchain", - "starter-kit": "SuperchainERC20 starter kit", - "--- Superchain interoperability": { - "title": "Superchain interoperability", - "type": "separator" - }, - "explainer": "Superchain interop explainer", - "predeploy": "Superchain interop predeploys", - "message-passing": "Superchain interop message passing", - "message-expiration": "Message expiration", - "estimate-costs": "Cost of interop messages", - "reading-logs": "Reading logs", - "op-supervisor": "OP Supervisor", - "superchain-eth-bridge": "Superchain ETH bridge", - "superchain-erc20": "SuperchainERC20", - "compatible-tokens": "Superchain interop compatible tokens", - "reorg": "Superchain interop reorg awareness", - "interop-security": "Superchain interop transaction safety", - "tools": "Tools", - "tutorials": "Tutorials" -} diff --git a/pages/interop/tools.mdx b/pages/interop/tools.mdx deleted file mode 100644 index d69c99caf..000000000 --- a/pages/interop/tools.mdx +++ /dev/null @@ -1,29 +0,0 @@ ---- -title: Interop -description: >- - Documentation covering Interop devnet, Supersim in the Interop section of the - OP Stack ecosystem. -lang: en-US -content_type: landing-page -topic: interop -personas: - - protocol-developer -categories: - - testnet - - protocol - - interoperability -is_imported_content: 'false' ---- - -import { Card, Cards } from 'nextra/components' - -# Interop - -Documentation covering Interop devnet, Supersim in the Interop section of the OP Stack ecosystem. - - - } /> - - } /> - - diff --git a/pages/interop/tools/_meta.json b/pages/interop/tools/_meta.json deleted file mode 100644 index 65bf56165..000000000 --- a/pages/interop/tools/_meta.json +++ /dev/null @@ -1,4 +0,0 @@ -{ - "devnet": "Superchain interop devnet", - "supersim": "Supersim Multichain Development Environment" -} diff --git a/pages/interop/tools/supersim.mdx b/pages/interop/tools/supersim.mdx deleted file mode 100644 index f5706793c..000000000 --- a/pages/interop/tools/supersim.mdx +++ /dev/null @@ -1,25 +0,0 @@ ---- -title: Supersim -description: >- - Learn how to use the Supersim local dev environment tool designed to simulate - the Optimism Superchain. -lang: en-US -content_type: guide -topic: supersim -personas: - - protocol-developer - - app-developer -categories: - - devnet - - local-devnet - - testing - - interoperability - - cross-chain-messaging - - supersim - - protocol -is_imported_content: 'true' ---- - -import Supersim from '@/pages/app-developers/tools/supersim.mdx' - - diff --git a/pages/interop/tutorials.mdx b/pages/interop/tutorials.mdx deleted file mode 100644 index 6537a9bfd..000000000 --- a/pages/interop/tutorials.mdx +++ /dev/null @@ -1,41 +0,0 @@ ---- -title: Interop tutorials -description: Documentation covering Interop related tutorials. -lang: en-US -content_type: landing-page -topic: interop-tutorials -personas: - - protocol-developer - - app-developer -categories: - - protocol - - interoperability - - cross-chain-messaging - - tutorial -is_imported_content: 'false' ---- - -import { Card, Cards } from 'nextra/components' - -# Interop tutorials - -Documentation covering Interop related tutorials. - - - } /> - - } /> - - } /> - - } /> - - } /> - - } /> - - } /> - - } /> - - diff --git a/pages/interop/tutorials/_meta.json b/pages/interop/tutorials/_meta.json deleted file mode 100644 index 04185eda4..000000000 --- a/pages/interop/tutorials/_meta.json +++ /dev/null @@ -1,12 +0,0 @@ -{ - "message-passing": "Interop message passing", - "deploy-superchain-erc20": "Deploying a SuperchainERC20", - "transfer-superchainERC20": "Transferring a SuperchainERC20", - "custom-superchain-erc20": "Custom SuperchainERC20 tokens", - "bridge-crosschain-eth": "Bridging native cross-chain ETH transfers", - "verify-messages": "Verifying log entries", - "contract-calls": "Making crosschain contract calls (ping pong)", - "event-reads": "Making crosschain event reads (tic-tac-toe)", - "event-contests": "Deploying crosschain event composability (contests)", - "upgrade-to-superchain-erc20": "Upgrade to SuperchainERC20" -} diff --git a/pages/interop/tutorials/message-passing/_meta.json b/pages/interop/tutorials/message-passing/_meta.json deleted file mode 100644 index 7401d0da8..000000000 --- a/pages/interop/tutorials/message-passing/_meta.json +++ /dev/null @@ -1,3 +0,0 @@ -{ - "manual-relay": "Relay transactions manually" -} diff --git a/pages/interop/tutorials/upgrade-to-superchain-erc20.mdx b/pages/interop/tutorials/upgrade-to-superchain-erc20.mdx deleted file mode 100644 index 89232c9cd..000000000 --- a/pages/interop/tutorials/upgrade-to-superchain-erc20.mdx +++ /dev/null @@ -1,58 +0,0 @@ ---- -title: Upgrading ERC20 to SuperchainERC20 -lang: en-US -description: Tutorial on how to take an existing ERC20 and upgrade it to SuperchainERC20. -topic: Interoperability -personas: [Developer] -categories: [Tutorial, Interop] -content_type: article ---- - -import { Callout, Steps, Card, Cards } from 'nextra/components' - - - The SuperchainERC20 standard is ready for production deployments. - Please note that the OP Stack interoperability upgrade, required for crosschain messaging, is currently still in active development. - - -# Upgrading ERC20 to SuperchainERC20 - -## Overview - -This guide explains how to upgrade an ERC20 to a [`SuperchainERC20`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/src/L2/SuperchainERC20.sol) that can teleport across the [Superchain interop cluster](/interop/explainer#superchain-interop-cluster) using the [`SuperchainTokenBridge`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/src/L2/SuperchainTokenBridge.sol) contract. For more information on how it works, [see the explainer](/interop/superchain-erc20). - -{/* - -I put this warning here when we don't have it on most pages because this tutorial -has, IMHO, code that is a lot more likely to be used in production. It doesn't just -show what is possible, it does the exact job needed. - -*/} - -There are several ways to upgrade an existing ERC20 for interop, depending on your circumstances: - -{/* - -* If you can upgrade the existing contract, but the address is not available on other chains? In that case, use a custom bridge - -upgrade-to-superchain-erc20/custom-bridge. - -*/} - -| When To Use | Action | -| ----------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------- | -| You can install a new ERC20 contract | [**Deploy New SuperchainERC20 contracts** directly](/interop/tutorials/deploy-superchain-erc20) | -| Existing ERC20 contract cannot be upgraded | [**Implement Lockbox Solution** to bridge between tokens](/interop/tutorials/upgrade-to-superchain-erc20/lockbox) | -| You can deploy to other chains using the same proxy address | [**Perform Contract Upgrade** while maintaining address](/interop/tutorials/upgrade-to-superchain-erc20/contract-upgrade) | - - - } /> - - } /> - - -## Next steps - -* Deploy a [SuperchainERC20](/interop/tutorials/deploy-superchain-erc20) to the Superchain -* [Learn more about SuperchainERC20](/interop/superchain-erc20) -* Build a [revolutionary app](/app-developers/get-started) that uses multiple blockchains within the Superchain diff --git a/pages/interop/tutorials/upgrade-to-superchain-erc20/_meta.json b/pages/interop/tutorials/upgrade-to-superchain-erc20/_meta.json deleted file mode 100644 index 29d8c190c..000000000 --- a/pages/interop/tutorials/upgrade-to-superchain-erc20/_meta.json +++ /dev/null @@ -1,4 +0,0 @@ -{ - "contract-upgrade": "Contract upgrade", - "lockbox": "Lockboxes for permissionless interop" -} diff --git a/pages/interop/tutorials/upgrade-to-superchain-erc20/contract-upgrade.mdx b/pages/interop/tutorials/upgrade-to-superchain-erc20/contract-upgrade.mdx deleted file mode 100644 index 5a7c65ccc..000000000 --- a/pages/interop/tutorials/upgrade-to-superchain-erc20/contract-upgrade.mdx +++ /dev/null @@ -1,328 +0,0 @@ ---- -title: Contract upgrade -lang: en-US -description: Tutorial on how to upgrade a proxied ERC20 contract for use with Superchain interop. -topic: Interoperability -personas: [Developer] -categories: [Tutorial, Interop] -content_type: article ---- - -import { Callout, Steps, Tabs } from 'nextra/components' - - - The SuperchainERC20 standard is ready for production deployments. - Please note that the OP Stack interoperability upgrade, required for cross-chain messaging, is currently still in active development. - - -# Contract upgrade - -## Overview - -This guide explains how to upgrade an ERC20 to a [`SuperchainERC20`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/src/L2/SuperchainERC20.sol) that can teleport across the [Superchain interop cluster](/interop/explainer#superchain-interop-cluster) when the original ERC20 contract was placed behind a proxy to enable future upgrades. - -
- About this tutorial - - **What you'll learn** - - * How to upgrade an ERC20 token to enable Superchain interoperability when it was deployed with a proxy. - - **Prerequisite knowledge** - - * You should already know how to [deploy SuperchainERC20 tokens with custom code](/interop/tutorials/). -
- - - The code on the documentation site is sample code, *not* production code. - This means that we ran it, and it works as advertised. - However, it did not pass through the rigorous audit process that most Optimism code undergoes. - You're welcome to use it, but if you need it for production purposes you should get it audited first. - - -{/* - -I put this warning here, when we don't have it on most pages, because this tutorial -has code that is a lot more likely to be used in production. It doesn't just -show what is possible, it does the exact job needed. - -*/} - -### What you'll do - -* Upgrade an existing ERC20 that uses [the proxy pattern](https://docs.openzeppelin.com/upgrades-plugins/proxies) to comply with interop requirements (with the proper authority). - -## How beacon proxies work - -```mermaid -sequenceDiagram - Actor User - User->>BeaconProxy: transfer(
, ) - BeaconProxy->>UpgradeableBeacon: What is the implementation address? - UpgradeableBeacon->>BeaconProxy: It is 0xBAD0...60A7 - BeaconProxy->>0xBAD0...60A7: transfer(
, ) -``` - -A [beacon proxy](https://docs.openzeppelin.com/contracts/3.x/api/proxy#BeaconProxy) uses two contracts. -The [`UpgradeableBeacon`](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/proxy/beacon/UpgradeableBeacon.sol) contract holds the address of the implementation contract. -The [`BeaconProxy`](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/proxy/beacon/BeaconProxy.sol) contract is the one called for the functionality, the one that holds the storage. -When a user (or another contract) calls `BeaconProxy`, it asks `UpgradeableBeacon` for the implementation address and then uses [`delegatecall`](https://www.evm.codes/?fork=cancun#f4) to call that contract. - -```mermaid -sequenceDiagram - Actor User - Actor Owner - Participant BeaconProxy - Participant 0x600D...60A7 - Owner->>UpgradeableBeacon: Your new implementation address is 0x600D...60A7 - User->>BeaconProxy: transfer(
, ) - BeaconProxy->>UpgradeableBeacon: What is the implementation address? - UpgradeableBeacon->>BeaconProxy: It is 0x600D...60A7 - BeaconProxy->>0x600D...60A7: transfer(
, ) -``` - -To upgrade the contract, an authorized address (typically the `Owner`) calls `UpgradeableBeacon` directly to specify the new implementation contract address. -After that happens, all new calls are sent to the new implementation. - -## Instructions - -Some steps depend on whether you want to deploy on [Supersim](/interop/tools/supersim) or on the [development network](/interop/tools/devnet). - - - ### Install and run Supersim - - If you are going to use Supersim, [follow these instructions](/app-developers/tutorials/supersim/getting-started/installation) to install and run Supersim. - - - Make sure to run Supersim with autorelay on. - - ```sh - ./supersim --interop.autorelay true - ``` - - - ### Setup the ERC20 token on chain A - - Download and run the setup script. - - ```sh - curl https://docs.optimism.io/tutorials/setup-for-erc20-upgrade.sh > setup-for-erc20-upgrade.sh - chmod +x setup-for-erc20-upgrade.sh - ./setup-for-erc20-upgrade.sh - ``` - - If you want to deploy to the [development networks](/interop/tools/devnet), provide `setup-for-erc20-upgrade.sh` with the private key of an address with ETH on both devnets. - - ```sh - ./setup-for-erc20-upgrade.sh - ``` - - ### Store the addresses - - Execute the bottom two lines of the setup script output to store the ERC20 address and the address of the beacon contract. - - ```sh - BEACON_ADDRESS=0xe7f1725E7734CE288F8367e1Bb143E90bb3F0512 - export ERC20_ADDRESS=0x9fE46736679d2D9a65F0992F2272dE9f3c7fa6e0 - ``` - - ### Specify environment variables - - Specify these variables, which we use later: - - - - Set these parameters for Supersim. - - ```sh - PRIVATE_KEY=0xac0974bec39a17e36ba4a6b4d238ff944bacb478cbed5efcae784d7bf4f2ff80 - USER_ADDRESS=0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266 - URL_CHAIN_A=http://127.0.0.1:9545 - URL_CHAIN_B=http://127.0.0.1:9546 - INTEROP_BRIDGE=0x4200000000000000000000000000000000000028 - ``` - - - - For Devnet, specify in `PRIVATE_KEY` the private key you used for the setup script and then these parameters. - - ```sh - USER_ADDRESS=`cast wallet address --private-key $PRIVATE_KEY` - URL_CHAIN_A=https://interop-alpha-0.optimism.io - URL_CHAIN_B=https://interop-alpha-1.optimism.io - INTEROP_BRIDGE=0x4200000000000000000000000000000000000028 - ``` - - - - ### Create a Foundry project - - We create a [Foundry](https://book.getfoundry.sh/) project and import the [OpenZeppelin](https://www.openzeppelin.com/solidity-contracts) contracts, which were used for the original ERC20 and proxy deployment. - - ```sh - mkdir proxy-upgrade - cd proxy-upgrade - forge init - forge install OpenZeppelin/openzeppelin-contracts - forge install OpenZeppelin/openzeppelin-contracts-upgradeable - forge install ethereum-optimism/interop-lib - ``` - - ### Create and run the deployment script - - 1. Create an `script/LabSetup.s.sol` file with this content: - - ```solidity file=/public/tutorials/setup-for-erc20-upgrade.sh#L26-L66 hash=dd6605814c00636310d93706ab06f664 filename="script/LabSetup.s.sol" - ``` - - This is the same deployment script used for the original deployment on chain A. - - 2. Run this command to deploy the same contracts on chain B. - - ```sh - forge script script/LabSetup.s.sol --rpc-url $URL_CHAIN_B --broadcast --private-key $PRIVATE_KEY --tc LabSetup - ``` - - Scroll up and see the Logs section of the output: - - ``` - == Logs == - Token address: 0x5FbDB2315678afecb367f032d93F642f64180aa3 - msg.sender: 0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266 - UpgradeableBeacon: 0xe7f1725E7734CE288F8367e1Bb143E90bb3F0512 - Proxy: 0x9fE46736679d2D9a65F0992F2272dE9f3c7fa6e0 - ``` - - Verify that the proxy address is the same as `$ERC20_ADDRESS`, and that the beacon address is the same as `$BEACON_ADDRESS`. - -
- What to do when the values are not the same - - This can happen when the nonce values of `0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266` (or your address in the case of using devnet) on chain A and chain B are different. - - You can see the nonce values using these commands: - - ```sh - cast nonce $USER_ADDRESS --rpc-url $URL_CHAIN_A - cast nonce $USER_ADDRESS --rpc-url $URL_CHAIN_B - ``` - - The easiest solution is to send transactions to the chain with the lower nonce until the nonces are equal, and then deploy to both chains. - - ```sh - forge script script/LabSetup.s.sol --rpc-url $URL_CHAIN_A --broadcast --private-key $PRIVATE_KEY --tc LabSetup - forge script script/LabSetup.s.sol --rpc-url $URL_CHAIN_B --broadcast --private-key $PRIVATE_KEY --tc LabSetup - ``` - - If you do this, remember to update `$ERC20_ADDRESS` and `$BEACON_ADDRESS`. - - If the nonce on chain B is already higher than the nonce was on chain A when the original proxy contract was deployed this method is not available and you have to either create a special bridge or [use a lockbox](/interop/tutorials/upgrade-to-superchain-erc20/lockbox). -
- - ### Deploy ERC7802 contracts - - We need to replace the ERC20 contracts with contracts that: - - * Support [ERC7802](https://eips.ethereum.org/EIPS/eip-7802) and [ERC165](https://eips.ethereum.org/EIPS/eip-165). - * Have the same storage layout as the ERC20 contracts they replace. - - - These contracts do *not* need to be deployed to the same address. - The address that needs to be the same is not the address of the ERC20 contract itself, but of the proxy. - - - 1. Create a file, `src/InteropToken.sol`: - - ```solidity file=/public/tutorials/InteropToken.sol hash=007791836635608fdeb9c70c1b368f25 filename="src/InteropToken.sol" - ``` - -
- Detailed explanation - - ```solidity file=/public/tutorials/InteropToken.sol#L1-L5 hash=36b9b9d0fb1ff680dc0eaa1c48b7c56b - ``` - - Most of the code is identical to the original `MyToken`. - - ```solidity file=/public/tutorials/InteropToken.sol#L6-L7 hash=f06f3bd72be73dbd754008da7dd00d48 - ``` - - These are the imports needed for ERC7802 support. - We need `IERC165` for documentation purposes, and `IERC7802` for the ERC7802 events. - - ```solidity file=/public/tutorials/InteropToken.sol#L9 hash=ca402292e7551621669ef1a59b85d7ce - ``` - - We also implement [ERC165](https://eips.ethereum.org/EIPS/eip-165), but we don't need to import anything from there. - - ```solidity file=/public/tutorials/InteropToken.sol#L10-L14 hash=37e9b49f50a8b70971ce5d0112bd934e - ``` - - This function is identical to the one in `MyToken`. - - ```solidity file=/public/tutorials/InteropToken.sol#L16-L36 hash=448a7e21e094b3fd961f2b8ee15bc6c7 - ``` - - Standard [ERC7802](https://eips.ethereum.org/EIPS/eip-7802) behavior. - - ```solidity file=/public/tutorials/InteropToken.sol#L38-L42 hash=abb2093e9681984f25afa6f9d8b237a3 - ``` - - Standard [ERC165](https://eips.ethereum.org/EIPS/eip-165) behavior. -
- - - Copying the original ERC20 token code with minimal differences is one method to keep the storage layout identical. - Alternatively, if you want to use a different contract, such as `SuperchainERC20`, you can modify the storage layout to match the old one using [the Solidity docs](https://docs.soliditylang.org/en/latest/internals/layout_in_storage.html). - - - 2. Deploy this contract on both chains, and store the addresses (which may or may not be the same). - - ```sh - ERC7802_A=`forge create InteropToken --private-key $PRIVATE_KEY --rpc-url $URL_CHAIN_A --broadcast | awk '/Deployed to:/ {print $3}'` - ERC7802_B=`forge create InteropToken --private-key $PRIVATE_KEY --rpc-url $URL_CHAIN_B --broadcast | awk '/Deployed to:/ {print $3}'` - ``` - - ### Update proxies - - Notify the beacon contracts of the new implementation contracts. - - ```sh - cast send $BEACON_ADDRESS --private-key $PRIVATE_KEY "upgradeTo(address)" $ERC7802_A --rpc-url $URL_CHAIN_A - cast send $BEACON_ADDRESS --private-key $PRIVATE_KEY "upgradeTo(address)" $ERC7802_B --rpc-url $URL_CHAIN_B - ``` - - ### Verification - - 1. See your balance on chain A. - - ```sh - cast call $ERC20_ADDRESS "balanceOf(address)" $USER_ADDRESS --rpc-url $URL_CHAIN_A | cast from-wei - ``` - - 2. See your balance on chain B. - - ```sh - cast call $ERC20_ADDRESS "balanceOf(address)" $USER_ADDRESS --rpc-url $URL_CHAIN_B | cast from-wei - ``` - - 3. Transfer 0.1 token. - - ```sh - AMOUNT=`echo 0.1 | cast to-wei` - cast send $INTEROP_BRIDGE --rpc-url $URL_CHAIN_A --private-key $PRIVATE_KEY "sendERC20(address,address,uint256,uint256)" $ERC20_ADDRESS $USER_ADDRESS $AMOUNT `cast chain-id --rpc-url $URL_CHAIN_B` - ``` - - 4. See the new balances. Chain A should have 0.9 tokens, and Chain B should have 0.1 tokens. - - ```sh - cast call $ERC20_ADDRESS "balanceOf(address)" $USER_ADDRESS --rpc-url $URL_CHAIN_A | cast from-wei - cast call $ERC20_ADDRESS "balanceOf(address)" $USER_ADDRESS --rpc-url $URL_CHAIN_B | cast from-wei - ``` - - -## Next steps - -* Deploy a [SuperchainERC20](/interop/tutorials/deploy-superchain-erc20) to the Superchain -* [Learn more about SuperchainERC20](/interop/superchain-erc20) -* Build a [revolutionary app](/app-developers/get-started) that uses multiple blockchains within the Superchain diff --git a/pages/interop/tutorials/upgrade-to-superchain-erc20/lockbox.mdx b/pages/interop/tutorials/upgrade-to-superchain-erc20/lockbox.mdx deleted file mode 100644 index c99468504..000000000 --- a/pages/interop/tutorials/upgrade-to-superchain-erc20/lockbox.mdx +++ /dev/null @@ -1,369 +0,0 @@ ---- -title: Lockboxes for permissionless interop -lang: en-US -description: Tutorial on how to take permissionlessly create a lockbox contract to enable Superchain interoperability. -topic: Interoperability -personas: [Developer] -categories: [Tutorial, Interop] -content_type: article ---- - -import { Steps, Callout, Tabs } from 'nextra/components' - - - The SuperchainERC20 standard is ready for production deployments. - Please note that the OP Stack interoperability upgrade, required for crosschain messaging, is currently still in active development. - - -# Lockboxes for permissionless interop - -## Overview - -The lockbox is a smart contract that accepts deposits of the original ERC-20 and issues an equivalent amount of tokens that are Superchain interop compatible. -Users can unwrap their Superchain interop token at any time by returning it to the contract, which burns the Superchain interop tokens and releases the corresponding original ERC-20 from the lockbox. - -
- About this tutorial - - **What you'll learn** - - * How to permissionlessly create a lockbox contract to enable Superchain interoperability. - - **Prerequisite knowledge** - - * You should already know how to [deploy SuperchainERC20 tokens with custom code](/interop/tutorials/custom-superchain-erc20). -
- - - The code on the documentation site is sample code, *not* production code. - This means that we ran it, and it works as advertised. - However, it did not pass through the rigorous audit process that most Optimism code undergoes. - You're welcome to use it, but if you need it for production purposes you should get it audited first. - - -{/* - -I put this warning here, when we don't have it on most pages, because this tutorial -has code that is a lot more likely to be used in production. It doesn't just -show what is possible, it does the exact job needed. - -*/} - -### What you'll do - -Create a lockbox `SuperchainERC20` contract to enable interoperability for an ERC20 contract without permission from the original ERC20 deployer. - -## Instructions - -Some steps depend on whether you want to deploy on [Supersim](/interop/tools/supersim) or on the [development network](/interop/tools/devnet). - - - ### Install and run Supersim - - If you are going to use Supersim, [follow these instructions](/app-developers/tutorials/supersim/getting-started/installation) to install and run Supersim. - - - Make sure to run Supersim with autorelay on. - - ```sh - ./supersim --interop.autorelay true - ``` - - - ### Setup the ERC-20 token on chain A - - Download and run the setup script. - - ```sh - curl https://docs.optimism.io/tutorials/setup-for-erc20-upgrade.sh > setup-for-erc20-upgrade.sh - chmod +x setup-for-erc20-upgrade.sh - ./setup-for-erc20-upgrade.sh - ``` - - If you want to deploy to the [development networks](/interop/tools/devnet), provide `setup-for-erc20-upgrade.sh` with the private key of an address with ETH on both devnets. - - ```sh - ./setup-for-erc20-upgrade.sh - ``` - - ### Store the addresses - - Execute the bottom two lines of the setup script output to store the ERC-20 address and the address of the beacon contract. - - ```sh - BEACON_ADDRESS=0xe7f1725E7734CE288F8367e1Bb143E90bb3F0512 - export ERC20_ADDRESS=0x9fE46736679d2D9a65F0992F2272dE9f3c7fa6e0 - ``` - - ### Specify environment variables - - 1. Specify these variables, which we use later: - - - - Set these parameters for Supersim. - - ```sh - PRIVATE_KEY=0xac0974bec39a17e36ba4a6b4d238ff944bacb478cbed5efcae784d7bf4f2ff80 - USER_ADDRESS=0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266 - URL_CHAIN_A=http://127.0.0.1:9545 - URL_CHAIN_B=http://127.0.0.1:9546 - ``` - - - - For Devnet, specify in `PRIVATE_KEY` the private key you used for the setup script and then these parameters. - - ```sh - USER_ADDRESS=`cast wallet address --private-key $PRIVATE_KEY` - URL_CHAIN_A=https://interop-alpha-0.optimism.io - URL_CHAIN_B=https://interop-alpha-1.optimism.io - ``` - - - - 2. Regardless of whether you use Supersim or Devnet, specify these variables. - - ```sh - INTEROP_BRIDGE=0x4200000000000000000000000000000000000028 - export ERC20_CHAINID=`cast chain-id --rpc-url $URL_CHAIN_A` - ORIGINAL_TOKEN_NAME=`cast call $ERC20_ADDRESS "name()" --rpc-url $URL_CHAIN_A | cast to-ascii` - export NEW_TOKEN_NAME="$ORIGINAL_TOKEN_NAME Lockbox" - ORIGINAL_TOKEN_SYMBOL=`cast call $ERC20_ADDRESS "symbol()" --rpc-url $URL_CHAIN_A | cast to-ascii` - export NEW_TOKEN_SYMBOL="$ORIGINAL_TOKEN_SYMBOL-L" - export TOKEN_DECIMALS=`cast call $ERC20_ADDRESS "decimals()" --rpc-url $URL_CHAIN_A | cast to-dec` - ``` - - ### Update the deployment utilities - - The new `SuperchainERC20` variant is called `LockboxSuperchainERC20`, and it requires different constructor parameters. - To be able to deploy it, we need to modify some of the deployment utilities. - - 1. Download [the SuperchainERC20 starter kit](/interop/tutorials/deploy-superchain-erc20), and install libraries, etc. - - ```sh - git clone https://github.com/ethereum-optimism/superchainerc20-starter.git - cd superchainerc20-starter - pnpm install - pnpm init:env - ``` - - 2. Replace `packages/contracts/package.json` with this code: - - ```json filename="packages/contracts/package.json" - { - "name": "@superchainerc20-starter/contracts", - "main": "index.js", - "scripts": { - "deploy:dev": "env-cmd -f .env cross-env-shell 'wait-port http://:8420/ready && forge script scripts/SuperchainERC20Deployer.s.sol --broadcast --private-key $DEPLOYER_PRIVATE_KEY'", - "deploy:token": "env-cmd -f .env cross-env-shell 'forge script scripts/LockboxDeployer.s.sol --broadcast --private-key $DEPLOYER_PRIVATE_KEY'", - "update:rpcs": "cd ../.. && ./scripts/fetch-superchain-rpc-urls.sh", - "install": "forge install", - "build": "forge build", - "test": "forge test", - "init:env": "cp .env.example .env" - }, - "dependencies": { - "viem": "^2.21.37" - } - } - ``` - - 3. Create a new file, `packages/contracts/scripts/LockboxDeployer.s.sol`: - - ```solidity filename="packages/contracts/scripts/LockboxDeployer.s.sol" file=/public/tutorials/LockboxDeployer.s.sol hash=534b543709be173d87508a53322d8c59 - ``` - -
- Explanation of the modified functions - - For the most part, this is the standard `SuperchainERC20Deployer.s.sol` that comes with the SuperchainERC20 starter kit. - Some functions are modified, as explained below. - - ```solidity file=/public/tutorials/LockboxDeployer.s.sol#L46-L52 hash=302d02c3895f109e5e64d265b0473e6a - ``` - - Get the majority of the configuration from the environment. - Mostly of it is derived from the configuration of the original ERC-20 token. - - Note that there is no `owner` here. - This `SuperchainERC20` contract does not need an owner, because minting and burning are handled by the users themselves (by locking and unlocking the original tokens). - - ```solidity file=/public/tutorials/LockboxDeployer.s.sol#L54-L69 hash=c45855080dc554cece35ed87e2d68f68 - ``` - - "Manually" calculate the address that [`CREATE2`](https://www.evm.codes/?fork=cancun#f5) will give us.\ - If there is already a contract there, we have a problem. - Otherwise, deploy `LockboxSuperchainERC20`. - - ```solidity file=/public/tutorials/LockboxDeployer.s.sol#L80-L84 hash=5d1f71b16a6f02d52a79b1a9e7588f87 - ``` - - I modified this salt function to include a timestamp (obtained using `vm.unixTime()` in the constructor). - This is not necessary, but I consider it a developer experience improvement. - During development you redeploy slightly modified code a lot of times. - It is easier if you don't need to manually change the salt every time. - - - Remove this before deploying to production. - Otherwise, as new blockchains join the Interop cluster, you may not be able to deploy your contract at the same address. - -
- - ### Create and deploy the new contract - - 1. Create this file in `packages/contracts/src/LockboxSuperchainERC20.sol`: - - ```solidity filename="packages/contracts/src/LockboxSuperchainERC20.sol" file=/public/tutorials/LockboxSuperchainERC20.sol hash=d326f0e1c26904b844263274914951cf - ``` - -
- Explanation - - ```solidity file=/public/tutorials/LockboxSuperchainERC20.sol#L11-L12 hash=45d211a19533f9b0dee310743b25459f - ``` - - The lockbox contract needs to know the contract for which it is a lockbox. - This requires not just the address, but also to know what chain has it. - - ```solidity file=/public/tutorials/LockboxSuperchainERC20.sol#L47-L57 hash=20f6aa15d113dcaf992875184173cb47 - ``` - - Users call this function to transfer original tokens to the contract and mint themselves an equivalent number of lockbox tokens. - This function has several tests to make sure it can be called. - - * Check the chain ID. - Locking and redeeming tokens can only be done on the original token's chain. - * Use [`transferFrom`](https://ethereum.org/en/developers/tutorials/erc20-annotated-code/#transferFrom) to transfer the tokens to ourselves. - This call typically reverts when it fails, but it can also return `false`. - In that case, we revert. - There are two reasons it may fail. - * The user (in this case, the `LockboxSuperchainERC20` contract) does not have [the allowance](https://ethereum.org/en/developers/tutorials/erc20-annotated-code/#_approve) to spend that amount of tokens from the original owner (`msg.sender`). - * The original owner (`msg.sender`) does not have enough tokens to transfer. - - If the tests are successful, mint the requested amount for `msg.sender`. - - ```solidity file=/public/tutorials/LockboxSuperchainERC20.sol#L59-L67 hash=2e63a9cd1ac1114c3fb2110e28b60924 - ``` - - Users call this function to redeem their existing lockbox tokens and replace them with the original tokens. - It also has multiple tests. - - * Again, check chain ID. - * Try to `_burn` the amount of lockbox tokens. - [The solady `_burn` function](https://github.com/Vectorized/solady/blob/main/src/tokens/ERC20.sol#L539-L542), the one we inherit from `SuperchainERC20`, reverts if the user does not have enough tokens to burn. - * Transfer the amount of the original ERC-20 redeemed to - the caller. - This should never fail, because lockbox ERC-20 tokens are supposed to always be backed by an equal number of the original tokens. - However, if it does fail for some reason, revert. -
- - 2. Deploy the contract. - - - - ```sh - pnpm contracts:deploy:token - ``` - - - - To deploy to the [development networks](/interop/tools/devnet), follow the steps [in the tutorial](/interop/tutorials/deploy-superchain-erc20#prepare-for-deployment) before you deploy the contract. - - Then, update `packages/contracts/.env` and deploy the token. - - ```sh - echo DEPLOYER_PRIVATE_KEY=$PRIVATE_KEY > packages/contracts/.env - pnpm contracts:deploy:token - ``` - - - - 3. Get the new token address and store it in an environment variable. - - ```sh - NEW_TOKEN_ADDRESS=`cat packages/contracts/broadcast/multi/LockboxDeployer.s.sol-latest/run.json | awk '/contractAddress/ {print $2}' | head -1 | sed 's/[",]//g'` - ``` - - ### Verification - - 1. Check that the user has a single token of the original ERC-20. - - ```sh - cast call $ERC20_ADDRESS "balanceOf(address)" $USER_ADDRESS --rpc-url $URL_CHAIN_A | cast from-wei - ``` - - 2. Lock a quarter token in the lockbox ERC-20 contract. - To do this we first need to give the lockbox ERC-20 contract an allowance and then call it. - - ```sh - QUARTER_TOKEN=`echo 0.25 | cast to-wei` - cast send $ERC20_ADDRESS "approve(address,uint256)" $NEW_TOKEN_ADDRESS $QUARTER_TOKEN --private-key $PRIVATE_KEY --rpc-url $URL_CHAIN_A - cast send $NEW_TOKEN_ADDRESS "lockAndMint(uint256)" $QUARTER_TOKEN --private-key $PRIVATE_KEY --rpc-url $URL_CHAIN_A - ``` - - 3. See the balances of the user, both original and lockbox, and the balance of the lockbox contract itself. - - ```sh - cast call $ERC20_ADDRESS "balanceOf(address)" $USER_ADDRESS --rpc-url $URL_CHAIN_A | cast from-wei - cast call $NEW_TOKEN_ADDRESS "balanceOf(address)" $USER_ADDRESS --rpc-url $URL_CHAIN_A | cast from-wei - cast call $ERC20_ADDRESS "balanceOf(address)" $NEW_TOKEN_ADDRESS --rpc-url $URL_CHAIN_A | cast from-wei - ``` - - 4. Transfer 0.1 token to chain B. - - ```sh - TENTH_TOKEN=`echo 0.1 | cast to-wei` - cast send $INTEROP_BRIDGE --rpc-url $URL_CHAIN_A --private-key $PRIVATE_KEY "sendERC20(address,address,uint256,uint256)" $NEW_TOKEN_ADDRESS $USER_ADDRESS $TENTH_TOKEN `cast chain-id --rpc-url $URL_CHAIN_B` - ``` - - 5. Check the user's balances on both chains. - - ```sh - cast call $NEW_TOKEN_ADDRESS "balanceOf(address)" $USER_ADDRESS --rpc-url $URL_CHAIN_A | cast from-wei - cast call $NEW_TOKEN_ADDRESS "balanceOf(address)" $USER_ADDRESS --rpc-url $URL_CHAIN_B | cast from-wei - ``` - - 6. Specify the configuration for another user. - - - - ```sh - USER_ADDRESS_2=0x3C44CdDdB6a900fa2b585dd299e03d12FA4293BC - PRIVATE_KEY_2=0x5de4111afa1a4b94908f83103eb1f1706367c2e68ca870fc3fb9a804cdab365a - ``` - - - - Specify the private key (`PRIVATE_KEY_2`) and user address (`USER_ADDRESS_2`) of another user that has ETH on both devnets. - - - - 7. Transfer new tokens to the new user (on chain B) and see that they were actually transferred. - - ```sh - cast send $NEW_TOKEN_ADDRESS "transfer(address,uint256)" $USER_ADDRESS_2 $TENTH_TOKEN --private-key $PRIVATE_KEY --rpc-url $URL_CHAIN_B - cast call $NEW_TOKEN_ADDRESS "balanceOf(address)" $USER_ADDRESS --rpc-url $URL_CHAIN_B | cast from-wei - cast call $NEW_TOKEN_ADDRESS "balanceOf(address)" $USER_ADDRESS_2 --rpc-url $URL_CHAIN_B | cast from-wei - ``` - - 8. As the new user, transfer tokens back to chain A and redeem them. - - ```sh - cast send $INTEROP_BRIDGE --rpc-url $URL_CHAIN_B --private-key $PRIVATE_KEY_2 "sendERC20(address,address,uint256,uint256)" $NEW_TOKEN_ADDRESS $USER_ADDRESS_2 $TENTH_TOKEN `cast chain-id --rpc-url $URL_CHAIN_A` - cast send $NEW_TOKEN_ADDRESS --rpc-url $URL_CHAIN_A --private-key $PRIVATE_KEY_2 "redeemAndBurn(uint256)" $TENTH_TOKEN - ``` - - 9. Check that the second user does not have any more of the new tokens, but does have the original token. - - ```sh - cast call $NEW_TOKEN_ADDRESS "balanceOf(address)" $USER_ADDRESS_2 --rpc-url $URL_CHAIN_A | cast from-wei - cast call $ERC20_ADDRESS "balanceOf(address)" $USER_ADDRESS_2 --rpc-url $URL_CHAIN_A | cast from-wei - ``` - - -## Next steps - -* Deploy a [SuperchainERC20](/interop/tutorials/deploy-superchain-erc20) to the Superchain -* [Learn more about SuperchainERC20](/interop/superchain-erc20) -* Build a [revolutionary app](/app-developers/get-started) that uses multiple blockchains within the Superchain diff --git a/pages/meta.json b/pages/meta.json new file mode 100644 index 000000000..8502979e2 --- /dev/null +++ b/pages/meta.json @@ -0,0 +1,5 @@ +{ + "404": "Page Not Found", + "500": "Internal Server Error", + "index": "Welcome to the Optimism Docs" +} diff --git a/pages/operators/node-operators/configuration/base-config.mdx b/pages/node-operators/guides/configuration/base.mdx similarity index 100% rename from pages/operators/node-operators/configuration/base-config.mdx rename to pages/node-operators/guides/configuration/base.mdx diff --git a/pages/operators/node-operators/configuration/consensus-config.mdx b/pages/node-operators/guides/configuration/consensus.mdx similarity index 100% rename from pages/operators/node-operators/configuration/consensus-config.mdx rename to pages/node-operators/guides/configuration/consensus.mdx diff --git a/pages/operators/node-operators/configuration/execution-config.mdx b/pages/node-operators/guides/configuration/execution.mdx similarity index 100% rename from pages/operators/node-operators/configuration/execution-config.mdx rename to pages/node-operators/guides/configuration/execution.mdx diff --git a/pages/node-operators/guides/configuration/meta.json b/pages/node-operators/guides/configuration/meta.json new file mode 100644 index 000000000..eb446a6a7 --- /dev/null +++ b/pages/node-operators/guides/configuration/meta.json @@ -0,0 +1,5 @@ +{ + "base": "Node base configuration", + "consensus": "Consensus layer configuration options (op-node)", + "execution": "Execution layer configuration options (op-geth)" +} diff --git a/pages/node-operators/guides/management/meta.json b/pages/node-operators/guides/management/meta.json new file mode 100644 index 000000000..a1d605dad --- /dev/null +++ b/pages/node-operators/guides/management/meta.json @@ -0,0 +1,7 @@ +{ + "metrics": "Node Metrics and Monitoring", + "regenesis-history": "Accessing pre-regenesis history", + "snap-sync": "Using snap sync for node operators", + "snapshots": "Snapshots", + "troubleshooting": "Node Troubleshooting" +} diff --git a/pages/operators/node-operators/management/metrics.mdx b/pages/node-operators/guides/management/metrics.mdx similarity index 100% rename from pages/operators/node-operators/management/metrics.mdx rename to pages/node-operators/guides/management/metrics.mdx diff --git a/pages/operators/node-operators/management/regenesis-history.mdx b/pages/node-operators/guides/management/regenesis-history.mdx similarity index 100% rename from pages/operators/node-operators/management/regenesis-history.mdx rename to pages/node-operators/guides/management/regenesis-history.mdx diff --git a/pages/operators/node-operators/management/snap-sync.mdx b/pages/node-operators/guides/management/snap-sync.mdx similarity index 100% rename from pages/operators/node-operators/management/snap-sync.mdx rename to pages/node-operators/guides/management/snap-sync.mdx diff --git a/pages/operators/node-operators/management/snapshots.mdx b/pages/node-operators/guides/management/snapshots.mdx similarity index 100% rename from pages/operators/node-operators/management/snapshots.mdx rename to pages/node-operators/guides/management/snapshots.mdx diff --git a/pages/operators/node-operators/management/troubleshooting.mdx b/pages/node-operators/guides/management/troubleshooting.mdx similarity index 100% rename from pages/operators/node-operators/management/troubleshooting.mdx rename to pages/node-operators/guides/management/troubleshooting.mdx diff --git a/pages/operators/node-operators/architecture.mdx b/pages/node-operators/reference/architecture/overview.mdx similarity index 100% rename from pages/operators/node-operators/architecture.mdx rename to pages/node-operators/reference/architecture/overview.mdx diff --git a/pages/operators/node-operators/rollup-node.mdx b/pages/node-operators/reference/architecture/rollup-node.mdx similarity index 100% rename from pages/operators/node-operators/rollup-node.mdx rename to pages/node-operators/reference/architecture/rollup-node.mdx diff --git a/pages/node-operators/reference/meta.json b/pages/node-operators/reference/meta.json new file mode 100644 index 000000000..6fb4eb188 --- /dev/null +++ b/pages/node-operators/reference/meta.json @@ -0,0 +1,6 @@ +{ + "architecture": "Node architecture", + "json-rpc": "JSON-RPC API", + "releases": "Node software releases", + "rollup-node": "How to run a node in the Superchain" +} diff --git a/pages/operators/node-operators/releases.mdx b/pages/node-operators/reference/releases.mdx similarity index 100% rename from pages/operators/node-operators/releases.mdx rename to pages/node-operators/reference/releases.mdx diff --git a/pages/operators/node-operators/json-rpc.mdx b/pages/node-operators/reference/rpc similarity index 100% rename from pages/operators/node-operators/json-rpc.mdx rename to pages/node-operators/reference/rpc diff --git a/pages/operators/node-operators/tutorials/node-from-docker.mdx b/pages/node-operators/tutorials/docker-node.mdx similarity index 100% rename from pages/operators/node-operators/tutorials/node-from-docker.mdx rename to pages/node-operators/tutorials/docker-node.mdx diff --git a/pages/node-operators/tutorials/meta.json b/pages/node-operators/tutorials/meta.json new file mode 100644 index 000000000..197eff6bd --- /dev/null +++ b/pages/node-operators/tutorials/meta.json @@ -0,0 +1,5 @@ +{ + "node-from-docker": "Running a Node With Docker", + "node-from-source": "Building a Superchain node from source", + "run-node-from-source": "Running a Superchain node from source" +} diff --git a/pages/operators/node-operators/tutorials/node-from-source.mdx b/pages/node-operators/tutorials/node-from-source.mdx similarity index 100% rename from pages/operators/node-operators/tutorials/node-from-source.mdx rename to pages/node-operators/tutorials/node-from-source.mdx diff --git a/pages/operators/node-operators/tutorials/run-node-from-source.mdx b/pages/node-operators/tutorials/source-node.mdx similarity index 100% rename from pages/operators/node-operators/tutorials/run-node-from-source.mdx rename to pages/node-operators/tutorials/source-node.mdx diff --git a/pages/notices/_meta.json b/pages/notices/_meta.json deleted file mode 100644 index 1dd3f29b7..000000000 --- a/pages/notices/_meta.json +++ /dev/null @@ -1,12 +0,0 @@ -{ - "upgrade-16a": "Upgrade 16a: Protocol upgrade", - "upgrade-16": "Upgrade 16: Preparing for Interop protocol upgrade", - "upgrade-15": "Upgrade 15: Isthmus Hard Fork", - "upgrade-14": "Upgrade 14: MT-Cannon and Isthmus L1 Contracts", - "upgrade-13": "Upgrade 13: OPCM and incident response improvements", - "pectra-fees": "Pectra user fees notice", - "pectra-changes": "Preparing for Pectra breaking changes", - "superchain-withdrawal-pause-test": "Superchain withdrawal pause test", - "holocene-changes": "Preparing for Holocene breaking changes", - "blob-fee-bug": "Superchain testnets' blob fee bug" -} \ No newline at end of file diff --git a/pages/notices/blob-fee-bug.mdx b/pages/notices/archive/blob-fee-bug.mdx similarity index 100% rename from pages/notices/blob-fee-bug.mdx rename to pages/notices/archive/blob-fee-bug.mdx diff --git a/pages/notices/archive/custom-gas-tokens-deprecation.mdx b/pages/notices/archive/custom-gas-tokens-deprecation.mdx new file mode 100644 index 000000000..0f8fb839e --- /dev/null +++ b/pages/notices/archive/custom-gas-tokens-deprecation.mdx @@ -0,0 +1,69 @@ +--- +title: Preparing for custom gas tokens deprecation +description: >- + This page outlines the details of the Custom Gas Tokens deprecation and points + towards alternatives +lang: en-US +content_type: guide +topic: custom-gas-tokens-deprecation +personas: + - app-developer + - chain-operator +categories: + - security + - automated-pause +is_imported_content: 'false' +--- + +## Deprecation of Custom Gas Tokens + +The Custom Gas Token beta feature has been deprecated. Beta features give developers access to early versions of highly requested features, allowing us to validate demand through usage data and user feedback. Since May 2024, usage of the custom gas token beta feature has steadily declined as ERC-4337 and robust paymaster services gained traction. + +Based on this trend, the beta feature was deprecated instead of being moved to the OP Stack standard configuration. While the custom gas token code has been removed from the Optimism monorepo, chains can choose to maintain their own OP Stack Fork at their own risk. Future upgrades to the OP Stack will not be compatible with custom gas tokens. Options for existing chains that use custom gas tokens and new chains are discussed below. + +Additionally, advancements in Account Abstraction (AA) tooling now enable gas payments in any token, offering better alternatives for the limited number of chains that require this feature. + + +## Highlights + +* Code removal: The Custom Gas Token code has been removed from the Optimism monorepo in the following PRs [1](https://github.com/ethereum-optimism/optimism/pull/13686), [2](https://github.com/ethereum-optimism/optimism/pull/13921), [3](https://github.com/ethereum-optimism/optimism/pull/1409). +* Use AA Tooling: New chains looking to enable Custom Gas Token functionality should utilize paymasters to enable the same functionality +* End of developer support: OP Labs Developer Support will no longer address CGT-related issues or requests. + +## Options for new chains + +The Optimism ecosystem is focusing on interoperability within the Superchain, with efforts and incentives directed towards [standard configured chains](/superchain/standard-configuration). Some options are: + +* All new chains launch with the standard ETH gas token configuration. +* Utilize Account Abstraction tooling to allow users to pay gas fees in alternative tokens instead of relying on Custom Gas Tokens. + * For example, a given chain can maintain ETH as its protocol gas token while using AA tooling to permit payments in their native token. + +There are many account abstractions providers in the space. You should find the correct one for your needs, but we've [compiled a list](/app-developers/tools/build/account-abstraction#account-abstraction-tools) to get you started. + +## Options for existing chains + +For existing chains that utilize Custom Gas Token, there are a few paths forward: + +* You can continue to operate your chain as is and not pull in the latest upgrades to the OP Stack. +* At your own risk, you can start maintaining an OP Stack fork that adds back in the CGT code, upstreaming the latest OP stack upgrades into your fork- which was removed from the Optimism monorepo in the following PRs [1](https://github.com/ethereum-optimism/optimism/pull/13686), [2](https://github.com/ethereum-optimism/optimism/pull/13921), [3](https://github.com/ethereum-optimism/optimism/pull/1409). +* You can launch a new standard configuration chain and coordinate a migration of applications and users from your current Custom Gas Token chain to the new chain. + +## Risks of continued use of Custom Gas Tokens + +For any chain considering CGT post-deprecation, be aware of the following risks: + +* Fee mechanism flaws: Fees are charged as a scalar on blob fees denominated in ETH. This means CGT chains will either drastically overcharge or undercharge users for transaction fees relative to their L1 Data Availability costs. + +* Higher overhead for RaaS providers: Managing CGT chains requires RaaS providers to assume additional risk exposure to the custom gas token asset. + +* Security concerns: The CGT code modifies the L1 `OptimismPortal`, where all native assets are stored, and will not have undergone third-party auditing. + +* Lack of future compatibility: Without official support from core protocol developers, there is no guarantee that future OP Stack upgrades will function properly with CGT-based chains. + +### Need help? + +For further assistance or questions about this migration, feel free to reach out through the following channels: + +* Join us on our [Superchain Dev Discord](https://guild.xyz/superchain-devs). +* For questions, discussions and general support check out the [developer forum](https://github.com/ethereum-optimism/developers/discussions). +* Open an [issue on our GitHub repository](https://github.com/ethereum-optimism/docs/issues) for documentation-related concerns. diff --git a/pages/notices/holocene-changes.mdx b/pages/notices/archive/holocene-changes.mdx similarity index 100% rename from pages/notices/holocene-changes.mdx rename to pages/notices/archive/holocene-changes.mdx diff --git a/pages/notices/archive/meta.json b/pages/notices/archive/meta.json new file mode 100644 index 000000000..879340372 --- /dev/null +++ b/pages/notices/archive/meta.json @@ -0,0 +1,12 @@ +{ + "blob-fee-bug": "Superchain testnets' blob fee bug", + "custom-gas-tokens-deprecation": "Preparing for custom gas tokens deprecation", + "holocene-changes": "Preparing for Holocene breaking changes", + "pectra-changes": "Preparing for Pectra breaking changes", + "pectra-fees": "L1 Pectra user fees and chain profitability", + "superchain-withdrawal-pause-test": "Superchain withdrawal pause test", + "upgrade-13": "Upgrade 13 OPCM and incident response improvements", + "upgrade-14": "Upgrade 14 MT-Cannon and Isthmus L1 Contracts", + "upgrade-15": "Upgrade 15 - Isthmus Hard Fork", + "upgrade-16": "Upgrade 16 - Protocol upgrade" +} diff --git a/pages/notices/pectra-changes.mdx b/pages/notices/archive/pectra-changes.mdx similarity index 100% rename from pages/notices/pectra-changes.mdx rename to pages/notices/archive/pectra-changes.mdx diff --git a/pages/notices/pectra-fees.mdx b/pages/notices/archive/pectra-fees.mdx similarity index 100% rename from pages/notices/pectra-fees.mdx rename to pages/notices/archive/pectra-fees.mdx diff --git a/pages/notices/superchain-withdrawal-pause-test.mdx b/pages/notices/archive/superchain-withdrawal-pause-test.mdx similarity index 100% rename from pages/notices/superchain-withdrawal-pause-test.mdx rename to pages/notices/archive/superchain-withdrawal-pause-test.mdx diff --git a/pages/notices/upgrade-13.mdx b/pages/notices/archive/upgrade-13.mdx similarity index 100% rename from pages/notices/upgrade-13.mdx rename to pages/notices/archive/upgrade-13.mdx diff --git a/pages/notices/upgrade-14.mdx b/pages/notices/archive/upgrade-14.mdx similarity index 100% rename from pages/notices/upgrade-14.mdx rename to pages/notices/archive/upgrade-14.mdx diff --git a/pages/notices/upgrade-15.mdx b/pages/notices/archive/upgrade-15.mdx similarity index 99% rename from pages/notices/upgrade-15.mdx rename to pages/notices/archive/upgrade-15.mdx index 686f9c83a..cec3d8073 100644 --- a/pages/notices/upgrade-15.mdx +++ b/pages/notices/archive/upgrade-15.mdx @@ -17,7 +17,7 @@ is_imported_content: 'false' import { Steps, Callout } from 'nextra/components' -# Upgrade 15: Isthmus Hard Fork +# Upgrade 15: Isthmus Hard Fork This page outlines breaking changes related to the Isthmus network upgrade for chain operators and node operators. The upgrade proposal is available [here](https://gov.optimism.io/t/upgrade-proposal-15-isthmus-hard-fork/9804) and the governance vote is available [here](https://gov.optimism.io/t/proposal-preview-implement-prague-features-on-the-op-stack/9703). diff --git a/pages/notices/upgrade-16.mdx b/pages/notices/archive/upgrade-16.mdx similarity index 98% rename from pages/notices/upgrade-16.mdx rename to pages/notices/archive/upgrade-16.mdx index f4473d491..bd7027935 100644 --- a/pages/notices/upgrade-16.mdx +++ b/pages/notices/archive/upgrade-16.mdx @@ -1,5 +1,5 @@ --- -title: Upgrade 16 Preparing for Interop protocol upgrade +title: Upgrade 16 - Protocol upgrade description: Learn how to prepare for the Upgrade 16 protocol changes. lang: en-US content_type: notice @@ -16,13 +16,13 @@ is_imported_content: 'false' import { Steps, Callout } from 'nextra/components' -# Upgrade 16: Preparing for Interop protocol upgrade +# Upgrade 16: Protocol upgrade This page outlines important changes related to Upgrade 16 for chain operators and users. The upgrade proposal includes modifications to the OP Stack that will set the Superchain up for continued success through the remainder of 2025. - The Upgrade 16 protocol upgrade on the **Sepolia** Superchain will be executed on **Wed, Jul 09, 2025**, and the **Mainnet** Superchain will be activated on **Thu, Jul 24, 2025 at 5:30 PM UTC (`1753675800`)**.\ - The upgrade will be executed on the following chains: `OP`, `Soneium`, `Ink`and `Unichain`.\ + The Upgrade 16 protocol upgrade on the **Sepolia** Superchain will be executed on **Wed, Jul 09, 2025**, and the **Mainnet** Superchain will be activated on **Thu, Jul 24, 2025 at 5:30 PM UTC (`1753675800`)**. + The upgrade will be executed on the following chains: `OP`, `Soneium`, `Ink`and `Unichain`. Execution times may vary depending on the current state of each chain. diff --git a/pages/notices/upgrade-16a.mdx b/pages/notices/upgrade-16a.mdx deleted file mode 100644 index 0e6ff3277..000000000 --- a/pages/notices/upgrade-16a.mdx +++ /dev/null @@ -1,129 +0,0 @@ ---- -title: Upgrade 16a Protocol upgrade -description: Learn how to prepare for the Upgrade 16a protocol changes. -lang: en-US -content_type: notice -topic: upgrade-16a-changes -personas: - - chain-operator -categories: - - security - - protocol - - infrastructure - - interoperability -is_imported_content: 'false' ---- - -import { Steps, Callout } from 'nextra/components' - -# Upgrade 16a: Protocol upgrade - -Upgrade 16a is a **maintenance release that supersedes Upgrade 16**. If you are on upgrade 15 **please skip** upgrade 16 and go straight to this upgrade. It temporarily removes unused interop withdrawal-proving code introduced in Upgrade 16 and adds system-level feature toggles to improve flexibility and rollout safety. These changes reduce risk while maintaining momentum toward the Superchain roadmap. - - - The Upgrade 16a protocol upgrade on the **Sepolia** Superchain will be executed on **Mon, Sept 22, 2025**, and the **Mainnet** Superchain will be activated on **Thur, Oct 2, 2025**. - The upgrade will be executed on the following chains: `OP`, `Base`, `Soneium`, `Ink`, and `Unichain`. - Execution times may vary depending on the current state of each chain. - - -## What's included in Upgrade 16a - -Upgrade 16a introduces the following changes: - -**Removal of interop withdrawal-proving code**: Code paths for interop withdrawals added in Upgrade 16 have been removed following partner feedback. ETHLockbox remains supported on chains already running U16. Chains moving directly from U15 → U16a will not adopt ETHLockbox until a future upgrade. - -**System-level feature toggles** -Added via the `SystemConfig` contract. ETHLockbox is the first feature placed behind a toggle. This mechanism enables chain-specific configuration and safer iterative upgrades. - -**Development-only feature flags** -Introduced to allow testing of interop functionality on non-production environments. These flags cannot be enabled on production chains. - -**OP Contracts Manager (OPCM) updates** -Updated to support both upgrade paths: `U15 → U16a` and `U16 → U16a`. - -## Impact summary - -* No chain downtime is expected, however if upgrading from U15, withdrawals will be invalidated (see below). -* Withdrawal proofs created under U16 remain valid. -* Chains still on U15 are affected in the same way described in the Upgrade 16 notice. -* Chains upgrading directly from U15 → U16a will not adopt ETHLockbox until a future release. -* System-level toggles improve operator control and make future upgrades easier to roll out. - -## For chain operators - -Withdrawal invalidation impacts only chains still on U15. -Any pending L1 withdrawals on those chains that are not finalized before the upgrade executes will need to be reproven after the upgrade completes. Users must re-submit their proof transactions after the upgrade. -Chains already on U16 are not affected. No funds are at risk. - -### Chain operators must complete the following tasks: - -* Update `op-challenger` to [op-challenger/v1.5.1](https://github.com/ethereum-optimism/optimism/releases/tag/op-challenger%2Fv1.5.1) - -### For permissionless fault proof enabled chains - -Chains running permissionless fault proofs will need to deploy new dispute game contracts with new absolute prestates. - - - ### Verify the new absolute prestate - - - As of upgrade 14, the 64 bit multi-threaded version of cannon is utilized. - - - The absolute prestate is generated with the [op-program/v1.6.1-rc.1](https://github.com/ethereum-optimism/optimism/tree/op-program/v1.6.1-rc.1). You can use this new absolute prestate `0x03eb07101fbdeaf3f04d9fb76526362c1eea2824e4c6e970bdb19675b72e4fc8` for the following chains: - - * Mainnet and Sepolia: `OP`, `Base`, `Soneium`, `Ink`and `Unichain` - - You can verify this absolute prestate by running the following [command](https://github.com/ethereum-optimism/optimism/blob/d6fb90dd489e39efa206b55200766ccc075c1d9b/Makefile#L130-L132) in the root of the monorepo on the `op-program/v1.6.1-rc.1` tag: - - ```shell - make reproducible-prestate - ``` - - This will output the calculated prestates, which will look something like: - - ```shell - -------------------- Production Prestates -------------------- - - - Cannon64 Absolute prestate hash: - 0x03eb07101fbdeaf3f04d9fb76526362c1eea2824e4c6e970bdb19675b72e4fc8 - - -------------------- Experimental Prestates -------------------- - - CannonInterop Absolute prestate hash: - 0x03fc3b4d091527d53f1ff369ea8ed65e5e17cc7fc98ebf75380238151cdc949c - - Cannon64Next Absolute prestate hash: - 0x03eb07101fbdeaf3f04d9fb76526362c1eea2824e4c6e970bdb19675b72e4fc8 - ``` - - * The "Cannon64" hash is the 64-bit prestate. - - Verify that your target prestate was calculated as expected and matches the corresponding entry in - [standard-prestates.toml](https://github.com/ethereum-optimism/superchain-registry/blob/main/validation/standard/standard-prestates.toml). - - ### Upload your new preimage file - - During the previous step, you also generated the preimage of the absolute prestate, which is the op-program serialized into a binary file. You'll find that new file at `optimism/op-program/bin/prestate-mt64.bin.gz`. Rename that file to have the absolute prestate hash as the filename so it looks like `PRESTATEHASH.bin.gz`. - - Upload that file to where you're storing your other absolute preimage files. This should be the location where you're pointing your `--cannon-prestates-url` at. The `op-challenger` will grab this file and use it when it needs to challenge games. - - ### Execute the upgrade - - Once your `op-challenger` is ready with the new preimage, you can execute the upgrade transaction. This should be done by making a delegatecall to the `upgrade()` function of the OP Contract Manager (at the address listed in [the registry](https://github.com/ethereum-optimism/superchain-registry/blob/6621a0f13ce523fe1bb8deea739fe37abe20f90d/validation/standard/standard-versions-mainnet.toml#L22). - - Please simulate and validate the expected output prior to executing the transaction. - - -### Withdrawal flow changes - -1. There will be a one-time invalidation of all pending withdrawal proofs created on L1. - -2. Complete any pending withdrawals before the upgrade is executed - -3. Avoid creating new withdrawal proofs that would not become executable in time - -4. If a withdrawal was invalidated, submit a second withdrawal proof transaction on L1 - -This invalidation does not place any ETH or ERC-20 tokens at risk. diff --git a/pages/operators/_meta.json b/pages/operators/_meta.json deleted file mode 100644 index 73c5f101e..000000000 --- a/pages/operators/_meta.json +++ /dev/null @@ -1,22 +0,0 @@ -{ - "--- Chains": { - "title": "Chain Operators", - "type": "separator" - }, - "chain-operators": { - "title": "Chains", - "display": "children" - }, - "+++ Nodes": { - "title": "", - "type": "separator" - }, - "--- NODES": { - "title": "Node Operators", - "type": "separator" - }, - "node-operators": { - "title": "Nodes", - "display": "children" - } - } \ No newline at end of file diff --git a/pages/operators/chain-operators.mdx b/pages/operators/chain-operators.mdx deleted file mode 100644 index 32e9d68a9..000000000 --- a/pages/operators/chain-operators.mdx +++ /dev/null @@ -1,46 +0,0 @@ ---- -title: Chain Operators -description: Documentation covering Architecture, Configuration, Deploy, Features, Hacks, Management, Self Hosted, Tools, Tutorials in the Chain Operators section of the OP Stack ecosystem. -lang: en-US -content_type: landing-page -topic: chain-operator-resources -personas: - - chain-operator -categories: - - chain-operation - - infrastructure - - system-configuration - - node-management - - deployment-tooling - - chain-deployment - - system-components - - system-design -is_imported_content: 'false' ---- - -import { Card, Cards } from 'nextra/components' -import { ChainOperatorsBanner } from '../../components/ChainOperatorsBanner' - - - -# Chain Operators - -Documentation covering Architecture, Configuration, Deploy, Features, Hacks, Management, Self Hosted, Tools, Tutorials in the Chain Operators section of the OP Stack ecosystem. - - - - - - - - - - - - - - - - - - diff --git a/pages/operators/chain-operators/_meta.json b/pages/operators/chain-operators/_meta.json deleted file mode 100644 index a502f517f..000000000 --- a/pages/operators/chain-operators/_meta.json +++ /dev/null @@ -1,10 +0,0 @@ -{ - "architecture": "Architecture", - "self-hosted": "Start a self-hosted chain", - "configuration": "Chain configuration", - "management": "Chain management", - "features": "Chain features", - "deploy": "Deployment", - "tutorials": "Tutorials", - "tools": "Chain tools" -} diff --git a/pages/operators/chain-operators/configuration.mdx b/pages/operators/chain-operators/configuration.mdx deleted file mode 100644 index 4f043904d..000000000 --- a/pages/operators/chain-operators/configuration.mdx +++ /dev/null @@ -1,35 +0,0 @@ ---- -title: Configuration -lang: en-US -description: Overview of configuration options for batchers, chain operators, proposers, and rollup deployments. -content_type: landing-page -topic: chain-configuration -personas: - - chain-operator - - protocol-developer -categories: - - batcher - - proposer - - rollup-configuration - - chain-configuration -is_imported_content: 'false' ---- - -import { Card, Cards } from 'nextra/components' -import { ChainOperatorsBanner } from '../../../components/ChainOperatorsBanner' - - - -# Configuration - -This section provides information on batcher configuration, chain operator configurations, proposer configuration, and rollup deployment configuration. Users will find API references and overviews to help understand and work with these topics. - - - - - - - - - - diff --git a/pages/operators/chain-operators/configuration/_meta.json b/pages/operators/chain-operators/configuration/_meta.json deleted file mode 100644 index cfa1aaf62..000000000 --- a/pages/operators/chain-operators/configuration/_meta.json +++ /dev/null @@ -1,6 +0,0 @@ -{ - "overview": "Overview", - "rollup": "Rollup deployment configuration", - "batcher": "Batcher configuration", - "proposer": "Proposer configuration" -} \ No newline at end of file diff --git a/pages/operators/chain-operators/deploy.mdx b/pages/operators/chain-operators/deploy.mdx deleted file mode 100644 index d65df0783..000000000 --- a/pages/operators/chain-operators/deploy.mdx +++ /dev/null @@ -1,47 +0,0 @@ ---- -title: Deploy -lang: en-US -description: Information on OP Stack genesis creation, deployment overview, and smart contract deployment. -content_type: landing-page -topic: chain-deployment -personas: - - chain-operator - - protocol-developer -categories: - - chain-deployment - - chain-configuration - - chain-operation - - node-management - - genesis-creation - - deployment-artifacts -is_imported_content: 'false' ---- - -import { Card, Cards } from 'nextra/components' -import { ChainOperatorsBanner } from '../../../components/ChainOperatorsBanner' - - - -# Deploy - -This section provides information on OP Stack genesis creation, deployment overview, and smart contract deployment. You'll find guides and overviews to help you understand and work with these topics. - - - - - - - - - - - - - - - - - - - - diff --git a/pages/operators/chain-operators/deploy/_meta.json b/pages/operators/chain-operators/deploy/_meta.json deleted file mode 100644 index 61f001ab4..000000000 --- a/pages/operators/chain-operators/deploy/_meta.json +++ /dev/null @@ -1,11 +0,0 @@ -{ - "overview": "Deployment overview", - "smart-contracts": "Smart contract deployment", - "genesis": "Chain artifacts creation", - "validate-deployment": "Validate your contract deployment", - "sequencer-node": "Spinning up the sequencer", - "proposer-setup-guide": "Spinning up the proposer", - "spin-batcher": "Spinning up the batcher", - "op-challenger": "Spinning up the op-challenger" -} - diff --git a/pages/operators/chain-operators/deploy/op-challenger.mdx b/pages/operators/chain-operators/deploy/op-challenger.mdx deleted file mode 100644 index 7c83d6cc6..000000000 --- a/pages/operators/chain-operators/deploy/op-challenger.mdx +++ /dev/null @@ -1,636 +0,0 @@ ---- -title: How to configure challenger for your chain -description: Learn how to configure challenger for your OP Stack chain. -lang: en-US -content_type: tutorial -topic: configure-challenger-for-your-chain -personas: - - chain-operator -categories: - - mainnet - - testnet - - fault-proofs - - op-challenger - - chain-configuration -is_imported_content: 'false' ---- - -import { Callout, Steps, Tabs, Tab } from 'nextra/components' - -# How to configure challenger for your chain - -This guide provides step-by-step instructions for setting up the configuration and monitoring options for `op-challenger`. The challenger is a critical fault proofs component that monitors dispute games and challenges invalid claims to protect your OP Stack chain. - -See the [OP-Challenger Explainer](/stack/fault-proofs/challenger) for a general overview of this fault proofs feature. - -The challenger is responsible for: - -* Monitoring dispute games created by the fault proof system -* Challenging invalid claims in dispute games -* Defending valid state transitions -* Resolving games when possible - -## Prerequisites - -### Essential requirements - -Before configuring your challenger, complete the following steps: - - - -### Deploy OP Stack chain with fault proofs enabled -* L1 contracts deployed with dispute game factory -* Fault proof system active on your chain -* Access to your chain's contract addresses -* [Generate an absolute prestate](/operators/chain-operators/tutorials/absolute-prestate#generating-the-absolute-prestate) for your network version - This is critical as the challenger will refuse to interact with games if it doesn't have the matching prestate - -### Set up required infrastructure access -* L1 RPC endpoint (Ethereum, Sepolia, etc.) -* L1 Beacon node endpoint (for blob access) -* L2 archive node with debug API enabled -* Rollup node (op-node) with historical data - -### Prepare configuration files -* `rollup.json` - Rollup configuration file -* `genesis-l2.json` - L2 genesis file -* `prestate.json` - The absolute prestate file generated in step 1 - - - -### Software requirements - -* Git (for cloning repositories) -* Go 1.21+ (if building from source) -* Docker and Docker Compose (optional but recommended) -* Access to a funded Ethereum account for challenger operations - -### Finding the current stable releases - -To ensure you're using the latest compatible versions of OP Stack components, always check the official releases page: - -[OP Stack releases page](https://github.com/ethereum-optimism/optimism/releases) - -Look for the latest `op-challenger/v*` release. The challenger version used in this guide (op-challenger/v1.5.0) is a verified stable version. - -Always check the release notes to ensure you're using compatible versions with your chain's deployment. - -## Software installation - -For challenger deployment, you can either build from source (recommended for better control and debugging) or use Docker for a containerized setup. - - - -### Build and Configure - -Building from source gives you full control over the binaries and is the preferred approach for production deployments. - -**Clone and build op-challenger** - -```bash -# Clone the optimism monorepo -git clone https://github.com/ethereum-optimism/optimism.git -cd optimism - -# Check out the latest release of op-challenger -git checkout op-challenger/v1.5.0 - -# Install dependencies and build -just op-challenger - -# Binary will be available at ./op-challenger/bin/op-challenger -``` - -### Verify installation - -Check that you have properly installed the challenger component: - -```bash -# Make sure you're in the optimism directory -./op-challenger/bin/op-challenger --help - -# You should see the challenger help output with available commands and flags -``` - -## Configuration setup - - - -### Organize your workspace - -After building the binaries, create your challenger working directory: - -```bash -# Create challenger directory (this should be at the same level as optimism directory) -mkdir challenger-node -cd challenger-node - -# Create necessary subdirectories -mkdir scripts -mkdir challenger-data - -# Verify the optimism directory is accessible -# Directory structure should look like: -# /optimism/ (contains the built binaries) -# /challenger-node/ (your working directory) -``` - -### Copy configuration files - -```bash -# Copy configuration files to your challenger directory -# Adjust paths based on your deployment setup -cp /path/to/your/rollup.json . -cp /path/to/your/genesis-l2.json . -``` - -### Set up environment variables - -You'll need to gather several pieces of information before creating your configuration. Here's where to get each value: - -**L1 network access:** - -* L1 RPC URL: Your L1 node endpoint (Infura, Alchemy, or self-hosted) -* L1 Beacon URL: Beacon chain API endpoint for blob access - -**L2 network access:** - -* L2 RPC URL: Your op-geth archive node endpoint -* Rollup RPC URL: Your op-node endpoint with historical data - -**Challenger wallet:** - -* Private key for challenger operations (must be funded) - -**Network configuration:** - -* Game factory address from your contract deployment -* Network identifier (e.g., op-sepolia, op-mainnet, or custom) - -Copy and paste in your terminal, to create your env file. - -```bash -# Create .env file with your actual values -cat > .env << 'EOF' -# L1 Configuration - Replace with your actual RPC URLs -L1_RPC_URL=https://sepolia.infura.io/v3/YOUR_ACTUAL_INFURA_KEY - -# L2 Configuration - Replace with your actual node endpoints -L2_RPC_URL=http://localhost:8545 -ROLLUP_RPC_URL=http://localhost:8547 -L1_BEACON=http://sepolia-cl-1:5051 - -# Wallet configuration - Choose either mnemonic + HD path OR private key -MNEMONIC="test test test test test test test test test test test junk" -HD_PATH="m/44'/60'/0'/0/0" -# PRIVATE_KEY=YOUR_ACTUAL_PRIVATE_KEY # Alternative to mnemonic - -# Network configuration -NETWORK=op-sepolia -GAME_FACTORY_ADDRESS=YOUR_GAME_FACTORY_ADDRESS - -# Trace configuration -TRACE_TYPE=permissioned,cannon - -# Data directory -DATADIR=./challenger-data - -# Cannon configuration -# Path to the cannon binary (built from optimism repo) -CANNON_BIN=/cannon/bin/cannon - -# Configuration files -CANNON_ROLLUP_CONFIG= -CANNON_L2_GENESIS= -CANNON_SERVER=/op-program/bin/op-program -CANNON_PRESTATE= -EOF -``` - -**Important:** Replace ALL placeholder values (`YOUR_ACTUAL_*`) with your real configuration values. - - -### Understanding key configuration flags - -
---l1-eth-rpc - -* This is the HTTP provider URL for a standard L1 node, can be a full node. `op-challenger` will be sending many requests, so chain operators need a node that is trusted and can easily handle many transactions. -* Note: Challenger has a lot of money, and it will spend it if it needs to interact with games. That might risk not defending games or challenging games correctly, so chain operators should really trust the nodes being pointed at Challenger. -
- -
---l1-beacon - -* This is needed just to get blobs from. -* In some instances, chain operators might need a blob archiver or L1 consensus node configured not to prune blobs: - * If the chain is proposing regularly, a blob archiver isn't needed. There's only a small window in the blob retention period that games can be played. - * If the chain doesn't post a valid output root in 18 days, then a blob archiver running a challenge game is needed. If the actor gets pushed to the bottom of the game, it could lose if it's the only one protecting the chain. -
- -
---l2-eth-rpc - -* This needs to be `op-geth` archive node, with `debug` enabled. -* Technically doesn't need to go to bedrock, but needs to have access to the start of any game that is still in progress. -
- -
---rollup-rpc - -* This needs to be an `op-node` archive node because challenger needs access to output roots from back when the games start. See below for important configuration details: - -1. Safe Head Database (SafeDB) Configuration for op-node: - - * The `op-node` behind the `op-conductor` must have the SafeDB enabled to ensure it is not stateless. - - * To enable SafeDB, set the `--safedb.path` value in your configuration. This specifies the file path used to persist safe head update data. - - * Example Configuration: - - ``` - --safedb.path # Replace with your actual path - ``` - - - If this path is not set, the SafeDB feature will be disabled. - - -2. Ensuring Historical Data Availability: - - * Both `op-node` and `op-geth` must have data from the start of the games to maintain network consistency and allow nodes to reference historical state and transactions. - * For `op-node`: Configure it to maintain a sufficient history of blockchain data locally or use an archive node. - * For `op-geth`: Similarly, configure to store or access historical data. - * Example Configuration: - - ``` - op-node \ - --rollup-rpc \ - --safedb.path - ``` - - - Replace `` with the URL of your archive node and `` with the desired path for storing SafeDB data. - -
- -
---private-key - -* Chain operators must specify a private key or use something else (like `op-signer`). -* This uses the same transaction manager arguments as `op-node` , batcher, and proposer, so chain operators can choose one of the following options: - * a mnemonic - * a private key - * `op-signer` endpoints -
- -
---network - -* This identifies the L2 network `op-challenger` is running for, e.g., `op-sepolia` or `op-mainnet`. -* When using the `--network` flag, the `--game-factory-address` will be automatically pulled from the [`superchain-registry`](https://github.com/ethereum-optimism/superchain-registry/blob/main/chainList.json). -* When cannon is executed, challenger needs the roll-up config and the L2 Genesis, which is op-geth's Genesis file. Both files are automatically loaded when Cannon Network is used, but custom networks will need to specify both Cannon L2 Genesis and Cannon rollup config. -* For custom networks not in the [`superchain-registry`](https://github.com/ethereum-optimism/superchain-registry/blob/main/chainList.json), the `--game-factory-address` and rollup must be specified, as follows: - - ``` - --cannon-rollup-config rollup.json \ - --cannon-l2-genesis genesis-l2.json \ - # use this if running challenger outside of the docker image - --cannon-server ./op-program/bin/op-program \ - # json or url, version of op-program deployed on chain - # if you use the wrong one, you will lose the game - # if you deploy your own contracts, you specify the hash, the root of the json file - # op mainnet are tagged versions of op-program - # make reproducible prestate - # challenger verifies that onchain - --cannon-prestate ./op-program/bin/prestate.json \ - # load the game factory address from system config or superchain registry - # point the game factory address at the dispute game factory proxy - --game-factory-address - ``` - - - These options vary based on which `--network` is specified. Chain operators always need to specify a way to load prestates and must also specify the cannon-server whenever the docker image isn't being used. - -
- -
---datadir - -* This is a directory that `op-challenger` can write to and store whatever data it needs. It will manage this directory to add or remove data as needed under that directory. -* If running in docker, it should point to a docker volume or mount point, so the data isn't lost on every restart. The data can be recreated if needed but particularly if challenger has executed cannon as part of responding to a game it may mean a lot of extra processing. -
- -
---cannon-prestates-url - -The pre-state is effectively the version of `op-program` that is deployed on chain. And chain operators must use the right version. `op-challenger` will refuse to interact with games that have a different absolute prestate hash to avoid making invalid claims. If deploying your own contracts, chain operators must specify an absolute prestate hash taken from the `make reproducible-prestate` command during contract deployment, which will also build the required prestate json file. - -All governance approved releases use a tagged version of `op-program`. These can be rebuilt by checking out the version tag and running `make reproducible-prestate`. - -* There are two ways to specify the prestate to use: - * `--cannon-prestate`: specifies a path to a single Cannon pre-state Json file - * `--cannon-prestates-url`: specifies a URL to load pre-states from. This enables participating in games that use different prestates, for example due to a network upgrade. The prestates are stored in this directory named by their hash. -* Example final URL for a prestate: - * [https://example.com/prestates/0x031e3b504740d0b1264e8cf72b6dde0d497184cfb3f98e451c6be8b33bd3f808.json](https://example.com/prestates/0x031e3b504740d0b1264e8cf72b6dde0d497184cfb3f98e451c6be8b33bd3f808.json) - * This file contains the cannon memory state. - - - Challenger will refuse to interact with any games if it doesn't have the matching prestate. - Check this [guide](/operators/chain-operators/tutorials/absolute-prestate#generating-the-absolute-prestate) on how to generate a absolute prestate. - -
- - - -### Create challenger startup script - -Create `scripts/start-challenger.sh`: - -```bash -#!/bin/bash -source .env - -# Path to the challenger binary -../optimism/op-challenger/bin/op-challenger \ - --trace-type permissioned,cannon \ - --l1-eth-rpc=$L1_RPC_URL \ - --l2-eth-rpc=$L2_RPC_URL \ - --l1-beacon=$L1_BEACON \ - --rollup-rpc=$ROLLUP_RPC_URL \ - --game-factory-address $GAME_FACTORY_ADDRESS \ - --datadir=$DATADIR \ - --cannon-bin=$CANNON_BIN \ - --cannon-rollup-config=$CANNON_ROLLUP_CONFIG \ - --cannon-l2-genesis=$CANNON_L2_GENESIS \ - --cannon-server=$CANNON_SERVER \ - --cannon-prestate=$CANNON_PRESTATE \ - --mnemonic "$MNEMONIC" \ - --hd-path "$HD_PATH" -``` - -## Initializing and starting the challenger - -### Start the challenger - -```bash -# Make sure you're in the challenger-node directory -cd challenger-node - -# Make script executable -chmod +x scripts/start-challenger.sh - -# Start challenger -./scripts/start-challenger.sh -``` - -### Verify challenger is running - -Monitor challenger logs to ensure it's operating correctly: - -```bash -# Check challenger logs -tail -f challenger-data/challenger.log - -# Or if running in foreground, monitor the output -``` - -The challenger should show logs indicating: - -* Successful connection to L1 and L2 nodes -* Loading of prestates and configuration -* Monitoring of dispute games - - - -### Docker Setup - -The Docker setup provides a containerized environment for running the challenger. This method uses the official Docker image that includes embedded `op-program` server and Cannon executable. - - - -### Create environment file -First, create a `.env` file with your configuration values. This file will be used by Docker Compose to set up the environment variables: - -```bash -# Create .env file with your actual values -cat > .env << 'EOF' -# L1 Configuration - Replace with your actual RPC URLs -L1_RPC_URL=https://sepolia.infura.io/v3/YOUR_ACTUAL_INFURA_KEY -L1_BEACON=http://sepolia-cl-1:5051 - -# L2 Configuration - Replace with your actual node endpoints -L2_RPC_URL=http://localhost:8545 -ROLLUP_RPC_URL=http://localhost:8547 - -# Wallet configuration - Choose either mnemonic + HD path OR private key -MNEMONIC="test test test test test test test test test test test junk" -HD_PATH="m/44'/60'/0'/0/0" - -# Network configuration -NETWORK=op-sepolia -GAME_FACTORY_ADDRESS=YOUR_GAME_FACTORY_ADDRESS -EOF -``` -**Important:** Replace ALL placeholder values (`YOUR_ACTUAL_*`) with your real configuration values. - -### Understanding configuration flags -Each environment variable maps to a specific challenger configuration flag. Here's what each one does: - -
---l1-eth-rpc - -* This is the HTTP provider URL for a standard L1 node, can be a full node. `op-challenger` will be sending many requests, so chain operators need a node that is trusted and can easily handle many transactions. -* Note: Challenger has a lot of money, and it will spend it if it needs to interact with games. That might risk not defending games or challenging games correctly, so chain operators should really trust the nodes being pointed at Challenger. -
- -
---l1-beacon - -* This is needed just to get blobs from. -* In some instances, chain operators might need a blob archiver or L1 consensus node configured not to prune blobs: - * If the chain is proposing regularly, a blob archiver isn't needed. There's only a small window in the blob retention period that games can be played. - * If the chain doesn't post a valid output root in 18 days, then a blob archiver running a challenge game is needed. If the actor gets pushed to the bottom of the game, it could lose if it's the only one protecting the chain. -
- -
---l2-eth-rpc - -* This needs to be `op-geth` archive node, with `debug` enabled. -* Technically doesn't need to go to bedrock, but needs to have access to the start of any game that is still in progress. -
- -
---rollup-rpc - -* This needs to be an `op-node` archive node because challenger needs access to output roots from back when the games start. See below for important configuration details: - -1. Safe Head Database (SafeDB) Configuration for op-node: - - * The `op-node` behind the `op-conductor` must have the SafeDB enabled to ensure it is not stateless. - - * To enable SafeDB, set the `--safedb.path` value in your configuration. This specifies the file path used to persist safe head update data. - - * Example Configuration: - - ``` - --safedb.path # Replace with your actual path - ``` - - - If this path is not set, the SafeDB feature will be disabled. - - -2. Ensuring Historical Data Availability: - - * Both `op-node` and `op-geth` must have data from the start of the games to maintain network consistency and allow nodes to reference historical state and transactions. - * For `op-node`: Configure it to maintain a sufficient history of blockchain data locally or use an archive node. - * For `op-geth`: Similarly, configure to store or access historical data. - * Example Configuration: - - ``` - op-node \ - --rollup-rpc \ - --safedb.path - ``` - - - Replace `` with the URL of your archive node and `` with the desired path for storing SafeDB data. - -
- -
---private-key - -* Chain operators must specify a private key or use something else (like `op-signer`). -* This uses the same transaction manager arguments as `op-node` , batcher, and proposer, so chain operators can choose one of the following options: - * a mnemonic - * a private key - * `op-signer` endpoints -
- -
---network - -* This identifies the L2 network `op-challenger` is running for, e.g., `op-sepolia` or `op-mainnet`. -* When using the `--network` flag, the `--game-factory-address` will be automatically pulled from the [`superchain-registry`](https://github.com/ethereum-optimism/superchain-registry/blob/main/chainList.json). -* When cannon is executed, challenger needs the roll-up config and the L2 Genesis, which is op-geth's Genesis file. Both files are automatically loaded when Cannon Network is used, but custom networks will need to specify both Cannon L2 Genesis and Cannon rollup config. -* For custom networks not in the [`superchain-registry`](https://github.com/ethereum-optimism/superchain-registry/blob/main/chainList.json), the `--game-factory-address` and rollup must be specified, as follows: - - ``` - --cannon-rollup-config rollup.json \ - --cannon-l2-genesis genesis-l2.json \ - # use this if running challenger outside of the docker image - --cannon-server ./op-program/bin/op-program \ - # json or url, version of op-program deployed on chain - # if you use the wrong one, you will lose the game - # if you deploy your own contracts, you specify the hash, the root of the json file - # op mainnet are tagged versions of op-program - # make reproducible prestate - # challenger verifies that onchain - --cannon-prestate ./op-program/bin/prestate.json \ - # load the game factory address from system config or superchain registry - # point the game factory address at the dispute game factory proxy - --game-factory-address - ``` - - - These options vary based on which `--network` is specified. Chain operators always need to specify a way to load prestates and must also specify the cannon-server whenever the docker image isn't being used. - -
- -
---datadir - -* This is a directory that `op-challenger` can write to and store whatever data it needs. It will manage this directory to add or remove data as needed under that directory. -* If running in docker, it should point to a docker volume or mount point, so the data isn't lost on every restart. The data can be recreated if needed but particularly if challenger has executed cannon as part of responding to a game it may mean a lot of extra processing. -
- -
---cannon-prestates-url - -The pre-state is effectively the version of `op-program` that is deployed on chain. And chain operators must use the right version. `op-challenger` will refuse to interact with games that have a different absolute prestate hash to avoid making invalid claims. If deploying your own contracts, chain operators must specify an absolute prestate hash taken from the `make reproducible-prestate` command during contract deployment, which will also build the required prestate json file. - -All governance approved releases use a tagged version of `op-program`. These can be rebuilt by checking out the version tag and running `make reproducible-prestate`. - -* There are two ways to specify the prestate to use: - * `--cannon-prestate`: specifies a path to a single Cannon pre-state Json file - * `--cannon-prestates-url`: specifies a URL to load pre-states from. This enables participating in games that use different prestates, for example due to a network upgrade. The prestates are stored in this directory named by their hash. -* Example final URL for a prestate: - * [https://example.com/prestates/0x031e3b504740d0b1264e8cf72b6dde0d497184cfb3f98e451c6be8b33bd3f808.json](https://example.com/prestates/0x031e3b504740d0b1264e8cf72b6dde0d497184cfb3f98e451c6be8b33bd3f808.json) - * This file contains the cannon memory state. - - - Challenger will refuse to interact with any games if it doesn't have the matching prestate. - Check this [guide](/operators/chain-operators/tutorials/absolute-prestate#generating-the-absolute-prestate) on how to generate a absolute prestate. - -
- -### Set up Docker Compose -Create a `docker-compose.yml` file that defines the challenger service: - -```yaml - -services: - challenger: - image: us-docker.pkg.dev/oplabs-tools-artifacts/images/op-challenger:v1.5.0 - user: "1000" - volumes: - - ./challenger-data:/data - - ./rollup.json:/workspace/rollup.json:ro - - ./genesis-l2.json:/workspace/genesis-l2.json:ro - environment: - - L1_RPC_URL=${L1_RPC_URL} - - L1_BEACON=${L1_BEACON} - - L2_RPC_URL=${L2_RPC_URL} - - ROLLUP_RPC_URL=${ROLLUP_RPC_URL} - - MNEMONIC=${MNEMONIC} - - HD_PATH=${HD_PATH} - - NETWORK=${NETWORK} - - GAME_FACTORY_ADDRESS=${GAME_FACTORY_ADDRESS} - command: - - "op-challenger" - - "--l1-eth-rpc=${L1_RPC_URL}" - - "--l1-beacon=${L1_BEACON}" - - "--l2-eth-rpc=${L2_RPC_URL}" - - "--rollup-rpc=${ROLLUP_RPC_URL}" - - "--selective-claim-resolution" - - "--mnemonic=${MNEMONIC}" - - "--hd-path=${HD_PATH}" - - "--network=${NETWORK}" - - "--game-factory-address=${GAME_FACTORY_ADDRESS}" - - "--datadir=/data" - - "--cannon-prestate=/workspace/prestate-proof.json" - restart: unless-stopped - ports: - - "8548:8548" # If challenger exposes metrics endpoint -``` - -### Launch the challenger -Start the challenger service and monitor its logs: - -```bash -# Start the challenger service -docker-compose up -d - -# View logs -docker-compose logs -f challenger -``` - - - - - - -### Monitoring with op-dispute-mon - -Consider running [`op-dispute-mon`](/operators/chain-operators/tools/chain-monitoring#dispute-mon) for enhanced security monitoring: - -* Provides visibility into all game statuses for the last 28 days -* Essential for production challenger deployments -* Create Grafana dashboards using: [Download the Dispute Monitor JSON](/resources/grafana/dispute-monitor-1718214549035.json) - -## Next steps - -* Read the [OP-Challenger Explainer](/stack/fault-proofs/challenger) for additional context and FAQ -* Review the detailed [challenger specifications](https://specs.optimism.io/fault-proof/stage-one/honest-challenger-fdg.html) for implementation details -* If you experience any problems, reach out to [developer support](https://github.com/ethereum-optimism/developers/discussions) diff --git a/pages/operators/chain-operators/deploy/sequencer-node.mdx b/pages/operators/chain-operators/deploy/sequencer-node.mdx deleted file mode 100644 index bcf586a52..000000000 --- a/pages/operators/chain-operators/deploy/sequencer-node.mdx +++ /dev/null @@ -1,589 +0,0 @@ ---- -title: Spinning up the sequencer -lang: en-US -description: Spin up a single sequencer node after verifying L1 smart-contract deployment. -content_type: tutorial -topic: spinning sequencer -personas: - - chain-operator - - node-operator - - protocol-developer -categories: - - chain-operation - - chain-deployment - - node-management - - sequencer-configuration - - op-stack -is_imported_content: 'false' ---- - -import { Callout, Steps, Tabs } from 'nextra/components' - -## Overview - -This guide provides step-by-step instructions for spinning up a sequencer node after deploying L1 smart contracts for your OP Stack chain with [`op-deployer`](/operators/chain-operators/tools/op-deployer). - -A sequencer node consists of two core components: - -* **op-geth**: Execution layer that processes transactions and maintains state -* **op-node**: Consensus layer that orders transactions and creates L2 blocks - -The sequencer is responsible for: - -* Ordering transactions from users -* Building L2 blocks -* Signing blocks on the P2P network - -## Prerequisites - -### Essential requirements - -Before spinning up your sequencer, complete the following steps: - -**1. Successful L1 contract deployment:** - -* Deployed L1 contracts using [`op-deployer apply`](/operators/chain-operators/tools/op-deployer#apply-deploy-your-chain) command. -* Generated genesis and rollup configuration files using: - ```bash - op-deployer inspect genesis --workdir .deployer > .deployer/genesis.json - op-deployer inspect rollup --workdir .deployer > .deployer/rollup.json - ``` - -**2. Required configuration files:** - -* `genesis.json` - L2 genesis file for initializing op-geth -* `rollup.json` - Rollup configuration file for op-node -* Access to your deployment `state.json` file from op-deployer - -**3. L1 network access:** - -* L1 RPC endpoint (Ethereum, Sepolia, etc.) -* L1 Beacon node endpoint - -### Software requirements - -* Git (for cloning repositories) -* Go 1.21+ (if building from source) -* Docker and Docker Compose (optional but recommended) -* OpenSSL for JWT secret generation - -### Finding the current stable releases - -To ensure you're using the latest compatible versions of OP Stack components, always check the official releases page: - -**[release page](https://github.com/ethereum-optimism/optimism/releases)** - -The main components you'll need for sequencer deployment are: - -* **op-node**: Look for the latest `op-node/v*` release -* **op-geth**: Look for the latest `op-geth/v*` [release](https://github.com/ethereum-optimism/op-geth/releases) - - -The versions used in this guide (**op-node/v1.13.3** and **op-geth/v1.101511.1**) are verified compatible versions. - -According to the **op-node v1.13.3** [release notes](https://github.com/ethereum-optimism/optimism/releases/tag/op-node%2Fv1.13.3), this op-node version specifically corresponds to **op-geth v1.101511.1**. -Always check the release notes to ensure you're using compatible versions. - - -## Software installation - -For spinning up a sequencer, we recommend building from source as it provides better control, and helps with debugging. -In this guide Docker alternative is also provided. - - - - Building from source gives you full control over the binaries. - - #### 1. Clone and build op-node - - ```bash - # Clone the optimism monorepo - git clone https://github.com/ethereum-optimism/optimism.git - cd optimism - - # Checkout the latest release tag - git checkout op-node/v1.13.3 - - # Build op-node - cd op-node - just - - # Binary will be available at ./bin/op-node - ``` - - #### 2. Clone and build op-geth - - ```bash - # Clone op-geth repository (in a separate directory) - git clone https://github.com/ethereum-optimism/op-geth.git - cd op-geth - - # Checkout to this release tag - git checkout v1.101511.1 - - # Build op-geth - make geth - - # Binary will be available at ./build/bin/geth - ``` - - ### Verify installation - - Check that you have properly installed the needed components. - - ```bash - # Make sure you're in the right directory - ./bin/op-node --version - ./build/bin/geth version - ``` - - ## Configuration setup - - ### 1. Organize your workspace - - After building the binaries, you should have the following directory structure: - - ``` - ~/ - ├── optimism/ # Optimism monorepo - │ └── op-node/ - │ └── bin/ - │ └── op-node # Built binary - ├── op-geth/ # OP-Geth repository - │ └── build/ - │ └── bin/ - │ └── geth # Built binary - └── .deployer/ # From op-deployer - ├── genesis.json - └── rollup.json - ``` - - Now create your sequencer working directory. We recommend creating it at the same level for easy path references: - - ```bash - # Create sequencer directory at the root level - mkdir ~/sequencer-node - cd ~/sequencer-node - ``` - -
- Alternative: Copy binaries to sequencer directory - - If you prefer to keep binaries close to your configuration, you can copy them: - - ```bash - mkdir ~/sequencer-node/bin - cp ~/optimism/op-node/bin/op-node ~/sequencer-node/bin/ - cp ~/op-geth/build/bin/geth ~/sequencer-node/bin/ - - # Then update scripts to use: - # ./bin/geth - # ./bin/op-node - ``` -
- - ### 2. Generate JWT secret - - ```bash - # Generate JWT secret in the sequencer directory - openssl rand -hex 32 > jwt.txt - - # Set appropriate permissions - chmod 600 jwt.txt - ``` - - ### 3. Set up directory structure and copy files - - In this guide, we're going to be using the binaries from their original build locations, we only need to create directories for configuration files and scripts. - - ```bash - # Create scripts directory - mkdir scripts - - # Copy configuration files from op-deployer - cp ~/.deployer/genesis.json . - cp ~/.deployer/rollup.json . - ``` - - Your final directory structure should look like: - - ```bash - ~/sequencer-node/ - ├── jwt.txt - ├── genesis.json - ├── rollup.json - └── scripts/ - ├── start-op-geth.sh # (to be created) - └── start-op-node.sh # (to be created) - ``` - - ### 4. Environment variables - - You'll need to gather several pieces of information before creating your configuration. Here's where to get each value: - - ### Get L1 network access - - You need access to the L1 network (Ethereum mainnet or Sepolia testnet) and its beacon node: - - **L1 RPC URL options:** - - * **Infura**: [infura.io](https://infura.io) - Requires an API key from a project - * **Alchemy**: [alchemy.com](https://alchemy.com) - Requires an API key from an app - - **L1 Beacon URL options:** - - * **Public beacon APIs**: `https://ethereum-sepolia-beacon-api.publicnode.com` (Sepolia) or `https://ethereum-beacon-api.publicnode.com` (Mainnet) - * **Infura beacon**: `https://sepolia.infura.io/v3/YOUR_KEY` (if your Infura plan includes beacon access) - - ### Get private key from your wallet - - For this basic sequencer setup, you only need a private key during op-node initialization. - - ### Get your public IP address - - ```bash - # Find your public IP address, once you get it, update the P2P_ADVERTISE_IP in your .env - curl ifconfig.me - # or - curl ipinfo.io/ip - ``` - - ### Choose your ports - - The default ports are standard but can be changed if needed: - - * `8545`: op-geth HTTP RPC (standard Ethereum RPC port) - * `8546`: op-geth WebSocket RPC - * `8551`: op-geth Auth RPC (for op-node communication) - * `8547`: op-node RPC - * `9222`: P2P networking (must be open on firewall) - - - - Now create your `.env` file with the actual values: - - ```bash - # Create .env file with your actual values - # L1 Configuration - Replace with your actual RPC URLs - L1_RPC_URL=https://sepolia.infura.io/v3/YOUR_ACTUAL_INFURA_KEY - L1_BEACON_URL=https://ethereum-sepolia-beacon-api.publicnode.com - - # Sequencer configuration - SEQUENCER_ENABLED=true - SEQUENCER_STOPPED=false - - # Private keys - PRIVATE_KEY=YOUR_ACTUAL_PRIVATE_KEY - - # P2P configuration - Replace with your actual public IP - P2P_LISTEN_PORT=9222 - P2P_ADVERTISE_IP=YOUR_ACTUAL_PUBLIC_IP - - # RPC configuration (can customize ports if needed) - OP_NODE_RPC_PORT=8547 - OP_GETH_HTTP_PORT=8545 - OP_GETH_WS_PORT=8546 - OP_GETH_AUTH_PORT=8551 - - # JWT secret location - JWT_SECRET=./jwt.txt - ``` - - **Important**: Replace ALL placeholder values (`YOUR_ACTUAL_*`) with your real configuration values. - - ## Sequencer specific configuration - - ### op-geth configuration for sequencer - - Create `scripts/start-op-geth.sh`: - - ```bash - #!/bin/bash - source .env - - # Path to the op-geth binary we built - ../op-geth/build/bin/geth \ - --datadir=./op-geth-data \ - --http \ - --http.addr=0.0.0.0 \ - --http.port=$OP_GETH_HTTP_PORT \ - --http.vhosts="*" \ - --http.corsdomain="*" \ - --http.api=eth,net,web3,debug,txpool,admin \ - --ws \ - --ws.addr=0.0.0.0 \ - --ws.port=$OP_GETH_WS_PORT \ - --ws.origins="*" \ - --ws.api=eth,net,web3,debug,txpool,admin \ - --authrpc.addr=0.0.0.0 \ - --authrpc.port=$OP_GETH_AUTH_PORT \ - --authrpc.vhosts="*" \ - --authrpc.jwtsecret=$JWT_SECRET \ - --syncmode=full \ - --gcmode=archive \ - --rollup.disabletxpoolgossip=true \ - --rollup.sequencerhttp=http://localhost:$OP_NODE_RPC_PORT - ``` - - ### op-node configuration for sequencer - - Create `scripts/start-op-node.sh`: - - ```bash - #!/bin/bash - - source .env - - # Path to the op-node binary we built - ../optimism/op-node/bin/op-node \ - --l1=$L1_RPC_URL \ - --l1.beacon=$L1_BEACON_URL \ - --l2=http://localhost:$OP_GETH_AUTH_PORT \ - --l2.jwt-secret=$JWT_SECRET \ - --rollup.config=./rollup.json \ - --sequencer.enabled=$SEQUENCER_ENABLED \ - --sequencer.stopped=$SEQUENCER_STOPPED \ - --sequencer.max-safe-lag=3600 \ - --verifier.l1-confs=4 \ - --p2p.listen.ip=0.0.0.0 \ - --p2p.listen.tcp=$P2P_LISTEN_PORT \ - --p2p.listen.udp=$P2P_LISTEN_PORT \ - --p2p.advertise.ip=$P2P_ADVERTISE_IP \ - --p2p.advertise.tcp=$P2P_LISTEN_PORT \ - --p2p.advertise.udp=$P2P_LISTEN_PORT \ - --p2p.sequencer.key=$PRIVATE_KEY \ - --rpc.addr=0.0.0.0 \ - --rpc.port=$OP_NODE_RPC_PORT \ - --rpc.enable-admin \ - --log.level=info \ - --log.format=json - ``` - - ## Initializing and starting the sequencer - - - - ### Initialize op-geth with your genesis file - - ```bash - # Make sure you're in the sequencer-node directory - cd ~/sequencer-node - - # Initialize op-geth with your genesis file - ../op-geth/build/bin/geth init --datadir=./op-geth-data --state.scheme=hash ./genesis.json - ``` - - ### Start op-geth - - ```bash - # Make scripts executable - chmod +x scripts/start-op-geth.sh - chmod +x scripts/start-op-node.sh - - # Start op-geth in the background or in a separate terminal - ./scripts/start-op-geth.sh - ``` - - **Note**: You should see output indicating that op-geth is starting and listening on the configured ports. - - ### Start op-node - - ```bash - # In a separate terminal, navigate to the sequencer directory - cd ~/sequencer-node - - # Start op-node - ./scripts/start-op-node.sh - ``` - - ### Verify sequencer is running - - Once both services are running, verify they're working correctly: - - ```bash - # Check op-geth is responding, do this in another terminal - curl -X POST -H "Content-Type: application/json" \ - --data '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}' \ - http://localhost:8545 - - # Check sequencer status - curl -X POST -H "Content-Type: application/json" \ - --data '{"jsonrpc":"2.0","method":"admin_sequencerActive","params":[],"id":1}' \ - http://localhost:8547 - ``` - - - Your sequencer node is now operational and ready to process transactions. - - - - - If you prefer containerized deployment, you can use the official Docker images, and do the following: - - 1. **Set up directory structure and copy configuration files:** - - ```bash - # Create your sequencer working directory - mkdir ~/sequencer-node - cd ~/sequencer-node - - # Copy configuration files from op-deployer output - # Note: Adjust the path if your .deployer directory is located elsewhere - cp ~/.deployer/genesis.json . - cp ~/.deployer/rollup.json . - - # Generate JWT secret - openssl rand -hex 32 > jwt.txt - chmod 600 jwt.txt - ``` - - 2. **Create environment variables file:** - - ```bash - # Create .env file with your actual values - cat > .env << 'EOF' - # L1 Configuration - Replace with your actual RPC URLs - L1_RPC_URL=https://sepolia.infura.io/v3/YOUR_ACTUAL_INFURA_KEY - L1_BEACON_URL=https://ethereum-sepolia-beacon-api.publicnode.com - - # Private keys - Replace with your actual private key - PRIVATE_KEY=YOUR_ACTUAL_PRIVATE_KEY - - # (Run `curl ifconfig.me` in a separate shell to obtain the value, then paste it below) - - # P2P configuration - Replace with your actual public IP - P2P_ADVERTISE_IP=YOUR_ACTUAL_PUBLIC_IP - - EOF - ``` - - **Important**: Replace ALL placeholder values (`YOUR_ACTUAL_*`) with your real configuration values. - - 3. **Create docker-compose.yml:** - - ```yaml - ' - - services: - op-geth: - image: us-docker.pkg.dev/oplabs-tools-artifacts/images/op-geth:v1.101511.1 - volumes: - # Mount entire directory to avoid file mounting issues - - .:/workspace - working_dir: /workspace - ports: - - "8545:8545" - - "8546:8546" - - "8551:8551" - command: - - "--datadir=/workspace/op-geth-data" - - "--http" - - "--http.addr=0.0.0.0" - - "--http.port=8545" - - "--ws" - - "--ws.addr=0.0.0.0" - - "--ws.port=8546" - - "--authrpc.addr=0.0.0.0" - - "--authrpc.port=8551" - - "--authrpc.jwtsecret=/workspace/jwt.txt" - - "--syncmode=full" - - "--gcmode=archive" - - "--rollup.disabletxpoolgossip=true" - - "--rollup.sequencerhttp=http://op-node:8547" - - "--http.vhosts=*" - - "--http.corsdomain=*" - - "--http.api=eth,net,web3,debug,txpool,admin" - - "--ws.origins=*" - - "--ws.api=eth,net,web3,debug,txpool,admin" - - "--authrpc.vhosts=*" - - op-node: - image: us-docker.pkg.dev/oplabs-tools-artifacts/images/op-node:v1.13.3 - depends_on: - - op-geth - volumes: - - .:/workspace - working_dir: /workspace - ports: - - "8547:8547" - - "9222:9222" - environment: - - L1_RPC_URL=${L1_RPC_URL} - - L1_BEACON_URL=${L1_BEACON_URL} - - PRIVATE_KEY=${PRIVATE_KEY} - - P2P_ADVERTISE_IP=${P2P_ADVERTISE_IP} - command: - - "op-node" - - "--l1=${L1_RPC_URL}" - - "--l1.beacon=${L1_BEACON_URL}" - - "--l2=http://op-geth:8551" - - "--l2.jwt-secret=/workspace/jwt.txt" - - "--rollup.config=/workspace/rollup.json" - - "--sequencer.enabled=true" - - "--sequencer.stopped=false" - - "--sequencer.max-safe-lag=3600" - - "--verifier.l1-confs=4" - - "--p2p.listen.ip=0.0.0.0" - - "--p2p.listen.tcp=9222" - - "--p2p.listen.udp=9222" - - "--p2p.advertise.ip=${P2P_ADVERTISE_IP}" - - "--p2p.advertise.tcp=9222" - - "--p2p.advertise.udp=9222" - - "--p2p.sequencer.key=${PRIVATE_KEY}" - - "--rpc.addr=0.0.0.0" - - "--rpc.port=8547" - - "--rpc.enable-admin" - - "--log.level=info" - - "--log.format=json" - ``` - - 4. **Initialize op-geth with Docker:** - - ```bash - # Make sure you're in the sequencer-node directory with all files copied - cd ~/sequencer-node - - # Initialize op-geth using Docker - docker run --rm \ - -v $(pwd):/workspace \ - -w /workspace \ - us-docker.pkg.dev/oplabs-tools-artifacts/images/op-geth:v1.101511.1 \ - init --datadir=./op-geth-data --state.scheme=hash ./genesis.json - ``` - - 5. **Start the services:** - - ```bash - # Start both services - docker-compose up -d - - # View logs - docker-compose logs -f - ``` - - 6. **Final directory structure:** - - ```bash - ~/sequencer-node/ - ├── jwt.txt # Generated JWT secret - ├── genesis.json # Copied from ~/.deployer/ - ├── rollup.json # Copied from ~/.deployer/ - ├── .env # Environment variables - ├── docker-compose.yml # Docker configuration - └── op-geth-data/ # Created by Docker during initialization - ├── geth/ # Geth data - └── keystore/ # Key files - ``` - - Your sequencer node is now operational and ready to process transactions. - - - - - -## Next steps - -* Discover how to [deploy chains with op-deployer](/operators/chain-operators/tools/op-deployer) for standardized OP Stack deployments. -* Learn how to configure and deploy the [batcher](/operators/chain-operators/configuration/batcher) to submit transaction data to L1. -* Set up the [proposer](/operators/chain-operators/configuration/proposer) to submit output roots for withdrawals. -* Explore chain operator [best practices](/operators/chain-operators/management/best-practices) for production deployments. diff --git a/pages/operators/chain-operators/features.mdx b/pages/operators/chain-operators/features.mdx deleted file mode 100644 index 689d40b4a..000000000 --- a/pages/operators/chain-operators/features.mdx +++ /dev/null @@ -1,36 +0,0 @@ ---- -title: Features -lang: en-US -description: >- - Learn about features in the Optimism ecosystem. This guide provides detailed - information and resources about features. -content_type: landing-page -topic: features -personas: - - chain-operator - - protocol-developer -categories: - - alt-da - - bridged-usdc-standard - - preinstalls - - span-batches -is_imported_content: 'false' ---- - -import { Card, Cards } from 'nextra/components' - -# Features - -This section provides information on various features for chain operators. You'll find guides and overviews to help you understand and work with topics such as running an alternative data availability mode chain, implementing the bridged USDC standard on the OP Stack, OP Stack preinstalls, and span batches. - - - - - - - - - - - - diff --git a/pages/operators/chain-operators/features/_meta.json b/pages/operators/chain-operators/features/_meta.json deleted file mode 100644 index a88282967..000000000 --- a/pages/operators/chain-operators/features/_meta.json +++ /dev/null @@ -1,7 +0,0 @@ -{ - "preinstalls": "Preinstalls", - "flashblocks": "Flashblocks", - "alt-da-mode": "Run an Alt-DA Mode chain", - "span-batches": "Use and enable span batches on your chain", - "bridged-usdc-standard": "Bridged USDC Standard for the OP Stack" -} \ No newline at end of file diff --git a/pages/operators/chain-operators/features/flashblocks.mdx b/pages/operators/chain-operators/features/flashblocks.mdx deleted file mode 100644 index b35122fb0..000000000 --- a/pages/operators/chain-operators/features/flashblocks.mdx +++ /dev/null @@ -1,30 +0,0 @@ ---- -title: Flashblocks -lang: en-US -description: >- - Learn about Flashblocks for lightning-fast transaction confirmations on OP Stack chains. - This guide provides detailed information for both app developers and chain operators. -content_type: landing-page -topic: flashblocks -personas: - - app-developer - - chain-operator - - protocol-developer -categories: - - protocol - - block-production - - developer-tools -is_imported_content: 'false' ---- - -import { Card, Cards } from 'nextra/components' - -# Flashblocks - -Flashblocks delivers sub-second transaction confirmations on OP Stack chains, enabling lightning-fast user experiences without compromising security. This section provides comprehensive guides for both app developers and chain operators. - - - - - - diff --git a/pages/operators/chain-operators/features/flashblocks/_meta.json b/pages/operators/chain-operators/features/flashblocks/_meta.json deleted file mode 100644 index 64f005fe9..000000000 --- a/pages/operators/chain-operators/features/flashblocks/_meta.json +++ /dev/null @@ -1,4 +0,0 @@ -{ - "apps": "Apps", - "chain-operators": "Chain Operators" -} diff --git a/pages/operators/chain-operators/features/flashblocks/apps.mdx b/pages/operators/chain-operators/features/flashblocks/apps.mdx deleted file mode 100644 index 7b1048347..000000000 --- a/pages/operators/chain-operators/features/flashblocks/apps.mdx +++ /dev/null @@ -1,244 +0,0 @@ ---- -title: Flashblocks -description: Learn how to integrate Flashblocks for lightning-fast transaction confirmations on OP Stack, with pre-confirmations in just 200 milliseconds. -lang: en-US -content_type: guide -topic: flashblocks -personas: - - app-developer - - protocol-developer - - chain-operator -categories: - - protocol - - block-production - - developer-tools -is_imported_content: 'false' ---- - -# Flashblocks - -Flashblocks is a block builder sidecar for OP Stack chains that delivers sub-second transaction confirmations - 250 ms on OP Mainnet, configurable down to 200 ms. - -By streaming pre-confirmations, "signals" that arrive before the next block is finalized, Flashblocks make OP Stack chains up to 10x faster, unlocking seamless user experiences without compromising security guarantees. - -Built for developers who need lightning fast UX, flashblocks are ideal for DeFi apps, payments, games, and real-time interactions where instant is the only answer. - -* **Payments**: Instant payment confirmations -* **DeFi**: Swaps and positions that update immediately -* **Marketplaces**: Fast, frictionless checkout flows -* **Games**: Real-time actions with no waiting between moves - -## How it works - -By default, blocks are produced every 1–2 seconds. -Flashblocks break that window into smaller intervals so instead of waiting the full block time to execute all transactions, the execution client continuously creates and broadcasts a "flash" block every few hundred milliseconds. - -Each flashblock includes all transactions processed so far, along with updated balances and contract states. -Apps can query this near-real-time state using RPC providers (Ankr, QuickNode, Alchemy, etc) and deliver the speed their users expect. - -## Integrate Flashblocks - -Integration is designed to be simple and low-friction. Most apps benefit with minimal code changes. - -* In production, point your app to a a Flashblocks‑aware RPC endpoint from your provider of choice. If your provider doesn't support flashblocks yet, let us know on Discord - and we'll work with them to get it added. -* Alternatively, you can run your own flashblocks-aware node using Base's [reth](https://github.com/base/node-reth) image. - -### Supported RPC methods - -Developers can access Flashblocks using the same familiar Ethereum JSON-RPC calls. -The difference is using the "pending" tag to query the pre-confirmed state instead of the last finalized block. - -* **`eth_getBlockByNumber`**: Use the `pending` tag to retrieve the latest flashblock snapshot. -
- Sample response - - ```json - { - "jsonrpc": "2.0", - "id": 1, - "result": { - "number": "0x1234", - "hash": "0x...", - "transactions": [...] - } - } - ``` -
- -* **`eth_call`**: Use the `pending` tag to execute calls against the most recent pre-confirmed state. - -
- Sample request - - ```json - { - "jsonrpc": "2.0", - "method": "eth_call", - "params": [{"to": "0x...", "data": "0x..."}, "pending"], - "id": 1 - } - ``` -
- -* `eth_getBalance` / `eth_getTransactionCount`: Use the `pending` tag to fetch balances or transaction counts as they evolve within the block window. - -
- Sample response for `eth_getBalance` - - ```json - { - "jsonrpc": "2.0", - "id": 1, - "result": "0x0234" - } - ``` -
- -
- Sample response for `eth_getTransactionCount` - - ```json - { - "jsonrpc": "2.0", - "id": 1, - "result": "0x1b" // 27 transactions - } - ``` -
- - Other methods, like `eth_getTransactionReceipt` and `eth_getTransactionByHash`, return data from pre-confirmed transactions without requiring the `pending` tag. - Consult the [Flashblocks specification](https://specs.optimism.io/protocol/flashblocks.html#flashblock-json-rpc-apis) for more details on each of these methods. - -## Libraries - -You will need a Flashblocks‑aware RPC endpoint to use the following libraries: - -### Viem - -```ts -import { createPublicClient, createWalletClient, http, parseEther } from 'viem'; -import { privateKeyToAccount } from 'viem/accounts'; -import { opSepolia } from 'viem/chains'; -import { publicActionsL2, walletActionsL2 } from 'viem/op-stack'; - -const account = privateKeyToAccount(`0x${process.env.PRIVATE_KEY}`); - -const walletClient = createWalletClient({ - account, - chain: opSepolia, - transport: http("https://sepolia.optimism.io"), -}).extend(walletActionsL2()); - -const publicClient = createPublicClient({ - chain: opSepolia, - transport: http("https://sepolia.optimism.io"), -}).extend(publicActionsL2()); - -const submissionTime = new Date(); -const hash = await walletClient.sendTransaction({ - to: '0x...', - value: parseEther('0.0001'), -}); - -// Wait for pre-confirmation -const receipt = await publicClient.waitForTransactionReceipt({ hash }); -const confirmTime = new Date(); -console.log('pre-confirmed in ms:', confirmTime.getTime() - submissionTime.getTime()); -``` - -### Ethers - -```ts -import { ethers } from 'ethers'; - -// Here, provider is a Flashblocks-enabled RPC provider -const provider = new ethers.JsonRpcProvider("https://sepolia.optimism.io"); -const wallet = new ethers.Wallet(process.env.PRIVATE_KEY as string, provider); - -const tx = { to: '0x...', value: ethers.parseEther('0.0001') }; -const submission = new Date(); - -const sent = await wallet.sendTransaction(tx); - -await sent.wait(0); -const confirmed = new Date(); - -// should represent the transaction (pre)confirmation faster than standard RPC -console.log('Pre-confirmed in ms:', confirmed.getTime() - submission.getTime()); - -// validates the transaction hash returned by the pre-confirmed transaction above -const receipt = await provider.getTransactionReceipt(sent.hash); -console.log('Receipt validated in ms:', validated.getTime() - submission.getTime()); -console.log('Transaction receipt:', receipt); - -``` - -## Flashblocks FAQ - -### Block building and availability - -
- How often are Flashblocks produced? - The flashblocks target interval is variable. - OP Mainnet runs flashblocks at 250ms while Base and Unichain run them at 200ms. - A 2-second block at 250 ms produces 9 flashblocks, indexed 0 to 8. - The index-0 block contains deposit-only transactions, followed by 8 normal Flashblocks. -
- -
- Will the number of Flashblocks per block always be the maximum? - Not always. Heavy execution in one interval may reduce time available for subsequent intervals. The FLASHBLOCKS\_TIME setting is a target, not a strict guarantee. -
- -
- Do large gas transactions get delayed? - High gas transactions can be included in any flashblock with sufficient gas capacity. Placement is optimized by heuristics, but available gas decreases as transactions fill earlier flashblocks. -
- -### High availability and safety - -
- What happens if the flashblocks builder fails? - In a default/non-HA setup, the system falls back to regular block building while preserving pre-confirmations. In an HA setup, `op-conductor` seamlessly transfers leadership to a healthy sequencer without interruption. - When leadership changes, streaming continues seamlessly from the new leader so downstream consumers always receive a continuous stream from a single stable endpoint. -
- -
- How is continuity handled in high availability setups with multiple sequencers? - Only the current leader streams Flashblocks. On leader change, streaming continues from the new leader so downstream consumers see a continuous stream from a single stable endpoint. For details on high-availability sequencer setups, see the [op-conductor documentation](https://docs.optimism.io/operators/chain-operators/tools/op-conductor). -
- -
- Do flashblocks change the safety model of the chain? - No. Each flashblock is validated by the same execution engine as normal blocks. -
- -### Pre-confirmations and reorgs - -
- Can pre-confirmations be revoked? - Rarely. If the sequencer reorgs, pre-confirmed state may change - but this carries no more risk than the reorg of normal blocks. -
- -
- Why can a pre-confirmed transaction later disappear? - If the sequencer reorgs, pre-confirmed state can be replaced. This does not add risk beyond the pending state reorg risk that already exists. -
- -
- Does Flashblocks change liveness or withdrawals? - No. Protocol guarantees remain the same; Flashblocks only speed up transaction confirmation. -
- -
- What is the structure of a pre-confirmation response? - In pre-confirmation responses, `blockHash`, `stateRoot`, and `receiptsRoot` are the values that represent the cumulative state of all transactions included up to that point in the block. The blockNumber reflects the current pending block number. - Each flashblock's view shows the complete state incorporating all transactions processed so far. -
- -## Next steps - -* Explore the [high-level guide](/operators/chain-operators/features/flashblocks/chain-operators) for operators. -* Review the [technical specs](https://specs.optimism.io/protocol/flashblocks.html) for architecture details. -* Join our [community](https://discord.gg/jPQhHTdemH) to share best practices and get support! diff --git a/pages/operators/chain-operators/features/flashblocks/chain-operators.mdx b/pages/operators/chain-operators/features/flashblocks/chain-operators.mdx deleted file mode 100644 index 3869be847..000000000 --- a/pages/operators/chain-operators/features/flashblocks/chain-operators.mdx +++ /dev/null @@ -1,153 +0,0 @@ ---- -title: "Flashblocks: A Guide for Chain Operators" -description: "Technical guide for chain operators on Flashblocks, covering components, operation, transaction flow, and leader selection." -lang: en-US -content_type: guide -topic: flashblocks -personas: - - chain-operator -categories: - - protocol - - block-production -is_imported_content: 'false' ---- - -import { Callout } from 'nextra/components' - -# Flashblocks for Chain Operators - - - We recommend chain operators read through [Flashbots' docs](https://rollup-boost.flashbots.net/operators/index.html#for-rollup-operators) on how to set up and run Flashblocks locally, in production, and in HA setups. - We'll be updating our docs over the next few weeks to bring the same level of detail here. - - -Flashblocks is a `rollup-boost` module that accelerates confirmation times by dividing block construction into smaller, incremental sections. -This enables pre-confirmations and improves user experience, while finalization still occurs at standard block intervals. - -The Flashblocks setup involves three main components: - -* **`rollup-boost`**: Coordination layer with Flashblocks enabled -* **`op-rbuilder`**: Execution client and builder with Flashblocks support -* **`op-geth`**: Fallback builder, a standard EL node (can be `op-reth` as well) - -Flashblocks are streamed from the `op-rbuilder` to `rollup-boost` over WebSockets, minimizing latency between the sequencer and the pre-confirmed state. - -For full details on design choices, data structures, and invariants, see the [Flashblocks specification](https://specs.optimism.io/protocol/flashblocks.html). - -## Flashblocks components - -Flashblocks relies on several components working together: - -* **`op-node`**: Consensus layer, initiates `engine_forkchoiceUpdated` calls and leads block building. -* **`op-geth`**: Default block builder, produces standard blocks. -* **`op-rbuilder`**: Reth-based execution client that builds both standard blocks and flashblocks. - * Exposes flashblocks on a WebSocket stream (not recommended for public exposure). - * Each event on the stream corresponds to a 250 ms flashblock. -* **`rollup-boost`**: Sits between `op-node` and execution layers, coordinating block building in flashblocks mode. - * Validates `op-rbuilder` payloads against `op-geth` - * Falls back to `op-geth` if `op-rbuilder` diverges or lags -* **`flashblocks-websocket-proxy`**: Relays the flashblocks stream from the active sequencer to RPC providers. -* **`op-node-rbuilder`** *(optional)*: `op-node` pointing only to `op-rbuilder`, used for syncing at startup. -* **`op-conductor`** *(optional but recommended)*: Manages multiple sequencers, ensuring only one healthy leader streams blocks. - -See the [System architecture section](https://specs.optimism.io/protocol/flashblocks.html#system-architecture) to learn more. - -## Flashblocks lifecycle - -```mermaid -flowchart LR - subgraph Sequencer - ON[OP Node] - RB[Rollup Boost] - FEL[Fallback EL] - BB[Block Builder] - end - - subgraph Network - WSP[WebSocket Proxy] - end - - subgraph Clients - RPC[RPC Providers] - Users[End Users] - end - - ON --> RB - RB --> FEL - RB <--> BB - RB --> WSP - WSP --> RPC - RPC --> Users -``` - -* Single-sequencer setup. -* `op-node` coordinates block production through `rollup-boost`, targeting `op-rbuilder` instead of `op-geth`. -* `op-rbuilder` acts as a full execution client: it builds blocks, exposes Ethereum JSON-RPC, and processes transactions. -* In addition, `op-rbuilder` emits flashblocks every 250 ms, streamed over a WebSocket interface (e.g. `wss://`). -* These flashblocks give early visibility into transaction inclusion before the final regular block is sealed. - -For full details on construction rules, validation, and lifecycle steps, see [Flashblocks lifecycle in the specification](https://specs.optimism.io/protocol/flashblocks.html#flashblock-lifecycle). - -## How to set up and run rollup-boost - -Flashblocks relies on `rollup-boost` as the coordination layer for block building. -To run Flashblocks, you'll configure `rollup-boost` alongside your sequencer and execution clients. - -* [Running rollup-boost locally](https://rollup-boost.flashbots.net/operators/local.html) -* [Running rollup-boost in production](https://rollup-boost.flashbots.net/operators/production.html) -* [HA setup for rollup-boost](https://rollup-boost.flashbots.net/operators/ha-setup.html) - -### Single‑sequencer setup - -As suggested in the above links, in a single-sequencer setup, Flashblocks are streamed from `rollup-boost` (or `op-rbuilder`) to `flashblocks-websocket-proxy` by setting the following environment variable in flashblocks-websocket-proxy: - -```jsx -UPSTREAM_WS: ws:///ws -``` - -### HA‑compliant multi‑sequencer setup - -While Flashblocks can be enabled in a single-sequencer setup, we **highly recommend running a high-availability (HA) multi-sequencer setup** managed by [`op-conductor`](/operators/chain-operators/tools/op-conductor). - -In an HA setup, multiple `op-conductor` instances form a [Raft](https://raft.github.io/) group. At any time, only one healthy sequencer acts as the active leader responsible for block building, while others remain in follower mode. Leadership changes automatically if the active sequencer becomes unhealthy. - -For Flashblocks, each sequencer (leader and followers) runs its own dedicated components, including `rollup-boost` and `op-rbuilder`. -Only the leader's `op-rbuilder` produces flashblocks; follower instances remain idle. - -In this setup, the connection between `rollup-boost` and the `flashblocks-websocket-proxy` is mediated by `op-conductor`. - -* `op-conductor` listens to Flashblocks from `rollup-boost` (or `op-rbuilder`). -* If it is the active leader, it forwards the Flashblocks to `flashblocks-websocket-proxy`. -* If it is not the leader, it does not forward anything. - -The rest of the data flow remains unchanged. - -### HA configuration - -**1. Configure `op-conductor`** to listen for Flashblocks and forward them if leader: - -```yaml -OP_CONDUCTOR_WEBSOCKET_SERVER_PORT: "8546" -OP_CONDUCTOR_ROLLUPBOOST_WS_URL: ws:///ws -OP_CONDUCTOR_ROLLUP_BOOST_ENABLED: "true" -OP_CONDUCTOR_EXECUTION_RPC: http://:8551 -``` - -* **Variable descriptions:** - * `OP_CONDUCTOR_WEBSOCKET_SERVER_PORT`: Port where `op-conductor` exposes Flashblocks if it is the leader. For example: `ws://:8546/ws`. - * `OP_CONDUCTOR_ROLLUPBOOST_WS_URL`: Direct URL of `rollup-boost` (or `op-rbuilder`) where Flashblocks are available. In a single-sequencer setup, this is the same URL you'd pass directly to `flashblocks-websocket-proxy`. - * `OP_CONDUCTOR_ROLLUP_BOOST_ENABLED`: Enables health checks for `rollup-boost` (and indirectly `op-rbuilder`) so leadership can fail over if either becomes unhealthy. - * `OP_CONDUCTOR_EXECUTION_RPC`: Execution RPC URL of `rollup-boost`. Same as `OP_NODE_L2_ENGINE_RPC` configured on `op-node`. - -**2. Configure `flashblocks-websocket-proxy`** to consume Flashblocks from all sequencer conductors: - -```yaml -UPSTREAM_WS: ws://:8546/ws,ws://:8546/ws,ws://:8546/ws -``` - -This way, the proxy always connects to the active leader via its `op-conductor`. - -Optional rate limits for `flashblocks-websocket-proxy`: - -* `PER_IP_CONNECTIONS_LIMIT`: Max connections allowed per client IP. -* `INSTANCE_CONNECTION_LIMIT`: Max total connections allowed per proxy instance. diff --git a/pages/operators/chain-operators/management.mdx b/pages/operators/chain-operators/management.mdx deleted file mode 100644 index 6394ecaf5..000000000 --- a/pages/operators/chain-operators/management.mdx +++ /dev/null @@ -1,42 +0,0 @@ ---- -title: Management -lang: en-US -description: >- - Learn about management in the Optimism ecosystem. This guide provides detailed - information and resources about management. -content_type: landing-page -topic: management -personas: - - chain-operator - - protocol-developer -categories: - - chain-operation - - chain-configuration - - best-practices - - blobs - - key-management - - rollup-operations - - snap-sync - - troubleshooting -is_imported_content: 'false' ---- - -import { Card, Cards } from 'nextra/components' - -# Management - -This section provides information on chain operator best practices, using blobs, managing keys, rollup operations, using snap sync for chain operators, and troubleshooting chain operations. You'll find guides and tutorials to help you understand and work with these topics. - - - - - - - - - - - - - - diff --git a/pages/operators/chain-operators/management/_meta.json b/pages/operators/chain-operators/management/_meta.json deleted file mode 100644 index dcfc4355a..000000000 --- a/pages/operators/chain-operators/management/_meta.json +++ /dev/null @@ -1,8 +0,0 @@ -{ - "blobs": "Using blobs", - "snap-sync": "Using Snap Sync", - "operations": "Rollup operations", - "key-management": "Key management", - "troubleshooting": "Troubleshooting", - "best-practices": "Best practices" -} diff --git a/pages/operators/chain-operators/tools.mdx b/pages/operators/chain-operators/tools.mdx deleted file mode 100644 index 9722f3d3a..000000000 --- a/pages/operators/chain-operators/tools.mdx +++ /dev/null @@ -1,42 +0,0 @@ ---- -title: Tools -lang: en-US -description: >- - Learn about tools in the Optimism ecosystem. This guide provides detailed - information and resources about tools. -content_type: landing-page -topic: tools -personas: - - chain-operator - - protocol-developer -categories: - - chain-monitoring - - fee-calculator - - op-validator - - op-challenger - - op-conductor - - op-txproxy - - proxyd - - op-deployer -is_imported_content: 'false' ---- - -import { Card, Cards } from 'nextra/components' -import { ChainOperatorsBanner } from '../../../components/ChainOperatorsBanner' - - - -# Tools - -This section provides information on chain monitoring options, deploying a block explorer, configuring a challenger for your chain, conductor, and deployer. You'll find guides, overviews, and tools to help you understand and work with these topics. - - - - - - - - - - - diff --git a/pages/operators/chain-operators/tools/_meta.json b/pages/operators/chain-operators/tools/_meta.json deleted file mode 100644 index cdcd24668..000000000 --- a/pages/operators/chain-operators/tools/_meta.json +++ /dev/null @@ -1,11 +0,0 @@ -{ - "chain-monitoring": "Chain monitoring", - "explorer": "Block explorer", - "op-challenger": "op-challenger", - "op-conductor": "op-conductor", - "op-deployer": "op-deployer", - "op-validator": "op-validator", - "op-txproxy": "op-txproxy", - "proxyd": "proxyd", - "fee-calculator": "Fee calculator" -} diff --git a/pages/operators/chain-operators/tutorials.mdx b/pages/operators/chain-operators/tutorials.mdx deleted file mode 100644 index 829550798..000000000 --- a/pages/operators/chain-operators/tutorials.mdx +++ /dev/null @@ -1,53 +0,0 @@ ---- -title: Tutorials -description: >- - Learn about tutorials in the Optimism ecosystem. This guide provides detailed - information and resources about tutorials. -lang: en-US -content_type: landing-page -topic: chain-operator-tutorials -personas: - - chain-operator - - protocol-developer -categories: - - derivation - - testnet - - local-devnet - - alt-da - - precompiles - - predeploys - - l2-rollup - - viem -is_imported_content: 'false' ---- - -import { Card, Cards } from 'nextra/components' -import { ChainOperatorsBanner } from '../../../components/ChainOperatorsBanner' - - - -# Tutorials - -This section provides information on adding attributes to the derivation function, adding a precompile, creating your own l2 rollup testnet, integrating a new da layer with alt da, modifying predeployed contracts and using viem. You'll find overview, tutorial, guide to help you understand and work with these topics. - - - - - - - - - - - - - - - - - - - - - - diff --git a/pages/operators/chain-operators/tutorials/_meta.json b/pages/operators/chain-operators/tutorials/_meta.json deleted file mode 100644 index 9168131fe..000000000 --- a/pages/operators/chain-operators/tutorials/_meta.json +++ /dev/null @@ -1,11 +0,0 @@ -{ - "create-l2-rollup": "Creating your own rollup testnet", - "adding-derivation-attributes": "Adding attributes to the derivation function", - "adding-precompiles": "Adding a precompile", - "modifying-predeploys": "Modifying predeployed contracts", - "integrating-da-layer": "Integrating a new DA layer", - "migrating-permissionless": "Migrating to permissionless fault proofs on OP Stack", - "dispute-games":"Deploying new dispute games with OPCM", - "absolute-prestate":"Generating absolute prestate and preimage files", - "chain-dev-net": "Running a local network environment" -} \ No newline at end of file diff --git a/pages/operators/chain-operators/tutorials/create-l2-rollup.mdx b/pages/operators/chain-operators/tutorials/create-l2-rollup.mdx deleted file mode 100644 index a840a2819..000000000 --- a/pages/operators/chain-operators/tutorials/create-l2-rollup.mdx +++ /dev/null @@ -1,196 +0,0 @@ ---- -title: Creating your own L2 rollup testnet -description: Learn how to deploy and orchestrate all OP Stack components for a complete testnet deployment. -lang: en-US -content_type: tutorial -topic: creating-your-own-l2-rollup-testnet -personas: - - chain-operator -categories: - - testnet - - chain-deployment - - op-deployer - - sequencer - - batcher - - proposer - - challenger - - integration -is_imported_content: 'false' ---- - -import { Callout, Card, Steps } from 'nextra/components' - -# Creating your own L2 rollup testnet - -Welcome to the complete guide for deploying your own OP Stack L2 rollup testnet. This multi-part tutorial will walk you through each component step-by-step, from initial setup to a fully functioning rollup. - - - This tutorial requires **intermediate-level experience working with EVM chains**. - You should be comfortable with concepts like smart contracts, private keys, RPC endpoints, gas fees, and command-line operations. - Basic familiarity with Docker is also recommended. - - -## What you'll build - -By the end of this tutorial, you'll have a complete OP Stack testnet with: - -* **L1 Smart Contracts** deployed on Sepolia testnet -* **Execution Client** (op-geth) processing transactions -* **Consensus Client** (op-node) managing rollup consensus -* **Batcher** (op-batcher) publishing transaction data to L1 -* **Proposer** (op-proposer) submitting state root proposals -* **Challenger** (op-challenger) monitoring for disputes - -## Before you start - -### Software dependencies - -| Dependency | Version | Version check command | -| ------------------------------------------------------------- | -------- | --------------------- | -| [git](https://git-scm.com/) | `^2` | `git --version` | -| [go](https://go.dev/) | `^1.21` | `go version` | -| [node](https://nodejs.org/en/) | `^20` | `node --version` | -| [pnpm](https://pnpm.io/installation) | `^8` | `pnpm --version` | -| [foundry](https://github.com/foundry-rs/foundry#installation) | `^0.2.0` | `forge --version` | -| [make](https://linux.die.net/man/1/make) | `^3` | `make --version` | -| [jq](https://github.com/jqlang/jq) | `^1.6` | `jq --version` | -| [direnv](https://direnv.net) | `^2` | `direnv --version` | -| [Docker](https://docs.docker.com/get-docker/) | `^24` | `docker --version` | - -### Notes on specific dependencies - - - Expand each dependency below for details - - -
- node - - We recommend using the latest LTS version of Node.js (currently v20).\ - [`nvm`](https://github.com/nvm-sh/nvm) is a useful tool that can help you manage multiple versions of Node.js on your machine.\ - You may experience unexpected errors on older versions of Node.js. -
- -
- foundry - - We will use cast to generate wallet addresses in this guide. -
- -
- direnv - - Parts of this tutorial use [`direnv`](https://direnv.net) as a way of loading environment variables from `.envrc` files into your shell.\ - This means you won't have to manually export environment variables every time you want to use them.\ - `direnv` only ever has access to files that you explicitly allow it to see. - - After [installing `direnv`](https://direnv.net/docs/installation.html), you will need to **make sure that [`direnv` is hooked into your shell](https://direnv.net/docs/hook.html)**.\ - Make sure you've followed [the guide on the `direnv` website](https://direnv.net/docs/hook.html), then **close your terminal and reopen it** so that the changes take effect (or `source` your config file if you know how to do that). - - - Make sure that you have correctly hooked `direnv` into your shell by modifying your shell configuration file (like `~/.bashrc` or `~/.zshrc`).\ - If you haven't edited a config file then you probably haven't configured `direnv` properly (and things might not work later). - -
- -
- Docker - - Docker is used extensively in this tutorial for running various OP Stack components.\ - Make sure you have both Docker and Docker Compose installed and running on your system.\ - On Linux, you may need to [configure Docker to run without sudo](https://docs.docker.com/engine/install/linux-postinstall/#manage-docker-as-a-non-root-user). - - - If you're using Docker Desktop, ensure it's running before starting the tutorial.\ - You can verify your installation with: - - ```bash - docker run hello-world - ``` - -
- -### Get access to a sepolia node - -Since you're deploying your OP Stack chain to Sepolia, you'll need to have access to a Sepolia node. -You can either use a node provider like [Alchemy](https://www.alchemy.com/) (easier) or run your own Sepolia node (harder). - -### Required resources - -* **Sepolia ETH** - You'll need about 2-3 ETH: - * Start with [Superchain Faucet](https://console.optimism.io/faucet) (gives 0.05 ETH) - * Get more from: - * [Alchemy Faucet](https://sepoliafaucet.com/) - * [Infura Faucet](https://www.infura.io/faucet/sepolia) - * [Paradigm Faucet](https://faucet.paradigm.xyz/) - * Or ask in [Optimism Discord](https://discord.gg/optimism) -* **L1 RPC URL** - An RPC endpoint to connect to the Sepolia network. You can get this from node providers like [Alchemy](https://www.alchemy.com/), [Infura](https://www.infura.io/). This is required so `op-deployer` and other services can read from and send transactions to L1. - - - **Testnet Only**: This guide is for **testnet deployment only**. - - - - **Follow in Order**: Each step builds on the previous one. Start with spinning up op-deployer and complete them sequentially for the best experience. - - -## Directory structure - -To keep your rollup deployment organized, we'll create a dedicated directory structure. All components will be set up within this structure: - -```bash -rollup/ -├── deployer/ # op-deployer files and contracts -├── sequencer/ # op-geth and op-node -├── batcher/ # op-batcher configuration -├── proposer/ # op-proposer setup -└── challenger/ # op-challenger files -``` - -Each component's documentation will show you how the directory structure evolves as you add files and configurations. - - - Throughout this tutorial, all file paths will be relative to this `rollup` directory structure. Make sure to adjust any commands if you use different directory names. - - -## Tutorial overview - -This tutorial is organized into sequential steps that build upon each other: - - - ### **[Spin up op-deployer](/operators/chain-operators/tutorials/create-l2-rollup/op-deployer-setup)** - - Install op-deployer, deploy L1 contracts, and prepare your environment - - ### **[Spin up sequencer](/operators/chain-operators/tutorials/create-l2-rollup/op-geth-setup)** - - Set up and run op-geth and op-node (the execution and consensus layers) - - ### **[Spin up batcher](/operators/chain-operators/tutorials/create-l2-rollup/op-batcher-setup)** - - Configure and start op-batcher for L1 data publishing - - ### **[Spin up proposer](/operators/chain-operators/tutorials/create-l2-rollup/op-proposer-setup)** - - Set up op-proposer for state root submissions - - ### **[Spin up challenger](/operators/chain-operators/tutorials/create-l2-rollup/op-challenger-setup)** - - Configure op-challenger for dispute resolution monitoring - - -## Ready to Start? - -Now that you understand what you'll be building, let's begin with the first step! - - - Already have your dependencies? Get started and spin up op-deployer - - -*** - -## Need Help? - -* **Community Support**: Join the [Optimism Discord](https://discord.gg/optimism) -* **Development Questions**: Visit [Developer Support](https://github.com/ethereum-optimism/developers/discussions) -* **Issues**: Report bugs on [GitHub](https://github.com/ethereum-optimism/optimism/issues) diff --git a/pages/operators/chain-operators/tutorials/create-l2-rollup/_meta.json b/pages/operators/chain-operators/tutorials/create-l2-rollup/_meta.json deleted file mode 100644 index 43db0cad0..000000000 --- a/pages/operators/chain-operators/tutorials/create-l2-rollup/_meta.json +++ /dev/null @@ -1,8 +0,0 @@ -{ - "index": "Overview", - "op-deployer-setup": "Spin up op-deployer", - "op-geth-setup": "Spin up sequencer", - "op-batcher-setup": "Spin up batcher", - "op-proposer-setup": "Spin up proposer", - "op-challenger-setup": "Spin up challenger" -} diff --git a/pages/operators/chain-operators/tutorials/create-l2-rollup/op-batcher-setup.mdx b/pages/operators/chain-operators/tutorials/create-l2-rollup/op-batcher-setup.mdx deleted file mode 100644 index c3015cd20..000000000 --- a/pages/operators/chain-operators/tutorials/create-l2-rollup/op-batcher-setup.mdx +++ /dev/null @@ -1,422 +0,0 @@ ---- -title: Spin up batcher -lang: en-US -description: Learn how to set up and configure an OP Stack batcher to submit L2 transaction batches to L1. -content_type: tutorial -topic: batcher-setup -personas: - - chain-operator -categories: - - testnet - - mainnet - - op-batcher - - batch-submission - - l2-to-l1-data - - transaction-batching -is_imported_content: 'false' ---- - -import { Callout, Steps, Card, Tabs } from 'nextra/components' - -# Spin up batcher - -After you have spun up your sequencer, you need to configure a batcher to submit L2 transaction batches to L1. - - - **Step 3 of 5**: This tutorial is designed to be followed step-by-step. Each step builds on the [previous one](/operators/chain-operators/tutorials/create-l2-rollup/op-geth-setup). - - -## Understanding the batcher's role - -The batcher (`op-batcher`) serves as a crucial component that bridges your L2 chain data to L1. Its primary responsibilities include: - -* **Batch submission**: Collecting L2 transactions and submitting them as batches to L1 -* **Data availability**: Ensuring L2 transaction data is available on L1 for verification -* **Cost optimization**: Compressing and efficiently packing transaction data to minimize L1 costs -* **Channel management**: Managing data channels for optimal batch submission timing - -The batcher reads transaction data from your sequencer and submits compressed batches to the `BatchInbox` contract on L1. - -## Prerequisites - -Before setting up your batcher, ensure you have: - -**Running infrastructure:** - -* An operational sequencer node -* Access to a L1 RPC endpoint - -**Network information:** - -* Your L2 chain ID and network configuration -* L1 network details (chain ID, RPC endpoints) -* `BatchInbox` contract address from your deployment - -For setting up the batcher, we recommend using Docker as it provides a consistent and isolated environment. Building from source is also available for more advanced users. - - - - If you prefer containerized deployment, you can use the official Docker images and do the following: - - - ### Set up directory structure and copy configuration files - - ```bash - # Create your batcher directory inside rollup - cd ../ # Go back to rollup directory if you're in sequencer - mkdir batcher - cd batcher - - # Copy configuration files from deployer - cp ../deployer/.deployer/state.json . - - # Extract the BatchInbox address - BATCH_INBOX_ADDRESS=$(cat state.json | jq -r '.opChainDeployments[0].systemConfigProxyAddress') - echo "BatchInbox Address: $BATCH_INBOX_ADDRESS" - ``` - - ### Create environment variables file - - ```bash - # Create .env file with your actual values - cat > .env << 'EOF' - # L1 Configuration - Replace with your actual RPC URLs - L1_RPC_URL=https://sepolia.infura.io/v3/YOUR_ACTUAL_INFURA_KEY - - # L2 Configuration - Should match your sequencer setup - L2_RPC_URL=http://op-geth:8545 - ROLLUP_RPC_URL=http://op-node:8547 - - # Contract addresses - Extract from your op-deployer output - BATCH_INBOX_ADDRESS=YOUR_ACTUAL_BATCH_INBOX_ADDRESS - - # Private key - Replace with your actual private key - BATCHER_PRIVATE_KEY=YOUR_ACTUAL_PRIVATE_KEY - - # Batcher configuration - POLL_INTERVAL=1s - SUB_SAFETY_MARGIN=6 - NUM_CONFIRMATIONS=1 - SAFE_ABORT_NONCE_TOO_LOW_COUNT=3 - RESUBMISSION_TIMEOUT=30s - MAX_CHANNEL_DURATION=25 - - # RPC configuration - BATCHER_RPC_PORT=8548 - EOF - ``` - - **Important**: Replace ALL placeholder values (`YOUR_ACTUAL_*`) with your real configuration values. - - ### Create a docker-compose.yml file - - - This configuration assumes your sequencer is running in a Docker container named `sequencer-node` on the same `op-stack` network. - Make sure your sequencer is running before starting the batcher. - - - ```yaml - - services: - op-batcher: - image: us-docker.pkg.dev/oplabs-tools-artifacts/images/op-batcher:v1.13.2 - volumes: - - .:/workspace - working_dir: /workspace - ports: - - "8548:8548" - env_file: - - .env - networks: - - sequencer-node_default - command: - - "op-batcher" - - "--l2-eth-rpc=${L2_RPC_URL}" - - "--rollup-rpc=${ROLLUP_RPC_URL}" - - "--poll-interval=${POLL_INTERVAL}" - - "--sub-safety-margin=${SUB_SAFETY_MARGIN}" - - "--num-confirmations=${NUM_CONFIRMATIONS}" - - "--safe-abort-nonce-too-low-count=${SAFE_ABORT_NONCE_TOO_LOW_COUNT}" - - "--resubmission-timeout=${RESUBMISSION_TIMEOUT}" - - "--rpc.addr=0.0.0.0" - - "--rpc.port=${BATCHER_RPC_PORT}" - - "--rpc.enable-admin" - - "--max-channel-duration=${MAX_CHANNEL_DURATION}" - - "--l1-eth-rpc=${L1_RPC_URL}" - - "--private-key=${BATCHER_PRIVATE_KEY}" - - "--batch-type=1" - - "--data-availability-type=blobs" - - "--log.level=info" - - "--max-pending-tx=0" - restart: unless-stopped - - networks: - sequencer-node_default: - external: false - ``` - - ### Start the batcher service - - ```bash - # Make sure your sequencer network exists - # Start the batcher - docker-compose up -d - - # View logs - docker-compose logs -f op-batcher - ``` - - ### Verify batcher is running - - ```bash - # Check container status - docker-compose ps - ``` - - ### Final directory structure - - ```bash - rollup/ - ├── deployer/ # From previous step - │ └── .deployer/ # Contains genesis.json and rollup.json - ├── sequencer/ # From previous step - └── batcher/ # You are here - ├── state.json # Copied from deployer - ├── .env # Environment variables - └── docker-compose.yml # Docker configuration - ``` - - - Your batcher is now operational and will continuously submit L2 transaction batches to L1! - - - - - To ensure you're using the latest compatible versions of OP Stack components, always check the official [releases page](https://github.com/ethereum-optimism/optimism/releases). - - Look for the latest `op-batcher/v*` release that's compatible with your sequencer setup. - - - This guide uses `op-batcher/v1.13.2` which is compatible with op-node/v1.13.3 and op-geth/v1.101511.1 from the sequencer setup. - Always check the [release notes](https://github.com/ethereum-optimism/optimism/releases) for compatibility information. - - - - ### Clone and build op-batcher - - ```bash - # If you don't already have the optimism repository from the sequencer setup - git clone https://github.com/ethereum-optimism/optimism.git - cd optimism - - # Checkout the latest release tag - git checkout op-batcher/v1.13.2 - - # Build op-batcher - cd op-batcher - just - - # Binary will be available at ./bin/op-batcher - ``` - - ### Verify installation - - Run this command to verify the installation: - - ```bash - ./bin/op-batcher --version - ``` - ### Configuration setup - - - For advanced configuration options and fine-tuning your batcher, including: - - * Batch submission policies - * Channel duration settings - * Data availability types (blobs vs calldata) - * Transaction throttling - * Network timeouts - - Check out the [Batcher Configuration Reference](/operators/chain-operators/configuration/batcher). - This will help you optimize your batcher's performance and cost-efficiency. - - - - ### Organize your workspace - - Create your batcher working directory: - - ```bash - # Create batcher directory inside rollup - cd ../ # Go back to rollup directory - mkdir batcher - cd batcher - - # Create scripts directory - mkdir scripts - ``` - - Your final directory structure should look like: - - ```bash - rollup/ - ├── deployer/ # From previous step - │ └── .deployer/ # Contains state.json - ├── optimism/ # Contains op-batcher binary - ├── sequencer/ # From previous step - └── batcher/ # You are here - ├── state.json # Copied from deployer - ├── .env # Environment variables - └── scripts/ # Startup scripts - └── start-batcher.sh - ``` - - ### Extract BatchInbox address - - Extract the `BatchInbox` contract address from your op-deployer output: - - ```bash - # Make sure you're in the rollup/batcher directory - cd rollup/batcher - - # Copy the deployment state file from deployer - cp ../deployer/.deployer/state.json . - - # Extract the BatchInbox address - BATCH_INBOX_ADDRESS=$(cat state.json | jq -r '.opChainDeployments[0].systemConfigProxyAddress') - echo "BatchInbox Address: $BATCH_INBOX_ADDRESS" - ``` - - - The batcher submits transaction batches to the `BatchInbox` contract on L1. This contract is responsible for accepting and storing L2 transaction data. - - - ### Set up environment variables - - Create your `.env` file with the actual values: - - ```bash - # Create .env file with your actual values - # L1 Configuration - Replace with your actual RPC URL - L1_RPC_URL=https://sepolia.infura.io/v3/YOUR_ACTUAL_INFURA_KEY - - # L2 Configuration - Should match your sequencer setup - L2_RPC_URL=http://op-geth:8545 - ROLLUP_RPC_URL=http://op-node:8547 - - # Contract addresses - Extract from your op-deployer output - BATCH_INBOX_ADDRESS=YOUR_ACTUAL_BATCH_INBOX_ADDRESS - - # Private key - Replace with your actual private key - BATCHER_PRIVATE_KEY=YOUR_ACTUAL_PRIVATE_KEY - - # Batcher configuration - POLL_INTERVAL=1s - SUB_SAFETY_MARGIN=6 - NUM_CONFIRMATIONS=1 - SAFE_ABORT_NONCE_TOO_LOW_COUNT=3 - RESUBMISSION_TIMEOUT=30s - MAX_CHANNEL_DURATION=25 - - # RPC configuration - BATCHER_RPC_PORT=8548 - ``` - - **Important**: Replace ALL placeholder values (`YOUR_ACTUAL_*`) with your real configuration values! - - ### Get your private key - - Get a private key from your wallet that will be used for submitting batches to L1. This account needs sufficient ETH to pay for L1 gas costs. - - - The batcher account needs to be funded with ETH on L1 to pay for batch submission transactions. Monitor this account's balance regularly as it will consume ETH for each batch submission. - - - - ### Batcher configuration - - Create `scripts/start-batcher.sh` in the same directory: - - ```bash - #!/bin/bash - - source .env - - # Path to the op-batcher binary we built - ../../optimism/op-batcher/bin/op-batcher \ - --l2-eth-rpc=$L2_RPC_URL \ - --rollup-rpc=$ROLLUP_RPC_URL \ - --poll-interval=$POLL_INTERVAL \ - --sub-safety-margin=$SUB_SAFETY_MARGIN \ - --num-confirmations=$NUM_CONFIRMATIONS \ - --safe-abort-nonce-too-low-count=$SAFE_ABORT_NONCE_TOO_LOW_COUNT \ - --resubmission-timeout=$RESUBMISSION_TIMEOUT \ - --rpc.addr=0.0.0.0 \ - --rpc.port=$BATCHER_RPC_PORT \ - --rpc.enable-admin \ - --max-channel-duration=$MAX_CHANNEL_DURATION \ - --l1-eth-rpc=$L1_RPC_URL \ - --private-key=$BATCHER_PRIVATE_KEY \ - --batch-type=1 \ - --data-availability-type=blobs \ - --log.level=info - ``` - - ### Batcher parameters explained - - * **`--poll-interval`**: How frequently the batcher checks for new L2 blocks to batch - * **`--sub-safety-margin`**: Number of confirmations to wait before considering L1 transactions safe - * **`--max-channel-duration`**: Maximum time (in L1 blocks) to keep a channel open - * **`--batch-type`**: Type of batch encoding (1 for span batches, 0 for singular batches) - * **`--data-availability-type`**: Whether to use blobs or calldata for data availability - - ### Starting the batcher - - ### Start the batcher - - ```bash - # Make the script executable - chmod +x scripts/start-batcher.sh - - # Start the batcher - ./scripts/start-batcher.sh - ``` - - - For detailed cost analysis and optimization strategies, refer to the [Fee calculation tools](/operators/chain-operators/tools/fee-calculator). - - - Your batcher is now operational and will continuously submit L2 transaction batches to L1! - - - - - - - **Understanding common startup messages** - - When starting your batcher, you might see various log messages: - - * `Added L2 block to local state`: Normal operation, shows the batcher processing blocks - * `SetMaxDASize RPC method unavailable`: Expected if the `op-geth` version used doesn't support this method. - * `context canceled` errors during shutdown: Normal cleanup messages - * `Failed to query L1 tip`: Can occur during graceful shutdowns - - Most of these messages are part of normal operation. For detailed explanations of configuration options and troubleshooting, see the [Batcher configuration reference](/operators/chain-operators/configuration/batcher). - - -## What's Next? - -Excellent! Your batcher is publishing transaction data to L1. The next step is to set up the proposer to submit state root proposals. - - - **Next**: Configure and start op-proposer to submit L2 state roots to L1 for withdrawal verification. - - -*** - -## Need Help? - -* **Community Support**: Join the [Optimism Discord](https://discord.optimism.io) -* **Batcher Configuration**: [op-batcher Configuration Reference](/operators/chain-operators/configuration/batcher) -* **Monitoring Guide**: [Chain Monitoring](/operators/chain-operators/tools/chain-monitoring) diff --git a/pages/operators/chain-operators/tutorials/create-l2-rollup/op-challenger-setup.mdx b/pages/operators/chain-operators/tutorials/create-l2-rollup/op-challenger-setup.mdx deleted file mode 100644 index 312ad4c33..000000000 --- a/pages/operators/chain-operators/tutorials/create-l2-rollup/op-challenger-setup.mdx +++ /dev/null @@ -1,628 +0,0 @@ ---- -title: Spin up challenger -description: Learn how to configure challenger for your OP Stack chain. -lang: en-US -content_type: tutorial -topic: configure-challenger-for-your-chain -personas: - - chain-operator -categories: - - mainnet - - testnet - - fault-proofs - - op-challenger - - chain-configuration -is_imported_content: 'false' ---- - -import { Callout, Steps, Tabs, Tab } from 'nextra/components' - -# Spin up challenger - -After you have spun up your sequencer, batcher, and proposer, the final step is to configure a challenger to monitor and respond to disputes. The challenger is the security component that ensures the integrity of your rollup by monitoring dispute games and responding to invalid claims. - - - **Step 5 of 5**: This tutorial is designed to be followed step-by-step. - Each step builds on the previous one, and this is the last part of the tutorial. - - -This guide provides step-by-step instructions for setting up the configuration and monitoring options for `op-challenger`. The challenger is a critical fault proofs component that monitors dispute games and challenges invalid claims to protect your OP Stack chain. - -See the [OP-Challenger explainer](/stack/fault-proofs/challenger) for a general overview of this fault proofs feature. - -The challenger is responsible for: - -* Monitoring dispute games created by the fault proof system -* Challenging invalid claims in dispute games -* Defending valid state transitions -* Resolving games when possible - -## Prerequisites - -### Essential requirements - -Before configuring your challenger, complete the following steps: - - - ### Deploy OP Stack chain with fault proofs enabled - -
- Generate absolute prestate (Required) - - The challenger needs the absolute prestate to participate in dispute games. Here's how to generate it: - - 1. **Clone and checkout the correct version**: - ```bash - git clone https://github.com/ethereum-optimism/optimism.git - cd optimism - git checkout op-program/v1.6.1 # Use the latest stable version - git submodule update --init --recursive - ``` - - 2. **Copy your chain configuration**: - ```bash - # Assuming you're in rollup/challenger/optimism directory - # Replace with your actual L2 chain ID - cp ../deployer/.deployer/rollup.json op-program/chainconfig/configs/-rollup.json - cp ../deployer/.deployer/genesis.json op-program/chainconfig/configs/-genesis.json - - # Your directory structure should look like: - # rollup/ - # ├── deployer/ - # │ └── .deployer/ - # │ ├── rollup.json # Source file - # │ └── genesis.json # Source file - # └── optimism/ # You are here - # └── op-program/ - # └── chainconfig/ - # └── configs/ - # ├── -rollup.json # Destination - # └── -genesis.json # Destination - ``` - - 3. **Generate the prestate**: - ```bash - make reproducible-prestate - ``` - You'll see output like: - ```bash - -------------------- Production Prestates -------------------- - Cannon64 Absolute prestate hash: - 0x03eb07101fbdeaf3f04d9fb76526362c1eea2824e4c6e970bdb19675b72e4fc8 - ``` - - 4. **Prepare the preimage file**: - ```bash - cd op-program/bin - mv prestate-mt64.bin.gz 0x[CANNON64_PRESTATE_HASH].bin.gz - ``` - Replace `[CANNON64_PRESTATE_HASH]` with the actual hash from step 3. - - - * Use the `Cannon64` hash for production - * Keep this file accessible - you'll need it for the challenger setup - * For Superchain registry chains, you can find official prestates in the [registry](https://github.com/ethereum-optimism/superchain-registry/blob/main/validation/standard/standard-prestates.toml) - -
- ### Set up required infrastructure access - - * L1 RPC endpoint (Ethereum, Sepolia, etc.) - * L1 Beacon node endpoint (for blob access) - - ### Prepare configuration files - - * `prestate.json` - The absolute prestate file generated in step 1 - * `rollup.json` - Rollup configuration file from the `op-deployer` guide - - -## Software installation - -For challenger deployment, we recommend using Docker as it provides a consistent and isolated environment. Building from source is also available for more advanced users. - - - - - ### Docker Setup - - The Docker setup provides a containerized environment for running the challenger. This method uses the official Docker image that includes embedded `op-program` server and Cannon executable. - - - ### Create challenger directory - - ```bash - # Create your challenger directory inside rollup - cd ../ # Go back to rollup directory if you're in proposer - mkdir challenger - cd challenger - ``` - - ### Create environment file - - First, create a `.env` file with your configuration values. This file will be used by Docker Compose to set up the environment variables: - - ```bash - # Create .env file with your actual values - cat > .env << 'EOF' - # L1 Configuration - Replace with your actual RPC URLs - L1_RPC_URL=https://sepolia.infura.io/v3/YOUR_ACTUAL_INFURA_KEY - L1_BEACON=https://ethereum-sepolia-beacon-api.publicnode.com - - # L2 Configuration - Replace with your actual node endpoints - L2_RPC_URL=http://op-geth:8545 - ROLLUP_RPC_URL=http://op-node:8547 - - # Private key - Replace with your actual private key - PRIVATE_KEY=YOUR_ACTUAL_PRIVATE_KEY - - # Network configuration - NETWORK=op-sepolia - GAME_FACTORY_ADDRESS=YOUR_GAME_FACTORY_ADDRESS - - # Prestate configuration - Replace with the hash from 'make reproducible-prestate' - PRESTATE_HASH=YOUR_PRESTATE_HASH - EOF - ``` - - **Important:** Replace ALL placeholder values (`YOUR_ACTUAL_*`) with your real configuration values. - - ### Set up Docker Compose - - Create a `docker-compose.yml` file that defines the challenger service. The file mounts several important files: - * `prestate-proof-mt64.json` and `${PRESTATE_HASH}.bin.gz`: Prestate files required for dispute games (the PRESTATE_HASH comes from running `make reproducible-prestate`), replace `PRESTATE_HASH` with the actual hash - - ```yaml - - services: - challenger: - image: us-docker.pkg.dev/oplabs-tools-artifacts/images/op-challenger:v1.5.0 - user: "1000" - volumes: - - ./challenger-data:/data - - ./rollup.json:/workspace/rollup.json:ro - - ./genesis-l2.json:/workspace/genesis-l2.json:ro - - ./prestate-proof-mt64.json:/workspace/prestate-proof.json:ro - - ./${PRESTATE_HASH}.bin.gz:/workspace/${PRESTATE_HASH}.bin.gz:ro - environment: - - L1_RPC_URL=${L1_RPC_URL} - - L1_BEACON=${L1_BEACON} - - L2_RPC_URL=${L2_RPC_URL} - - ROLLUP_RPC_URL=${ROLLUP_RPC_URL} - - PRIVATE_KEY=${PRIVATE_KEY} - - NETWORK=${NETWORK} - - GAME_FACTORY_ADDRESS=${GAME_FACTORY_ADDRESS} - command: - - "op-challenger" - - "--trace-type=cannon,asterisc-kona" - - "--l1-eth-rpc=${L1_RPC_URL}" - - "--l1-beacon=${L1_BEACON}" - - "--l2-eth-rpc=${L2_RPC_URL}" - - "--rollup-rpc=${ROLLUP_RPC_URL}" - - "--selective-claim-resolution" - - "--private-key=${PRIVATE_KEY}" - - "--game-factory-address=${GAME_FACTORY_ADDRESS}" - - "--datadir=/data" - - "--cannon-prestate=/workspace/prestate-proof.json" - - "--cannon-bin=/workspace/${PRESTATE_HASH}.bin.gz" - - "--asterisc-kona-prestate=/workspace/prestate-proof.json" - restart: unless-stopped - networks: - - sequencer-node_default - - networks: - sequencer-node_default: - external: false - - - ``` - - ### Launch the challenger - - Start the challenger service and monitor its logs: - - ```bash - # Start the challenger service - docker-compose up -d - - # View logs - docker-compose logs -f challenger - ``` - - - - - - To ensure you're using the latest compatible versions of OP Stack components, always check the official releases page: - - [OP Stack releases page](https://github.com/ethereum-optimism/optimism/releases) - - Look for the latest `op-challenger/v*` release. The challenger version used in this guide (op-challenger/v1.5.0) is a verified stable version. - - Always check the release notes to ensure you're using compatible versions with your chain's deployment. - - ### Build and Configure - - Building from source gives you full control over the binaries. - - **Clone and build op-challenger** - - ```bash - # Clone the optimism monorepo - git clone https://github.com/ethereum-optimism/optimism.git - cd optimism - - # Check out the latest release of op-challenger - git checkout op-challenger/v1.5.0 - - # Install dependencies and build - just op-challenger - - # Binary will be available at ./op-challenger/bin/op-challenger - ``` - - ### Verify installation - - Check that you have properly installed the challenger component: - - ```bash - # Make sure you're in the optimism directory - ./op-challenger/bin/op-challenger --help - - # You should see the challenger help output with available commands and flags - ``` - - ## Configuration setup - - - The following steps require a Cannon binary and the op-program server. - Ensure these binaries are available at the paths you configure (`CANNON_BIN` and `CANNON_SERVER`). - - - - ### Organize your workspace - - After building the binaries, create your challenger working directory: - - ```bash - # Create challenger directory inside rollup - cd ../ # Go back to rollup directory - mkdir challenger - cd challenger - - # Create necessary subdirectories - mkdir scripts - mkdir challenger-data - - # Verify the optimism directory is accessible - # Directory structure should look like: - # rollup/ - # ├── deployer/ (from previous step) - # ├── optimism/ (contains the built binaries) - # ├── sequencer/ (from previous step) - # ├── batcher/ (from previous step) - # ├── proposer/ (from previous step) - # └── challenger/ (you are here) - ``` - - ### Copy configuration files - - ```bash - # Copy configuration files to your challenger directory - # Adjust paths based on your deployment setup - cp /path/to/your/rollup.json . - cp /path/to/your/genesis-l2.json . - ``` - - ### Set up environment variables - - You'll need to gather several pieces of information before creating your configuration. Here's where to get each value: - - **L1 network access:** - - * L1 RPC URL: Your L1 node endpoint (Infura, Alchemy, or self-hosted) - * L1 Beacon URL: Beacon chain API endpoint for blob access - - **L2 network access:** - - * L2 RPC URL: Your op-geth archive node endpoint - * Rollup RPC URL: Your op-node endpoint with historical data - - **Challenger wallet:** - - * Private key for challenger operations (must be funded) - - **Network configuration:** - - * Game factory address from your contract deployment - * Network identifier (e.g., op-sepolia, op-mainnet, or custom) - - Copy and paste in your terminal, to create your env file. - - ```bash - # Create .env file with your actual values - cat > .env << 'EOF' - # L1 Configuration - Replace with your actual RPC URLs - L1_RPC_URL=https://sepolia.infura.io/v3/YOUR_ACTUAL_INFURA_KEY - - # L2 Configuration - Replace with your actual node endpoints - L2_RPC_URL=http://localhost:8545 - ROLLUP_RPC_URL=http://localhost:8547 - L1_BEACON=http://sepolia-cl-1:5051 - - # Private key - Replace with your actual private key - PRIVATE_KEY=YOUR_ACTUAL_PRIVATE_KEY - - # Network configuration - NETWORK=op-sepolia - GAME_FACTORY_ADDRESS=YOUR_GAME_FACTORY_ADDRESS - - # Trace configuration - TRACE_TYPE=permissioned,cannon - - # Data directory - DATADIR=./challenger-data - - # Configuration files from your deployment - CANNON_ROLLUP_CONFIG=./rollup.json - CANNON_L2_GENESIS=./genesis-l2.json - - # Cannon configuration - # Prestate file - Generate this using the absolute prestate guide - # Run 'make reproducible-prestate' in the optimism repo to generate it - # The Cannon binary is a specific hash file that matches your deployment - CANNON_BIN=./0x.bin.gz - # The op-program server binary is built when you run 'just op-challenger' - CANNON_SERVER=../../optimism/op-program/bin/op-program - CANNON_PRESTATE=../../optimism/op-program/bin/prestate.json - - EOF - ``` - - **Important:** Replace ALL placeholder values (`YOUR_ACTUAL_*`) with your real configuration values. - - ### Understanding key configuration flags - -
- --l1-eth-rpc - - * This is the HTTP provider URL for a standard L1 node, can be a full node. `op-challenger` will be sending many requests, so chain operators need a node that is trusted and can easily handle many transactions. - * Note: Challenger has a lot of money, and it will spend it if it needs to interact with games. That might risk not defending games or challenging games correctly, so chain operators should really trust the nodes being pointed at Challenger. -
- -
- --l1-beacon - - * This is needed just to get blobs from. - * In some instances, chain operators might need a blob archiver or L1 consensus node configured not to prune blobs: - * If the chain is proposing regularly, a blob archiver isn't needed. There's only a small window in the blob retention period that games can be played. - * If the chain doesn't post a valid output root in 18 days, then a blob archiver running a challenge game is needed. If the actor gets pushed to the bottom of the game, it could lose if it's the only one protecting the chain. -
- -
- --l2-eth-rpc - - * This needs to be `op-geth` archive node, with `debug` enabled. - * Technically doesn't need to go to bedrock, but needs to have access to the start of any game that is still in progress. -
- -
- --rollup-rpc - - * This needs to be an `op-node` archive node because challenger needs access to output roots from back when the games start. See below for important configuration details: - - 1. Safe Head Database (SafeDB) Configuration for op-node: - - * The `op-node` behind the `op-conductor` must have the SafeDB enabled to ensure it is not stateless. - * To enable SafeDB, set the `--safedb.path` value in your configuration. This specifies the file path used to persist safe head update data. - * Example Configuration: - - ``` - --safedb.path # Replace with your actual path - ``` - - - If this path is not set, the SafeDB feature will be disabled. - - - 2. Ensuring Historical Data Availability: - - * Both `op-node` and `op-geth` must have data from the start of the games to maintain network consistency and allow nodes to reference historical state and transactions. - * For `op-node`: Configure it to maintain a sufficient history of blockchain data locally or use an archive node. - * For `op-geth`: Similarly, configure to store or access historical data. - * Example Configuration: - - ``` - op-node \ - --rollup-rpc \ - --safedb.path - ``` - - - Replace `` with the URL of your archive node and `` with the desired path for storing SafeDB data. - -
- -
- --private-key - - * Chain operators must specify a private key or use something else (like `op-signer`). - * This uses the same transaction manager arguments as `op-node` , batcher, and proposer, so chain operators can choose one of the following options: - * a mnemonic - * a private key - * `op-signer` endpoints -
- -
- --network - - * This identifies the L2 network `op-challenger` is running for, e.g., `op-sepolia` or `op-mainnet`. - * When using the `--network` flag, the `--game-factory-address` will be automatically pulled from the [`superchain-registry`](https://github.com/ethereum-optimism/superchain-registry/blob/main/chainList.json). - * When cannon is executed, challenger needs the roll-up config and the L2 Genesis, which is op-geth's Genesis file. Both files are automatically loaded when Cannon Network is used, but custom networks will need to specify both Cannon L2 Genesis and Cannon rollup config. - * For custom networks not in the [`superchain-registry`](https://github.com/ethereum-optimism/superchain-registry/blob/main/chainList.json), the `--game-factory-address` and rollup must be specified, as follows: - - ``` - --cannon-rollup-config rollup.json \ - --cannon-l2-genesis genesis-l2.json \ - # use this if running challenger outside of the docker image - --cannon-server ./op-program/bin/op-program \ - # json or url, version of op-program deployed on chain - # if you use the wrong one, you will lose the game - # if you deploy your own contracts, you specify the hash, the root of the json file - # op mainnet are tagged versions of op-program - # make reproducible prestate - # challenger verifies that onchain - --cannon-prestate ./op-program/bin/prestate.json \ - # load the game factory address from system config or superchain registry - # point the game factory address at the dispute game factory proxy - --game-factory-address - ``` - - - These options vary based on which `--network` is specified. Chain operators always need to specify a way to load prestates and must also specify the cannon-server whenever the docker image isn't being used. - -
- -
- --datadir - - * This is a directory that `op-challenger` can write to and store whatever data it needs. It will manage this directory to add or remove data as needed under that directory. - * If running in docker, it should point to a docker volume or mount point, so the data isn't lost on every restart. The data can be recreated if needed but particularly if challenger has executed cannon as part of responding to a game it may mean a lot of extra processing. -
- -
- --cannon-prestates-url - - The pre-state is effectively the version of `op-program` that is deployed on chain. And chain operators must use the right version. `op-challenger` will refuse to interact with games that have a different absolute prestate hash to avoid making invalid claims. If deploying your own contracts, chain operators must specify an absolute prestate hash taken from the `make reproducible-prestate` command during contract deployment, which will also build the required prestate json file. - - All governance approved releases use a tagged version of `op-program`. These can be rebuilt by checking out the version tag and running `make reproducible-prestate`. - - * There are two ways to specify the prestate to use: - * `--cannon-prestate`: specifies a path to a single Cannon pre-state Json file - * `--cannon-prestates-url`: specifies a URL to load pre-states from. This enables participating in games that use different prestates, for example due to a network upgrade. The prestates are stored in this directory named by their hash. - * Example final URL for a prestate: - * [https://example.com/prestates/0x031e3b504740d0b1264e8cf72b6dde0d497184cfb3f98e451c6be8b33bd3f808.json](https://example.com/prestates/0x031e3b504740d0b1264e8cf72b6dde0d497184cfb3f98e451c6be8b33bd3f808.json) - * This file contains the cannon memory state. - - - Challenger will refuse to interact with any games if it doesn't have the matching prestate. - Check this [guide](/operators/chain-operators/tutorials/absolute-prestate#generating-the-absolute-prestate) on how to generate an absolute prestate. - -
- - - ### Create challenger startup script - - Create `scripts/start-challenger.sh`: - - ```bash - #!/bin/bash - source .env - - # Path to the challenger binary - ../../optimism/op-challenger/bin/op-challenger \ - --trace-type permissioned,cannon \ - --l1-eth-rpc=$L1_RPC_URL \ - --l2-eth-rpc=$L2_RPC_URL \ - --l1-beacon=$L1_BEACON \ - --rollup-rpc=$ROLLUP_RPC_URL \ - --game-factory-address $GAME_FACTORY_ADDRESS \ - --datadir=$DATADIR \ - --cannon-bin=$CANNON_BIN \ - --cannon-rollup-config=$CANNON_ROLLUP_CONFIG \ - --cannon-l2-genesis=$CANNON_L2_GENESIS \ - --cannon-server=$CANNON_SERVER \ - --cannon-prestate=$CANNON_PRESTATE \ - --private-key="$PRIVATE_KEY" - ``` - ### Start the challenger - - ```bash - # Make sure you're in the rollup/challenger directory - cd rollup/challenger - - # Make script executable - chmod +x scripts/start-challenger.sh - - # Start challenger - ./scripts/start-challenger.sh - ``` - - ### Verify challenger is running - - Monitor challenger logs to ensure it's operating correctly: - - ```bash - # Check challenger logs - tail -f challenger-data/challenger.log - - # Or if running in foreground, monitor the output - ``` - - The challenger should show logs indicating: - - * Successful connection to L1 and L2 nodes - * Loading of prestates and configuration - * Monitoring of dispute games - - - - -### Monitoring with op-dispute-mon - -Consider running [`op-dispute-mon`](/operators/chain-operators/tools/chain-monitoring#dispute-mon) for enhanced security monitoring: - -* Provides visibility into all game statuses for the last 28 days -* Essential for production challenger deployments -* Create Grafana dashboards using: [Download the Dispute Monitor JSON](/resources/grafana/dispute-monitor-1718214549035.json) - -## Congratulations - -You've successfully completed the entire L2 rollup testnet tutorial! Your rollup is now fully operational with all components running: - -* **op-deployer** - L1 contracts deployed -* **Sequencer** - Processing transactions -* **Batcher** - Publishing data to L1 -* **Proposer** - Submitting state roots -* **Challenger** - Monitoring disputes - -## Connect your wallet to your chain - -You now have a fully functioning OP Stack Rollup with a Sequencer node running on `http://localhost:8545`. You can connect your wallet to this chain the same way you'd connect your wallet to any other EVM chain. - -## Get ETH on your chain - -Once you've connected your wallet, you'll probably notice that you don't have any ETH to pay for gas on your chain. - -The easiest way to deposit Sepolia ETH into your chain is to send ETH directly to the `L1StandardBridge` contract. - -### Get the L1StandardBridge address - -The `L1StandardBridge` proxy address can be found in your deployment state file. To get it, run: - -```bash -# From your project root -jq -r .l1StandardBridgeProxyAddress /.deployer/state.json -``` - -This will output the `L1StandardBridge` proxy address that you should use for deposits. Make sure to use the proxy address, not the implementation address. - -### Deposit ETH to your L2 - -Once you have the `L1StandardBridge` address, send a small amount of Sepolia ETH (0.1 or less) to that address from the wallet you want to use on L2. -This will trigger a deposit that will mint ETH into your wallet on L2. - - - It may take up to 5 minutes for the ETH to appear in your wallet on L2. - This delay is due to the time needed for the deposit transaction to be processed and finalized. - - -## See your rollup in action - -You can interact with your Rollup the same way you'd interact with any other EVM chain. -Send some transactions, deploy some contracts, and see what happens! - -## Need Help? - -* **Community Support**: Join the [Optimism Discord](https://discord.optimism.io) -* **OP Challenger Explainer**: [Fault Proofs Overview](/stack/fault-proofs/challenger) -* **Technical Specs**: [Honest Challenger Specification](https://specs.optimism.io/fault-proof/stage-one/honest-challenger-fdg.html) -* **Developer Support**: [GitHub Discussions](https://github.com/ethereum-optimism/developers/discussions) diff --git a/pages/operators/chain-operators/tutorials/create-l2-rollup/op-deployer-setup.mdx b/pages/operators/chain-operators/tutorials/create-l2-rollup/op-deployer-setup.mdx deleted file mode 100644 index 24798f405..000000000 --- a/pages/operators/chain-operators/tutorials/create-l2-rollup/op-deployer-setup.mdx +++ /dev/null @@ -1,400 +0,0 @@ ---- -title: Deploy L1 contracts with op-deployer -description: Install op-deployer, prepare your environment, and deploy the L1 smart contracts for your rollup. -lang: en-US -content_type: tutorial -topic: create-l2-rollup-setup -personas: - - chain-operator -categories: - - testnet - - chain-deployment - - op-deployer -is_imported_content: 'false' ---- - -import {Callout, Steps, Card, Tabs} from 'nextra/components' - -# Deploy L1 contracts with op-deployer - -Welcome to the first step of creating your own L2 rollup testnet! In this section, you'll install the op-deployer tool and deploy the necessary L1 smart contracts for your rollup. - - - **Step 1 of 5**: This tutorial is designed to be followed step-by-step. Each step builds on the previous one. - - -## About op-deployer - -`op-deployer` simplifies the process of deploying the OP Stack. You define a declarative config file called an "**intent**," then run a command to apply it. `op-deployer` compares your chain's current state against the intent and makes the necessary changes to match. - -## Installation - -There are a couple of ways to install `op-deployer`: - - - - The recommended way to install `op-deployer` is to download the latest release from the monorepo's [release page](https://github.com/ethereum-optimism/optimism/releases). - - - ### Download the correct binary - - 1. Go to the [release page](https://github.com/ethereum-optimism/optimism/releases) - 2. Use the search bar to find the latest release that includes `op-deployer`. - 3. Under **assets**, download the binary that matches your system: - - * For Linux: `op-deployer-linux-amd64` - * For macOS: - * Apple Silicon (M1/M2): `op-deployer-darwin-arm64` - * Intel processors: `op-deployer-darwin-amd64` - * For Windows: `op-deployer-windows-amd64.exe` - - - Not sure which macOS version to use? - - * Open Terminal and run `uname -m` - * If it shows `arm64`, use the arm64 version - * If it shows `x86_64`, use the amd64 version - - - ### Create deployer directory and install binary - - 1. Create the rollup directory structure and enter the deployer directory: - - ```bash - # Create main rollup directory - mkdir rollup && cd rollup - - # Create and enter the deployer directory - mkdir deployer && cd deployer - ``` - - Your directory structure will now look like this: - ```bash - rollup/ - └── deployer/ # You are here - ``` - - 2. Move and rename the downloaded binary: - - - The downloaded file is likely in your Downloads folder: - - * macOS/Linux: `/Users/YOUR_USERNAME/Downloads` - * Windows WSL: `/mnt/c/Users/YOUR_USERNAME/Downloads` - - - ```bash - # Step 1: Extract the tar.gz archive in the deployer directory - # Replace USERNAME with your username and adjust the version/arch if needed - tar -xvzf /Users/USERNAME/Downloads/op-deployer-0.2.6-darwin-arm64.tar.gz - - # Step 2: Make the binary executable - chmod +x op-deployer-0.2.6-darwin-arm64 - - # Step 3: Remove macOS quarantine attribute (fixes "can't be opened" warning) - sudo xattr -dr com.apple.quarantine op-deployer-0.2.6-darwin-arm64 - - # Step 4: Move the binary to your PATH - # For Intel Macs: - sudo mv op-deployer-0.2.6-darwin-arm64 /usr/local/bin/ - # For Apple Silicon Macs: - sudo mv op-deployer-0.2.6-darwin-arm64 /opt/homebrew/bin/ - - # Step 7: Verify installation (should print version info) - op-deployer --version - ``` - - - - - To install from source, you will need [Go](https://go.dev/doc/install), `just`, and `git`. - After installing all of that, run following: - - ```bash - git clone https://github.com/ethereum-optimism/optimism.git # you can skip this if you already have the repo - cd optimism/op-deployer - just build - cp ./bin/op-deployer /usr/local/bin/op-deployer # or any other directory in your $PATH - - # Verify installation - op-deployer --version - ``` - - - -## L1 network requirements - -Before deploying your L1 contracts, you'll need: - -**L1 RPC URL**: An Ethereum RPC endpoint for your chosen L1 network - - ```bash - # Examples: - # Sepolia (recommended for testing) - L1_RPC_URL=https://sepolia.infura.io/v3/YOUR-PROJECT-ID - # or https://eth-sepolia.g.alchemy.com/v2/YOUR-API-KEY - - # Local network - L1_RPC_URL=http://localhost:8545 - ``` - - - For testing, we recommend using Sepolia testnet. You can get free RPC access from: - - * [Infura](https://infura.io) (create account, get API key) - * [Alchemy](https://alchemy.com) (create account, get API key) - * [Ankr](https://ankr.com) (create account, get API key) - - -## Generate deployment addresses - -Your rollup needs several addresses for different roles. Let's generate them first: - - - ### Create address directory - - ```bash - # Create a address directory inside the deployer directory - mkdir -p address - cd address - ``` - - Your directory structure will now look like this: - ```bash - rollup/ - └── deployer/ - └── address/ # You are here - ``` - - ### Generate address for each role - - ```bash - # Generate 8 new wallet addresses - for role in admin base_Fee_Vault_Recipient l1_Fee_Vault_Recipient sequencer_Fee_Vault_Recipient system_config unsafe_block_signer batcher proposer ; do - wallet_output=$(cast wallet new) - echo "$wallet_output" | grep "Address:" | awk '{print $2}' > ${role}_address.txt - echo "Created wallet for $role" - done - ``` - - This will save the various addresses for your intent file into files in your current directory. To view them later you can use `cat *_address.txt`. - - - - **Important**: - - * Save these address - you'll need them to operate your chain - * You can use any address for the purpose of testing, for production, use proper key management solutions (HSMs, multisigs addresses) - - - -## Create and configure intent file - -The intent file defines your chain's configuration. - - - ### Initialize intent file - - Inside the `deployer` folder, run this command: - - ```bash - #You can use a 2-7 digit random number for your `` - op-deployer init \ - --l1-chain-id 11155111 \ - --l2-chain-ids \ - --workdir .deployer \ - --intent-type standard-overrides - ``` - -
- Understanding intent types - - `op-deployer` supports three intent types: - - * `standard`: Uses default OP Stack configuration, minimal customization - * `standard-overrides`: Recommended. Uses defaults but allows overriding specific values - * `custom`: Full customization, requires manual configuration of all values - - For most users, `standard-overrides` provides the best balance of simplicity and flexibility. -
- - ### Update the intent file - - Edit `.deployer/intent.toml` with your generated addresses: - - ```toml - configType = "standard-overrides" - l1ChainID = 11155111 # Sepolia - fundDevAccounts = false # Set to false for production/testnet - useInterop = false - l1ContractsLocator = "tag://op-contracts/v2.0.0" - l2ContractsLocator = "tag://op-contracts/v1.7.0-beta.1+l2-contracts" - - [superchainRoles] - proxyAdminOwner = "0x..." # admin address - protocolVersionsOwner = "0x..." # admin address - guardian = "0x..." # admin address - - [[chains]] - id = "0x000000000000000000000000000000000000000000000000000000000016de8d" - baseFeeVaultRecipient = "0x..." # base_Fee_Vault_Recipient address - l1FeeVaultRecipient = "0x..." # l1_Fee_Vault_Recipient address - sequencerFeeVaultRecipient = "0x..." # sequencer_Fee_Vault_Recipient address - eip1559DenominatorCanyon = 250 - eip1559Denominator = 50 - eip1559Elasticity = 6 - [chains.roles] - l1ProxyAdminOwner = "0x1eb2ffc903729a0f03966b917003800b145f56e2" - l2ProxyAdminOwner = "0x2fc3ffc903729a0f03966b917003800b145f67f3" - systemConfigOwner = "0x..." # system_config address - unsafeBlockSigner = "0x..." # unsafe_block_signer address - batcher = "0x..." # batcher address - proposer = "0x..." # proposer address - challenger = "0xfd1d2e729ae8eee2e146c033bf4400fe75284301" - ``` - -
- Understanding the configuration values - - **Global Settings:** - - * `l1ChainID`: The L1 network ID (11155111 for Sepolia) - * `fundDevAccounts`: Creates test accounts with ETH if true - * `useInterop`: Enable interoperability features - * `l1ContractsLocator`: Version of L1 contracts to deploy - * `l2ContractsLocator`: Version of L2 contracts to deploy - - **Superchain Roles:** - - * `proxyAdminOwner`: Can upgrade Superchain-wide contracts - * `protocolVersionsOwner`: Can update protocol versions - * `guardian`: Can pause withdrawals and manage disputes - - **Chain Configuration:** - - * `id`: Unique identifier for your chain - * `*FeeVaultRecipient`: Addresses receiving various fees - * `eip1559*`: Parameters for gas price calculation - - **Chain Roles:** - - * `l1ProxyAdminOwner`: Updates L1 contract implementations - * `l2ProxyAdminOwner`: Updates L2 contract implementations - * `systemConfigOwner`: Manages system configuration - * `unsafeBlockSigner`: Signs pre-confirmation blocks - * `batcher`: Submits L2 transactions to L1 - * `proposer`: Submits L2 state roots to L1 - * `challenger`: Monitors and challenges invalid states -
- - - - Replace all `0x...` with actual addresses from your `addresses.txt` file. - Never use the default test mnemonic addresses in production or public testnets! - - -## Create environment file - -Before deploying, create a `.env` file in your `deployer` directory to store your environment variables: - -```bash -# Create .env file -cat << 'EOF' > .env -# Your L1 RPC URL (e.g., from Alchemy, Infura) -L1_RPC_URL=https://eth-sepolia.g.alchemy.com/v2/YOUR_API_KEY - -# Private key for deployment. -# Get this from your self-custody wallet, like Metamask. -PRIVATE_KEY=WALLET_PRIVATE_KEY -EOF -``` - - - Never commit your `.env` file to version control. Add it to your `.gitignore`: - - ```bash - echo ".env" >> .gitignore - ``` - - -Load the environment variables: - -```bash -source .env -``` - -## Deploy L1 Contracts - -Now that your intent file and environment variables are configured, let's deploy the L1 contracts: - -```bash -op-deployer apply \ - --workdir .deployer \ - --l1-rpc-url $L1_RPC_URL \ - --private-key $PRIVATE_KEY -``` - -This will: - -1. Deploy all required L1 contracts -2. Configure them according to your intent file -3. Save deployment information to `.deployer/state.json` - - - The deployment can take 10-15 seconds and requires multiple transactions. - - -## Generate chain configuration - -After successful deployment, generate your chain configuration files: - -```bash -# Generate genesis and rollup configs -op-deployer inspect genesis --workdir .deployer > .deployer/genesis.json -op-deployer inspect rollup --workdir .deployer > .deployer/rollup.json -``` - -## What's Next? - -Great! You've successfully: - -1. Installed `op-deployer` using the `init` and `apply` command. -2. Created and configured your intent file -3. Deployed L1 smart contracts -4. Generated chain artifacts - -Your final directory structure should look like this: -```bash -rollup/ -└── deployer/ - ├── .deployer/ # Contains deployment state and configs - │ ├── genesis.json # L2 genesis configuration - │ ├── intent.toml # Your chain configuration - │ ├── rollup.json # Rollup configuration - │ └── state.json # Deployment state - ├── .env # Environment variables - └── address/ # Generated address pairs - ├── base_Fee_Vault_Recipient_address.txt - ├── batcher_address.txt - ├── l1_Fee_Vault_Recipient_address.txt - ├── proposer_address.txt - ├── sequencer_Fee_Vault_Recipient_address.txt - ├── system_config_address.txt - └── unsafe_block_signer_address.txt - └── admin.txt - -``` - -Now you can move on to setting up your sequencer node. - - - **Next**: Set up op-geth and op-node, essential building blocks of the execution and consensus layers in your rollup. - - -*** - -## Need Help? - -* **Community Support**: Join the [Optimism Discord](https://discord.gg/optimism) -* **op-deployer Repository**: [GitHub](https://github.com/ethereum-optimism/optimism/tree/develop/op-deployer/cmd/op-deployer) -* **OPCM Documentation**: [OP Contracts Manager](/stack/opcm) diff --git a/pages/operators/chain-operators/tutorials/create-l2-rollup/op-geth-setup.mdx b/pages/operators/chain-operators/tutorials/create-l2-rollup/op-geth-setup.mdx deleted file mode 100644 index 9b91c4441..000000000 --- a/pages/operators/chain-operators/tutorials/create-l2-rollup/op-geth-setup.mdx +++ /dev/null @@ -1,580 +0,0 @@ ---- -title: Spin up sequencer -lang: en-US -description: Set up and run op-geth and op-node, the execution and consensus layers for your rollup. -content_type: tutorial -topic: create-l2-rollup-geth -personas: - - chain-operator -categories: - - chain-deployment - - op-geth - - op-node - - sequencer-configuration -is_imported_content: 'false' ---- - -import { Callout, Steps, Card, Tabs } from 'nextra/components' - -# Spin up sequencer - -Now that you have op-deployer configured, it's time to spin up the sequencer for your rollup. This involves running both `op-geth` and `op-node` to create a functioning sequencer. - - - **Step 2 of 5**: This tutorial builds on [Spin up op-deployer](./op-deployer-setup). Make sure you've completed that first. - - -## What you'll set up - -The sequencer node consists of two core components: - -* `op-geth`: Execution layer that processes transactions and maintains state -* `op-node`: Consensus layer that orders transactions and creates L2 blocks - -The sequencer is responsible for: - -* Ordering transactions from users -* Building L2 blocks -* Signing blocks on the P2P network - -## Software installation - -For spinning up a sequencer, we recommend using Docker, as it provides a simpler setup and consistent environment. In this guide, building from source is also provided as an alternative for those who need more control and easier debugging. - - - - - - - If you prefer containerized deployment, you can use the official Docker images, and do the following: - - ### Set up directory structure and copy configuration files - - ```bash - # Create your sequencer directory inside rollup - cd ../ # Go back to rollup directory if you're in deployer - mkdir sequencer - cd sequencer - - # Copy configuration files from deployer - cp ../deployer/.deployer/genesis.json . - cp ../deployer/.deployer/rollup.json . - - # Generate JWT secret - openssl rand -hex 32 > jwt.txt - chmod 600 jwt.txt - ``` - - ### Create environment variables file - - ```bash - # Create .env file with your actual values - cat > .env << 'EOF' - # L1 Configuration - Replace with your actual RPC URLs - L1_RPC_URL=https://sepolia.infura.io/v3/YOUR_ACTUAL_INFURA_KEY - L1_BEACON_URL=https://ethereum-sepolia-beacon-api.publicnode.com - - # Private keys - Replace with your actual private key - PRIVATE_KEY=YOUR_ACTUAL_PRIVATE_KEY - - # P2P configuration - Replace with your actual public IP - # Run `curl ifconfig.me` in a separate shell to obtain the value, then paste it below - P2P_ADVERTISE_IP=YOUR_ACTUAL_PUBLIC_IP - - EOF - ``` - - **Important**: Replace ALL placeholder values (`YOUR_ACTUAL_*`) with your real configuration values. - - ### Make sure your docker application is running - Create a `docker-compose.yml` file in the same directory - - ```yaml - - services: - op-geth: - image: us-docker.pkg.dev/oplabs-tools-artifacts/images/op-geth:v1.101511.1 - volumes: - # Mount entire directory to avoid file mounting issues - - .:/workspace - working_dir: /workspace - ports: - - "8545:8545" - - "8546:8546" - - "8551:8551" - command: - - "--datadir=/workspace/op-geth-data" - - "--http" - - "--http.addr=0.0.0.0" - - "--http.port=8545" - - "--ws" - - "--ws.addr=0.0.0.0" - - "--ws.port=8546" - - "--authrpc.addr=0.0.0.0" - - "--authrpc.port=8551" - - "--authrpc.jwtsecret=/workspace/jwt.txt" - - "--syncmode=full" - - "--gcmode=archive" - - "--rollup.disabletxpoolgossip=true" - - "--rollup.sequencerhttp=http://op-node:8547" - - "--http.vhosts=*" - - "--http.corsdomain=*" - - "--http.api=eth,net,web3,debug,txpool,admin" - - "--ws.origins=*" - - "--ws.api=eth,net,web3,debug,txpool,admin" - - "--authrpc.vhosts=*" - - op-node: - image: us-docker.pkg.dev/oplabs-tools-artifacts/images/op-node:v1.13.5 - depends_on: - - op-geth - volumes: - - .:/workspace - working_dir: /workspace - ports: - - "8547:8547" - - "9222:9222" - environment: - - L1_RPC_URL=${L1_RPC_URL} - - L1_BEACON_URL=${L1_BEACON_URL} - - PRIVATE_KEY=${PRIVATE_KEY} - - P2P_ADVERTISE_IP=${P2P_ADVERTISE_IP} - command: - - "op-node" - - "--l1=${L1_RPC_URL}" - - "--l1.beacon=${L1_BEACON_URL}" - - "--l2=http://op-geth:8551" - - "--l2.jwt-secret=/workspace/jwt.txt" - - "--rollup.config=/workspace/rollup.json" - - "--sequencer.enabled=true" - - "--sequencer.stopped=false" - - "--sequencer.max-safe-lag=3600" - - "--verifier.l1-confs=4" - - "--p2p.listen.ip=0.0.0.0" - - "--p2p.listen.tcp=9222" - - "--p2p.listen.udp=9222" - - "--p2p.advertise.ip=${P2P_ADVERTISE_IP}" - - "--p2p.advertise.tcp=9222" - - "--p2p.advertise.udp=9222" - - "--p2p.sequencer.key=${PRIVATE_KEY}" - - "--rpc.addr=0.0.0.0" - - "--rpc.port=8547" - - "--rpc.enable-admin" - - "--log.level=info" - - "--log.format=json" - ``` - - ### Initialize op-geth with Docker - - ```bash - # Make sure you're in the rollup/sequencer directory with all files copied - cd rollup/sequencer - - # Initialize op-geth using Docker - docker run --rm \ - -v $(pwd):/workspace \ - -w /workspace \ - us-docker.pkg.dev/oplabs-tools-artifacts/images/op-geth:v1.101511.1 \ - init --datadir=./op-geth-data --state.scheme=hash ./genesis.json - ``` - - ### Start the services - - ```bash - # Start both services - docker-compose up -d - - # View logs - docker-compose logs -f - ``` - - ### Final directory structure - - ```bash - rollup/ - ├── deployer/ # From previous step - │ └── .deployer/ # Contains genesis.json and rollup.json - └── sequencer/ # You are here - ├── jwt.txt # Generated JWT secret - ├── genesis.json # Copied from deployer - ├── rollup.json # Copied from deployer - ├── .env # Environment variables - ├── docker-compose.yml # Docker configuration - └── opnode_discovery_db/ # Created by Docker during initialization - └── opnode_peerstore_db/ # Created by Docker during initialization - └── op-geth-data/ # Created by Docker during initialization - ├── geth/ # Geth data - └── keystore/ # Key files - ``` - - Your sequencer node is now operational and ready to process transactions. - - - - - - To ensure you're using the latest compatible versions of OP Stack components, always check the official [release page](https://github.com/ethereum-optimism/optimism/releases). - - The main components you'll need for sequencer deployment are: - - * `op-node`: Look for the latest `op-node/v*` [release](https://github.com/ethereum-optimism/optimism/releases) - * `op-geth`: Look for the latest `op-geth/v*` [release](https://github.com/ethereum-optimism/op-geth/releases) - - - The versions used in this guide (**op-node/v1.13.5** and **op-geth/v1.101511.1**) are verified compatible versions. - - According to the **op-node v1.13.5** [release notes](https://github.com/ethereum-optimism/optimism/releases), this op-node version specifically corresponds to **op-geth v1.101511.1**. - Always check the release notes to ensure you're using compatible versions. - - Building from source gives you full control over the binaries. - - - ### Clone and build op-node - - ```bash - # Clone the optimism monorepo - git clone https://github.com/ethereum-optimism/optimism.git - cd optimism - - # Checkout the latest release tag - git checkout op-node/v1.13.5 - - # Build op-node - cd op-node - just - - # Binary will be available at ./bin/op-node - ``` - - ### Clone and build op-geth - - ```bash - # Clone op-geth repository (in a separate directory) - git clone https://github.com/ethereum-optimism/op-geth.git - cd op-geth - - # Checkout to this release tag - git checkout v1.101511.1 - - # Build op-geth - make geth - - # Binary will be available at ./build/bin/geth - ``` - - ### Verify installation - - Check that you have properly installed the needed components. - - ```bash - # Make sure you're in the right directory - ./bin/op-node --version - ./build/bin/geth version - ``` - - - ## Configuration setup - - - ### Organize your workspace - - After building the binaries, you should have the following directory structure: - - ```bash - rollup/ - ├── deployer/ # From previous step - │ └── .deployer/ # Contains genesis.json and rollup.json - ├── optimism/ # Optimism monorepo - │ └── op-node/ - │ └── bin/ - │ └── op-node # Built binary - └── op-geth/ # OP-Geth repository - └── build/ - └── bin/ - └── geth # Built binary - ``` - - Now create your sequencer working directory. We recommend creating it at the same level for easy path references: - - ```bash - # Create sequencer directory inside rollup - cd ../ # Go back to rollup directory - mkdir sequencer - cd sequencer - ``` - -
- Alternative: Copy binaries to sequencer directory - - If you prefer to keep binaries close to your configuration, you can copy them: - - ```bash - mkdir sequencer-node/bin - cp optimism/op-node/bin/op-node sequencer-node/bin/ - cp op-geth/build/bin/geth sequencer-node/bin/ - - # Then update scripts to use: - # ./bin/geth - # ./bin/op-node - ``` -
- - ### Generate JWT secret - - ```bash - # Generate JWT secret in the sequencer directory - openssl rand -hex 32 > jwt.txt - - # Set appropriate permissions - chmod 600 jwt.txt - ``` - - ### Set up directory structure and copy files - - In this guide, we're going to be using the binaries from their original build locations, we only need to create directories for configuration files and scripts. - - ```bash - # Create scripts directory - mkdir scripts - - # Copy configuration files from deployer - cp ../deployer/.deployer/genesis.json . - cp ../deployer/.deployer/rollup.json . - ``` - - Your final directory structure should look like: - - ```bash - rollup/ - ├── deployer/ # From previous step - │ └── .deployer/ # Contains genesis.json and rollup.json - ├── optimism/ # Contains op-node binary - ├── op-geth/ # Contains op-geth binary - └── sequencer/ # You are here - ├── jwt.txt # Generated JWT secret - ├── genesis.json # Copied from deployer - ├── rollup.json # Copied from deployer - └── scripts/ # Startup scripts - ├── start-op-geth.sh - └── start-op-node.sh - ``` - - ### Environment variables - - You'll need to gather several pieces of information before creating your configuration. Here's where to get each value: - - - ### Get L1 network access - - You need access to the L1 network (Ethereum mainnet or Sepolia testnet) and its beacon node: - - **L1 RPC URL options:** - - * **Infura**: [infura.io](https://infura.io) - Requires an API key from a project - * **Alchemy**: [alchemy.com](https://alchemy.com) - Requires an API key from an app - - **L1 Beacon URL options:** - - * **Public beacon APIs**: `https://ethereum-sepolia-beacon-api.publicnode.com` (Sepolia) or `https://ethereum-beacon-api.publicnode.com` (Mainnet) - * **Infura beacon**: `https://sepolia.infura.io/v3/YOUR_KEY` (if your Infura plan includes beacon access) - - ### Get private key from your wallet - - For this basic sequencer setup, you only need a private key during op-node initialization. - - ### Get your public IP address - - ```bash - # Find your public IP address, once you get it, update the P2P_ADVERTISE_IP in your .env - curl ifconfig.me - # or - curl ipinfo.io/ip - ``` - - ### Choose your ports - - The default ports are standard but can be changed if needed: - - * `8545`: op-geth HTTP RPC (standard Ethereum RPC port) - * `8546`: op-geth WebSocket RPC - * `8551`: op-geth Auth RPC (for op-node communication) - * `8547`: op-node RPC - * `9222`: P2P networking (must be open on firewall) - - - Now create your `.env` file and copy the values below: - -
- Replace ALL placeholder values with your real configuration values. - - ```bash - # Create .env file with your actual values - # L1 Configuration - Replace with your actual RPC URLs - L1_RPC_URL=https://sepolia.infura.io/v3/YOUR_ACTUAL_INFURA_KEY - L1_BEACON_URL=https://ethereum-sepolia-beacon-api.publicnode.com - - # Sequencer configuration - SEQUENCER_ENABLED=true - SEQUENCER_STOPPED=false - - # Private keys - PRIVATE_KEY=YOUR_ACTUAL_PRIVATE_KEY - - # P2P configuration - Replace with your actual public IP - # Run `curl ifconfig.me` in a separate shell to obtain the value, then paste it below - P2P_LISTEN_PORT=9222 - P2P_ADVERTISE_IP=YOUR_ACTUAL_PUBLIC_IP - - # RPC configuration (can customize ports if needed) - OP_NODE_RPC_PORT=8547 - OP_GETH_HTTP_PORT=8545 - OP_GETH_WS_PORT=8546 - OP_GETH_AUTH_PORT=8551 - - # JWT secret location - JWT_SECRET=./jwt.txt - ``` -
- - - ## Sequencer specific configuration - - ### op-geth configuration for sequencer - - Create `scripts/start-op-geth.sh`: - - ```bash - #!/bin/bash - source .env - - # Path to the op-geth binary we built - ../../op-geth/build/bin/geth \ - --datadir=./op-geth-data \ - --http \ - --http.addr=0.0.0.0 \ - --http.port=$OP_GETH_HTTP_PORT \ - --http.vhosts="*" \ - --http.corsdomain="*" \ - --http.api=eth,net,web3,debug,txpool,admin,miner \ - --ws \ - --ws.addr=0.0.0.0 \ - --ws.port=$OP_GETH_WS_PORT \ - --ws.origins="*" \ - --ws.api=eth,net,web3,debug,txpool,admin,miner \ - --authrpc.addr=0.0.0.0 \ - --authrpc.port=$OP_GETH_AUTH_PORT \ - --authrpc.vhosts="*" \ - --authrpc.jwtsecret=$JWT_SECRET \ - --syncmode=full \ - --gcmode=archive \ - --rollup.disabletxpoolgossip=true \ - --rollup.sequencerhttp=http://localhost:$OP_NODE_RPC_PORT - ``` - - ### op-node configuration for sequencer - - Create `scripts/start-op-node.sh`: - - ```bash - #!/bin/bash - - source .env - - # Path to the op-node binary we built - ../../optimism/op-node/bin/op-node \ - --l1=$L1_RPC_URL \ - --l1.beacon=$L1_BEACON_URL \ - --l2=http://localhost:$OP_GETH_AUTH_PORT \ - --l2.jwt-secret=$JWT_SECRET \ - --rollup.config=./rollup.json \ - --sequencer.enabled=$SEQUENCER_ENABLED \ - --sequencer.stopped=$SEQUENCER_STOPPED \ - --sequencer.max-safe-lag=3600 \ - --verifier.l1-confs=4 \ - --p2p.listen.ip=0.0.0.0 \ - --p2p.listen.tcp=$P2P_LISTEN_PORT \ - --p2p.listen.udp=$P2P_LISTEN_PORT \ - --p2p.advertise.ip=$P2P_ADVERTISE_IP \ - --p2p.advertise.tcp=$P2P_LISTEN_PORT \ - --p2p.advertise.udp=$P2P_LISTEN_PORT \ - --p2p.sequencer.key=$PRIVATE_KEY \ - --rpc.addr=0.0.0.0 \ - --rpc.port=$OP_NODE_RPC_PORT \ - --rpc.enable-admin \ - --log.level=info \ - --log.format=json - ``` - - ## Initializing and starting the sequencer - - - ### Initialize op-geth with your genesis file - - ```bash - # Make sure you're in the rollup/sequencer directory - cd rollup/sequencer - - # Initialize op-geth with your genesis file - ../../op-geth/build/bin/geth init --datadir=./op-geth-data --state.scheme=hash ./genesis.json - ``` - - ### Start op-geth - - ```bash - # Make scripts executable - chmod +x scripts/start-op-geth.sh - chmod +x scripts/start-op-node.sh - - # Start op-geth in the background or in a separate terminal - ./scripts/start-op-geth.sh - ``` - - **Note**: You should see output indicating that op-geth is starting and listening on the configured ports. - - ### Start op-node - - ```bash - # In a separate terminal, navigate to the sequencer directory - cd rollup/sequencer - - # Start op-node - ./scripts/start-op-node.sh - ``` - - ### Verify sequencer is running - - Once both services are running, verify they're working correctly: - - ```bash - # Check op-geth is responding, do this in another terminal - curl -X POST -H "Content-Type: application/json" \ - --data '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}' \ - http://localhost:8545 - - # Check sequencer status - curl -X POST -H "Content-Type: application/json" \ - --data '{"jsonrpc":"2.0","method":"admin_sequencerActive","params":[],"id":1}' \ - http://localhost:8547 - ``` - - - Your sequencer node is now operational and ready to process transactions. - - - - -## What's Next? - -Great! Your sequencer is running and processing transactions. The next step is to set up the batcher to publish transaction data to L1. - - - **Next**: Configure and start op-batcher to publish L2 transaction data to L1 for data availability. - - -*** - -## Need Help? - -* **Community Support**: Join the [Optimism Discord](https://discord.optimism.io) -* **Batcher Configuration**: [op-batcher Configuration Guide](/operators/chain-operators/configuration/batcher) -* **Best Practices**: [Chain Operator Best Practices](/operators/chain-operators/management/best-practices) diff --git a/pages/operators/chain-operators/tutorials/create-l2-rollup/op-proposer-setup.mdx b/pages/operators/chain-operators/tutorials/create-l2-rollup/op-proposer-setup.mdx deleted file mode 100644 index 23b0bdd08..000000000 --- a/pages/operators/chain-operators/tutorials/create-l2-rollup/op-proposer-setup.mdx +++ /dev/null @@ -1,467 +0,0 @@ ---- -title: Spin up proposer -lang: en-US -description: Learn how to set up and configure an OP Stack proposer to post L2 state roots. -content_type: tutorial -topic: proposer-setup -personas: - - chain-operator -categories: - - testnet - - mainnet - - op-proposer - - state-commitment - - l2-output-submission - - withdrawal-verification -is_imported_content: 'false' ---- - -import { Callout, Steps, Card, Tabs } from 'nextra/components' - -# Spin up proposer - -After you have spun up your sequencer and batcher, you need to attach a proposer to post your L2 state roots data back onto L1 so we can prove withdrawal validity. The proposer is a critical component that enables trustless L2-to-L1 messaging and creates the authoritative view of L2 state from L1's perspective. - - - **Step 4 of 5**: This tutorial is designed to be followed step-by-step. Each step builds on the previous one. - - -This guide assumes you already have a functioning sequencer, batcher, and the necessary L1 contracts deployed using [`op-deployer`](./op-deployer-setup). If you haven't set up your sequencer and batcher yet, please refer to the [sequencer guide](./op-geth-setup) and [batcher guide](./op-batcher-setup) first. - -To see configuration info for the proposer, check out the [configuration page](/operators/chain-operators/configuration/proposer). - -## Understanding the proposer's role - -The proposer (`op-proposer`) serves as a crucial bridge between your L2 chain and L1. Its primary responsibilities include: - -* **State commitment**: Proposing L2 state roots to L1 at regular intervals -* **Withdrawal enablement**: Providing the necessary commitments for users to prove and finalize withdrawals - -The proposer creates dispute games via the `DisputeGameFactory` contract. - -## Prerequisites - -Before setting up your proposer, ensure you have: - -**Running infrastructure:** - -* An operational sequencer node -* Access to a L1 RPC endpoint - -**Network information:** - -* Your L2 chain ID and network configuration -* L1 network details (chain ID, RPC endpoints) - -For setting up the proposer, we recommend using Docker as it provides a consistent and isolated environment. Building from source is also available as an option. - - - - If you prefer containerized deployment, you can use the official Docker images and do the following: - - - ### Set up directory structure and copy configuration files - - ```bash - # Create a proposer directory inside rollup - cd ../ # Go back to rollup directory if you're in batcher - mkdir proposer - cd proposer - # inside the proposer directory, copy the state.json file from the op-deployer setup - # Copy configuration files from deployer - cp ../deployer/.deployer/state.json . - - # Extract the DisputeGameFactory address - GAME_FACTORY_ADDRESS=$(cat state.json | jq -r '.opChainDeployments[0].disputeGameFactoryProxyAddress') - echo "DisputeGameFactory Address: $GAME_FACTORY_ADDRESS" - ``` - - ### Create environment variables file - - ```bash - # Create .env file with your actual values - cat > .env << 'EOF' - # L1 Configuration - Replace with your actual RPC URLs - L1_RPC_URL=https://sepolia.infura.io/v3/YOUR_ACTUAL_INFURA_KEY - - # L2 Configuration - Should match your sequencer setup - L2_RPC_URL=http://op-geth:8545 - ROLLUP_RPC_URL=http://op-node:8547 - - # Contract addresses - Extract from your op-deployer output - GAME_FACTORY_ADDRESS=YOUR_ACTUAL_GAME_FACTORY_ADDRESS - - # Private key - Replace with your actual private key - PRIVATE_KEY=YOUR_ACTUAL_PRIVATE_KEY - - # Proposer configuration - PROPOSAL_INTERVAL=3600s - GAME_TYPE=0 - POLL_INTERVAL=20s - - # RPC configuration - PROPOSER_RPC_PORT=8560 - EOF - ``` - - **Important**: Replace ALL placeholder values (`YOUR_ACTUAL_*`) with your real configuration values. - - ### Create docker-compose.yml - - - If you get "failed to dial address" errors, ensure your proposer is in the same Docker network as your sequencer. - - Common fixes: - - * Add `networks: - sequencer-node_default` to your proposer's docker-compose.yml - * Use service names like `op-geth:8545` and `op-node:8547` in your `.env` file - * Verify your sequencer network name with `docker network ls` - - - ```yaml - - services: - op-proposer: - image: us-docker.pkg.dev/oplabs-tools-artifacts/images/op-proposer:v1.10.0 - volumes: - - .:/workspace - working_dir: /workspace - ports: - - "8560:8560" - env_file: - - .env - command: - - "op-proposer" - - "--poll-interval=${POLL_INTERVAL}" - - "--rpc.port=${PROPOSER_RPC_PORT}" - - "--rpc.enable-admin" - - "--rollup-rpc=${ROLLUP_RPC_URL}" - - "--l1-eth-rpc=${L1_RPC_URL}" - - "--private-key=${PRIVATE_KEY}" - - "--game-factory-address=${GAME_FACTORY_ADDRESS}" - - "--game-type=${GAME_TYPE}" - - "--proposal-interval=${PROPOSAL_INTERVAL}" - - "--num-confirmations=1" - - "--resubmission-timeout=30s" - - "--wait-node-sync=true" - - "--log.level=info" - restart: unless-stopped - networks: - - sequencer-node_default - - networks: - sequencer-node_default: - external: false - - ``` - - ### Start the proposer service - - ```bash - # Make sure your sequencer network exists - docker network create op-stack 2>/dev/null || true - - # Start the proposer - docker-compose up -d - - # View logs - docker-compose logs -f op-proposer - ``` - - ### Verify proposer is running - - ```bash - # Check container status - docker-compose ps - ``` - - ### Final directory structure - - ```bash - rollup/ - ├── deployer/ # From previous step - │ └── .deployer/ # Contains state.json - ├── sequencer/ # From previous step - ├── batcher/ # From previous step - └── proposer/ # You are here - ├── state.json # Copied from deployer - ├── .env # Environment variables - └── docker-compose.yml # Docker configuration - ``` - - -
- Understanding proposer startup logs - - When you first start your proposer, you'll see several types of log messages: - - 1. **Initialization messages** (normal): - ``` - lvl=info msg="Initializing L2Output Submitter" - lvl=info msg="Connected to DisputeGameFactory" - lvl=info msg="Starting JSON-RPC server" - ``` - - 2. **Sync status messages** (expected during startup): - ``` - msg="rollup current L1 block still behind target, retrying" - current_l1=...:9094035 target_l1=9132815 - ``` - This is normal! It means: - * Your rollup is still syncing with L1 (e.g., Sepolia) - * The proposer is waiting until sync is closer to L1 tip - * You'll see the `current_l1` number increasing as it catches up - * Once caught up, the proposer will start submitting proposals - - Don't worry about the "retrying" messages - they show healthy progress as your rollup catches up to the latest L1 blocks. - - **Common log patterns:** - - * Startup: You'll see initialization messages as services start - * Sync: "block still behind target" messages while catching up - * Normal operation: Regular proposal submissions once synced - * Network: Connection messages to L1/L2 endpoints - - If you see errors about "failed to dial" or connection issues: - - * For source build: Verify your localhost ports and services -
- - Your proposer is now operational and will continuously submit state roots to L1! - - - - - ### Finding the current stable releases - - To ensure you're using the latest compatible versions of OP Stack components, always check the official [releases page](https://github.com/ethereum-optimism/optimism/releases). - - Look for the latest `op-proposer/v*` release that's compatible with your sequencer setup. - - - This guide uses `op-proposer/v1.10.0` which is compatible with op-node/v1.13.3 and op-geth/v1.101511.1 from the sequencer setup. - Always check the [release notes](https://github.com/ethereum-optimism/optimism/releases) for compatibility information. - - Building from source gives you full control over the binaries. - - - ### Clone and build op-proposer - - ```bash - # If you don't already have the optimism repository from the sequencer setup - git clone https://github.com/ethereum-optimism/optimism.git - cd optimism - - # Checkout the latest release tag - git checkout op-proposer/v1.10.0 - - # Build op-proposer - cd op-proposer - just - - # Binary will be available at ./bin/op-proposer - ``` - - ### Verify installation - - Run this command to verify the installation: - - ```bash - ./bin/op-proposer --version - ``` - - - ## Configuration setup - - - The rest of this guide assumes you're using the **build-from-source** approach. - If you chose Docker, all the necessary configuration was covered in the Docker tab above. - - - - ### Organize your workspace - - Create your proposer working directory at the same level as your sequencer: - - ```bash - # Create proposer directory inside rollup - cd ../ # Go back to rollup directory - mkdir proposer - cd proposer - - # Create scripts directory - mkdir scripts - ``` - - ### Extract DisputeGameFactory address - - Extract the `DisputeGameFactory` contract address from your op-deployer output: - - ```bash - # Make sure you're in the rollup/proposer directory - cd rollup/proposer - - # Copy the state.json from deployer - cp ../deployer/.deployer/state.json . - - # Extract the DisputeGameFactory address - GAME_FACTORY_ADDRESS=$(cat state.json | jq -r '.opChainDeployments[0].disputeGameFactoryProxyAddress') - echo "DisputeGameFactory Address: $GAME_FACTORY_ADDRESS" - ``` - - - The proposer only needs the `DisputeGameFactory` address to submit proposals. - The `GAME_TYPE=0` represents the standard fault proof game type. - - - ### Set up environment variables - - Create your `.env` file with the actual values: - - ```bash - # Create .env file with your actual values - # L1 Configuration - Replace with your actual RPC URL - L1_RPC_URL=https://sepolia.infura.io/v3/YOUR_ACTUAL_INFURA_KEY - - # L2 Configuration - Should match your sequencer setup - L2_RPC_URL=http://localhost:8545 - ROLLUP_RPC_URL=http://localhost:8547 - - # Contract addresses - Extract from your op-deployer output - GAME_FACTORY_ADDRESS=YOUR_ACTUAL_GAME_FACTORY_ADDRESS - - # Private key - Replace with your actual private key - PRIVATE_KEY=YOUR_ACTUAL_PRIVATE_KEY - - # Proposer configuration - PROPOSAL_INTERVAL=3600s - GAME_TYPE=0 - POLL_INTERVAL=20s - - # RPC configuration - PROPOSER_RPC_PORT=8560 - ``` - - **Important**: Replace ALL placeholder values (`YOUR_ACTUAL_*`) with your real configuration values! - - ### Get your private key - - Get a private key from your wallet that will be used for submitting proposals to L1. This account needs sufficient ETH to pay for L1 gas costs. - - - The proposer account needs to be funded with ETH on L1 to pay for proposal submission transactions. Monitor this account's balance regularly as it will consume ETH for each proposal submission. - - - - ## Proposer configuration - - Create `scripts/start-proposer.sh`: - - ```bash - #!/bin/bash - - source .env - - # Path to the op-proposer binary we built - ../../optimism/op-proposer/bin/op-proposer \ - --poll-interval=$POLL_INTERVAL \ - --rpc.port=$PROPOSER_RPC_PORT \ - --rpc.enable-admin \ - --rollup-rpc=$ROLLUP_RPC_URL \ - --l1-eth-rpc=$L1_RPC_URL \ - --private-key=$PRIVATE_KEY \ - --game-factory-address=$GAME_FACTORY_ADDRESS \ - --game-type=$GAME_TYPE \ - --proposal-interval=$PROPOSAL_INTERVAL \ - --num-confirmations=1 \ - --resubmission-timeout=30s \ - --wait-node-sync=true \ - --log.level=info - ``` - - Your final directory structure should look like: - - ```bash - rollup/ - ├── deployer/ # From previous step - │ └── .deployer/ # Contains state.json - ├── optimism/ # Contains op-proposer binary - ├── sequencer/ # From previous step - ├── batcher/ # From previous step - └── proposer/ # You are here - ├── state.json # Copied from deployer - ├── .env # Environment variables - └── scripts/ # Startup scripts - └── start-proposer.sh - ``` - - ## Starting the proposer - - - ### Start the proposer - - ```bash - # Make the script executable - chmod +x scripts/start-proposer.sh - - # Start the proposer - ./scripts/start-proposer.sh - ``` - - -
- Understanding proposer startup logs - - When you first start your proposer, you'll see several types of log messages: - - 1. **Initialization messages** (normal): - ``` - lvl=info msg="Initializing L2Output Submitter" - lvl=info msg="Connected to DisputeGameFactory" - lvl=info msg="Starting JSON-RPC server" - ``` - - 2. **Sync status messages** (expected during startup): - ``` - msg="rollup current L1 block still behind target, retrying" - current_l1=...:9094035 target_l1=9132815 - ``` - This is normal! It means: - * Your rollup is still syncing with L1 (e.g., Sepolia) - * The proposer is waiting until sync is closer to L1 tip - * You'll see the `current_l1` number increasing as it catches up - * Once caught up, the proposer will start submitting proposals - - Don't worry about the "retrying" messages - they show healthy progress as your rollup catches up to the latest L1 blocks. - - **Common log patterns:** - - * Startup: You'll see initialization messages as services start - * Sync: "block still behind target" messages while catching up - * Normal operation: Regular proposal submissions once synced - * Network: Connection messages to L1/L2 endpoints - - If you see errors about "failed to dial" or connection issues: - - * For Docker: Check your network configuration and service names -
- - Your proposer is now operational! - - - -## What's Next? - -Perfect! Your proposer is submitting state roots to L1. The final step is to set up the challenger to monitor and respond to disputes. - - - **Next**: Configure and start op-challenger to monitor disputes and maintain your rollup's security. - - -*** - -## Need Help? - -* **Community Support**: Join the [Optimism Discord](https://discord.optimism.io) -* **Proposer Configuration**: [op-proposer Configuration Reference](/operators/chain-operators/configuration/proposer) -* **Dispute Games**: [Deploying Dispute Games with OPCM](/operators/chain-operators/tutorials/dispute-games) diff --git a/pages/operators/node-operators.mdx b/pages/operators/node-operators.mdx deleted file mode 100644 index d50c923c3..000000000 --- a/pages/operators/node-operators.mdx +++ /dev/null @@ -1,43 +0,0 @@ ---- -title: Node Operators -description: Documentation covering Architecture, Configuration, Json Rpc, Management, Network Upgrades, Releases, Rollup Node, Tutorials in the Node Operators section of the OP Stack ecosystem. -lang: en-US -content_type: landing-page -topic: node-operator-resources -personas: - - node-operator -categories: - - node-configuration - - infrastructure - - system-configuration - - node-management - - execution-client - - consensus-client - - monitoring - - rollup-node -is_imported_content: 'false' ---- - -import { Card, Cards } from 'nextra/components' - -# Node Operators - -Documentation covering Architecture, Configuration, Json Rpc, Management, Network Upgrades, Releases, Rollup Node, Tutorials in the Node Operators section of the OP Stack ecosystem. - - - - - - - - - - - - - - - - - - diff --git a/pages/operators/node-operators/_meta.json b/pages/operators/node-operators/_meta.json deleted file mode 100644 index 818311233..000000000 --- a/pages/operators/node-operators/_meta.json +++ /dev/null @@ -1,10 +0,0 @@ -{ - "architecture": "Architecture", - "rollup-node": "Run a node in the Superchain", - "tutorials": "Tutorials", - "configuration": "Configuration", - "management": "Node management", - "network-upgrades": "Network upgrades", - "json-rpc": "JSON-RPC API", - "releases": "Software releases" -} diff --git a/pages/operators/node-operators/configuration.mdx b/pages/operators/node-operators/configuration.mdx deleted file mode 100644 index 90dcae18b..000000000 --- a/pages/operators/node-operators/configuration.mdx +++ /dev/null @@ -1,35 +0,0 @@ ---- -title: Configuration -lang: en-US -description: >- - Learn about configuration in the Optimism ecosystem. This guide provides - detailed information and resources about configuration. -content_type: landing-page -topic: node-configuration-resources -personas: - - node-operator -categories: - - node-configuration - - infrastructure - - system-configuration - - node-management - - execution-client - - consensus-client - - system-design - - system-components -is_imported_content: 'false' ---- - -import { Card, Cards } from 'nextra/components' - -# Configuration - -This section provides information on node base configuration, consensus layer configuration options (OP Node), and execution layer configuration options (OP Geth). You'll find information to help you understand and work with these topics. - - - - - - - - diff --git a/pages/operators/node-operators/configuration/_meta.json b/pages/operators/node-operators/configuration/_meta.json deleted file mode 100644 index 8794a3782..000000000 --- a/pages/operators/node-operators/configuration/_meta.json +++ /dev/null @@ -1,5 +0,0 @@ -{ - "base-config": "Base configuration", - "consensus-config": "Consensus layer configuration", - "execution-config": "Execution layer configuration" - } \ No newline at end of file diff --git a/pages/operators/node-operators/management.mdx b/pages/operators/node-operators/management.mdx deleted file mode 100644 index 293b7f1a5..000000000 --- a/pages/operators/node-operators/management.mdx +++ /dev/null @@ -1,39 +0,0 @@ ---- -title: Management -lang: en-US -description: Find detailed information and resources about node management in the Optimism ecosystem. -content_type: landing-page -topic: node-management-resources -personas: - - node-operator -categories: - - node-management - - infrastructure - - system-configuration - - monitoring - - stability-monitoring - - node-configuration - - execution-client - - consensus-client -is_imported_content: 'false' ---- - -import { Card, Cards } from 'nextra/components' - -# Management - -This section provides information on using blobs, node metrics and monitoring, snap sync for node operators, node snapshots, and troubleshooting. Users will find APIs, references, and guides to help understand and work with these topics. - - - } /> - - } /> - - } /> - - } /> - - } /> - - } /> - diff --git a/pages/operators/node-operators/management/_meta.json b/pages/operators/node-operators/management/_meta.json deleted file mode 100644 index 7a92a8492..000000000 --- a/pages/operators/node-operators/management/_meta.json +++ /dev/null @@ -1,8 +0,0 @@ -{ - "blobs": "Using blobs", - "snap-sync": "Using Snap Sync", - "snapshots": "Snapshot downloads", - "regenesis-history": "Historical data", - "metrics": "Monitoring", - "troubleshooting": "Troubleshooting" -} diff --git a/pages/operators/node-operators/management/blobs.mdx b/pages/operators/node-operators/management/blobs.mdx deleted file mode 100644 index 7205f1d37..000000000 --- a/pages/operators/node-operators/management/blobs.mdx +++ /dev/null @@ -1,133 +0,0 @@ ---- -title: Using blobs -lang: en-US -description: Learn how to handle blobs for your node. -content_type: guide -topic: using-blobs -personas: - - node-operator -categories: - - blob-configuration - - data-availability - - node-configuration - - system-configuration - - consensus-client - - execution-client - - network-upgrades - - infrastructure -is_imported_content: 'false' ---- - -import { Callout, Steps } from 'nextra/components' -import { Tabs } from 'nextra/components' - -# Using blobs - -The proposed Ecotone upgrade impacts node operators because of the new Beacon -endpoint for `op-node`. Soon after the Ecotone activation, batch transactions -will be sent as 4844 blobs, and blobs can only be retrieved from Beacon nodes. -This means node operators will need access to a beacon node/consensus client -(i.e. Lighthouse, Lodestar, Nimbus, Prysm, Teku, etc.). - -## Preparing your node - -These steps are necessary for EVERY node operator: - - -### Update to the latest release - -See the [Software Releases](/operators/node-operators/releases) page for the minimum release version. - -### Configure the Ecotone activation date - -* If you are operating a node for an OP Chain that has an entry in the [`superchain-registry`](https://github.com/ethereum-optimism/superchain-registry/blob/main/chainList.json), -the Ecotone activation date is handled automatically by both execution clients: - - - - The activation date is part of the node configuration. No action needed after upgrading to the latest release. - - - The activation date is included in the built-in chain configuration. No action needed after upgrading to the latest release. - - - -* For node operators of custom chains not included in the [`superchain-registry`](https://github.com/ethereum-optimism/superchain-registry/blob/main/chainList.json): - - - - Set the activation time in `rollup.json` (`ecotone_time`) and via CLI overrides - - - Use the chain configuration examples in `src/Nethermind/Chains` as templates for your custom chain configuration - - - - - When using `op-geth`, even if the ecotone activation is configured via the `rollup.json`, it still - needs to be configured separately via command line flag. - - - - - ```shell - --override.ecotone value (default: 0) ($OP_NODE_OVERRIDE_ECOTONE) - Manually specify the Ecotone fork timestamp, overriding the bundled setting - ``` - - - - ```shell - --override.ecotone value (default: 0) ($GETH_OVERRIDE_ECOTONE) - Manually specify the Optimism Ecotone fork timestamp, overriding the bundled - setting - ``` - - - -### Prepare for activation - -* All node operators must set an L1 beacon value in your `op-node` as soon as you update to the latest release. - -```shell ---l1.beacon value ($OP_NODE_L1_BEACON) - HTTP endpoint Address of L1 Beacon-node. -``` - -* Either run your own L1 beacon node like [Lighthouse](https://lighthouse-book.sigmaprime.io/run_a_node.html) or use a third-party beacon node RPC service, like [Quicknode](https://www.quicknode.com/docs/ethereum/eth-v1-beacon-genesis). - - - -## Configure a blob archiver - -There is a configurable `beacon-archiver` that will allow nodes to sync blob data that is older than 18 days - after blobs are 18 days old, normal beacon nodes will "prune" or remove them. If your node is already in sync with the head of the chain, you won't need to use a `beacon-archiver`. - -* If you're spinning up a new node, if you load it from a snapshot that's within 18 days (the amount of time until blobs are pruned) you will not need to use a `beacon-archiver` at all as long as your node does not fall offline for more than 18 days. -* If you're running a new node that is syncing more than 18 days (the amount of time until blobs are pruned) after Ecotone launch, then you will need to configure a `beacon-archiver` on the `op-node`. - -```shell ---l1.beacon-archiver value ($OP_NODE_L1_BEACON) - HTTP Endpoint of a Blob Archiver or an L1 Beacon-node that does not prune blobs -``` - -Choose one of the following options to access a beacon archiver endpoint: - -* **Option 1:** Run a beacon node with blobs pruning disabled. For example, you can run your own L1 beacon node like [Lighthouse](https://lighthouse-book.sigmaprime.io/run_a_node.html) and configure it to retain all blobs and use that endpoint here. - -```shell -# lighthouse ---prune-blobs=false -``` - -* **Option 2:** Run a `blob-archiver` and configure `op-node` to use the `blob-archiver` API service with `--l1.beacon-archiver`. - Running a `blob-archiver` is lighter weight than running a beacon node that does not prune blobs: [https://github.com/base-org/blob-archiver](https://github.com/base-org/blob-archiver). There is a configurable `beacon-archiver` that will allow nodes to sync blob data that is older than 18 days - after blobs are 18 days old, normal beacon nodes will "prune" or remove them. If your node is already in sync with the head of the chain, you won't need to use a `beacon-archiver`. - * If you're spinning up a new node, if you load it from a snapshot that's within 18 days (the amount of time until blobs are pruned) you will not need to use a `beacon-archiver` at all as long as your node does not fall offline for more than 18 days. - * If you're running a new node that is syncing more than 18 days (the amount of time until blobs are pruned) after Ecotone launch, then you will need to configure a `beacon-archiver` on the `op-node`. - -```shell ---l1.beacon-archiver value ($OP_NODE_L1_BEACON) - HTTP Endpoint of a Blob Archiver or an L1 Beacon-node that does not prune blobs -``` - -* **Option 3:** If you don't want to operate any Beacon infrastructure, you can use an external service that provides access to pruned Blobs. - diff --git a/pages/operators/node-operators/tutorials.mdx b/pages/operators/node-operators/tutorials.mdx deleted file mode 100644 index 91364ac09..000000000 --- a/pages/operators/node-operators/tutorials.mdx +++ /dev/null @@ -1,36 +0,0 @@ ---- -title: Tutorials -lang: en-US -description: >- - Learn about tutorials in the Optimism ecosystem. This guide provides detailed - information and resources about tutorials. - content_type: landing-page -topic: node-tutorials -personas: - - node-operator -categories: - - node-configuration - - infrastructure - - system-configuration - - node-management - - docker - - execution-client - - consensus-client - - local-development-environment -is_imported_content: 'false' ---- - -import { Card, Cards } from 'nextra/components' - -# Tutorials - -This section provides information on how to run a node on a Superchain network. It covers running a node with Docker, building a Superchain node from source, and running a Superchain node from source. - - - - - - - - - diff --git a/pages/operators/node-operators/tutorials/_meta.json b/pages/operators/node-operators/tutorials/_meta.json deleted file mode 100644 index 7e846b883..000000000 --- a/pages/operators/node-operators/tutorials/_meta.json +++ /dev/null @@ -1,5 +0,0 @@ -{ - "node-from-docker": "Running a node with Docker", - "node-from-source": "Building a Superchain node from source", - "run-node-from-source": "Running a Superchain node from source" -} diff --git a/pages/superchain/addresses.mdx b/pages/reference/addresses.mdx similarity index 100% rename from pages/superchain/addresses.mdx rename to pages/reference/addresses.mdx diff --git a/pages/connect/resources/glossary.mdx b/pages/reference/glossary.mdx similarity index 100% rename from pages/connect/resources/glossary.mdx rename to pages/reference/glossary.mdx diff --git a/pages/reference/meta.json b/pages/reference/meta.json new file mode 100644 index 000000000..0dad22676 --- /dev/null +++ b/pages/reference/meta.json @@ -0,0 +1,6 @@ +{ + "addresses": "Contract Addresses", + "glossary": "glossary", + "networks": "OP Stack networks and public RPC endpoints", + "resources": "Resources" +} diff --git a/pages/superchain/networks.mdx b/pages/reference/networks.mdx similarity index 100% rename from pages/superchain/networks.mdx rename to pages/reference/networks.mdx diff --git a/pages/connect/resources.mdx b/pages/reference/resources.mdx similarity index 100% rename from pages/connect/resources.mdx rename to pages/reference/resources.mdx diff --git a/pages/scaner.sh b/pages/scaner.sh new file mode 100755 index 000000000..48158d849 --- /dev/null +++ b/pages/scaner.sh @@ -0,0 +1,159 @@ +#!/bin/bash + +# Directory Scanner to CSV - Shell Script +# Recursively scans a directory and outputs all file paths to CSV +# Ignores files named "meta.json" + +# Function to display usage +show_usage() { + echo "Usage: $0 [output-file.csv]" + echo "Example: $0 ./pages files-list.csv" + echo "Example: $0 /path/to/directory" + echo "" + echo "This script will:" + echo " - Recursively scan the input directory" + echo " - Find all files except 'meta.json' files" + echo " - Output results to CSV with full paths and file info" + exit 1 +} + +# Function to escape CSV fields +escape_csv() { + # Replace quotes with double quotes and wrap in quotes + echo "\"$(echo "$1" | sed 's/"/""/g')\"" +} + +# Function to get file size (cross-platform) +get_file_size() { + local file="$1" + if [[ "$OSTYPE" == "darwin"* ]]; then + # macOS + stat -f%z "$file" 2>/dev/null || echo "0" + else + # Linux + stat -c%s "$file" 2>/dev/null || echo "0" + fi +} + +# Function to get relative path +get_relative_path() { + local file="$1" + local base_dir="$2" + + # Use realpath if available, otherwise use basic substitution + if command -v realpath >/dev/null 2>&1; then + local abs_file=$(realpath "$file") + local abs_base=$(realpath "$base_dir") + echo "${abs_file#$abs_base/}" + else + # Fallback method + echo "${file#$base_dir/}" + fi +} + +# Main function +main() { + # Check arguments + if [[ $# -eq 0 ]]; then + show_usage + fi + + local input_dir="$1" + local output_file="${2:-directory-scan.csv}" + + # Validate input directory + if [[ ! -d "$input_dir" ]]; then + echo "Error: Directory '$input_dir' does not exist or is not a directory" + exit 1 + fi + + # Convert to absolute path + if command -v realpath >/dev/null 2>&1; then + input_dir=$(realpath "$input_dir") + else + input_dir=$(cd "$input_dir" && pwd) + fi + + echo "Scanning directory: $input_dir" + echo "Output file: $output_file" + echo "Ignoring: meta.json files" + echo "" + + # Create CSV header + echo "\"Full Path\",\"Relative Path\",\"File Name\",\"Extension\",\"Directory\",\"Size (bytes)\"" > "$output_file" + + local file_count=0 + local temp_file=$(mktemp) + + # Find all files recursively, excluding meta.json files + find "$input_dir" -type f -name "*.json" -name "meta.json" -prune -o -type f -print | \ + while IFS= read -r file; do + # Skip if this is a meta.json file (double check) + if [[ "$(basename "$file")" == "meta.json" ]]; then + continue + fi + + # Get file information + local full_path="$file" + local relative_path=$(get_relative_path "$file" "$input_dir") + local file_name=$(basename "$file") + local extension="${file_name##*.}" + local directory=$(dirname "$relative_path") + local size=$(get_file_size "$file") + + # Handle case where file has no extension + if [[ "$extension" == "$file_name" ]]; then + extension="" + else + extension=".$extension" + fi + + # Handle root directory case + if [[ "$directory" == "." ]]; then + directory="." + fi + + # Create CSV row + local csv_row="$(escape_csv "$full_path"),$(escape_csv "$relative_path"),$(escape_csv "$file_name"),$(escape_csv "$extension"),$(escape_csv "$directory"),$size" + + # Append to temp file (to count files) + echo "$csv_row" >> "$temp_file" + + done + + # Sort the temp file and append to output + if [[ -s "$temp_file" ]]; then + sort "$temp_file" >> "$output_file" + file_count=$(wc -l < "$temp_file") + fi + + # Clean up + rm -f "$temp_file" + + if [[ $file_count -eq 0 ]]; then + echo "No files found in the directory (excluding meta.json files)" + # Remove the CSV file if no content + rm -f "$output_file" + exit 0 + fi + + echo "Found $file_count files (excluding meta.json)" + echo "CSV file created: $output_file" + + # Show preview of first few files + echo "" + echo "First few files found:" + tail -n +2 "$output_file" | head -5 | while IFS=, read -r full_path relative_path file_name extension directory size; do + # Remove quotes for display + relative_clean=$(echo "$relative_path" | sed 's/^"//; s/"$//') + size_clean=$(echo "$size" | sed 's/^"//; s/"$//') + echo " $relative_clean ($size_clean bytes)" + done + + if [[ $file_count -gt 5 ]]; then + echo " ... and $((file_count - 5)) more files" + fi +} + +# Run the main function with all arguments +main "$@" \ No newline at end of file diff --git a/pages/stack/_meta.json b/pages/stack/_meta.json deleted file mode 100644 index e6aa85300..000000000 --- a/pages/stack/_meta.json +++ /dev/null @@ -1,30 +0,0 @@ -{ - "--- OP Stack": { - "title": "OP Stack", - "type": "separator" - }, - "getting-started": "Getting Started with OP Stack", - "fact-sheet": "Fact sheet", - "differences": "Differences between Ethereum and OP Stack chains", - "design-principles": "Design philosophy & principles", - "components": "OP Stack components", - "public-devnets": "Public devnets", - "superchain-ops-guide": "Superchain-ops upgrades", - "opcm": "OP Contracts Manager", - "smart-contracts": "Smart contracts", - "rollup": "Rollup", - "fault-proofs": "Fault proofs", - "transactions": "Transactions", - "features": "Features", - "security": "Security", - "+++ Experimental": { - "title": "", - "type": "separator" - }, - "--- Experimental": { - "title": "Experimental", - "type": "separator" - }, - "beta-features": "Beta features", - "research": "Research" -} diff --git a/pages/stack/beta-features/_meta.json b/pages/stack/beta-features/_meta.json deleted file mode 100644 index 3272ba593..000000000 --- a/pages/stack/beta-features/_meta.json +++ /dev/null @@ -1,3 +0,0 @@ -{ - "alt-da-mode": "Alt-DA Mode" -} diff --git a/pages/stack/components.mdx b/pages/stack/components.mdx deleted file mode 100644 index dbbc6a3fb..000000000 --- a/pages/stack/components.mdx +++ /dev/null @@ -1,123 +0,0 @@ ---- -title: OP Stack components -description: >- - Learn about OP Stack components including the different layers and modules - available for development. -lang: en-US -content_type: guide -topic: op-stack-components -personas: - - protocol-developer - - chain-operator - - app-developer -categories: - - mainnet - - protocol - - architecture - - system-design - - modularity - - settlement-layer -is_imported_content: 'false' ---- - -import { Callout } from 'nextra/components' - -# OP Stack components - -**The OP Stack is a common development stack for building L2 blockchain ecosystems, built by the Optimism Collective to power Optimism.** - -The OP Stack is best thought of as a collection of software components maintained by the Optimism Collective that either help to define new layers of the stack or fit in as modules within the stack. - -Because the OP Stack is a work in progress, the different layers and modules are still evolving. -This page sketches out the different conceptual layers of the stack as they exist today and introduces some of the modules that fit into those layers. -This doesn't include all of the modules or layers that may exist in the future, but it gives a good overview of the major OP Stack components. - - - Please note that not all of the modules described on this page already exist in a production state — these are explicitly marked as either "**in development**"or "**proposed**." - - -## Layers - -### Data availability - -The Data Availability Layer defines where the raw inputs to an OP Stack based chain are published. An OP Stack chain can use a single Data Availability module to source its input data. Because an OP Stack chain is derived from the Data Availability Layer, the Data Availability module used has a significant impact on the security model of a system. For example, if a certain piece of data can no longer be retrieved from the Data Availability Layer, it may not be possible to sync the chain. - -#### Ethereum DA - -Ethereum DA is currently the most widely used Data Availability module for the OP Stack. When using the Ethereum DA module, source data can be derived from any piece of information accessible on the Ethereum blockchain. This includes Ethereum calldata, events, and 4844 data blobs. - -* [Specifications](https://specs.optimism.io/protocol/derivation.html#batch-submission-wire-format?utm_source=op-docs&utm_medium=docs) -* [Source code](https://github.com/ethereum-optimism/optimism/tree/v1.1.4/op-batcher) - -### Sequencing - -The Sequencing Layer determines how user transactions on an OP Stack chain are collected and published to the Data Availability Layer module(s) in use. In the default Rollup configuration of the OP Stack, Sequencing is typically handled by a single dedicated Sequencer. Rules defined in the Derivation Layer generally restrict the Sequencer's ability to withhold transactions for more than a specific period of time. In the future, Sequencing will be modular such that chains can easily select and change the mechanism that controls their current Sequencer. - -#### Single sequencer - -The default Sequencer module for the OP Stack is the Single Sequencer module in which a dedicated actor is given the ability to act as the Sequencer. The Single Sequencer module allows a governance mechanism to determine who may act as the Sequencer at any given time. - -#### Multiple sequencer - -A simple modification to the Single Sequencer module is the Multiple Sequencer module in which the Sequencer at any given time is selected from a pre-defined set of possible actors. Individual OP Stack based chains would be able to determine the exact mechanism that defines the set of possible Sequencers and the mechanism that selects a Sequencer from the set. - -### Derivation - -The Derivation Layer defines how the raw data in the Data Availability Layer is processed to form the processed inputs that are sent to the Execution Layer via the standard [Ethereum Engine API](https://github.com/ethereum/execution-apis/blob/94164851c1630ff0a9c31d8d7d3d4fb886e196c0/src/engine/README.md). The Derivation Layer may also use the current system state, as defined by the Execution Layer, to inform the parsing of raw input data. The Derivation Layer can be modified to derive Engine API inputs from many different data sources. The Derivation Layer is typically tied closely to the Data Availability Layer because it must understand how to parse any raw input data. - -#### Rollup - -The Rollup module derives Engine API inputs from Ethereum block data, Sequencer transaction batches, Deposited transaction events, and more. - -* [Specifications](https://specs.optimism.io/protocol/derivation.html#l2-chain-derivation-pipeline?utm_source=op-docs&utm_medium=docs) -* [Source code](https://github.com/ethereum-optimism/optimism/tree/v1.1.4/op-node) - -#### Indexer - -The Indexer module is a Derivation Layer module that would derive Engine API inputs when transactions are sent to, events are emitted by, or storage is modified in specific smart contracts on a Data Availability Layer module like Ethereum DA. - -### Execution - -The Execution Layer defines the structure of state within an OP Stack system and defines the state transition function that mutates this state. State transitions are triggered when inputs are received from the Derivation Layer via the Engine API. The Execution Layer abstraction opens up the door to EVM modifications or different underlying VMs entirely. - -#### EVM - -The EVM is an Execution Layer module that uses the same state representation and state transition function as the Ethereum Virtual Machine. The EVM module in the Ethereum Rollup configuration of the OP Stack is a [lightly modified](https://op-geth.optimism.io/?utm_source=op-docs&utm_medium=docs) version of the EVM that adds support for L2 transactions initiated on Ethereum and adds an extra L1 Data Fee to each transaction to account for the cost of publishing transactions to Ethereum. - -* [Specifications](https://specs.optimism.io/protocol/exec-engine.html?utm_source=op-docs&utm_medium=docs) (where it differs from [geth](https://geth.ethereum.org/)) -* [Source code](https://github.com/ethereum-optimism/op-geth/tree/09ade3df6d1d3a4f8f308553825348be132bc960) - -### Settlement layer - -The Settlement Layer is a mechanism on external blockchains that establish a **view** of the state of an OP Stack chain (target) on those external, third-party chains (including other OP Stack chains). For each target chain, there may be one or more Settlement mechanisms on one or more external chains. Settlement Layer mechanisms are **read-only** and allow a third-party chain to make decisions, potentially impacting their own state, based on the state of the target OP Stack chain. - -The term "Settlement Layer" has its origins in the fact that Settlement Layer mechanisms are often used to handle withdrawals of ETH and tokens out of a blockchain. This sort of withdrawal system first involves proving the state of the target blockchain to some third-party chain and then processing a withdrawal based on that state. The Settlement Layer, at its core, simply allows a third-party chain to become convinced of the state of the target chain. - -Once a transaction is published and finalized on the corresponding Data Availability layer, the transaction is also finalized on the OP Stack chain. Short of breaking the underlying Data Availability layer, it can no longer be modified or removed. It may not be accepted by the Settlement Layer yet because the Settlement Layer needs to be able to verify transaction *results*, but the transaction itself is already immutable. - -#### Attestation-based fault proof - -An Attestation-based Fault Proof mechanism uses an optimistic protocol to establish a view of an OP Stack chain. In optimistic settlement mechanisms generally, **Proposer** entities can propose what they believe to be the current valid state of the OP Stack chain. If these proposals are not invalidated within a certain period of time (the "challenge period"), then the proposals are assumed by the mechanism to be correct. In the Attestation Proof mechanism in particular, a proposal can be invalidated if some threshold of pre-defined parties provide attestations to a valid state that is different than the state in the proposal. This places a trust assumption on the honesty of at least a threshold number of the pre-defined participants. - -* [Specifications](https://specs.optimism.io/protocol/withdrawals.html?utm_source=op-docs&utm_medium=docs) (called [withdrawal transactions](/app-developers/bridging/messaging)) -* [Source code](https://github.com/ethereum-optimism/optimism/tree/v1.1.4/packages/contracts-bedrock/src) - -#### Fault Proof Optimistic Settlement - -A Fault Proof Optimistic Settlement mechanism is mostly identical to the Attestation-based Fault Proof mechanism used today but it replaces the MultiSig challenger with a permissionless fault proving process. A correctly constructed fault proof should be able to invalidate any incorrect proposals during the allocated challenge period. This places a trust assumption on the correctness of the fault proof construction. At this time, work on the development of a Fault Proof mechanism is well underway. - -#### Validity Proof Settlement - -A Validity Proof Settlement mechanism uses a mathematical proof to attest to the correctness of a proposed view. When a proposed state is accompanied by a valid proof, it is immediately and unconditionally accepted; otherwise, it is rejected. This mechanism relies on cryptographic assumptions, rather than trust in certain participants or processes. While it eliminates the need for a challenge period, it requires significant upfront computation to generate the proof. - -### Governance - -The Governance Layer refers to the general set of tools and processes used to manage system configuration, upgrades, and design decisions. This is a relatively abstract layer that can contain a wide range of mechanisms on a target OP Stack chain and on third-party chains that impact many of the other layers of the OP Stack. - -#### MultiSig contracts - -MultiSig Contracts are smart contracts that carry out actions when they receive a threshold of signatures from some pre-defined set of participants. These are often used to manage upgrades of components of an OP Stack based system. Currently, this is the mechanism used to manage upgrades of the bridge contracts on OP Mainnet. The security of a MultiSig Contract system depends on many different factors, including the number of participants, the threshold, and the safety procedures of each individual participant. - -#### Governance tokens - -Governance Tokens are widely used to decentralize decision-making. Although the exact functionality of a Governance Token varies on a case-by-case basis, the most common mechanisms allow token holders to vote on some subset of decisions that a project must make. Voting can either be carried out directly or via delegation. diff --git a/pages/stack/fault-proofs.mdx b/pages/stack/fault-proofs.mdx deleted file mode 100644 index 420d72704..000000000 --- a/pages/stack/fault-proofs.mdx +++ /dev/null @@ -1,39 +0,0 @@ ---- -title: Fault Proofs -description: >- - Documentation covering Cannon, Challenger, Explainer, Fp Components, Fp - Security, Mips in the Fault Proofs section of the OP Stack ecosystem. -lang: en-US -content_type: landing-page -topic: fault-proofs -personas: - - protocol-developer -categories: - - mainnet - - protocol - - security-model - - dispute-resolution - - cannon - - security -is_imported_content: 'false' ---- - -import { Card, Cards } from 'nextra/components' - -# Fault Proofs - -Documentation covering Cannon, Challenger, Explainer, Fp Components, Fp Security, Mips in the Fault Proofs section of the OP Stack ecosystem. - - - } /> - - } /> - - } /> - - } /> - - } /> - - } /> - diff --git a/pages/stack/fault-proofs/_meta.json b/pages/stack/fault-proofs/_meta.json deleted file mode 100644 index 0bf43dd6e..000000000 --- a/pages/stack/fault-proofs/_meta.json +++ /dev/null @@ -1,8 +0,0 @@ -{ - "explainer": "Fault proofs explainer", - "fp-components": "FP system components", - "cannon": "FPVM: Cannon", - "challenger": "OP-Challenger", - "mips": "MIPS.sol", - "fp-security": "FP Mainnet security" -} \ No newline at end of file diff --git a/pages/stack/features.mdx b/pages/stack/features.mdx deleted file mode 100644 index b90d0d29b..000000000 --- a/pages/stack/features.mdx +++ /dev/null @@ -1,26 +0,0 @@ ---- -title: Features -description: >- - Documentation covering Send Raw Transaction Conditional in the Features - section of the OP Stack ecosystem. -lang: en-US -content_type: landing-page -topic: features -personas: - - protocol-developer -categories: - - protocol - - conditional-transactions - - mempool -is_imported_content: 'false' ---- - -import { Card, Cards } from 'nextra/components' - -# Features - -Documentation covering Send Raw Transaction Conditional in the Features section of the OP Stack ecosystem. - - - - diff --git a/pages/stack/features/_meta.json b/pages/stack/features/_meta.json deleted file mode 100644 index 1d8a795f7..000000000 --- a/pages/stack/features/_meta.json +++ /dev/null @@ -1,3 +0,0 @@ -{ - "send-raw-transaction-conditional": "SendRawTransactionConditional" -} diff --git a/pages/stack/research.mdx b/pages/stack/research.mdx deleted file mode 100644 index f447c9236..000000000 --- a/pages/stack/research.mdx +++ /dev/null @@ -1,25 +0,0 @@ ---- -title: Research -description: >- - Documentation covering Block Time Research in the Research section of the OP - Stack ecosystem. -lang: en-US -content_type: landing-page -topic: research -personas: - - protocol-developer -categories: - - protocol - - block-time -is_imported_content: 'false' ---- - -import { Card, Cards } from 'nextra/components' - -# Research - -Documentation covering Block Time Research in the Research section of the OP Stack ecosystem. - - - - diff --git a/pages/stack/research/_meta.json b/pages/stack/research/_meta.json deleted file mode 100644 index 470d7e645..000000000 --- a/pages/stack/research/_meta.json +++ /dev/null @@ -1,4 +0,0 @@ -{ - "block-time-research": "Block time research" -} - \ No newline at end of file diff --git a/pages/stack/rollup.mdx b/pages/stack/rollup.mdx deleted file mode 100644 index 8052236f2..000000000 --- a/pages/stack/rollup.mdx +++ /dev/null @@ -1,34 +0,0 @@ ---- -title: Rollup -description: >- - The big idea that makes Optimism possible is the Optimistic Rollup. We'll go - through a brief explainer of *how* Optimistic Rollups work at a high l... -lang: en-US -content_type: guide -topic: rollup -personas: - - protocol-developer -categories: - - protocol - - layer2-scaling - - derivation-pipeline - - sequencer - - data-availability - - state-commitment - - fault-tolerance -is_imported_content: 'false' ---- - -import { Card, Cards } from 'nextra/components' - -# Rollup - -The big idea that makes Optimism possible is the Optimistic Rollup. We'll go through a brief explainer of *how* Optimistic Rollups work at a high l... - - - - - - - - diff --git a/pages/stack/rollup/_meta.json b/pages/stack/rollup/_meta.json deleted file mode 100644 index def933fd0..000000000 --- a/pages/stack/rollup/_meta.json +++ /dev/null @@ -1,5 +0,0 @@ -{ - "overview": "Rollup overview", - "derivation-pipeline": "Derivation pipeline", - "outages": "Sequencer outages" -} \ No newline at end of file diff --git a/pages/stack/security.mdx b/pages/stack/security.mdx deleted file mode 100644 index 9b4aef542..000000000 --- a/pages/stack/security.mdx +++ /dev/null @@ -1,37 +0,0 @@ ---- -title: Security -description: >- - Documentation covering Faq, Pause in the Security section of the OP Stack - ecosystem. -lang: en-US -content_type: landing-page -topic: security -personas: - - protocol-developer -categories: - - protocol - - security-model - - pause - - audits - - bug-bounty-program - - security-policy -is_imported_content: 'false' ---- - -import { Card, Cards } from 'nextra/components' - -# Security - -Documentation covering Faq, Pause in the Security section of the OP Stack ecosystem. - - - - - - - - - - - - diff --git a/pages/stack/security/_meta.json b/pages/stack/security/_meta.json deleted file mode 100644 index 39cb1fa72..000000000 --- a/pages/stack/security/_meta.json +++ /dev/null @@ -1,5 +0,0 @@ -{ - "faq": "Security FAQs", - "pause": "Pause and unpause the bridge", - "audits-report": "Audit reports" -} \ No newline at end of file diff --git a/pages/stack/smart-contracts/_meta.json b/pages/stack/smart-contracts/_meta.json deleted file mode 100644 index 3446960d9..000000000 --- a/pages/stack/smart-contracts/_meta.json +++ /dev/null @@ -1,6 +0,0 @@ -{ - "smart-contracts": "Smart Contracts", - "superchain-ops-guide": "Upgrade using superchain-ops", - "op-deployer-upgrade": "Upgrade L1 contracts using op-deployer", - "upgrade-op-contracts-1-3-1-8": "Upgrading Smart Contracts from v1.3.0 to v1.8.0" -} \ No newline at end of file diff --git a/pages/stack/transactions.mdx b/pages/stack/transactions.mdx deleted file mode 100644 index 73b491f20..000000000 --- a/pages/stack/transactions.mdx +++ /dev/null @@ -1,48 +0,0 @@ ---- -title: Transactions -description: >- - Documentation covering Cross Domain, Deposit Flow, Fees, Forced Transaction, - Transaction Flow, Transactions, Withdrawal Flow in the Transactions section of - the OP Stack ecosystem. -lang: en-US -content_type: landing-page -topic: transactions -personas: - - protocol-developer -categories: - - protocol - - transaction-flow - - cross-domain-messaging - - deposit-flow - - withdrawal-flow - - transaction-fees - - transaction-finality - - forced-transactions -is_imported_content: 'false' ---- - -import { Card, Cards } from 'nextra/components' - -# Transactions - -Documentation covering Cross Domain, Deposit Flow, Fees, Forced Transaction, Transaction Flow, Withdrawal Flow in the Transactions section of the OP Stack ecosystem. - - - - - - - - - - - - - - - - - - - - diff --git a/pages/stack/transactions/_meta.json b/pages/stack/transactions/_meta.json deleted file mode 100644 index ebc6603e2..000000000 --- a/pages/stack/transactions/_meta.json +++ /dev/null @@ -1,9 +0,0 @@ -{ - "fees": "Transaction fees", - "transaction-flow": "Transaction flow", - "transaction-finality" : "Transaction finality", - "deposit-flow": "Deposit flow", - "withdrawal-flow": "Withdrawal flow", - "forced-transaction": "Forced transaction", - "cross-domain": "Cross domain transaction" -} diff --git a/pages/stack/transactions/flashblocks.mdx b/pages/stack/transactions/flashblocks.mdx deleted file mode 100644 index 1af08ad36..000000000 --- a/pages/stack/transactions/flashblocks.mdx +++ /dev/null @@ -1,244 +0,0 @@ ---- -title: Flashblocks -description: Learn how to integrate Flashblocks for lightning-fast transaction confirmations on OP Stack, with pre-confirmations in just 200 milliseconds. -lang: en-US -content_type: guide -topic: flashblocks -personas: - - app-developer - - protocol-developer - - chain-operator -categories: - - protocol - - block-production - - developer-tools -is_imported_content: 'false' ---- - -# Flashblocks - -Flashblocks is a block builder sidecar for OP Stack chains that delivers sub-second transaction confirmations - 250 ms on OP Mainnet, configurable down to 200 ms. - -By streaming pre-confirmations, "signals" that arrive before the next block is finalized, Flashblocks make OP Stack chains up to 10x faster, unlocking seamless user experiences without compromising security guarantees. - -Built for developers who need lightning fast UX, flashblocks are ideal for DeFi apps, payments, games, and real-time interactions where instant is the only answer. - -* **Payments**: Instant payment confirmations -* **DeFi**: Swaps and positions that update immediately -* **Marketplaces**: Fast, frictionless checkout flows -* **Games**: Real-time actions with no waiting between moves - -## How it works - -By default, blocks are produced every 1–2 seconds. -Flashblocks break that window into smaller intervals so instead of waiting the full block time to execute all transactions, the execution client continuously creates and broadcasts a "flash" block every few hundred milliseconds. - -Each flashblock includes all transactions processed so far, along with updated balances and contract states. -Apps can query this near-real-time state using RPC providers (Ankr, QuickNode, Alchemy, etc) and deliver the speed their users expect. - -## Integrate Flashblocks - -Integration is designed to be simple and low-friction. Most apps benefit with minimal code changes. - -* In production, point your app to a a Flashblocks‑aware RPC endpoint from your provider of choice. If your provider doesn't support flashblocks yet, let us know on Discord - and we'll work with them to get it added. -* Alternatively, you can run your own flashblocks-aware node using Base's [reth](https://github.com/base/node-reth) image. - -### Supported RPC methods - -Developers can access Flashblocks using the same familiar Ethereum JSON-RPC calls. -The difference is using the "pending" tag to query the pre-confirmed state instead of the last finalized block. - -* **`eth_getBlockByNumber`**: Use the `pending` tag to retrieve the latest flashblock snapshot. -
- Sample response - - ```json - { - "jsonrpc": "2.0", - "id": 1, - "result": { - "number": "0x1234", - "hash": "0x...", - "transactions": [...] - } - } - ``` -
- -* **`eth_call`**: Use the `pending` tag to execute calls against the most recent pre-confirmed state. - -
- Sample request - - ```json - { - "jsonrpc": "2.0", - "method": "eth_call", - "params": [{"to": "0x...", "data": "0x..."}, "pending"], - "id": 1 - } - ``` -
- -* `eth_getBalance` / `eth_getTransactionCount`: Use the `pending` tag to fetch balances or transaction counts as they evolve within the block window. - -
- Sample response for `eth_getBalance` - - ```json - { - "jsonrpc": "2.0", - "id": 1, - "result": "0x0234" - } - ``` -
- -
- Sample response for `eth_getTransactionCount` - - ```json - { - "jsonrpc": "2.0", - "id": 1, - "result": "0x1b" // 27 transactions - } - ``` -
- - Other methods, like `eth_getTransactionReceipt` and `eth_getTransactionByHash`, return data from pre-confirmed transactions without requiring the `pending` tag. - Consult the specs (insert link) for more details on each of these methods. - -## Libraries - -You will need a Flashblocks‑aware RPC endpoint to use the following libraries: - -### Viem - -```ts -import { createPublicClient, createWalletClient, http, parseEther } from 'viem'; -import { privateKeyToAccount } from 'viem/accounts'; -import { opSepolia } from 'viem/chains'; -import { publicActionsL2, walletActionsL2 } from 'viem/op-stack'; - -const account = privateKeyToAccount(`0x${process.env.PRIVATE_KEY}`); - -const walletClient = createWalletClient({ - account, - chain: opSepolia, - transport: http("https://sepolia.optimism.io"), -}).extend(walletActionsL2()); - -const publicClient = createPublicClient({ - chain: opSepolia, - transport: http("https://sepolia.optimism.io"), -}).extend(publicActionsL2()); - -const submissionTime = new Date(); -const hash = await walletClient.sendTransaction({ - to: '0x...', - value: parseEther('0.0001'), -}); - -// Wait for pre-confirmation -const receipt = await publicClient.waitForTransactionReceipt({ hash }); -const confirmTime = new Date(); -console.log('pre-confirmed in ms:', confirmTime.getTime() - submissionTime.getTime()); -``` - -### Ethers - -```ts -import { ethers } from 'ethers'; - -// Here, provider is a Flashblocks-enabled RPC provider -const provider = new ethers.JsonRpcProvider("https://sepolia.optimism.io"); -const wallet = new ethers.Wallet(process.env.PRIVATE_KEY as string, provider); - -const tx = { to: '0x...', value: ethers.parseEther('0.0001') }; -const submission = new Date(); - -const sent = await wallet.sendTransaction(tx); - -await sent.wait(0); -const confirmed = new Date(); - -// should represent the transaction (pre)confirmation faster than standard RPC -console.log('Pre-confirmed in ms:', confirmed.getTime() - submission.getTime()); - -// validates the transaction hash returned by the pre-confirmed transaction above -const receipt = await provider.getTransactionReceipt(sent.hash); -console.log('Receipt validated in ms:', validated.getTime() - submission.getTime()); -console.log('Transaction receipt:', receipt); - -``` - -## Flashblocks FAQ - -### Block building and availability - -
- How often are Flashblocks produced? - The flashblocks target interval is variable. - OP Mainnet runs flashblocks at 250ms while Base and Unichain run them at 200ms. - A 2-second block at 250 ms produces 9 flashblocks, indexed 0 to 8. - The index-0 block contains deposit-only transactions, followed by 8 normal Flashblocks. -
- -
- Will the number of Flashblocks per block always be the maximum? - Not always. Heavy execution in one interval may reduce time available for subsequent intervals. The FLASHBLOCKS\_TIME setting is a target, not a strict guarantee. -
- -
- Do large gas transactions get delayed? - High gas transactions can be included in any flashblock with sufficient gas capacity. Placement is optimized by heuristics, but available gas decreases as transactions fill earlier flashblocks. -
- -### High availability and safety - -
- What happens if the flashblocks builder fails? - In a default/non-HA setup, the system falls back to regular block building while preserving pre-confirmations. In an HA setup, `op-conductor` seamlessly transfers leadership to a healthy sequencer without interruption. - When leadership changes, streaming continues seamlessly from the new leader so downstream consumers always receive a continuous stream from a single stable endpoint. -
- -
- How is continuity handled in high availability setups with multiple sequencers? - Only the current leader streams Flashblocks. On leader change, streaming continues from the new leader so downstream consumers see a continuous stream from a single stable endpoint. For details on high-availability sequencer setups, see the [op-conductor documentation](https://docs.optimism.io/operators/chain-operators/tools/op-conductor). -
- -
- Do flashblocks change the safety model of the chain? - No. Each flashblock is validated by the same execution engine as normal blocks. -
- -### Pre-confirmations and reorgs - -
- Can pre-confirmations be revoked? - Rarely. If the sequencer reorgs, pre-confirmed state may change - but this carries no more risk than the reorg of normal blocks. -
- -
- Why can a pre-confirmed transaction later disappear? - If the sequencer reorgs, pre-confirmed state can be replaced. This does not add risk beyond the pending state reorg risk that already exists. -
- -
- Does Flashblocks change liveness or withdrawals? - No. Protocol guarantees remain the same; Flashblocks only speed up transaction confirmation. -
- -
- What is the structure of a pre-confirmation response? - In pre-confirmation responses, `blockHash`, `stateRoot`, and `receiptsRoot` are the values that represent the cumulative state of all transactions included up to that point in the block. The blockNumber reflects the current pending block number. - Each flashblock's view shows the complete state incorporating all transactions processed so far. -
- -## Next steps - -* Explore the [high-level guide](/operators/chain-operators/features/flashblocks/chain-operators) for operators. -* Review the [technical specs](https://specs.optimism.io/protocol/flashblocks.html) for architecture details. -* Join our [community](https://discord.gg/jPQhHTdemH) to share best practices and get support! diff --git a/pages/superchain/_meta.json b/pages/superchain/_meta.json deleted file mode 100644 index e279ad550..000000000 --- a/pages/superchain/_meta.json +++ /dev/null @@ -1,15 +0,0 @@ -{ - "--- Superchain": { - "title": "The Superchain", - "type": "separator" - }, - "superchain-explainer": "The Superchain explainer", - "superchain-registry": "The Superchain Registry", - "superchain-upgrades": "Superchain upgrades", - "blockspace-charter": "Blockspace Charters and the Standard Rollup Charter", - "standard-configuration": "What makes a chain standard", - "tokenlist": "Bridged token addresses", - "addresses": "Contract addresses", - "networks": "OP Stack networks and public RPC endpoints", - "privileged-roles": "Privileged Roles in OP Stack Chains" -} diff --git a/pages/superchain/standard-configuration.mdx b/pages/superchain/standard-configuration.mdx deleted file mode 100644 index e169ae770..000000000 --- a/pages/superchain/standard-configuration.mdx +++ /dev/null @@ -1,128 +0,0 @@ ---- -title: What makes a chain standard? -description: >- - Learn what makes a chain standard, how op-deployer helps with standardization, - and why being standard matters. -lang: en-US -content_type: guide -topic: what-makes-a-chain-standard -personas: - - chain-operator - - protocol-developer - - auditor -categories: - - protocol - - security -is_imported_content: 'false' ---- - -import { Callout } from 'nextra/components' - -# What makes a chain standard? - -The standard configuration within the OP Stack ensures that chains deployed in the Superchain ecosystem adhere to a consistent set of technical and governance parameters. -This standardization is critical for Superchain interoperability, network security, and ease of upgrading your chain. - -This guide provides an in-depth explanation of what defines a standard configuration, how the [op-deployer](/operators/chain-operators/tools/op-deployer) aids standardization, and why adhering to these standards is essential. - -## What is a Standard chain? - -A standard chain in the OP Stack refers to a rollup that adheres to the following principles: - -1. **Technical conformance:** - * Compliance with the consensus parameters, policy parameters, admin roles, and service roles defined in the specifications. - For more details, please see the [OP Stack Configurability Specification](https://specs.optimism.io/protocol/configurability.html?utm_source=op-docs&utm_medium=docs). - * Utilization of officially supported features and modules of the OP Stack. - -2. **Governance alignment:** - * Adherence to the [Standard Rollup Charter](/superchain/blockspace-charter#the-standard-rollup-charter). - * Transparent and collaborative decision-making aligned with the Superchain ecosystem. - -3. **Interoperability:** - * Maintaining compatibility with the Superchain protocol level cross-chain interactions. - -Chains that deviate from these principles, such as introducing unsupported features, are considered non-standard configurations. - -## Role of op-deployer in standardization - -The [op-deployer](/operators/chain-operators/tools/op-deployer) is a powerful tool designed to automate and streamline the deployment of standard configuration-compliant chains. -Key features include: - -* **Default values:** - op-deployer provides default values that adhere to standard specifications. - - -* **Ease of customization within standards:** - The op-deployer tool allows for overriding default values. For example, you can override the L2 block time to 1s, which is standard. However, please ensure you know what you're doing when applying overrides because they may violate standard specifications. - -By using op-deployer, chain operators can reduce the complexity of chain deployment while ensuring alignment with Superchain standards. - - -## Why standardization matters - -Standardization benefits the Superchain ecosystem in several ways: - -* **Interoperability:** - A standard stack and security model makes your chain eligible for interactions between other standard chains, such as single block cross-chain messaging and token transfers. - -* **Simplified upgrade path:** - Reduces the complexity of upgrading your chain to the latest version. - - -* **Reduced Support Overhead:** - Minimizes the need for custom support by ensuring uniformity across deployments. - - -### Standard features - -* **Default system contracts:** - Core protocol contracts must use governance approved release implementations of the OP Stack to provide security and compatibility. - - -* **Specified sequencer configurations:** - Sequencer settings must follow prescribed parameters for transaction ordering and submission to maintain network stability. - -## What is Not Standard? - -Certain configurations are explicitly not part of the standard setup. For example: - -* **Modified system contracts:** - Any alterations to core system contracts break standardization and aren't supported in the official OP Stack specification. - -For a detailed list of standard configurations, refer to the [Standard rollup configuration page](/superchain/blockspace-charter). - -## Superchain Registry - -The [Superchain Registry](/superchain/superchain-registry) is the authoritative index of all chains within the Superchain ecosystem. It ensures: - -* **Transparency:** - All registered chains are publicly listed with their configurations. - -* **Superchain levels:** - Chains listed in the registry are denoted with a [`superchain_level`](https://github.com/ethereum-optimism/superchain-registry/blob/main/docs/glossary.md#superchain-level-and-rollup-stage) which tells you which chains are standard. - -* **Community trust:** - Being part of the registry signals reliability and alignment with Optimism Collective principles. - -## Next Steps - -1. **Understand standards:** - Familiarize yourself with the [OP Stack specifications](https://specs.optimism.io/protocol/configurability.html?utm_source=op-docs&utm_medium=docs) and the Blockspace Charter. - -2. **Use op-deployer:** - Leverage [op-deployer](/operators/chain-operators/tools/op-deployer) to ensure your chain aligns with standard configurations. - -3. **Verify deployment with op-validator:** - Use [op-validator](/operators/chain-operators/tools/op-validator) to verify your chain's deployment. - -4. **Seek guidance:** - Consult the [developer support](https://github.com/ethereum-optimism/developers/discussions) team for clarifications on standardization. - -5. **Contribute to the ecosystem:** - Engage with the [Optimism Collective](https://community.optimism.io/?utm_source=op-docs&utm_medium=docs) to share feedback and propose improvements. - -## References - -* [OP Stack Specifications](https://specs.optimism.io/protocol/configurability.html?utm_source=op-docs&utm_medium=docs) -* [Blockspace Charter](/superchain/blockspace-charter) -* [Superchain Registry](https://github.com/ethereum-optimism/superchain-registry) From 012bc7afcdfc479b717b42dd7ce1daf890276ae5 Mon Sep 17 00:00:00 2001 From: Bradley Camacho <42678939+bradleycamacho@users.noreply.github.com> Date: Thu, 25 Sep 2025 09:18:21 -0700 Subject: [PATCH 2/3] Fresh redirects --- public/_redirects | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+) diff --git a/public/_redirects b/public/_redirects index 252eb6d7b..8822f0393 100644 --- a/public/_redirects +++ b/public/_redirects @@ -203,6 +203,31 @@ /interop /interop/explainer /stack/interop /interop/get-started +# Tutorials and Guides +/builders/dapp-developers/tutorials/first-contract /app-developers/get-started +/builders/dapp-developers/tutorials/cross-dom-bridge-eth /app-developers/tutorials/bridging/cross-dom-bridge-eth +/builders/dapp-developers/tutorials/cross-dom-bridge-erc20 /app-developers/tutorials/bridging/cross-dom-bridge-erc20 +/builders/dapp-developers/tutorials/sdk-estimate-costs /app-developers/tutorials/transactions/sdk-estimate-costs +/builders/dapp-developers/tutorials/sdk-trace-txns /app-developers/tutorials/transactions/sdk-trace-txns +/builders/dapp-developers/tutorials/send-tx-from-eth /app-developers/tutorials/transactions/send-tx-from-eth +/builders/dapp-developers/tutorials/cross-dom-solidity /app-developers/tutorials/bridging/cross-dom-solidity +/builders/dapp-developers/tutorials/* /app-developers/tutorials/:splat + +# Bridging Documentation +/builders/dapp-developers/bridging/basics /app-developers/bridging/basics +/builders/dapp-developers/bridging/messaging /app-developers/bridging/messaging +/builders/dapp-developers/bridging/standard-bridge /app-developers/bridging/standard-bridge +/builders/dapp-developers/bridging/custom-bridge /app-developers/bridging/custom-bridge +/builders/dapp-developers/bridging/* /app-developers/bridging/:splat + +# Contracts and Transactions +/builders/dapp-developers/contracts/account-abstraction /app-developers/tools/build/account-abstraction +/builders/dapp-developers/contracts/cheap-dapp /app-developers/contracts/optimization +/builders/dapp-developers/contracts/compatibility /app-developers/contracts/compatibility +/builders/dapp-developers/contracts/system-contracts /app-developers/contracts/system-contracts +/builders/dapp-developers/contracts/* /app-developers/contracts/:splat +/builders/dapp-developers/transactions/* /app-developers/transactions/:splat + # ---------------------------------------------------------------------------- # Catch-all Rules (Keep at bottom) From 284c4a26ae55249eedcc9328906d1eb98c204496 Mon Sep 17 00:00:00 2001 From: Bradley Camacho <42678939+bradleycamacho@users.noreply.github.com> Date: Thu, 2 Oct 2025 08:05:38 -0700 Subject: [PATCH 3/3] More redirects --- public/_redirects | 68 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 68 insertions(+) diff --git a/public/_redirects b/public/_redirects index 8822f0393..d745b0472 100644 --- a/public/_redirects +++ b/public/_redirects @@ -228,6 +228,74 @@ /builders/dapp-developers/contracts/* /app-developers/contracts/:splat /builders/dapp-developers/transactions/* /app-developers/transactions/:splat +/builders/dapp-developers/bridging/basics /app-developers/bridging/basics +/builders/dapp-developers/bridging/messaging /app-developers/bridging/messaging +/builders/dapp-developers/bridging/standard-bridge /app-developers/bridging/standard-bridge +/builders/dapp-developers/bridging/custom-bridge /app-developers/bridging/custom-bridge +/builders/dapp-developers/bridging/* /app-developers/bridging/:splat + +/app-developers/tools/overview /app-developers/tools +/app-developers/tools/ecosystem-overview /app-developers/tools/build/ecosystem-overview +/app-developers/tools/monitor/* /app-developers/tools/build/:splat +/resources/glossary /connect/resources/glossary +/app-developers/app-developers/bridging/messaging /app-developers/bridging/messaging +/app-developers/app-developers/bridging/standard-bridge /app-developers/bridging/standard-bridge +/app-developers/app-developers/transactions/fees /app-developers/transactions/fees +/app-developers/app-developers/bridging/basics /app-developers/bridging/basics + +# ---------------------------------------------------------------------------- +# Stack Documentation Migration +# ---------------------------------------------------------------------------- +# Protocol and Architecture +/stack/protocol/fault-proofs/* /stack/fault-proofs/:splat +/stack/protocol/interop/* /stack/interop/:splat +/stack/protocol/features/* /stack/features/:splat +/stack/protocol/rollup/* /stack/rollup/:splat +/stack/protocol/* /stack/:splat + +# Transaction Flows +/stack/protocol/deposit-flow /stack/transactions/deposit-flow +/stack/protocol/transaction-flow /stack/transactions/transaction-flow +/stack/protocol/withdrawal-flow /stack/transactions/withdrawal-flow + +# Interoperability +/stack/interop/assets/* /stack/interop/:splat +/stack/interop/transfer-superchainERC20 /stack/interop/tutorials/transfer-superchainERC20 +/stack/interop/architecture /stack/interop/explainer#interoperability-architecture +/stack/interop/cross-chain-message /stack/interop/explainer#how-messages-get-from-one-chain-to-the-other +/stack/interop/cross-chain/contract-calls /stack/interop/tutorials/contract-calls +/stack/interop/cross-chain/event-contests /stack/interop/tutorials/event-contests +/stack/interop/cross-chain/event-reads /stack/interop/tutorials/event-reads +/stack/interop/cross-chain/security /stack/interop/interop-security +/stack/interop/cross-chain/ /stack/interop + +# Others +/audit-reports/1 /stack/security/audits-report +/audit-reports/_numQueuedTransactions /stack/security/audits-report +/stack/overview /stack/getting-started +/stack/explainer /stack/getting-started +/stack/beta-features/custom-gas-token /notices/custom-gas-tokens-deprecation +/stack/transactions/transaction-fees /stack/transactions/fees + +# Superchain +/stack/explainer /superchain/superchain-explainer +/stack/components /superchain/superchain-explainer + + +# ---------------------------------------------------------------------------- +# Chain and Identity Documentation +# ---------------------------------------------------------------------------- +# Chain Resources +/tokenlist /superchain/tokenlist +/addresses /superchain/addresses +/chain/networks /superchain/networks +/chain/addresses /superchain/addresses +/chain/tokenlist /superchain/tokenlist +/chain/getting-started /app-developers/building-apps +/chain/testing/* /app-developers/testing-:splat +/chain/security/privileged-roles /superchain/privileged-roles +/chain/differences /stack/differences + # ---------------------------------------------------------------------------- # Catch-all Rules (Keep at bottom)