From 4231e45f4b43f44eab25a2e0664bb894a871fdc8 Mon Sep 17 00:00:00 2001 From: soyboy Date: Wed, 5 Nov 2025 20:09:07 -0800 Subject: [PATCH 1/2] fixing broken links --- .../ISSUE_TEMPLATE/suggest_troubleshooting_item.yaml | 2 +- app-developers/guides/interoperability/get-started.mdx | 4 +--- .../tutorials/bridging/bridge-crosschain-eth.mdx | 4 ++-- .../tutorials/interoperability/message-passing.mdx | 2 +- .../tutorials/tokens/custom-superchain-erc20.mdx | 4 ++-- .../tutorials/tokens/deploy-superchain-erc20.mdx | 4 ++-- chain-operators/guides/management/best-practices.mdx | 2 +- chain-operators/guides/management/operations.mdx | 2 +- chain-operators/guides/management/snap-sync.mdx | 8 ++++---- chain-operators/quickstarts/self-hosted.mdx | 4 ++-- chain-operators/reference/opcm.mdx | 2 +- chain-operators/reference/standard-configuration.mdx | 6 +++--- chain-operators/reference/superchain-registry.mdx | 4 ++-- chain-operators/reference/superchain-upgrades.mdx | 6 +++--- chain-operators/tools/chain-monitoring.mdx | 2 +- chain-operators/tools/op-validator.mdx | 2 +- .../tutorials/create-l2-rollup/op-challenger-setup.mdx | 2 +- concepts/architecture/fault-proofs/cannon.mdx | 8 ++++---- concepts/architecture/fault-proofs/fp-components.mdx | 2 +- concepts/interoperability/explainer.mdx | 2 +- concepts/stack/fact-sheet.mdx | 2 +- connect/contribute/docs-contribute.mdx | 2 +- docs.json | 8 ++++---- index.mdx | 2 +- messages/WipMsg.md | 3 --- node-operators/guides/base-config.mdx | 4 ++-- node-operators/guides/management/snap-sync.mdx | 6 +++--- node-operators/reference/architecture/rollup-node.mdx | 10 +++++----- 28 files changed, 52 insertions(+), 57 deletions(-) delete mode 100644 messages/WipMsg.md diff --git a/.github/ISSUE_TEMPLATE/suggest_troubleshooting_item.yaml b/.github/ISSUE_TEMPLATE/suggest_troubleshooting_item.yaml index 95ebb7d80..bdc435058 100644 --- a/.github/ISSUE_TEMPLATE/suggest_troubleshooting_item.yaml +++ b/.github/ISSUE_TEMPLATE/suggest_troubleshooting_item.yaml @@ -6,7 +6,7 @@ body: - type: markdown attributes: value: | - Before submitting this suggestion, be sure to read our expectations for [troubleshooting content](https://docs.optimism.io/connect/contribute/style-guide#troubleshooting-guides).
For an example troubleshooting guide with problem+solution pairs, see [Troubleshooting: L2 Rollup](https://docs.optimism.io/operators/chain-operators/management/troubleshooting). + Before submitting this suggestion, be sure to read our expectations for [troubleshooting content](https://docs.optimism.io/connect/contribute/style-guide#troubleshooting-guides).
For an example troubleshooting guide with problem+solution pairs, see [Troubleshooting: L2 Rollup](https://docs.optimism.io/chain-operators/guides/troubleshooting). - type: markdown id: project_info attributes: diff --git a/app-developers/guides/interoperability/get-started.mdx b/app-developers/guides/interoperability/get-started.mdx index 61b0e36a1..569d0b524 100644 --- a/app-developers/guides/interoperability/get-started.mdx +++ b/app-developers/guides/interoperability/get-started.mdx @@ -16,9 +16,7 @@ Choose your development environment to build, test, and quickly iterate on your | Environment | Purpose | Getting Started | | --------------------- | ----------------------------------------- | ---------------------------------------------------------- | | **Local development** | Rapid iteration and testing with Supersim | [Setup Supersim guide](/app-developers/tutorials/supersim) | -| **Interop devnet** | Large-scale testing on testnets | [Network specs](/interop/tools/devnet) | - -For complete network details including RPC endpoints, chain IDs, contract addresses, and bridging instructions, see the [Superchain Interop Devnet Documentation](/interop/tools/devnet). +| **Interop devnet** | Large-scale testing on testnets | [Network specs](/app-developers/guides/building-apps) | ## Deploy your app to devnet in minutes diff --git a/app-developers/tutorials/bridging/bridge-crosschain-eth.mdx b/app-developers/tutorials/bridging/bridge-crosschain-eth.mdx index 08e356575..0c6a3c3d1 100644 --- a/app-developers/tutorials/bridging/bridge-crosschain-eth.mdx +++ b/app-developers/tutorials/bridging/bridge-crosschain-eth.mdx @@ -16,7 +16,7 @@ description: Learn how to transfer ETH across the Superchain interop cluster Crosschain ETH transfers in the Superchain are facilitated through the [SuperchainETHBridge](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/src/L2/SuperchainETHBridge.sol) contract. This tutorial walks through how to send ETH from one chain to another. -You can do this on [Supersim](/interop/tools/supersim), [the Interop devnet](/interop/tools/devnet), or production once it is released. +You can do this on [Supersim](/interop/tools/supersim) or production once it is released. ### What you'll build @@ -61,7 +61,7 @@ The tutorial uses these primary tools: - You can run this tutorial either with [Supersim](/interop/tools/supersim) running locally, or using the [Interop devnet](/interop/tools/devnet). + You can run this tutorial either with [Supersim](/interop/tools/supersim) running locally, or using the [Interop devnet](/app-developers/guides/building-apps). Select the correct tab and follow the directions. diff --git a/app-developers/tutorials/interoperability/message-passing.mdx b/app-developers/tutorials/interoperability/message-passing.mdx index 29ff3514f..e01352762 100644 --- a/app-developers/tutorials/interoperability/message-passing.mdx +++ b/app-developers/tutorials/interoperability/message-passing.mdx @@ -88,7 +88,7 @@ The implementation consists of three main components: ./supersim --interop.autorelay ``` - If you are using [the devnets](/interop/tools/devnet), just skip this step. + If you are using [the devnets](/app-developers/guides/building-apps), just skip this step. diff --git a/app-developers/tutorials/tokens/custom-superchain-erc20.mdx b/app-developers/tutorials/tokens/custom-superchain-erc20.mdx index 250fc8f65..e8170c0d5 100644 --- a/app-developers/tutorials/tokens/custom-superchain-erc20.mdx +++ b/app-developers/tutorials/tokens/custom-superchain-erc20.mdx @@ -64,7 +64,7 @@ Here we will use the [SuperchainERC20 Starter Kit](/app-developers/starter-kit). (1) This should be an address you control (for which you know the private key), which has some ETH on the blockchains in question. In the case of Supersim, the default has 10k ETH and you can use it. - For the devnets, [see here](/interop/tools/devnet#sending-eth-to-the-interop-devnets) to send ETH. + For the devnets, [see here](/app-developers/guides/building-appst#sending-eth-to-the-interop-devnets) to send ETH. 4. If you change `owner_address`, you need to also set the private key. Edit `packages/contracts/.env` to set `DEPLOYER_PRIVATE_KEY` to the private key of an account that has ETH on both devnet blockchains. @@ -87,7 +87,7 @@ Here we will use the [SuperchainERC20 Starter Kit](/app-developers/starter-kit). The [SuperchainERC20 Starter Kit](/app-developers/starter-kit) is already set up for [Supersim](/interop/tools/supersim). - If you want to use it with a different set of blockchains, for example the [Devnets](/interop/tools/devnet), follow these steps. + If you want to use it with a different set of blockchains, for example the [Devnets](/app-developers/guides/building-apps), follow these steps. 1. Edit `packages/contracts/foundry.toml` to add the RPC endpoints (add the bottom two rows). diff --git a/app-developers/tutorials/tokens/deploy-superchain-erc20.mdx b/app-developers/tutorials/tokens/deploy-superchain-erc20.mdx index 9e03e34e8..40bb473f6 100644 --- a/app-developers/tutorials/tokens/deploy-superchain-erc20.mdx +++ b/app-developers/tutorials/tokens/deploy-superchain-erc20.mdx @@ -59,7 +59,7 @@ The tutorial uses these primary tools: The Starter Kit already deploys a `SuperchainERC20` token to [Supersim](/interop/tools/supersim). - Here are the required changes to deploy it to the [Interop devnet](/interop/tools/devnet). + Here are the required changes to deploy it to the [Interop devnet](/app-developers/guides/building-apps). 1. Edit `packages/contracts/foundry.toml` to add the RPC endpoints for the devnet (add the bottom two rows). @@ -98,7 +98,7 @@ The tutorial uses these primary tools: | decimals | Number of decimal places | 18 | | (1) This should be an address you control (for which you know the private key), which has some ETH on the devnets. - [See here](/interop/tools/devnet#sending-eth-to-the-interop-devnets) to add ETH to the devnets. + [See here](/app-developers/guides/building-apps#sending-eth-to-the-interop-devnets) to add ETH to the devnets. Here is a sample `packages/contracts/configs/deploy-config.toml` file you can use, as long as you update `owner_address`. diff --git a/chain-operators/guides/management/best-practices.mdx b/chain-operators/guides/management/best-practices.mdx index 4784aad21..89cfb6c79 100644 --- a/chain-operators/guides/management/best-practices.mdx +++ b/chain-operators/guides/management/best-practices.mdx @@ -75,7 +75,7 @@ GETH_TXPOOL_LIFETIME: "1h" GETH_TXPOOL_NOLOCALS: "true" ``` -For additional information about these flags, check out our [Execution Layer Configuration Options](/operators/node-operators/configuration/execution-config) doc. +For additional information about these flags, check out our [Execution Layer Configuration Options](/node-operators/guides/execution-config) doc. ## Write your own runbooks diff --git a/chain-operators/guides/management/operations.mdx b/chain-operators/guides/management/operations.mdx index a2e537f65..29ce10663 100644 --- a/chain-operators/guides/management/operations.mdx +++ b/chain-operators/guides/management/operations.mdx @@ -207,5 +207,5 @@ You should *not* add an `op-batcher` because there should be only one. ## Next steps -* See the [Node Configuration](/operators/node-operators/configuration/base-config) guide for additional explanation or customization. +* See the [Node Configuration](/node-operators/guides/base-config) guide for additional explanation or customization. * If you experience difficulty at any stage of this process, please reach out to [developer support](https://github.com/ethereum-optimism/developers/discussions). diff --git a/chain-operators/guides/management/snap-sync.mdx b/chain-operators/guides/management/snap-sync.mdx index 6e1306d48..f9c2b2616 100644 --- a/chain-operators/guides/management/snap-sync.mdx +++ b/chain-operators/guides/management/snap-sync.mdx @@ -18,15 +18,15 @@ To enable snap sync, chain operators need to spin up a node which is exposed to For snap sync, all `op-geth` nodes should expose port `30303` TCP and `30303` UDP to easily find other op-geth nodes to sync from. - * If you set the port with [`--discovery.port`](/operators/node-operators/configuration/execution-config#discoveryport), then you must open the port specified for UDP. - * If you set [`--port`](/operators/node-operators/configuration/execution-config#port), then you must open the port specified for TCP. + * If you set the port with [`--discovery.port`](/node-operators/guides/execution-config#discoveryport), then you must open the port specified for UDP. + * If you set [`--port`](/node-operators/guides/execution-config#port), then you must open the port specified for TCP. * The only exception is for sequencers and transaction ingress nodes. * Expose port `30303` (`op-geth`'s default discovery port) to the internet on TCP and UDP. - * Disable transaction gossip with the [`--rollup.disabletxpoolgossip`](/operators/node-operators/configuration/execution-config#rollupdisabletxpoolgossip) flag + * Disable transaction gossip with the [`--rollup.disabletxpoolgossip`](/node-operators/guides/execution-config#rollupdisabletxpoolgossip) flag @@ -36,5 +36,5 @@ For snap sync, all `op-geth` nodes should expose port `30303` TCP and `30303` UD ## Next Steps -* See the [Node configuration](/operators/node-operators/configuration/base-config#configuration) guide for additional explanation or customization. +* See the [Node configuration](/node-operators/guides/base-config#configuration) guide for additional explanation or customization. * If you experience difficulty at any stage of this process, please reach out to [developer support](https://github.com/ethereum-optimism/developers/discussions). diff --git a/chain-operators/quickstarts/self-hosted.mdx b/chain-operators/quickstarts/self-hosted.mdx index 03c48d5e4..abad79c13 100644 --- a/chain-operators/quickstarts/self-hosted.mdx +++ b/chain-operators/quickstarts/self-hosted.mdx @@ -16,8 +16,8 @@ To work with OP Chains, you'll need to understand the fundamental components of * **Chain Architecture**: OP Chains use execution and consensus clients as well as the OP Stack's privileged roles. For more details, see the [Chain Architecture](/operators/chain-operators/architecture) guide. * **Smart Contracts**: OP Chains use several smart contracts on the L1 blockchain to manage aspects of the Rollup. Each OP Stack chain has its own - set of [L1 smart contracts](/stack/smart-contracts/smart-contracts), - [L2 predeploy contracts](/stack/smart-contracts/smart-contracts), + set of [L1 smart contracts](/concepts/stack/smart-contracts), + [L2 predeploy contracts](/concepts/stack/smart-contracts), and [L2 preinstall contracts](/operators/chain-operators/features/preinstalls) that are deployed when the chain is created. * **Preinstalls**: OP Chains come with [preinstalled core contracts](/operators/chain-operators/features/preinstalls), making them usable as soon as a chain is initialized on the OP Stack. diff --git a/chain-operators/reference/opcm.mdx b/chain-operators/reference/opcm.mdx index a300fd6db..9bcd56b65 100644 --- a/chain-operators/reference/opcm.mdx +++ b/chain-operators/reference/opcm.mdx @@ -5,7 +5,7 @@ description: Learn how OP Contracts Manager deploys the OP Stack with one transa The OP Contracts Manager is a contract that deploys the L1 contracts for an OP Stack chain in a single transaction. It provides a minimal set of user-configurable parameters to ensure that the resulting chain meets the standard configuration requirements. Additionally, as of [Upgrade 13](https://gov.optimism.io/t/upgrade-proposal-13-opcm-and-incident-response-improvements/9739), instances of OPCM can upgrade existing OP Stack chains. -The version deployed is always a governance-approved contract release. The set of governance approved contract releases can be found on the Optimism Monorepo releases page, and is the set of releases named `op-contracts/vX.Y.Z`. It deploys the [Fault Proof System](/stack/fault-proofs/explainer), using the [PermissionedDisputeGame](/stack/smart-contracts/smart-contracts#permissioneddisputegame). +The version deployed is always a governance-approved contract release. The set of governance approved contract releases can be found on the Optimism Monorepo releases page, and is the set of releases named `op-contracts/vX.Y.Z`. It deploys the [Fault Proof System](/stack/fault-proofs/explainer), using the [PermissionedDisputeGame](/concepts/stack/smart-contracts#permissioneddisputegame). ## Purpose diff --git a/chain-operators/reference/standard-configuration.mdx b/chain-operators/reference/standard-configuration.mdx index f5b9d1bd1..16e39e09c 100644 --- a/chain-operators/reference/standard-configuration.mdx +++ b/chain-operators/reference/standard-configuration.mdx @@ -17,7 +17,7 @@ A standard chain in the OP Stack refers to a rollup that adheres to the followin * 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). + * Adherence to the [Standard Rollup Charter](/concepts/blockspace-charter#the-standard-rollup-charter). * Transparent and collaborative decision-making aligned with the Superchain ecosystem. 3. **Interoperability:** @@ -71,7 +71,7 @@ Certain configurations are explicitly not part of the standard setup. For exampl * **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). +For a detailed list of standard configurations, refer to the [Standard rollup configuration page](/concepts/blockspace-charter). ## Superchain Registry @@ -106,5 +106,5 @@ The [Superchain Registry](/superchain/superchain-registry) is the authoritative ## References * [OP Stack Specifications](https://specs.optimism.io/protocol/configurability.html?utm_source=op-docs&utm_medium=docs) -* [Blockspace Charter](/superchain/blockspace-charter) +* [Blockspace Charter](/concepts/blockspace-charter) * [Superchain Registry](https://github.com/ethereum-optimism/superchain-registry) diff --git a/chain-operators/reference/superchain-registry.mdx b/chain-operators/reference/superchain-registry.mdx index 2df0261c6..9cd7217f9 100644 --- a/chain-operators/reference/superchain-registry.mdx +++ b/chain-operators/reference/superchain-registry.mdx @@ -15,10 +15,10 @@ An OP Stack Standard Rollup follows the Standard Rollup Charter. This configuration targets the Optimism Collective's highest bar for security, uptime, and decentralization. -You can find more details in the [Standard Rollup Charter documentation](/superchain/blockspace-charter). +You can find more details in the [Standard Rollup Charter documentation](/concepts/blockspace-charter). - We **strongly** recommend using the [op-deployer](/operators/chain-operators/tools/op-deployer) to deploy L1 contracts and generate the L2 genesis file that meets the configuration requirements outlined in the [Standard Rollup Charter](/superchain/blockspace-charter). + We **strongly** recommend using the [op-deployer](/operators/chain-operators/tools/op-deployer) to deploy L1 contracts and generate the L2 genesis file that meets the configuration requirements outlined in the [Standard Rollup Charter](/concepts/blockspace-charter). ## Joining the Registry diff --git a/chain-operators/reference/superchain-upgrades.mdx b/chain-operators/reference/superchain-upgrades.mdx index 0f74c6565..f88b6b112 100644 --- a/chain-operators/reference/superchain-upgrades.mdx +++ b/chain-operators/reference/superchain-upgrades.mdx @@ -39,11 +39,11 @@ Networks that have opted into the [hard fork inheritance behavior](/superchain/s ## `rollup.halt` flags on node binaries -The [`rollup.halt`](/operators/node-operators/configuration/execution-config#rolluphalt) flag is an opt-in configuration option available in both the execution and consensus layer node binaries. +The [`rollup.halt`](/node-operators/guides/execution-config#rolluphalt) flag is an opt-in configuration option available in both the execution and consensus layer node binaries. Its primary function is to temporarily halt node activities, during the transition phase of an upgrade, if or when it encounters an incompatible or unsupported protocol version requirement. -* Execution layer configuration: In the execution layer *(`op-geth`)*, the [`--rollup.halt`](/operators/node-operators/configuration/execution-config#rolluphalt) flag can be set to specify the level of incompatibility (major, minor, patch, none) that will trigger a halt. This ensures that nodes do not process transactions under unsupported protocol versions. -* Consensus layer configuration: Similarly, in the consensus layer *(`op-node`)*, the [`--rollup.halt`](/operators/node-operators/configuration/consensus-config#rolluphalt) flag serves the same purpose, allowing nodes to halt when encountering incompatible protocol versions. +* Execution layer configuration: In the execution layer *(`op-geth`)*, the [`--rollup.halt`](/node-operators/guides/execution-config#rolluphalt) flag can be set to specify the level of incompatibility (major, minor, patch, none) that will trigger a halt. This ensures that nodes do not process transactions under unsupported protocol versions. +* Consensus layer configuration: Similarly, in the consensus layer *(`op-node`)*, the [`--rollup.halt`](/node-operators/guides/configuration/consensus-config#rolluphalt) flag serves the same purpose, allowing nodes to halt when encountering incompatible protocol versions. Failing to upgrade your node with new hardfork rules will trigger the use of the `rollup.halt` flag on the Superchain signaling and your node will halt. diff --git a/chain-operators/tools/chain-monitoring.mdx b/chain-operators/tools/chain-monitoring.mdx index 2170d2b91..d83102743 100644 --- a/chain-operators/tools/chain-monitoring.mdx +++ b/chain-operators/tools/chain-monitoring.mdx @@ -66,7 +66,7 @@ Additional flags: You can find more info on `op-dispute-mon` on [the repo](https://github.com/ethereum-optimism/optimism/tree/develop/op-dispute-mon). -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). +Chain operators can easily create their grafana dashboard for Dispute Monitor using the following json file: [Download the Dispute Monitor JSON](/public/resources/grafana/dispute-monitor-1718214549035.json). ## Offchain component monitoring diff --git a/chain-operators/tools/op-validator.mdx b/chain-operators/tools/op-validator.mdx index d1d7478c8..5ca0b07b8 100644 --- a/chain-operators/tools/op-validator.mdx +++ b/chain-operators/tools/op-validator.mdx @@ -3,7 +3,7 @@ title: op-validator description: Learn how to use op-validator to validate chain configurations and deployments. --- -The `op-validator` is a tool for validating Standard OP Stack chain configurations and deployments to ensure they're in compliance with the [Standard Rollup Charter](/superchain/blockspace-charter#the-standard-rollup-charter). It works by calling into the `StandardValidator` smart contracts (`StandardValidatorV180` and `StandardValidatorV200`). These then perform a set of checks, and return error codes for any issues found. +The `op-validator` is a tool for validating Standard OP Stack chain configurations and deployments to ensure they're in compliance with the [Standard Rollup Charter](/concepts/blockspace-charter#the-standard-rollup-charter). It works by calling into the `StandardValidator` smart contracts (`StandardValidatorV180` and `StandardValidatorV200`). These then perform a set of checks, and return error codes for any issues found. These checks include: diff --git a/chain-operators/tutorials/create-l2-rollup/op-challenger-setup.mdx b/chain-operators/tutorials/create-l2-rollup/op-challenger-setup.mdx index fcc0ad5e0..ee77ed8cd 100644 --- a/chain-operators/tutorials/create-l2-rollup/op-challenger-setup.mdx +++ b/chain-operators/tutorials/create-l2-rollup/op-challenger-setup.mdx @@ -545,7 +545,7 @@ Consider running [`op-dispute-mon`](/operators/chain-operators/tools/chain-monit * 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) +* Create Grafana dashboards using: [Download the Dispute Monitor JSON](/public/resources/grafana/dispute-monitor-1718214549035.json) ## Congratulations diff --git a/concepts/architecture/fault-proofs/cannon.mdx b/concepts/architecture/fault-proofs/cannon.mdx index e9a63808a..30269a757 100644 --- a/concepts/architecture/fault-proofs/cannon.mdx +++ b/concepts/architecture/fault-proofs/cannon.mdx @@ -14,7 +14,7 @@ Note that Cannon is just one example of an FPVM that can be used to resolve disp This documentation will go into detail about the subcomponents that make up the offchain Cannon implementation as a whole. Additionally, we will explore the differences between Cannon and the onchain `MIPS.sol`. For more information about the onchain -implementation, please refer to [MIPS reference](/stack/fault-proofs/mips). +implementation, please refer to [MIPS reference](/concepts/architecture/fault-proofs/mips). Now for simplicity, when referring to Cannon in this documentation, we are referring to the offchain implementation. ## Control flow @@ -103,7 +103,7 @@ do any endianness swapping and can assume all data uses Big-Endian ordering. Thi The last major component is located in [`state.go`](https://github.com/ethereum-optimism/optimism/blob/develop/cannon/mipsevm/state.go). The `State` struct in `state.go` holds all the execution state that is required for the `mipsevm`. -The information stored is largely identical to the [VM execution state](/stack/fault-proofs/mips#packed-vm-execution-state) for `MIPS.sol`. The key differences are: +The information stored is largely identical to the [VM execution state](/concepts/architecture/fault-proofs/mips#packed-vm-execution-state) for `MIPS.sol`. The key differences are: * Instead of storing just the memory Merkle root, there is a `Memory` Struct pointer for the binary Merkle tree representation of the entire 32-bit memory space. * There is an optional `LastHint` bytes variable, which can be used to communicate a Pre-image hint to avoid having to load in multiple prior Pre-images. @@ -120,7 +120,7 @@ The top-level [`witness.go`](https://github.com/ethereum-optimism/optimism/blob/ in `cannon/cmd` initiates the witness proof generation. The internal [`witness.go`](https://github.com/ethereum-optimism/optimism/blob/develop/cannon/mipsevm/witness.go) in `cannon/mipsevm` defines the struct that holds all the relevant information for the particular MIPS instruction. The information that is encoded for the `MIPS.sol` -calldata can be seen in the [`MIPS.sol` documentation](/stack/fault-proofs/mips#contract-state). +calldata can be seen in the [`MIPS.sol` documentation](/concepts/architecture/fault-proofs/mips#contract-state). Additionally, if a Pre-image is required for the MIPS instruction, `witness.go` will communicate the relevant Pre-image key and offset to OP-Challenger so that it can be posted onchain @@ -178,7 +178,7 @@ and Pre-image information (if required for the MIPS instruction). [`mips.go`](https://github.com/ethereum-optimism/optimism/blob/develop/cannon/mipsevm/multithreaded/mips.go) implements all the required MIPS instructions, and also tracks additional memory access for the instruction currently being run. This is important to make sure that the second memory proof is encoded correctly for instructions that use it, such as loads, stores, and -certain syscalls. The full list of instructions supported can be found [here](/stack/fault-proofs/mips#table-of-supported-mips-instructions). +certain syscalls. The full list of instructions supported can be found [here](/concepts/architecture/fault-proofs/mips#table-of-supported-mips-instructions). #### `mips.go` vs. `MIPS.sol` diff --git a/concepts/architecture/fault-proofs/fp-components.mdx b/concepts/architecture/fault-proofs/fp-components.mdx index a06ccc132..168401adb 100644 --- a/concepts/architecture/fault-proofs/fp-components.mdx +++ b/concepts/architecture/fault-proofs/fp-components.mdx @@ -49,7 +49,7 @@ To do this, only one instruction is proven at a time. The bisection game will na * To execute the instruction, the VM emulates something akin to an instruction-cycle of a thread-context: the instruction is read from memory, interpreted, and the register-file and memory may change a little. * To support the pre-image oracle, and basic program runtime needs like memory-allocation, the execution also supports a subset of linux syscalls. Read/write syscalls allow interaction with the pre-image oracle: the program writes a hash as request for a pre-image, and then reads the value in small chunks at a time. -[Cannon](/stack/fault-proofs/cannon) is the default FPVM used in all disputes. [MIPS](/stack/fault-proofs/mips) is the onchain smart contract implementation of Cannon that can be implemented due to the modularity of the dispute game. +[Cannon](/stack/fault-proofs/cannon) is the default FPVM used in all disputes. [MIPS](/concepts/architecture/fault-proofs/mips) is the onchain smart contract implementation of Cannon that can be implemented due to the modularity of the dispute game. ## Dispute game protocol diff --git a/concepts/interoperability/explainer.mdx b/concepts/interoperability/explainer.mdx index 8bca3fd25..a79701e6b 100644 --- a/concepts/interoperability/explainer.mdx +++ b/concepts/interoperability/explainer.mdx @@ -202,7 +202,7 @@ flowchart LR A <--> C <--> E <--> B <--> D <--> A ``` -Each blockchain in the Superchain interop cluster shares the same security model to mitigate the weakest-link scenario. As outlined in the [Standard Rollup Charter](/superchain/blockspace-charter), these chains share the same L1 `ProxyAdmin` Owner. Any changes to the Superchain interop cluster must follow the standard Protocol Upgrade vote procedure—the established governance process for Superchain modifications. +Each blockchain in the Superchain interop cluster shares the same security model to mitigate the weakest-link scenario. As outlined in the [Standard Rollup Charter](/concepts/blockspace-charter), these chains share the same L1 `ProxyAdmin` Owner. Any changes to the Superchain interop cluster must follow the standard Protocol Upgrade vote procedure—the established governance process for Superchain modifications. The Superchain interop cluster will be rolled out iteratively, but to see a list of eligible chains that could join the cluster visit the [Superchain Index](https://www.superchain.eco/superchain-index) and look at chains that have a `Standard` charter. diff --git a/concepts/stack/fact-sheet.mdx b/concepts/stack/fact-sheet.mdx index 5a9e73c10..ad1d7d7db 100644 --- a/concepts/stack/fact-sheet.mdx +++ b/concepts/stack/fact-sheet.mdx @@ -5,7 +5,7 @@ description: Get an overview of features associated with an OP Stack chain Get an overview of the capabilities associated with an OP Stack chain. -While the OP Stack allows for full customization, chains in the Superchain adhere to a [standard set of technical and governance parameters](/superchain/blockspace-charter), facilitating Superchain interoperability, network security, and ease of upgrading your chain. +While the OP Stack allows for full customization, chains in the Superchain adhere to a [standard set of technical and governance parameters](/concepts/blockspace-charter), facilitating Superchain interoperability, network security, and ease of upgrading your chain. # Technical stack diff --git a/connect/contribute/docs-contribute.mdx b/connect/contribute/docs-contribute.mdx index 14e7c0bcb..08d78ed05 100644 --- a/connect/contribute/docs-contribute.mdx +++ b/connect/contribute/docs-contribute.mdx @@ -16,7 +16,7 @@ Optimism Docs (docs.optimism.io) is an open-source project, and we welcome your * [Add or update an FAQ item](https://github.com/ethereum-optimism/docs/issues/new?assignees=\&labels=documentation%2Cfaq%2Ccommunity-request\&projects=\&template=suggest_faq_item.yaml\&title=Suggest+an+FAQ+item): add a new FAQ (question+answer set) to an [existing page](/stack/security/faq-sec-model), create a new FAQ page, or update an existing FAQ question/answer set. * [Add or update a troubleshooting item](https://github.com/ethereum-optimism/docs/issues/new?assignees=\&labels=documentation%2Ctroubleshooting%2Ccommunity-request\&projects=\&template=suggest_troubleshooting_item.yaml\&title=Suggest+a+troubleshooting+item): - add a new troubleshooting item (problem+solution set) to an [existing page](/operators/chain-operators/management/troubleshooting), create a new troubleshooting page, or update an existing troubleshooting problem/solution set. + add a new troubleshooting item (problem+solution set) to an [existing page](/chain-operators/guides/troubleshooting), create a new troubleshooting page, or update an existing troubleshooting problem/solution set. * [Add a glossary term](https://github.com/ethereum-optimism/docs/issues/new?assignees=\&labels=glossary%2Cdocumentation%2Ccommunity-request\&projects=\&template=suggest_glossary_term.yaml\&title=Suggest+a+glossary+term): help us continue to expand the Optimism [glossary](/connect/resources/glossary). * [Add a faucet to the developer community](https://github.com/ethereum-optimism/developers/tree/main/community): diff --git a/docs.json b/docs.json index 7d8c4a6fd..f52e78589 100644 --- a/docs.json +++ b/docs.json @@ -1095,7 +1095,7 @@ }, { "source": "/operators/node-operators/configuration/base-config", - "destination": "/node-operators/guides/configuration/base-config" + "destination": "/node-operators/guides/base-config" }, { "source": "/operators/node-operators/configuration/consensus-config", @@ -1103,7 +1103,7 @@ }, { "source": "/operators/node-operators/configuration/execution-config", - "destination": "/node-operators/guides/configuration/execution-config" + "destination": "/node-operators/guides/execution-config" }, { "source": "/operators/node-operators/json-rpc", @@ -1215,7 +1215,7 @@ }, { "source": "/stack/fault-proofs/mips", - "destination": "/core-contributors/reference/specs/mips" + "destination": "/concepts/architecture/fault-proofs/mips" }, { "source": "/stack/features", @@ -1327,7 +1327,7 @@ }, { "source": "/superchain/blockspace-charter", - "destination": "/governance/blockspace-charter" + "destination": "/concepts/blockspace-charter" }, { "source": "/superchain/networks", diff --git a/index.mdx b/index.mdx index 72b6db750..e34b5e079 100644 --- a/index.mdx +++ b/index.mdx @@ -191,7 +191,7 @@ mode: "wide"
→
- +

View the Troubleshooting Guide for help

diff --git a/messages/WipMsg.md b/messages/WipMsg.md deleted file mode 100644 index 85a10d077..000000000 --- a/messages/WipMsg.md +++ /dev/null @@ -1,3 +0,0 @@ -Please **do not rely** on the content of this page as it is currently undergoing maintenance. **Code samples and solutions may not function as expected.** Please check back for an update or [signup to help us revise this -page](https://github.com/ethereum-optimism/docs/labels/tutorial). We welcome -your contribution! ❤️ diff --git a/node-operators/guides/base-config.mdx b/node-operators/guides/base-config.mdx index 344dbb8e4..a1252b3f0 100644 --- a/node-operators/guides/base-config.mdx +++ b/node-operators/guides/base-config.mdx @@ -249,6 +249,6 @@ The term *historical execution* refers to RPC methods that need to execute trans If you do not need these RPC methods for historical data, then you do not need to run Legacy Geth at all. ## Next steps -* See the [`op-node` configuration](/operators/node-operators/configuration/consensus-config) guide for additional configuration options for `op-node` and the Consensus-Layer. -* For execution client configuration, visit [execution client configuration](/operators/node-operators/configuration/execution-config) for additional options when using `op-geth` or `nethermind` +* See the [`op-node` configuration](/node-operators/guides/configuration/consensus-config) guide for additional configuration options for `op-node` and the Consensus-Layer. +* For execution client configuration, visit [execution client configuration](/node-operators/guides/execution-config) for additional options when using `op-geth` or `nethermind` * If you run into any problems, please reach out to our [developer support forum](https://github.com/ethereum-optimism/developers/discussions) for help. diff --git a/node-operators/guides/management/snap-sync.mdx b/node-operators/guides/management/snap-sync.mdx index 4f1f27eb9..bffaa3edd 100644 --- a/node-operators/guides/management/snap-sync.mdx +++ b/node-operators/guides/management/snap-sync.mdx @@ -17,8 +17,8 @@ This means that performing a Snap Sync is significantly faster than performing a For snap sync, all `op-geth` nodes should expose port `30303` TCP and `30303` UDP to easily find other op-geth nodes to sync from. - * If you set the port with [`--discovery.port`](/operators/node-operators/configuration/execution-config#discoveryport), then you must open the port specified for UDP. - * If you set [`--port`](/operators/node-operators/configuration/execution-config#port), then you must open the port specified for TCP. + * If you set the port with [`--discovery.port`](/node-operators/guides/execution-config#discoveryport), then you must open the port specified for UDP. + * If you set [`--port`](/node-operators/guides/execution-config#port), then you must open the port specified for TCP. * The only exception is for sequencers and transaction ingress nodes. @@ -122,6 +122,6 @@ To enable execution layer sync for these clients, set the following flags on `op ## Next steps -* See the [Node Configuration](/operators/node-operators/configuration/base-config#configuration) guide for additional explanation or customization. +* See the [Node Configuration](/node-operators/guides/base-config#configuration) guide for additional explanation or customization. * To enable snap sync for your chain, see [Using Snap Sync for Chain Operators](/operators/chain-operators/management/snap-sync). * If you experience difficulty at any stage of this process, please reach out to [developer support](https://github.com/ethereum-optimism/developers/discussions). diff --git a/node-operators/reference/architecture/rollup-node.mdx b/node-operators/reference/architecture/rollup-node.mdx index 19f0a8336..962df73b5 100644 --- a/node-operators/reference/architecture/rollup-node.mdx +++ b/node-operators/reference/architecture/rollup-node.mdx @@ -38,9 +38,9 @@ OP Stack rollup nodes can be configured for individual needs. The following step * Configure your execution client: - * For `op-geth`: Use the [base configuration](/operators/node-operators/configuration/base-config#working-base-configuration) and set the [recommended flags](/operators/node-operators/configuration/base-config#recommended-flags-for-op-geth-configuration) - * For `nethermind`: Use the [base configuration](/operators/node-operators/configuration/base-config#working-base-configuration-nethermind) and set the [recommended flags](/operators/node-operators/configuration/base-config#recommended-flags-for-nethermind-configuration) - * Configure `op-node` using the [base configuration](/operators/node-operators/configuration/base-config#working-base-configuration-1). + * For `op-geth`: Use the [base configuration](/node-operators/guides/base-config#working-base-configuration) and set the [recommended flags](/node-operators/guides/base-config#recommended-flags-for-op-geth-configuration) + * For `nethermind`: Use the [base configuration](/node-operators/guides/base-config#working-base-configuration-nethermind) and set the [recommended flags](/node-operators/guides/base-config#recommended-flags-for-nethermind-configuration) + * Configure `op-node` using the [base configuration](/node-operators/guides/base-config#working-base-configuration-1). @@ -49,7 +49,7 @@ OP Stack rollup nodes can be configured for individual needs. The following step This is an **optional** feature but highly recommended for node providers. - Additional configuration options exist for [`op-geth`](/operators/node-operators/configuration/execution-config) and [`op-node`](/operators/node-operators/configuration/consensus-config), respectively. + Additional configuration options exist for [`op-geth`](/node-operators/guides/execution-config) and [`op-node`](/node-operators/guides/configuration/consensus-config), respectively. @@ -75,7 +75,7 @@ You will now run your node from source for your Superchain network. Here are you As part of running your rollup node, you may want to adjust the log level for more or less granular feedback when debugging. - * Update node [log level](/operators/node-operators/configuration/consensus-config#loglevel) based on individual needs. For more details, see the guide on [Geth Logs](https://geth.ethereum.org/docs/fundamentals/logs). + * Update node [log level](/node-operators/guides/configuration/consensus-config#loglevel) based on individual needs. For more details, see the guide on [Geth Logs](https://geth.ethereum.org/docs/fundamentals/logs). From 41fe30500f7477a45b8c7d77b8dd9552ba8289ec Mon Sep 17 00:00:00 2001 From: soyboy Date: Wed, 5 Nov 2025 20:17:17 -0800 Subject: [PATCH 2/2] broken links --- concepts/interoperability/superchain-erc20.mdx | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/concepts/interoperability/superchain-erc20.mdx b/concepts/interoperability/superchain-erc20.mdx index 1b817f2a7..e72fae776 100644 --- a/concepts/interoperability/superchain-erc20.mdx +++ b/concepts/interoperability/superchain-erc20.mdx @@ -80,13 +80,13 @@ sequenceDiagram 2. The token bridge calls [`SuperchainERC20.crosschainBurn`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/src/L2/SuperchainERC20.sol#L37-L46) to burn those tokens on the source chain. 3. The source token bridge calls [`SuperchainTokenBridge.relayERC20`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/src/L2/SuperchainTokenBridge.sol#L80-L97) on the destination token bridge. - This call is relayed using [`L2ToL2CrossDomainMessenger`](./message-passing). + This call is relayed using [`L2ToL2CrossDomainMessenger`](/app-developers/tutorials/interoperability/message-passing). The call is *initiated* here, by emitting an initiating message. - It will be executed later, after the destination chain receives an executing message to [`L2ToL2CrossDomainMessenger`](./message-passing). + It will be executed later, after the destination chain receives an executing message to [`L2ToL2CrossDomainMessenger`](/app-developers/tutorials/interoperability/message-passing). #### Executing message (destination chain) -4. The autorelayer (or the user, or any offchain entity) sends an executing message to [`L2ToL2CrossDomainMessenger`](./message-passing) to relay the message. +4. The autorelayer (or the user, or any offchain entity) sends an executing message to [`L2ToL2CrossDomainMessenger`](/app-developers/tutorials/interoperability/message-passing) to relay the message. 5. The destination token bridge calls [`SuperchainERC20.crosschainMint`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/src/L2/SuperchainERC20.sol#L26-L35) to mint tokens for the user/contract that called `SuperchainTokenBridge.sendERC20` originally.