From fd5f542d226731dd103aeb5f13f97686eaee8452 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 8 Sep 2026 13:30:36 -0500 Subject: [PATCH 1/9] Moving run-feed-relay; beacon-node-historical-blobs to run-arbitrum-node/data-availability --- docs/arbitrum-bridge/06-withdrawal-monitoring.mdx | 2 +- docs/get-started/overview.mdx | 2 +- .../deep-dives/sequencer-transaction-flow.mdx | 4 ++-- .../operate/sequencer-troubleshooting.mdx | 4 ++-- .../run-a-node/high-availability-sequencer.mdx | 2 +- docs/notices/fusaka-upgrade-notice.mdx | 2 +- docs/run-arbitrum-node/01-overview.mdx | 2 +- docs/run-arbitrum-node/02-run-full-node.mdx | 2 +- .../04-l1-ethereum-beacon-chain-rpc-providers.mdx | 2 +- docs/run-arbitrum-node/assign-node-roles.mdx | 4 ++-- docs/run-arbitrum-node/data-availability.mdx | 2 +- .../beacon-nodes-historical-blobs.mdx | 2 +- .../{ => data-availability}/run-feed-relay.mdx | 0 ...optional-orbit-sequencer-compatible-cli-partial.mdx | 2 +- .../partials/run-full-node/_optional-parameters.mdx | 2 +- .../sequencer/02-read-sequencer-feed.mdx | 2 +- docs/run-arbitrum-node/start-here.mdx | 2 +- redirects.config.js | 8 ++++++++ sidebars.js | 4 ++-- vercel.json | 10 ++++++++++ 20 files changed, 39 insertions(+), 21 deletions(-) rename docs/run-arbitrum-node/{ => data-availability}/beacon-nodes-historical-blobs.mdx (98%) rename docs/run-arbitrum-node/{ => data-availability}/run-feed-relay.mdx (100%) diff --git a/docs/arbitrum-bridge/06-withdrawal-monitoring.mdx b/docs/arbitrum-bridge/06-withdrawal-monitoring.mdx index 5016d2ea7d..5a51dc47da 100644 --- a/docs/arbitrum-bridge/06-withdrawal-monitoring.mdx +++ b/docs/arbitrum-bridge/06-withdrawal-monitoring.mdx @@ -298,7 +298,7 @@ Work through the stages in order—each row's check assumes the previous rows pa -Ethereum consensus nodes are required to serve blob data for only 4,096 epochs (≈18 days). Monitors that reconstruct old withdrawal history need archive access: an [archive beacon endpoint for historical blobs](/run-arbitrum-node/beacon-nodes-historical-blobs.mdx) to re-derive the chain from batch data, and an archive child chain node for the event logs that `constructOutboxProof` reads. On AnyTrust chains, the equivalent concern is the Data Availability Committee's retention window. Claiming a confirmed withdrawal itself is unaffected—proofs are built from child chain logs, not blobs. +Ethereum consensus nodes are required to serve blob data for only 4,096 epochs (≈18 days). Monitors that reconstruct old withdrawal history need archive access: an [archive beacon endpoint for historical blobs](/run-arbitrum-node/data-availability/beacon-nodes-historical-blobs.mdx) to re-derive the chain from batch data, and an archive child chain node for the event logs that `constructOutboxProof` reads. On AnyTrust chains, the equivalent concern is the Data Availability Committee's retention window. Claiming a confirmed withdrawal itself is unaffected—proofs are built from child chain logs, not blobs. diff --git a/docs/get-started/overview.mdx b/docs/get-started/overview.mdx index f652f1a1b4..d3250940d5 100644 --- a/docs/get-started/overview.mdx +++ b/docs/get-started/overview.mdx @@ -79,7 +79,7 @@ Run the machines that power the Arbitrum ecosystem. > - + diff --git a/docs/how-arbitrum-works/deep-dives/sequencer-transaction-flow.mdx b/docs/how-arbitrum-works/deep-dives/sequencer-transaction-flow.mdx index 2ae125ac10..a5248668fb 100644 --- a/docs/how-arbitrum-works/deep-dives/sequencer-transaction-flow.mdx +++ b/docs/how-arbitrum-works/deep-dives/sequencer-transaction-flow.mdx @@ -97,7 +97,7 @@ The queue is deliberately a short buffer, not a mempool: with default settings i ## From block to the rest of the network -As soon as a block is created, the transaction streamer hands the new message to the broadcaster, which publishes it over WebSocket on the sequencer feed ([`transaction_streamer.go#L1307`](https://github.com/OffchainLabs/nitro/blob/a618155919315241665356fe60f3cd00d66d5e46/arbnode/transaction_streamer.go#L1307)). Full nodes and [feed relays](/run-arbitrum-node/run-feed-relay.mdx) consume the feed to give sub-second soft confirmations; see [How to read the sequencer feed](/run-arbitrum-node/sequencer/02-read-sequencer-feed.mdx). +As soon as a block is created, the transaction streamer hands the new message to the broadcaster, which publishes it over WebSocket on the sequencer feed ([`transaction_streamer.go#L1307`](https://github.com/OffchainLabs/nitro/blob/a618155919315241665356fe60f3cd00d66d5e46/arbnode/transaction_streamer.go#L1307)). Full nodes and [feed relays](/run-arbitrum-node/data-availability/run-feed-relay.mdx) consume the feed to give sub-second soft confirmations; see [How to read the sequencer feed](/run-arbitrum-node/sequencer/02-read-sequencer-feed.mdx). Independently, the [batch poster](/how-arbitrum-works/deep-dives/batchposter.mdx) compresses the sequenced transactions and posts them to the sequencer inbox on the parent chain, at which point they inherit the parent chain's finality. Validators then re-execute the posted sequence and assert the resulting state. [The Sequencer and censorship resistance](/how-arbitrum-works/deep-dives/sequencer.mdx#sequencing-and-broadcasting) covers the feed, batch posting, and the finality trade-offs in detail, and [Assertions](/how-arbitrum-works/deep-dives/assertions.mdx) covers validation. @@ -124,4 +124,4 @@ This pattern complements rather than replaces queue tuning: `queue-size` and `qu - [RPC endpoints and providers](/arbitrum-essentials/reference/node-providers.mdx): public endpoint behavior, retries, and fallback patterns - [How to set up a high-availability sequencer](/launch-arbitrum-chain/run-a-node/high-availability-sequencer.mdx): redundant Sequencers with Redis-based coordination - [How to run a Sequencer Coordinator Manager](/run-arbitrum-node/sequencer/03-run-sequencer-coordination-manager.mdx): managing the sequencer priority list -- [How to read the sequencer feed](/run-arbitrum-node/sequencer/02-read-sequencer-feed.mdx) and [How to run a feed relay](/run-arbitrum-node/run-feed-relay.mdx) +- [How to read the sequencer feed](/run-arbitrum-node/sequencer/02-read-sequencer-feed.mdx) and [How to run a feed relay](/run-arbitrum-node/data-availability/run-feed-relay.mdx) diff --git a/docs/launch-arbitrum-chain/operate/sequencer-troubleshooting.mdx b/docs/launch-arbitrum-chain/operate/sequencer-troubleshooting.mdx index 5ba8222d6d..33a2271dc4 100644 --- a/docs/launch-arbitrum-chain/operate/sequencer-troubleshooting.mdx +++ b/docs/launch-arbitrum-chain/operate/sequencer-troubleshooting.mdx @@ -47,7 +47,7 @@ sequencers → sequencer relays → external relays → public subscribers Sequencer relays subscribe to _every_ sequencer replica, not just the active one. Non-chosen sequencers still broadcast, so aggregating all of them means no messages are lost when the chosen sequencer changes. This is why the Helm setup needs per-replica headless services—a single load-balanced address would connect to only one replica. See [How to set up a high-availability sequencer](/launch-arbitrum-chain/run-a-node/high-availability-sequencer.mdx#2-relays-setup). -For installation steps, see [How to run a feed relay](/run-arbitrum-node/run-feed-relay.mdx). For the message format, see [How to read the sequencer feed](/run-arbitrum-node/sequencer/02-read-sequencer-feed.mdx). +For installation steps, see [How to run a feed relay](/run-arbitrum-node/data-availability/run-feed-relay.mdx). For the message format, see [How to read the sequencer feed](/run-arbitrum-node/sequencer/02-read-sequencer-feed.mdx). ### Timeouts that govern a feed connection @@ -127,7 +127,7 @@ The feed carries no _heartbeat_ at the application level, so silence is ambiguou -You can point a relay at the same endpoint twice to survive a reset without waiting for a reconnect. This doubles bandwidth and risks rate limiting. Configure it at the relay, never at individual nodes, and never use more than one redundant connection. See [How to run a feed relay](/run-arbitrum-node/run-feed-relay.mdx). +You can point a relay at the same endpoint twice to survive a reset without waiting for a reconnect. This doubles bandwidth and risks rate limiting. Configure it at the relay, never at individual nodes, and never use more than one redundant connection. See [How to run a feed relay](/run-arbitrum-node/data-availability/run-feed-relay.mdx). diff --git a/docs/launch-arbitrum-chain/run-a-node/high-availability-sequencer.mdx b/docs/launch-arbitrum-chain/run-a-node/high-availability-sequencer.mdx index aacf1f4c9e..8e01920ad7 100644 --- a/docs/launch-arbitrum-chain/run-a-node/high-availability-sequencer.mdx +++ b/docs/launch-arbitrum-chain/run-a-node/high-availability-sequencer.mdx @@ -114,7 +114,7 @@ helm install external-relay offchainlabs/relay \ --set configmap.data.node.feed.input.url=ws://sequencer-relay:9642 ``` -You can check [run a feed relay](/run-arbitrum-node/run-feed-relay.mdx) to see how to set up a relay node. +You can check [run a feed relay](/run-arbitrum-node/data-availability/run-feed-relay.mdx) to see how to set up a relay node. ### 3. Nitro full node setup diff --git a/docs/notices/fusaka-upgrade-notice.mdx b/docs/notices/fusaka-upgrade-notice.mdx index 59dc8e0cb4..cbee129798 100644 --- a/docs/notices/fusaka-upgrade-notice.mdx +++ b/docs/notices/fusaka-upgrade-notice.mdx @@ -63,4 +63,4 @@ import ClientFlagsTable from '../partials/_client-flags.mdx'; -To read more about Fusaka PeerDAS changes and why Layer 2 network operators must connect to an Ethereum beacon chain node with historical blob data, see the [historical blobs docs](../run-arbitrum-node/beacon-nodes-historical-blobs.mdx). +To read more about Fusaka PeerDAS changes and why Layer 2 network operators must connect to an Ethereum beacon chain node with historical blob data, see the [historical blobs docs](../run-arbitrum-node/data-availability/beacon-nodes-historical-blobs.mdx). diff --git a/docs/run-arbitrum-node/01-overview.mdx b/docs/run-arbitrum-node/01-overview.mdx index 87379b0dda..ec46bb70b0 100644 --- a/docs/run-arbitrum-node/01-overview.mdx +++ b/docs/run-arbitrum-node/01-overview.mdx @@ -64,7 +64,7 @@ If you are running a single node, there is no requirement to set up a feed relay Soon, feed endpoints will mandate compression using a custom dictionary. Therefore, if you plan to connect to a feed using anything other than a standard node, it is strongly advised to run a local feed relay. This local feed relay will ensure that you have access to an uncompressed feed by default, maintaining optimal performance and compatibility. -For detailed instructions, read [how to run an Arbitrum feed relay](/run-arbitrum-node/run-feed-relay.mdx). +For detailed instructions, read [how to run an Arbitrum feed relay](/run-arbitrum-node/data-availability/run-feed-relay.mdx). ## Support policy diff --git a/docs/run-arbitrum-node/02-run-full-node.mdx b/docs/run-arbitrum-node/02-run-full-node.mdx index 359b738855..b9ec9e176c 100644 --- a/docs/run-arbitrum-node/02-run-full-node.mdx +++ b/docs/run-arbitrum-node/02-run-full-node.mdx @@ -61,7 +61,7 @@ A default full node is unaffected: it runs the watchtower strategy, which does n :::warning Caution -If you are running more than one node, you should [run a feed relay](/run-arbitrum-node/run-feed-relay.mdx). +If you are running more than one node, you should [run a feed relay](/run-arbitrum-node/data-availability/run-feed-relay.mdx). ::: diff --git a/docs/run-arbitrum-node/04-l1-ethereum-beacon-chain-rpc-providers.mdx b/docs/run-arbitrum-node/04-l1-ethereum-beacon-chain-rpc-providers.mdx index f6a111a004..b14a234d5b 100644 --- a/docs/run-arbitrum-node/04-l1-ethereum-beacon-chain-rpc-providers.mdx +++ b/docs/run-arbitrum-node/04-l1-ethereum-beacon-chain-rpc-providers.mdx @@ -11,7 +11,7 @@ Following [Ethereum's Dencun upgrade in March 2024](https://eips.ethereum.org/EI To run a node for an Arbitrum child chain (i.e., Arbitrum One, Arbitrum Nova, and L3 Arbitrum chains), your node will need access to blob data to sync up to the latest state of your Arbitrum child chain. Blob data on Ethereum is stored on the beacon chain and is inaccessible to the EVM, hence why dedicated RPC endpoints for the beacon chain will be required after the Dencun upgrade. You can find more details on node requirements in the [Run a full node guide](/run-arbitrum-node/02-run-full-node.mdx). -Furthermore, new node operators joining a network or node operators who come online following an extended period of offline time will require access to _historical_ blob data to sync up to the latest state of their Arbitrum chain. If you run your own beacon node, see [Beacon nodes: historical blobs](/run-arbitrum-node/beacon-nodes-historical-blobs.mdx) for the client flags needed to retain and serve historical blob data through the Fusaka upgrade. +Furthermore, new node operators joining a network or node operators who come online following an extended period of offline time will require access to _historical_ blob data to sync up to the latest state of their Arbitrum chain. If you run your own beacon node, see [Beacon nodes: historical blobs](/run-arbitrum-node/data-availability/beacon-nodes-historical-blobs.mdx) for the client flags needed to retain and serve historical blob data through the Fusaka upgrade. ## List of Ethereum beacon chain RPC providers diff --git a/docs/run-arbitrum-node/assign-node-roles.mdx b/docs/run-arbitrum-node/assign-node-roles.mdx index 79d5a8c4c7..c57bb74e7e 100644 --- a/docs/run-arbitrum-node/assign-node-roles.mdx +++ b/docs/run-arbitrum-node/assign-node-roles.mdx @@ -28,7 +28,7 @@ Roles can combine on a single node (a sequencer can also post batches, for examp | Batch poster | `--node.batch-poster.enable` | Funded parent-chain wallet; no bond | One active (Redis lock coordinates a set) | [Run a batch poster](/launch-arbitrum-chain/run-a-node/batch-poster.mdx) | | Validator (staker) | `--node.staker.strategy` set to an active value | Funded wallet and bond for active strategies only | One active per wallet | [Run a validator](/run-arbitrum-node/more-types/02-run-validator-node.mdx) | | Validation server (split validation) | `nitro-val` binary + `--node.block-validator.validation-server.url` on the node | No wallet, no bond (all onchain action stays on the node) | Many (one node can use several) | [Run a split validator node](/launch-arbitrum-chain/run-a-node/split-validator-node.mdx) | -| Feed relay | `relay` binary + `--node.feed.input.url` + `--chain.id` | No wallet, no bond, no parent-chain connection | Many (stateless fan-out) | [Run a feed relay](/run-arbitrum-node/run-feed-relay.mdx) | +| Feed relay | `relay` binary + `--node.feed.input.url` + `--chain.id` | No wallet, no bond, no parent-chain connection | Many (stateless fan-out) | [Run a feed relay](/run-arbitrum-node/data-availability/run-feed-relay.mdx) | Every role except the feed relay and the split-validation server needs a parent-chain connection through `--parent-chain.connection.url`. Nodes whose parent chain is Ethereum L1 also need `--parent-chain.blob-client.beacon-url` to read batches posted as EIP-4844 blobs. For well-known chains, setting `--chain.id` or `--chain.name` auto-fills defaults such as `--execution.forwarding-target` and `--node.feed.input.url` from the chain info embedded in the binary (the forwarding target is only auto-filled when the sequencer is disabled). @@ -185,7 +185,7 @@ The feed relay is not a mode of the `nitro` binary. It is a separate `relay` bin Downstream nodes then point their own `--node.feed.input.url` at the relay. You can run as many relays as you like: each one independently subscribes upstream and serves its downstream clients, and relays can even be chained. A node connected to multiple feeds or relays deduplicates messages by sequence number, so redundant feed sources are safe. -For setup, Docker commands, and Kubernetes charts, see [How to run a feed relay](/run-arbitrum-node/run-feed-relay.mdx). +For setup, Docker commands, and Kubernetes charts, see [How to run a feed relay](/run-arbitrum-node/data-availability/run-feed-relay.mdx). ## Converting between roles diff --git a/docs/run-arbitrum-node/data-availability.mdx b/docs/run-arbitrum-node/data-availability.mdx index 253d3472dc..a611528aa7 100644 --- a/docs/run-arbitrum-node/data-availability.mdx +++ b/docs/run-arbitrum-node/data-availability.mdx @@ -97,7 +97,7 @@ Arbitrum full nodes decode data received from the parent chain (and, in the case Once Arbitrum full nodes have caught up with the chain, they switch from initial synchronization to a real-time update mode. This switch involves receiving data from the sequencer feed, which continuously broadcasts updates about newly queued transactions. 1. Data acquisition: - 1. Full nodes maintain a connection to the sequencer feed or your private feed. For how to run a private feed, please refer to [**How to run a feed relay**](/run-arbitrum-node/run-feed-relay.mdx) + 1. Full nodes maintain a connection to the sequencer feed or your private feed. For how to run a private feed, please refer to [**How to run a feed relay**](/run-arbitrum-node/data-availability/run-feed-relay.mdx) 2. The sequencer feed transmits data packets containing information about the latest queued transactions. 2. Data decoding: 1. Full nodes decode the received data packets using the methods described in [How to read the sequencer feed](/run-arbitrum-node/sequencer/02-read-sequencer-feed.mdx). diff --git a/docs/run-arbitrum-node/beacon-nodes-historical-blobs.mdx b/docs/run-arbitrum-node/data-availability/beacon-nodes-historical-blobs.mdx similarity index 98% rename from docs/run-arbitrum-node/beacon-nodes-historical-blobs.mdx rename to docs/run-arbitrum-node/data-availability/beacon-nodes-historical-blobs.mdx index e0c4355a9d..3b2129f2b5 100644 --- a/docs/run-arbitrum-node/beacon-nodes-historical-blobs.mdx +++ b/docs/run-arbitrum-node/data-availability/beacon-nodes-historical-blobs.mdx @@ -61,7 +61,7 @@ Currently, the following clients are supported for Sepolia only. -import ClientFlagsTable from '../partials/_client-flags.mdx'; +import ClientFlagsTable from '../../partials/_client-flags.mdx'; diff --git a/docs/run-arbitrum-node/run-feed-relay.mdx b/docs/run-arbitrum-node/data-availability/run-feed-relay.mdx similarity index 100% rename from docs/run-arbitrum-node/run-feed-relay.mdx rename to docs/run-arbitrum-node/data-availability/run-feed-relay.mdx diff --git a/docs/run-arbitrum-node/partials/run-full-node/_optional-orbit-sequencer-compatible-cli-partial.mdx b/docs/run-arbitrum-node/partials/run-full-node/_optional-orbit-sequencer-compatible-cli-partial.mdx index 7684c02cef..79c66ab4dc 100644 --- a/docs/run-arbitrum-node/partials/run-full-node/_optional-orbit-sequencer-compatible-cli-partial.mdx +++ b/docs/run-arbitrum-node/partials/run-full-node/_optional-orbit-sequencer-compatible-cli-partial.mdx @@ -9,7 +9,7 @@ | `--http.vhosts` | Accepts requests from these comma-separated virtual hostnames (server enforced). Default: `localhost`. Accepts `*`. | | `--http.addr` | Address to bind RPC to. May require `0.0.0.0` for Docker networking. | | `--execution.caching.archive` | Will retain past block state. **For archive nodes**. | -| `--node.feed.input.url=` | Default: `wss://.arbitrum.io/feed`. ⚠️ One feed relay per datacenter is advised. See [feed relay guide](/run-arbitrum-node/run-feed-relay.mdx). | +| `--node.feed.input.url=` | Default: `wss://.arbitrum.io/feed`. ⚠️ One feed relay per datacenter is advised. See [feed relay guide](/run-arbitrum-node/data-availability/run-feed-relay.mdx). | | `--execution.rpc.evm-timeout` | Default: `5s`. Timeout for `eth_call`. (`0` == no timeout). | | `--execution.rpc.gas-cap` | Default: `50000000`. Gas cap for `eth_call`/`estimateGas`. (`0` = no cap). | | `--execution.rpc.tx-fee-cap` | Default: `1`. Transaction fee cap (in **ETH**) for RPC APIs. (`0` = no cap). | diff --git a/docs/run-arbitrum-node/partials/run-full-node/_optional-parameters.mdx b/docs/run-arbitrum-node/partials/run-full-node/_optional-parameters.mdx index 4624807202..72285a4c40 100644 --- a/docs/run-arbitrum-node/partials/run-full-node/_optional-parameters.mdx +++ b/docs/run-arbitrum-node/partials/run-full-node/_optional-parameters.mdx @@ -10,7 +10,7 @@ | `--execution.caching.state-scheme` | Default: `hash`. Sets the scheme Nitro uses to store its state trie, inherited from Geth. Set it to `path` to enable PathDB, which prunes automatically while the node keeps running. PathDB cannot validate blocks, and `--init.latest` cannot download its snapshots — use `--init.url`. See [Choose a state scheme](/run-arbitrum-node/02-run-full-node.mdx#choose-a-state-scheme). | | `--execution.caching.state-history` | PathDB only. Number of recent blocks of state history to retain on disk. Set to `0` to retain the entire chain. When unset, Nitro defaults to 345,600 blocks (24 hours at the default @@l2BlockTimeMs=250@@ ms block speed) on a full node, or `0` on an archive node. | | `--execution.caching.pathdb-max-diff-layers` | Default: 128 layers. Maximum number of diff layers kept in the node's memory before flushing to disk. Increasing the number of diff layers may cause the node to fall behind the chain head during busy periods since doing so slows down block processing speed and reduces sync speed. This configuration is primarily used to improve performance of shallow re-orgs (which are a concern on Ethereum but not on Arbitrum chains) and for efficient access to recent state. | -| `--node.feed.input.url=` | Sets the sequencer feed address to this URL. Default: `wss://.arbitrum.io/feed`. ⚠️ One feed relay per datacenter is advised. See [feed relay guide](/run-arbitrum-node/run-feed-relay.mdx). | +| `--node.feed.input.url=` | Sets the sequencer feed address to this URL. Default: `wss://.arbitrum.io/feed`. ⚠️ One feed relay per datacenter is advised. See [feed relay guide](/run-arbitrum-node/data-availability/run-feed-relay.mdx). | | `--execution.forwarding-target=` | Sets the sequencer endpoint to forward requests to. | | `--execution.rpc.evm-timeout` | Default: `5s`. Timeout for `eth_call`. (0 == no timeout). | | `--execution.rpc.gas-cap` | Default: `50000000`. Gas cap for `eth_call`/`estimateGas`. (0 = no cap). | diff --git a/docs/run-arbitrum-node/sequencer/02-read-sequencer-feed.mdx b/docs/run-arbitrum-node/sequencer/02-read-sequencer-feed.mdx index ff9ffcd5d4..5212967fb3 100644 --- a/docs/run-arbitrum-node/sequencer/02-read-sequencer-feed.mdx +++ b/docs/run-arbitrum-node/sequencer/02-read-sequencer-feed.mdx @@ -11,7 +11,7 @@ todos: - Align on what we want to treat as proper nouns vs common nouns --- -[Running an Arbitrum relay locally as a feed relay](/run-arbitrum-node/run-feed-relay.mdx) lets you subscribe to an uncompressed sequencer feed for real-time data as the sequencer accepts and orders transactions offchain. +[Running an Arbitrum relay locally as a feed relay](/run-arbitrum-node/data-availability/run-feed-relay.mdx) lets you subscribe to an uncompressed sequencer feed for real-time data as the sequencer accepts and orders transactions offchain. When connected to websocket port `9642` of the local relay, you'll receive a data feed that looks something like this: diff --git a/docs/run-arbitrum-node/start-here.mdx b/docs/run-arbitrum-node/start-here.mdx index 28d87859cc..7570ae2b62 100644 --- a/docs/run-arbitrum-node/start-here.mdx +++ b/docs/run-arbitrum-node/start-here.mdx @@ -97,7 +97,7 @@ For more details on snapshot downloading and initialization, see the [complete s :::warning Fusaka upgrade: historical blobs -If you're running a beacon node, historical data will now be in blobs. To make this transition to using historical blobs, refer to the [Historical Blobs for Beacon Nodes](/run-arbitrum-node/beacon-nodes-historical-blobs.mdx) guide. +If you're running a beacon node, historical data will now be in blobs. To make this transition to using historical blobs, refer to the [Historical Blobs for Beacon Nodes](/run-arbitrum-node/data-availability/beacon-nodes-historical-blobs.mdx) guide. ::: diff --git a/redirects.config.js b/redirects.config.js index 9edd3b99fc..8f754605f1 100644 --- a/redirects.config.js +++ b/redirects.config.js @@ -423,5 +423,13 @@ export const redirects = [ from: '/launch-arbitrum-chain/chain-config/validation/compliance-filtering', to: '/launch-arbitrum-chain/chain-config/sequencer/compliance-filtering', }, + { + from: '/run-arbitrum-node/run-feed-relay', + to: '/run-arbitrum-node/data-availability/run-feed-relay', + }, + { + from: '/run-arbitrum-node/beacon-nodes-historical-blobs', + to: '/run-arbitrum-node/data-availability/beacon-nodes-historical-blobs', + }, // AUTO-GENERATED REDIRECTS END ]; diff --git a/sidebars.js b/sidebars.js index 7565510322..a5e756459a 100644 --- a/sidebars.js +++ b/sidebars.js @@ -753,12 +753,12 @@ const sidebars = { }, { type: 'doc', - id: 'run-arbitrum-node/run-feed-relay', + id: 'run-arbitrum-node/data-availability/run-feed-relay', label: 'Run a feed relay', }, { type: 'doc', - id: 'run-arbitrum-node/beacon-nodes-historical-blobs', + id: 'run-arbitrum-node/data-availability/beacon-nodes-historical-blobs', label: 'Historical blobs', }, { diff --git a/vercel.json b/vercel.json index ed6d749c8f..0203181d7a 100644 --- a/vercel.json +++ b/vercel.json @@ -536,6 +536,16 @@ "destination": "/launch-arbitrum-chain/chain-config/sequencer/compliance-filtering", "permanent": false }, + { + "source": "/run-arbitrum-node/run-feed-relay", + "destination": "/run-arbitrum-node/data-availability/run-feed-relay", + "permanent": false + }, + { + "source": "/run-arbitrum-node/beacon-nodes-historical-blobs", + "destination": "/run-arbitrum-node/data-availability/beacon-nodes-historical-blobs", + "permanent": false + }, { "source": "/__redirects-autogen-end__", "destination": "/", "permanent": false }, { "source": "/(anytrust/?)", From 5ac14d2fc21a42275cd1e6c2cccf8f96a800a5b9 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 8 Sep 2026 13:39:36 -0500 Subject: [PATCH 2/9] Moving cli-flags-reference, configuration-system, da-tools-reference, l1-ethereum-beacon-chain-rpc-providers, and nitro-database-snapshots to run-arbitrum-node/reference --- .../sequencer/sequencer-config-reference.mdx | 2 +- .../sequencer-timing-adjustments.mdx | 2 +- .../operate/upgrade-runbook.mdx | 2 +- .../operate/validator-troubleshooting.mdx | 2 +- .../overview/introduction.mdx | 2 +- .../run-a-node/run-full-node-with-helm.mdx | 4 +-- docs/run-arbitrum-node/02-run-full-node.mdx | 2 +- docs/run-arbitrum-node/06-troubleshooting.mdx | 2 +- .../arbos-releases/arbos20.mdx | 4 +-- docs/run-arbitrum-node/assign-node-roles.mdx | 2 +- .../beacon-nodes-historical-blobs.mdx | 2 +- .../run-full-node/_dao-chains-parameters.mdx | 2 +- .../run-full-node/_optional-parameters.mdx | 2 +- .../_orbit-chains-parameters.mdx | 2 +- .../cli-flags-reference.mdx | 30 +++++++++---------- .../configuration-system.mdx | 0 .../da-tools-reference.mdx | 0 ...1-ethereum-beacon-chain-rpc-providers.mdx} | 0 .../nitro-database-snapshots.mdx} | 0 docs/run-arbitrum-node/start-here.mdx | 8 ++--- redirects.config.js | 20 +++++++++++++ sidebars.js | 10 +++---- vercel.json | 25 ++++++++++++++++ 23 files changed, 85 insertions(+), 40 deletions(-) rename docs/run-arbitrum-node/{nitro => reference}/cli-flags-reference.mdx (99%) rename docs/run-arbitrum-node/{nitro => reference}/configuration-system.mdx (100%) rename docs/run-arbitrum-node/{nitro => reference}/da-tools-reference.mdx (100%) rename docs/run-arbitrum-node/{04-l1-ethereum-beacon-chain-rpc-providers.mdx => reference/l1-ethereum-beacon-chain-rpc-providers.mdx} (100%) rename docs/run-arbitrum-node/{nitro/03-nitro-database-snapshots.mdx => reference/nitro-database-snapshots.mdx} (100%) diff --git a/docs/launch-arbitrum-chain/chain-config/sequencer/sequencer-config-reference.mdx b/docs/launch-arbitrum-chain/chain-config/sequencer/sequencer-config-reference.mdx index 98b5e81154..c83d27c988 100644 --- a/docs/launch-arbitrum-chain/chain-config/sequencer/sequencer-config-reference.mdx +++ b/docs/launch-arbitrum-chain/chain-config/sequencer/sequencer-config-reference.mdx @@ -8,7 +8,7 @@ user_story: As an Arbitrum chain operator, I need to understand what each sequen content_type: reference --- -This page explains what the operational sequencer flags do and what changes when you set them. For the complete list of every Nitro flag, see the [CLI flags reference](/run-arbitrum-node/nitro/cli-flags-reference.mdx). For failure diagnosis, see [Sequencer troubleshooting](/launch-arbitrum-chain/operate/sequencer-troubleshooting.mdx). +This page explains what the operational sequencer flags do and what changes when you set them. For the complete list of every Nitro flag, see the [CLI flags reference](/run-arbitrum-node/reference/cli-flags-reference.mdx). For failure diagnosis, see [Sequencer troubleshooting](/launch-arbitrum-chain/operate/sequencer-troubleshooting.mdx). All flags take the prefix `--execution.sequencer.` or `--node.seq-coordinator.` as shown. diff --git a/docs/launch-arbitrum-chain/chain-config/sequencer/sequencer-timing-adjustments.mdx b/docs/launch-arbitrum-chain/chain-config/sequencer/sequencer-timing-adjustments.mdx index 683ab2ae66..f05a0a713c 100644 --- a/docs/launch-arbitrum-chain/chain-config/sequencer/sequencer-timing-adjustments.mdx +++ b/docs/launch-arbitrum-chain/chain-config/sequencer/sequencer-timing-adjustments.mdx @@ -163,7 +163,7 @@ With `reorg-resistance-margin=0`, a parent-chain reorg — or simply a batch lan -Note the interaction with `maxTimeVariation`: a wider past window (`delayBlocks` and `delaySeconds`) gives the batch poster more room before the margin is threatened, while a narrower window makes the margin bite sooner. See the [CLI flags reference](/run-arbitrum-node/nitro/cli-flags-reference.mdx) for the full batch-poster flag set. +Note the interaction with `maxTimeVariation`: a wider past window (`delayBlocks` and `delaySeconds`) gives the batch poster more room before the margin is threatened, while a narrower window makes the margin bite sooner. See the [CLI flags reference](/run-arbitrum-node/reference/cli-flags-reference.mdx) for the full batch-poster flag set. ## Changing `maxTimeVariation` diff --git a/docs/launch-arbitrum-chain/operate/upgrade-runbook.mdx b/docs/launch-arbitrum-chain/operate/upgrade-runbook.mdx index c948c97008..7f2f89679a 100644 --- a/docs/launch-arbitrum-chain/operate/upgrade-runbook.mdx +++ b/docs/launch-arbitrum-chain/operate/upgrade-runbook.mdx @@ -323,4 +323,4 @@ Rolling `nitro-contracts` back is only remotely viable if no assertions have bee - [Monitoring tools and considerations](/launch-arbitrum-chain/operate/monitoring.mdx)—what to watch during and after an upgrade - [Batch poster troubleshooting](/launch-arbitrum-chain/operate/batch-poster-troubleshooting.mdx)—diagnosing batch poster errors - [Customize your chain's behavior](/launch-arbitrum-chain/extend-the-protocol/stf.mdx)—building a custom STF and its replay binary -- [Nitro CLI flags reference](/run-arbitrum-node/nitro/cli-flags-reference.mdx)—reference for the Nitro configuration flags named here (`dangerous` flags are not listed) +- [Nitro CLI flags reference](/run-arbitrum-node/reference/cli-flags-reference.mdx)—reference for the Nitro configuration flags named here (`dangerous` flags are not listed) diff --git a/docs/launch-arbitrum-chain/operate/validator-troubleshooting.mdx b/docs/launch-arbitrum-chain/operate/validator-troubleshooting.mdx index ae79d2a0d4..3bd3b6aabf 100644 --- a/docs/launch-arbitrum-chain/operate/validator-troubleshooting.mdx +++ b/docs/launch-arbitrum-chain/operate/validator-troubleshooting.mdx @@ -52,7 +52,7 @@ Two rules to check when tuning these: - **The posting interval must exceed the Rollup contract's `minimumAssertionPeriod`.** That is an onchain constraint measured in parent-chain blocks (`block.number` units — on an Arbitrum parent these track the underlying L1 block number, not the Arbitrum block height). The validator checks it before posting and waits until enough blocks have passed, so a shorter posting interval silently caps you at the onchain floor rather than causing reverted transactions. Read `minimumAssertionPeriod` from your Rollup contract rather than assuming the default. - **Do not tune the confirming interval to make confirmations happen sooner.** Confirmation timing is governed onchain by `confirmPeriodBlocks` and, where a challenge occurred, `challengeGracePeriodBlocks`. Lowering `--node.bold.assertion-confirming-interval` only increases how often the validator checks, which adds parent-chain RPC load without advancing anything. -For the full flag list, see the [Nitro CLI flags reference](/run-arbitrum-node/nitro/cli-flags-reference.mdx). For the onchain parameters, see the parameter table in [BoLD for Arbitrum chains](/launch-arbitrum-chain/chain-config/validation/bold.mdx#table-of-arbitrum-bold-parameters). +For the full flag list, see the [Nitro CLI flags reference](/run-arbitrum-node/reference/cli-flags-reference.mdx). For the onchain parameters, see the parameter table in [BoLD for Arbitrum chains](/launch-arbitrum-chain/chain-config/validation/bold.mdx#table-of-arbitrum-bold-parameters). ## Parent-chain read consistency diff --git a/docs/launch-arbitrum-chain/overview/introduction.mdx b/docs/launch-arbitrum-chain/overview/introduction.mdx index 7604646def..634d70f709 100644 --- a/docs/launch-arbitrum-chain/overview/introduction.mdx +++ b/docs/launch-arbitrum-chain/overview/introduction.mdx @@ -288,7 +288,7 @@ Protocol-level transaction filtering added to the List of Ethereum beacon chain RPC providers + This often happens when you connect to a beacon chain endpoint while the blob you are querying is expired. To resolve this error, connect to a beacon endpoint that supports historical blob data (see List of Ethereum beacon chain RPC providers ). diff --git a/docs/run-arbitrum-node/arbos-releases/arbos20.mdx b/docs/run-arbitrum-node/arbos-releases/arbos20.mdx index ab0fbffd63..e068dafc39 100644 --- a/docs/run-arbitrum-node/arbos-releases/arbos20.mdx +++ b/docs/run-arbitrum-node/arbos-releases/arbos20.mdx @@ -16,7 +16,7 @@ For an index of all ArbOS releases and upgrade expectations, see the [ArbOS Soft - [Nitro v2.3.1](https://github.com/OffchainLabs/nitro/releases/tag/v2.3.1) or higher - [nitro-contracts v1.2.1](https://github.com/OffchainLabs/nitro-contracts/releases/tag/v1.2.1) or higher - Wasm module root: `0x8b104a2e80ac6165dc58b9048de12f301d70b02a0ab51396c22b4b4b802a16a4` -- Access to the [Ethereum Beacon Chain APIs](https://ethereum.github.io/beacon-APIs/#/), either from your own self-managed parent chain Ethereum node or from a 3rd party provider like [those on this list](/run-arbitrum-node/04-l1-ethereum-beacon-chain-rpc-providers.mdx). +- Access to the [Ethereum Beacon Chain APIs](https://ethereum.github.io/beacon-APIs/#/), either from your own self-managed parent chain Ethereum node or from a 3rd party provider like [those on this list](/run-arbitrum-node/reference/l1-ethereum-beacon-chain-rpc-providers.mdx). ## High-level description of ArbOS 20 changes @@ -32,7 +32,7 @@ ArbOS 20 is an upgrade to enable Arbitrum's support for the parent chain Ethereu ## Special notes on ArbOS 20: Atlas support for EIP-4844 -- Upgrading to **the Atlas ArbOS release will require access to the parent chain's Ethereum beacon chain endpoints to retrieve blob data. For nodes of a chain that come online 18 days after Atlas gets activated on their chain will need access to historical data to sync up to the latest state.** If you are not operating your own Ethereum consensus client, [please visit this page to view a list of beacon chain RPC providers](/run-arbitrum-node/04-l1-ethereum-beacon-chain-rpc-providers.mdx) where you can access blob data. +- Upgrading to **the Atlas ArbOS release will require access to the parent chain's Ethereum beacon chain endpoints to retrieve blob data. For nodes of a chain that come online 18 days after Atlas gets activated on their chain will need access to historical data to sync up to the latest state.** If you are not operating your own Ethereum consensus client, [please visit this page to view a list of beacon chain RPC providers](/run-arbitrum-node/reference/l1-ethereum-beacon-chain-rpc-providers.mdx) where you can access blob data. - Applications on Arbitrum will not have to be modified or take any explicit action to get the benefits of using EIP-4844 (i.e., the whole chain opts-in with ArbOS 20 “Atlas”). - ArbOS 20 “Atlas” adds support for Arbitrum chains to send data in a blob storage format to data availability layers, like the parent chain Ethereum, that support the blob transaction type. This includes Arbitrum One and Arbitrum Nova. ArbOS 20 “Atlas” does not add support for Arbitrum chains to receive data in a blob storage format. This means that an L3 Arbitrum chain on top of an Arbitrum L2 will use calldata when posting L3 transaction data to the underlying L2. The child chain (L2) Arbitrum chain will then be able to post data to a parent chain data availability layer like Ethereum using blobs. - There currently aren’t estimates on what the end-user gas savings of using blob data will be. This topic is something being actively worked on and monitored. Without Mainnet data, the estimates for blob gas prices will not be accurate enough to reliably predict the cost reductions that users will experience—and even with Mainnet data, the savings will vary by use case (i.e., no current way to predict the price impacts from all blob gas market participants yet). In general, however, the use of blobs will reduce the cost of using Arbitrum L2s. To learn more about what EIP-4844 will mean for the child chain users, please checkout this [blog post on Medium by Offchain Lab's Co-foudner and Chief Scientist Ed Felten](https://medium.com/offchainlabs/eip-4844-what-does-it-mean-for-l2-users-5e86ebc4c028). diff --git a/docs/run-arbitrum-node/assign-node-roles.mdx b/docs/run-arbitrum-node/assign-node-roles.mdx index c57bb74e7e..fd793976b6 100644 --- a/docs/run-arbitrum-node/assign-node-roles.mdx +++ b/docs/run-arbitrum-node/assign-node-roles.mdx @@ -14,7 +14,7 @@ Because roles are just configuration, you assign or change a role by editing fla If you already know which role you want, go straight to its guide—each one is linked from the table below. Read this page when you're deciding which role to run, want to see how the roles relate to each other, or need to convert an existing node from one role to another. -Flags can be passed on the command line or collected in a JSON configuration file loaded with `--conf.file`. For how flag names, defaults, and the config file relate to each other, see [Nitro configuration system](/run-arbitrum-node/nitro/configuration-system.mdx). This article covers only the flags that define and support each role; for the complete flag list, see the [CLI flags reference](/run-arbitrum-node/nitro/cli-flags-reference.mdx). +Flags can be passed on the command line or collected in a JSON configuration file loaded with `--conf.file`. For how flag names, defaults, and the config file relate to each other, see [Nitro configuration system](/run-arbitrum-node/reference/configuration-system.mdx). This article covers only the flags that define and support each role; for the complete flag list, see the [CLI flags reference](/run-arbitrum-node/reference/cli-flags-reference.mdx). Roles can combine on a single node (a sequencer can also post batches, for example), but this article describes them separately so that each role's requirements are clear. diff --git a/docs/run-arbitrum-node/data-availability/beacon-nodes-historical-blobs.mdx b/docs/run-arbitrum-node/data-availability/beacon-nodes-historical-blobs.mdx index 3b2129f2b5..96b99a5549 100644 --- a/docs/run-arbitrum-node/data-availability/beacon-nodes-historical-blobs.mdx +++ b/docs/run-arbitrum-node/data-availability/beacon-nodes-historical-blobs.mdx @@ -9,7 +9,7 @@ content_type: how-to Layer 2 network operators must connect to an Ethereum beacon chain node with historical blob data to ensure proper functioning of the Nitro node software, or risk failure in fetching blob data. -If you don't run your own beacon node, see [Ethereum beacon chain RPC providers](/run-arbitrum-node/04-l1-ethereum-beacon-chain-rpc-providers.mdx) for a curated list of third-party providers and their historical-blob support status. +If you don't run your own beacon node, see [Ethereum beacon chain RPC providers](/run-arbitrum-node/reference/l1-ethereum-beacon-chain-rpc-providers.mdx) for a curated list of third-party providers and their historical-blob support status. ## Impacted audiences diff --git a/docs/run-arbitrum-node/partials/run-full-node/_dao-chains-parameters.mdx b/docs/run-arbitrum-node/partials/run-full-node/_dao-chains-parameters.mdx index 03540ac1b6..e4f860edb8 100644 --- a/docs/run-arbitrum-node/partials/run-full-node/_dao-chains-parameters.mdx +++ b/docs/run-arbitrum-node/partials/run-full-node/_dao-chains-parameters.mdx @@ -22,7 +22,7 @@ If you choose to self-host an EVM node, the [Prysm client software](https://www. ::: -You can also consult our [list of Ethereum beacon chain RPC providers](/run-arbitrum-node/04-l1-ethereum-beacon-chain-rpc-providers.mdx). Note that historical blob data is required for these chains to properly sync up if they are new or have been offline for more than 18 days. The beacon chain RPC endpoint you use may also need to provide historical blob data. Please see [Special notes on ArbOS 20: Atlas support for EIP-4844](/run-arbitrum-node/arbos-releases/arbos20.mdx#special-notes-on-arbos-20-atlas-support-for-eip-4844) for more details. +You can also consult our [list of Ethereum beacon chain RPC providers](/run-arbitrum-node/reference/l1-ethereum-beacon-chain-rpc-providers.mdx). Note that historical blob data is required for these chains to properly sync up if they are new or have been offline for more than 18 days. The beacon chain RPC endpoint you use may also need to provide historical blob data. Please see [Special notes on ArbOS 20: Atlas support for EIP-4844](/run-arbitrum-node/arbos-releases/arbos20.mdx#special-notes-on-arbos-20-atlas-support-for-eip-4844) for more details. #### 2. Arbitrum chain parameters diff --git a/docs/run-arbitrum-node/partials/run-full-node/_optional-parameters.mdx b/docs/run-arbitrum-node/partials/run-full-node/_optional-parameters.mdx index 72285a4c40..7929a5e50c 100644 --- a/docs/run-arbitrum-node/partials/run-full-node/_optional-parameters.mdx +++ b/docs/run-arbitrum-node/partials/run-full-node/_optional-parameters.mdx @@ -20,7 +20,7 @@ | `--node.resource-mgmt.mem-free-limit` | Declines incoming RPC requests when free system memory (excluding page cache) drops below this threshold. Accepts values with suffixes like `4GiB`, `512MiB`. Helps prevent OOM crashes under heavy load. | | `--ipc.path` | Filename for IPC socket/pipe within datadir. 🔉 Not supported on macOS. The path is within the Docker container. | | `--init.prune` | Prunes the database before starting the node. Can be "full" or "validator". | -| `--init.url=""` | (Required for Arbitrum One) URL to download the genesis database from. Only required for Arbitrum One nodes, when running them for the first time. See the [Nitro database snapshots guide](/run-arbitrum-node/nitro/03-nitro-database-snapshots.mdx) for more information. | +| `--init.url=""` | (Required for Arbitrum One) URL to download the genesis database from. Only required for Arbitrum One nodes, when running them for the first time. See the [Nitro database snapshots guide](/run-arbitrum-node/reference/nitro-database-snapshots.mdx) for more information. | | `--init.download-path="/path/to/dir"` | Temporarily saves the downloaded database snapshot. Defaults to `/tmp/`. Used with `--init.url`. | | `--init.latest` | Searches for the latest snapshot of the given kind (accepted values: `archive`, `pruned`, `genesis`) | | `--init.latest-base` | Base URL used when searching for the latest snapshot. Example value used for Arb1: `https://snapshot.arbitrum.foundation/`. Different chains will have different Base URLs, but only if they provide snapshots. Talk to chain owner for value to use. | diff --git a/docs/run-arbitrum-node/partials/run-full-node/_orbit-chains-parameters.mdx b/docs/run-arbitrum-node/partials/run-full-node/_orbit-chains-parameters.mdx index 957446badd..8d2d66de1e 100644 --- a/docs/run-arbitrum-node/partials/run-full-node/_orbit-chains-parameters.mdx +++ b/docs/run-arbitrum-node/partials/run-full-node/_orbit-chains-parameters.mdx @@ -28,7 +28,7 @@ Additionally, if the chain is a Layer-2 (L2) chain on top of Ethereum and uses < ::: -You can find beacon providers in our [list of Ethereum beacon chain RPC providers](/run-arbitrum-node/04-l1-ethereum-beacon-chain-rpc-providers.mdx). Note that historical blob data is required for these chains to properly sync up if they are new or have been offline for more than 18 days. This means that the beacon chain RPC endpoint you use may also need to provide historical blob data. Please see [Special notes on ArbOS 20: Atlas support for EIP-4844](/run-arbitrum-node/arbos-releases/arbos20.mdx#special-notes-on-arbos-20-atlas-support-for-eip-4844) for more details. +You can find beacon providers in our [list of Ethereum beacon chain RPC providers](/run-arbitrum-node/reference/l1-ethereum-beacon-chain-rpc-providers.mdx). Note that historical blob data is required for these chains to properly sync up if they are new or have been offline for more than 18 days. This means that the beacon chain RPC endpoint you use may also need to provide historical blob data. Please see [Special notes on ArbOS 20: Atlas support for EIP-4844](/run-arbitrum-node/arbos-releases/arbos20.mdx#special-notes-on-arbos-20-atlas-support-for-eip-4844) for more details. #### 2. Child chain parameters diff --git a/docs/run-arbitrum-node/nitro/cli-flags-reference.mdx b/docs/run-arbitrum-node/reference/cli-flags-reference.mdx similarity index 99% rename from docs/run-arbitrum-node/nitro/cli-flags-reference.mdx rename to docs/run-arbitrum-node/reference/cli-flags-reference.mdx index 459094cbcd..a5c63524b9 100644 --- a/docs/run-arbitrum-node/nitro/cli-flags-reference.mdx +++ b/docs/run-arbitrum-node/reference/cli-flags-reference.mdx @@ -18,10 +18,10 @@ import { VanillaAdmonition } from '@site/src/components/VanillaAdmonition/'; This page lists every CLI flag accepted by the Nitro node binary. For explanations, examples, and recommended configurations, see the curated guides: -- [Configuration system](/run-arbitrum-node/nitro/configuration-system) +- [Configuration system](/run-arbitrum-node/reference/configuration-system) - [Docker and CLI binaries](/run-arbitrum-node/nitro/docker-and-cli-binaries) - [Node tuning and monitoring](/run-arbitrum-node/nitro/node-tuning-and-monitoring) -- [DA tools reference](/run-arbitrum-node/nitro/da-tools-reference) +- [DA tools reference](/run-arbitrum-node/reference/da-tools-reference) **Total flags:** 724 across 23 namespaces. @@ -41,7 +41,7 @@ nitro --conf.file=/path/to/config.json ## auth -Related guide: [Configuration system](/run-arbitrum-node/nitro/configuration-system) +Related guide: [Configuration system](/run-arbitrum-node/reference/configuration-system)
auth flags (5) @@ -58,7 +58,7 @@ Related guide: [Configuration system](/run-arbitrum-node/nitro/configuration-sys ## chain -Related guide: [Configuration system](/run-arbitrum-node/nitro/configuration-system) +Related guide: [Configuration system](/run-arbitrum-node/reference/configuration-system)
chain flags (9) @@ -79,7 +79,7 @@ Related guide: [Configuration system](/run-arbitrum-node/nitro/configuration-sys ## conf -Related guide: [Configuration system](/run-arbitrum-node/nitro/configuration-system) +Related guide: [Configuration system](/run-arbitrum-node/reference/configuration-system)
conf flags (9) @@ -100,7 +100,7 @@ Related guide: [Configuration system](/run-arbitrum-node/nitro/configuration-sys ## ensure-rollup-deployment -Related guide: [Configuration system](/run-arbitrum-node/nitro/configuration-system) +Related guide: [Configuration system](/run-arbitrum-node/reference/configuration-system)
ensure-rollup-deployment flags (1) @@ -309,7 +309,7 @@ Related guide: [Node tuning and monitoring](/run-arbitrum-node/nitro/node-tuning ## graphql -Related guide: [Configuration system](/run-arbitrum-node/nitro/configuration-system) +Related guide: [Configuration system](/run-arbitrum-node/reference/configuration-system)
graphql flags (3) @@ -324,7 +324,7 @@ Related guide: [Configuration system](/run-arbitrum-node/nitro/configuration-sys ## http -Related guide: [Configuration system](/run-arbitrum-node/nitro/configuration-system) +Related guide: [Configuration system](/run-arbitrum-node/reference/configuration-system)
http flags (10) @@ -387,7 +387,7 @@ Related guide: [Docker and CLI binaries](/run-arbitrum-node/nitro/docker-and-cli ## ipc -Related guide: [Configuration system](/run-arbitrum-node/nitro/configuration-system) +Related guide: [Configuration system](/run-arbitrum-node/reference/configuration-system)
ipc flags (1) @@ -400,7 +400,7 @@ Related guide: [Configuration system](/run-arbitrum-node/nitro/configuration-sys ## log-level -Related guide: [Configuration system](/run-arbitrum-node/nitro/configuration-system) +Related guide: [Configuration system](/run-arbitrum-node/reference/configuration-system)
log-level flags (1) @@ -413,7 +413,7 @@ Related guide: [Configuration system](/run-arbitrum-node/nitro/configuration-sys ## log-type -Related guide: [Configuration system](/run-arbitrum-node/nitro/configuration-system) +Related guide: [Configuration system](/run-arbitrum-node/reference/configuration-system)
log-type flags (1) @@ -874,7 +874,7 @@ Related guide: [Node tuning and monitoring](/run-arbitrum-node/nitro/node-tuning ## parent-chain -Related guide: [Configuration system](/run-arbitrum-node/nitro/configuration-system) +Related guide: [Configuration system](/run-arbitrum-node/reference/configuration-system)
parent-chain flags (14) @@ -947,7 +947,7 @@ Related guide: [Node tuning and monitoring](/run-arbitrum-node/nitro/node-tuning ## rpc -Related guide: [Configuration system](/run-arbitrum-node/nitro/configuration-system) +Related guide: [Configuration system](/run-arbitrum-node/reference/configuration-system)
rpc flags (2) @@ -999,7 +999,7 @@ Related guide: [Node tuning and monitoring](/run-arbitrum-node/nitro/node-tuning ## version-alerter -Related guide: [Configuration system](/run-arbitrum-node/nitro/configuration-system) +Related guide: [Configuration system](/run-arbitrum-node/reference/configuration-system)
version-alerter flags (12) @@ -1023,7 +1023,7 @@ Related guide: [Configuration system](/run-arbitrum-node/nitro/configuration-sys ## ws -Related guide: [Configuration system](/run-arbitrum-node/nitro/configuration-system) +Related guide: [Configuration system](/run-arbitrum-node/reference/configuration-system)
ws flags (6) diff --git a/docs/run-arbitrum-node/nitro/configuration-system.mdx b/docs/run-arbitrum-node/reference/configuration-system.mdx similarity index 100% rename from docs/run-arbitrum-node/nitro/configuration-system.mdx rename to docs/run-arbitrum-node/reference/configuration-system.mdx diff --git a/docs/run-arbitrum-node/nitro/da-tools-reference.mdx b/docs/run-arbitrum-node/reference/da-tools-reference.mdx similarity index 100% rename from docs/run-arbitrum-node/nitro/da-tools-reference.mdx rename to docs/run-arbitrum-node/reference/da-tools-reference.mdx diff --git a/docs/run-arbitrum-node/04-l1-ethereum-beacon-chain-rpc-providers.mdx b/docs/run-arbitrum-node/reference/l1-ethereum-beacon-chain-rpc-providers.mdx similarity index 100% rename from docs/run-arbitrum-node/04-l1-ethereum-beacon-chain-rpc-providers.mdx rename to docs/run-arbitrum-node/reference/l1-ethereum-beacon-chain-rpc-providers.mdx diff --git a/docs/run-arbitrum-node/nitro/03-nitro-database-snapshots.mdx b/docs/run-arbitrum-node/reference/nitro-database-snapshots.mdx similarity index 100% rename from docs/run-arbitrum-node/nitro/03-nitro-database-snapshots.mdx rename to docs/run-arbitrum-node/reference/nitro-database-snapshots.mdx diff --git a/docs/run-arbitrum-node/start-here.mdx b/docs/run-arbitrum-node/start-here.mdx index 7570ae2b62..dc3910b49a 100644 --- a/docs/run-arbitrum-node/start-here.mdx +++ b/docs/run-arbitrum-node/start-here.mdx @@ -63,7 +63,7 @@ Snapshots are published per state scheme, and a snapshot only works with a node Only the HashDB kinds distinguish pruned from unpruned. PathDB prunes as it runs, so every PathDB snapshot is already pruned to its state-history window—there is no separate unpruned variant to publish. The `pruned` kind exists because a HashDB database is pruned manually, and the published HashDB full node snapshots happen to be pruned ones. -`--init.latest` cannot download the PathDB kinds. See [PathDB snapshots](/run-arbitrum-node/nitro/03-nitro-database-snapshots.mdx#pathdb-snapshots). +`--init.latest` cannot download the PathDB kinds. See [PathDB snapshots](/run-arbitrum-node/reference/nitro-database-snapshots.mdx#pathdb-snapshots). Database snapshots for other Arbitrum chains may be available at the discretion of the chain's team. Get in touch with them if you're interested in using a database snapshot for their chains. @@ -71,12 +71,12 @@ Database snapshots for other Arbitrum chains may be available at the discretion Supplying a database snapshot when starting your node for the first time is required for Arbitrum One (to provide information from the Classic era) but is optional for other chains. Supplying a database snapshot on the first run will provide the state and data for that chain up to a specific block, allowing the node to sync faster to the head of the chain. -We provide a summary of the available parameters here, but it is recommended to read the [complete guide](/run-arbitrum-node/nitro/03-nitro-database-snapshots.mdx) if you plan to use snapshots. +We provide a summary of the available parameters here, but it is recommended to read the [complete guide](/run-arbitrum-node/reference/nitro-database-snapshots.mdx) if you plan to use snapshots. - Use the parameter `--init.latest ` (accepted values: `archive`, `pruned`, `genesis`) to instruct your node to download the corresponding snapshot from the configured URL - Optionally, use the parameter `--init.latest-base` to set the base URL when searching for the latest snapshot - Note that these parameters get ignored if a database already exists -- When running more than one node, it's easier to manually download the different parts of the snapshot, join them into a single archive, and host it locally for your nodes. Please see [Downloading the snapshot manually](/run-arbitrum-node/nitro/03-nitro-database-snapshots.mdx#downloading-the-snapshot-manually) for instructions on how to do that. +- When running more than one node, it's easier to manually download the different parts of the snapshot, join them into a single archive, and host it locally for your nodes. Please see [Downloading the snapshot manually](/run-arbitrum-node/reference/nitro-database-snapshots.mdx#downloading-the-snapshot-manually) for instructions on how to do that. - Only snapshots formatted with your node's specified state scheme are compatible. In other words, a PathDB snapshot won't work for a node using HashDB, and vice versa. Each snapshot directory publishes a `metadata.json` file naming its `state_scheme`; check it before downloading. :::tip Which initialization mode should I use? @@ -91,7 +91,7 @@ We provide a summary of the available parameters here, but it is recommended to | Hosting one snapshot for **multiple nodes** | Download manually, then use `--init.url file:///path/to/archive.tar` on each node | | Using a **custom snapshot URL** | `--init.url https://your-snapshot-url/archive.tar` | -For more details on snapshot downloading and initialization, see the [complete snapshot guide](/run-arbitrum-node/nitro/03-nitro-database-snapshots.mdx). +For more details on snapshot downloading and initialization, see the [complete snapshot guide](/run-arbitrum-node/reference/nitro-database-snapshots.mdx). ::: diff --git a/redirects.config.js b/redirects.config.js index 8f754605f1..456c85d3e2 100644 --- a/redirects.config.js +++ b/redirects.config.js @@ -431,5 +431,25 @@ export const redirects = [ from: '/run-arbitrum-node/beacon-nodes-historical-blobs', to: '/run-arbitrum-node/data-availability/beacon-nodes-historical-blobs', }, + { + from: '/run-arbitrum-node/nitro/cli-flags-reference', + to: '/run-arbitrum-node/reference/cli-flags-reference', + }, + { + from: '/run-arbitrum-node/nitro/da-tools-reference', + to: '/run-arbitrum-node/reference/da-tools-reference', + }, + { + from: '/run-arbitrum-node/nitro/nitro-database-snapshots', + to: '/run-arbitrum-node/reference/nitro-database-snapshots', + }, + { + from: '/run-arbitrum-node/l1-ethereum-beacon-chain-rpc-providers', + to: '/run-arbitrum-node/reference/l1-ethereum-beacon-chain-rpc-providers', + }, + { + from: '/run-arbitrum-node/nitro/configuration-system', + to: '/run-arbitrum-node/reference/configuration-system', + }, // AUTO-GENERATED REDIRECTS END ]; diff --git a/sidebars.js b/sidebars.js index a5e756459a..5828ad68d7 100644 --- a/sidebars.js +++ b/sidebars.js @@ -743,7 +743,7 @@ const sidebars = { }, { type: 'doc', - id: 'run-arbitrum-node/l1-ethereum-beacon-chain-rpc-providers', + id: 'run-arbitrum-node/reference/l1-ethereum-beacon-chain-rpc-providers', label: 'L1 Ethereum RPC providers', }, { @@ -859,7 +859,7 @@ const sidebars = { }, { type: 'doc', - id: 'run-arbitrum-node/nitro/nitro-database-snapshots', + id: 'run-arbitrum-node/reference/nitro-database-snapshots', label: 'Database snapshots', }, { @@ -874,17 +874,17 @@ const sidebars = { }, { type: 'doc', - id: 'run-arbitrum-node/nitro/configuration-system', + id: 'run-arbitrum-node/reference/configuration-system', label: 'Configuration system', }, { type: 'doc', - id: 'run-arbitrum-node/nitro/da-tools-reference', + id: 'run-arbitrum-node/reference/da-tools-reference', label: 'DA tools reference', }, { type: 'doc', - id: 'run-arbitrum-node/nitro/cli-flags-reference', + id: 'run-arbitrum-node/reference/cli-flags-reference', label: 'CLI flags reference', }, { diff --git a/vercel.json b/vercel.json index 0203181d7a..a738a3315c 100644 --- a/vercel.json +++ b/vercel.json @@ -546,6 +546,31 @@ "destination": "/run-arbitrum-node/data-availability/beacon-nodes-historical-blobs", "permanent": false }, + { + "source": "/run-arbitrum-node/nitro/cli-flags-reference", + "destination": "/run-arbitrum-node/reference/cli-flags-reference", + "permanent": false + }, + { + "source": "/run-arbitrum-node/nitro/da-tools-reference", + "destination": "/run-arbitrum-node/reference/da-tools-reference", + "permanent": false + }, + { + "source": "/run-arbitrum-node/nitro/nitro-database-snapshots", + "destination": "/run-arbitrum-node/reference/nitro-database-snapshots", + "permanent": false + }, + { + "source": "/run-arbitrum-node/l1-ethereum-beacon-chain-rpc-providers", + "destination": "/run-arbitrum-node/reference/l1-ethereum-beacon-chain-rpc-providers", + "permanent": false + }, + { + "source": "/run-arbitrum-node/nitro/configuration-system", + "destination": "/run-arbitrum-node/reference/configuration-system", + "permanent": false + }, { "source": "/__redirects-autogen-end__", "destination": "/", "permanent": false }, { "source": "/(anytrust/?)", From 5b60bf16501e78c8441a1cf4dd5f08b5686c2352 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 8 Sep 2026 13:47:19 -0500 Subject: [PATCH 3/9] Moving assign-node-roles to run-arbitrum-node/operation --- docs/launch-arbitrum-chain/run-a-node/batch-poster.mdx | 2 +- .../run-a-node/split-validator-node.mdx | 2 +- docs/run-arbitrum-node/01-overview.mdx | 2 +- docs/run-arbitrum-node/02-run-full-node.mdx | 2 +- docs/run-arbitrum-node/data-availability/run-feed-relay.mdx | 2 +- docs/run-arbitrum-node/more-types/01-run-archive-node.mdx | 2 +- docs/run-arbitrum-node/more-types/02-run-validator-node.mdx | 2 +- docs/run-arbitrum-node/{ => operation}/assign-node-roles.mdx | 0 docs/run-arbitrum-node/sequencer/04-run-sequencer-node.mdx | 2 +- redirects.config.js | 4 ++++ sidebars.js | 2 +- vercel.json | 5 +++++ 12 files changed, 18 insertions(+), 9 deletions(-) rename docs/run-arbitrum-node/{ => operation}/assign-node-roles.mdx (100%) diff --git a/docs/launch-arbitrum-chain/run-a-node/batch-poster.mdx b/docs/launch-arbitrum-chain/run-a-node/batch-poster.mdx index 1f4ecf4378..b94b3bebce 100644 --- a/docs/launch-arbitrum-chain/run-a-node/batch-poster.mdx +++ b/docs/launch-arbitrum-chain/run-a-node/batch-poster.mdx @@ -8,7 +8,7 @@ user_story: As a current Arbitrum chain owner, I need to understand how to confi content_type: how-to --- -To learn how the batch-poster role relates to the other Nitro node roles, including its wallet requirements and the safety rules for running redundant posters, see [How to assign roles to a Nitro node](/run-arbitrum-node/assign-node-roles.mdx). +To learn how the batch-poster role relates to the other Nitro node roles, including its wallet requirements and the safety rules for running redundant posters, see [How to assign roles to a Nitro node](/run-arbitrum-node/operation/assign-node-roles.mdx). The [batch poster](/how-arbitrum-works/deep-dives/assertions.mdx) uses the following default configuration flags and values: diff --git a/docs/launch-arbitrum-chain/run-a-node/split-validator-node.mdx b/docs/launch-arbitrum-chain/run-a-node/split-validator-node.mdx index 8c06677ffd..8d76ab59ad 100644 --- a/docs/launch-arbitrum-chain/run-a-node/split-validator-node.mdx +++ b/docs/launch-arbitrum-chain/run-a-node/split-validator-node.mdx @@ -16,7 +16,7 @@ Split validators separate the validation work to a stateless validation node, wh This guide explains how to set up a split validator configuration for Arbitrum chains by running a Nitro node (bonder) and a validation node separately. -Before you read this doc, please ensure you have already walked through [run a validator](/run-arbitrum-node/more-types/02-run-validator-node.mdx) docs to understand the basics of a validator node. For an overview of how split validation fits among the other Nitro node roles, see [How to assign roles to a Nitro node](/run-arbitrum-node/assign-node-roles.mdx). +Before you read this doc, please ensure you have already walked through [run a validator](/run-arbitrum-node/more-types/02-run-validator-node.mdx) docs to understand the basics of a validator node. For an overview of how split validation fits among the other Nitro node roles, see [How to assign roles to a Nitro node](/run-arbitrum-node/operation/assign-node-roles.mdx). ### What is AUTH-RPC and the validation API diff --git a/docs/run-arbitrum-node/01-overview.mdx b/docs/run-arbitrum-node/01-overview.mdx index ec46bb70b0..30a0016162 100644 --- a/docs/run-arbitrum-node/01-overview.mdx +++ b/docs/run-arbitrum-node/01-overview.mdx @@ -36,7 +36,7 @@ The rest of this series focuses on the second approach: running your own Arbitru When interacting with the Arbitrum network, users have the option to run either a full node or an archive node. There are distinct advantages to running an Arbitrum full node. In this quick start, we will explore the reasons why a user may prefer to run a full node instead of an archive node. By understanding the benefits and trade-offs of each node type, users can make an informed decision based on their specific requirements and objectives. -Beyond full and archive nodes, a Nitro node can take on other roles — sequencer, batch poster, validator, or feed relay—purely through configuration. For the flags that define each role and how to convert a node between roles, see [How to assign roles to a Nitro node](/run-arbitrum-node/assign-node-roles.mdx). +Beyond full and archive nodes, a Nitro node can take on other roles — sequencer, batch poster, validator, or feed relay—purely through configuration. For the flags that define each role and how to convert a node between roles, see [How to assign roles to a Nitro node](/run-arbitrum-node/operation/assign-node-roles.mdx). ## Considerations for running an Arbitrum full node diff --git a/docs/run-arbitrum-node/02-run-full-node.mdx b/docs/run-arbitrum-node/02-run-full-node.mdx index eb46c81139..376e0dc48e 100644 --- a/docs/run-arbitrum-node/02-run-full-node.mdx +++ b/docs/run-arbitrum-node/02-run-full-node.mdx @@ -16,7 +16,7 @@ This page assumes that you've completed the steps from the [Start here](/run-arb To view the short and long term support policy, visit the [Nitro support policy](/run-arbitrum-node/nitro-support-policy.mdx) page. -If you're looking to run a node with a different role — sequencer, batch poster, validator, archive node, or feed relay—see [How to assign roles to a Nitro node](/run-arbitrum-node/assign-node-roles.mdx) for the flags that define each role. +If you're looking to run a node with a different role — sequencer, batch poster, validator, archive node, or feed relay—see [How to assign roles to a Nitro node](/run-arbitrum-node/operation/assign-node-roles.mdx) for the flags that define each role. ::: diff --git a/docs/run-arbitrum-node/data-availability/run-feed-relay.mdx b/docs/run-arbitrum-node/data-availability/run-feed-relay.mdx index 219a91d47b..fa711e6d6d 100644 --- a/docs/run-arbitrum-node/data-availability/run-feed-relay.mdx +++ b/docs/run-arbitrum-node/data-availability/run-feed-relay.mdx @@ -13,7 +13,7 @@ Feed endpoints will soon require compression with a custom dictionary, so if con ::: -For context on where the feed relay fits into Arbitrum's overall data flow, see [Data availability](/run-arbitrum-node/data-availability.mdx#how-full-nodes-sync-the-data-from-the-sequencer-feed). For the wire format the feed delivers, see [How to read the sequencer feed](/run-arbitrum-node/sequencer/02-read-sequencer-feed.mdx). For how the feed relay compares to the other Nitro node roles, see [How to assign roles to a Nitro node](/run-arbitrum-node/assign-node-roles.mdx). +For context on where the feed relay fits into Arbitrum's overall data flow, see [Data availability](/run-arbitrum-node/data-availability.mdx#how-full-nodes-sync-the-data-from-the-sequencer-feed). For the wire format the feed delivers, see [How to read the sequencer feed](/run-arbitrum-node/sequencer/02-read-sequencer-feed.mdx). For how the feed relay compares to the other Nitro node roles, see [How to assign roles to a Nitro node](/run-arbitrum-node/operation/assign-node-roles.mdx). The feed relay is in the same Docker image as the Nitro node. diff --git a/docs/run-arbitrum-node/more-types/01-run-archive-node.mdx b/docs/run-arbitrum-node/more-types/01-run-archive-node.mdx index fadd131db2..4f29e9177e 100644 --- a/docs/run-arbitrum-node/more-types/01-run-archive-node.mdx +++ b/docs/run-arbitrum-node/more-types/01-run-archive-node.mdx @@ -8,7 +8,7 @@ content_type: how-to An Arbitrum **archive node** is an Arbitrum full node that maintains an archive of historical chain states. This how-to walks you through the process of configuring an archive node on your local machine so that you can query both pre-Nitro and post-Nitro state data. -For how archive mode relates to the other Nitro node roles, see [How to assign roles to a Nitro node](/run-arbitrum-node/assign-node-roles.mdx). +For how archive mode relates to the other Nitro node roles, see [How to assign roles to a Nitro node](/run-arbitrum-node/operation/assign-node-roles.mdx). :::caution diff --git a/docs/run-arbitrum-node/more-types/02-run-validator-node.mdx b/docs/run-arbitrum-node/more-types/02-run-validator-node.mdx index 334dd2fd54..2b83ace23e 100644 --- a/docs/run-arbitrum-node/more-types/02-run-validator-node.mdx +++ b/docs/run-arbitrum-node/more-types/02-run-validator-node.mdx @@ -16,7 +16,7 @@ This how-to assumes that you're familiar with the following: - [How the Rollup protocol works](/how-arbitrum-works/01-inside-arbitrum-nitro.mdx) - [How BoLD works](/how-arbitrum-works/bold/bold-technical-deep-dive.mdx#how-bold-leverages-ethereum), if you're running a validator for a chain that has BoLD activated - [Data availability](/run-arbitrum-node/data-availability.mdx), for how Rollup-mode and AnyTrust-mode chains differ in the data your validator must reconstruct -- [How to assign roles to a Nitro node](/run-arbitrum-node/assign-node-roles.mdx), for how the validator role relates to the other node roles and what converting a node to a validator involves +- [How to assign roles to a Nitro node](/run-arbitrum-node/operation/assign-node-roles.mdx), for how the validator role relates to the other node roles and what converting a node to a validator involves ## Validation strategies diff --git a/docs/run-arbitrum-node/assign-node-roles.mdx b/docs/run-arbitrum-node/operation/assign-node-roles.mdx similarity index 100% rename from docs/run-arbitrum-node/assign-node-roles.mdx rename to docs/run-arbitrum-node/operation/assign-node-roles.mdx diff --git a/docs/run-arbitrum-node/sequencer/04-run-sequencer-node.mdx b/docs/run-arbitrum-node/sequencer/04-run-sequencer-node.mdx index 1b90ffa450..b4c029c5c6 100644 --- a/docs/run-arbitrum-node/sequencer/04-run-sequencer-node.mdx +++ b/docs/run-arbitrum-node/sequencer/04-run-sequencer-node.mdx @@ -15,7 +15,7 @@ We also provide a [guide for running a high-availability sequencer node for an A This how-to provides step-by-step instructions for running a sequencer node on your local machine. -For background on how sequencers fit into Arbitrum's data flow (batch posting, the sequencer feed, and how full nodes consume sequencer output), see [Data availability](/run-arbitrum-node/data-availability.mdx). For how the sequencer role relates to the other Nitro node roles and the flags that define them, see [How to assign roles to a Nitro node](/run-arbitrum-node/assign-node-roles.mdx). +For background on how sequencers fit into Arbitrum's data flow (batch posting, the sequencer feed, and how full nodes consume sequencer output), see [Data availability](/run-arbitrum-node/data-availability.mdx). For how the sequencer role relates to the other Nitro node roles and the flags that define them, see [How to assign roles to a Nitro node](/run-arbitrum-node/operation/assign-node-roles.mdx). ## Minimum hardware configuration diff --git a/redirects.config.js b/redirects.config.js index 456c85d3e2..d547a8a858 100644 --- a/redirects.config.js +++ b/redirects.config.js @@ -451,5 +451,9 @@ export const redirects = [ from: '/run-arbitrum-node/nitro/configuration-system', to: '/run-arbitrum-node/reference/configuration-system', }, + { + from: '/run-arbitrum-node/assign-node-roles', + to: '/run-arbitrum-node/operation/assign-node-roles', + }, // AUTO-GENERATED REDIRECTS END ]; diff --git a/sidebars.js b/sidebars.js index 5828ad68d7..a64f737e77 100644 --- a/sidebars.js +++ b/sidebars.js @@ -721,7 +721,7 @@ const sidebars = { }, { type: 'doc', - id: 'run-arbitrum-node/assign-node-roles', + id: 'run-arbitrum-node/operation/assign-node-roles', label: 'Assign node roles', }, { diff --git a/vercel.json b/vercel.json index a738a3315c..b78dab2bb6 100644 --- a/vercel.json +++ b/vercel.json @@ -571,6 +571,11 @@ "destination": "/run-arbitrum-node/reference/configuration-system", "permanent": false }, + { + "source": "/run-arbitrum-node/assign-node-roles", + "destination": "/run-arbitrum-node/operation/assign-node-roles", + "permanent": false + }, { "source": "/__redirects-autogen-end__", "destination": "/", "permanent": false }, { "source": "/(anytrust/?)", From 462dc715b96932f72427d2d31cb7e1d9d424aeb1 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 8 Sep 2026 13:50:29 -0500 Subject: [PATCH 4/9] moving node-tuning-and-monitoring to run-arbitrum-node/operation --- .../operate/monitoring.mdx | 2 +- .../run-a-node/run-full-node-with-helm.mdx | 2 +- docs/run-arbitrum-node/02-run-full-node.mdx | 2 +- .../more-types/01-run-archive-node.mdx | 2 +- ...onvert-databases-from-leveldb-to-pebble.mdx | 2 +- .../node-tuning-and-monitoring.mdx | 0 .../reference/cli-flags-reference.mdx | 18 +++++++++--------- redirects.config.js | 4 ++++ sidebars.js | 2 +- vercel.json | 5 +++++ 10 files changed, 24 insertions(+), 15 deletions(-) rename docs/run-arbitrum-node/{nitro => operation}/node-tuning-and-monitoring.mdx (100%) diff --git a/docs/launch-arbitrum-chain/operate/monitoring.mdx b/docs/launch-arbitrum-chain/operate/monitoring.mdx index 835860ee66..2eb9e35fa9 100644 --- a/docs/launch-arbitrum-chain/operate/monitoring.mdx +++ b/docs/launch-arbitrum-chain/operate/monitoring.mdx @@ -65,7 +65,7 @@ nitro --metrics \ --metrics-server.port 6070 ``` -For metrics-server flags, memory-related metrics, health-check patterns, and Kubernetes `ServiceMonitor` examples, see [Node tuning and monitoring](/run-arbitrum-node/nitro/node-tuning-and-monitoring.mdx). +For metrics-server flags, memory-related metrics, health-check patterns, and Kubernetes `ServiceMonitor` examples, see [Node tuning and monitoring](/run-arbitrum-node/operation/node-tuning-and-monitoring.mdx). The signals that are not Nitro metrics — onchain events and account balances on the parent chain — are called out explicitly in each table below. diff --git a/docs/launch-arbitrum-chain/run-a-node/run-full-node-with-helm.mdx b/docs/launch-arbitrum-chain/run-a-node/run-full-node-with-helm.mdx index 2fa243d034..9e385d8288 100644 --- a/docs/launch-arbitrum-chain/run-a-node/run-full-node-with-helm.mdx +++ b/docs/launch-arbitrum-chain/run-a-node/run-full-node-with-helm.mdx @@ -120,7 +120,7 @@ extraEnv: value: 'value' ``` -For the allocator details, the `GOMEMLIMIT` formula, and `MALLOC_ARENA_MAX`, see the [memory management deep-dive](/run-arbitrum-node/nitro/node-tuning-and-monitoring.mdx) and the [memory management section](/run-arbitrum-node/02-run-full-node.mdx#memory-management) of the Docker full-node guide. +For the allocator details, the `GOMEMLIMIT` formula, and `MALLOC_ARENA_MAX`, see the [memory management deep-dive](/run-arbitrum-node/operation/node-tuning-and-monitoring.mdx) and the [memory management section](/run-arbitrum-node/02-run-full-node.mdx#memory-management) of the Docker full-node guide. ## Step 3: First sync from a snapshot diff --git a/docs/run-arbitrum-node/02-run-full-node.mdx b/docs/run-arbitrum-node/02-run-full-node.mdx index 376e0dc48e..3e117aee3f 100644 --- a/docs/run-arbitrum-node/02-run-full-node.mdx +++ b/docs/run-arbitrum-node/02-run-full-node.mdx @@ -174,7 +174,7 @@ Under heavy RPC load or during operations such as large `debug_traceBlockByNumbe - `--node.resource-mgmt.mem-free-limit`: Declines incoming RPC requests when free system memory drops below the specified threshold (e.g., `--node.resource-mgmt.mem-free-limit=4GiB`). This helps protect the node from OOM under high request load. - `GOMEMLIMIT` environment variable: Sets a soft memory limit for the Go runtime garbage collector (e.g., `GOMEMLIMIT=48GiB` for a 64 GB machine), helping reduce memory spikes. -For an in-depth breakdown of Nitro's memory allocators, cache tuning, and OOM mitigations, see [node tuning and monitoring](/run-arbitrum-node/nitro/node-tuning-and-monitoring.mdx). +For an in-depth breakdown of Nitro's memory allocators, cache tuning, and OOM mitigations, see [node tuning and monitoring](/run-arbitrum-node/operation/node-tuning-and-monitoring.mdx). :::tip For Docker deployments, you can set these in your `docker run` command: diff --git a/docs/run-arbitrum-node/more-types/01-run-archive-node.mdx b/docs/run-arbitrum-node/more-types/01-run-archive-node.mdx index 4f29e9177e..6c7b02f19c 100644 --- a/docs/run-arbitrum-node/more-types/01-run-archive-node.mdx +++ b/docs/run-arbitrum-node/more-types/01-run-archive-node.mdx @@ -61,7 +61,7 @@ Before v3.10.0 it defaulted to 24 hours' worth of blocks even in archive mode. N -For cache sizing and memory tuning that applies to archive nodes generally, see [node tuning and monitoring](/run-arbitrum-node/nitro/node-tuning-and-monitoring.mdx). +For cache sizing and memory tuning that applies to archive nodes generally, see [node tuning and monitoring](/run-arbitrum-node/operation/node-tuning-and-monitoring.mdx). ### Initialize a PathDB archive node diff --git a/docs/run-arbitrum-node/nitro/04-how-to-convert-databases-from-leveldb-to-pebble.mdx b/docs/run-arbitrum-node/nitro/04-how-to-convert-databases-from-leveldb-to-pebble.mdx index 163d0b9479..de1af4bcd1 100644 --- a/docs/run-arbitrum-node/nitro/04-how-to-convert-databases-from-leveldb-to-pebble.mdx +++ b/docs/run-arbitrum-node/nitro/04-how-to-convert-databases-from-leveldb-to-pebble.mdx @@ -12,7 +12,7 @@ Switching from LevelDB to Pebble in Ethereum While Pebble provides better resilience and potentially improved performance, deciding to switch should consider your specific needs and the possible effects of a full resync on your operations. -For background on how the database backend interacts with Nitro's caches and memory usage, see [node tuning and monitoring](/run-arbitrum-node/nitro/node-tuning-and-monitoring.mdx). +For background on how the database backend interacts with Nitro's caches and memory usage, see [node tuning and monitoring](/run-arbitrum-node/operation/node-tuning-and-monitoring.mdx). diff --git a/docs/run-arbitrum-node/nitro/node-tuning-and-monitoring.mdx b/docs/run-arbitrum-node/operation/node-tuning-and-monitoring.mdx similarity index 100% rename from docs/run-arbitrum-node/nitro/node-tuning-and-monitoring.mdx rename to docs/run-arbitrum-node/operation/node-tuning-and-monitoring.mdx diff --git a/docs/run-arbitrum-node/reference/cli-flags-reference.mdx b/docs/run-arbitrum-node/reference/cli-flags-reference.mdx index a5c63524b9..65a3d8bff3 100644 --- a/docs/run-arbitrum-node/reference/cli-flags-reference.mdx +++ b/docs/run-arbitrum-node/reference/cli-flags-reference.mdx @@ -20,7 +20,7 @@ This page lists every CLI flag accepted by the Nitro node binary. For explanatio - [Configuration system](/run-arbitrum-node/reference/configuration-system) - [Docker and CLI binaries](/run-arbitrum-node/nitro/docker-and-cli-binaries) -- [Node tuning and monitoring](/run-arbitrum-node/nitro/node-tuning-and-monitoring) +- [Node tuning and monitoring](/run-arbitrum-node/operation/node-tuning-and-monitoring) - [DA tools reference](/run-arbitrum-node/reference/da-tools-reference) **Total flags:** 724 across 23 namespaces. @@ -113,7 +113,7 @@ Related guide: [Configuration system](/run-arbitrum-node/reference/configuration ## execution -Related guide: [Node tuning and monitoring](/run-arbitrum-node/nitro/node-tuning-and-monitoring) +Related guide: [Node tuning and monitoring](/run-arbitrum-node/operation/node-tuning-and-monitoring)
execution flags (164) @@ -289,7 +289,7 @@ Related guide: [Node tuning and monitoring](/run-arbitrum-node/nitro/node-tuning ## file-logging -Related guide: [Node tuning and monitoring](/run-arbitrum-node/nitro/node-tuning-and-monitoring) +Related guide: [Node tuning and monitoring](/run-arbitrum-node/operation/node-tuning-and-monitoring)
file-logging flags (8) @@ -426,7 +426,7 @@ Related guide: [Configuration system](/run-arbitrum-node/reference/configuration ## metrics -Related guide: [Node tuning and monitoring](/run-arbitrum-node/nitro/node-tuning-and-monitoring) +Related guide: [Node tuning and monitoring](/run-arbitrum-node/operation/node-tuning-and-monitoring)
metrics flags (1) @@ -439,7 +439,7 @@ Related guide: [Node tuning and monitoring](/run-arbitrum-node/nitro/node-tuning ## metrics-server -Related guide: [Node tuning and monitoring](/run-arbitrum-node/nitro/node-tuning-and-monitoring) +Related guide: [Node tuning and monitoring](/run-arbitrum-node/operation/node-tuning-and-monitoring)
metrics-server flags (3) @@ -454,7 +454,7 @@ Related guide: [Node tuning and monitoring](/run-arbitrum-node/nitro/node-tuning ## node -Related guide: [Node tuning and monitoring](/run-arbitrum-node/nitro/node-tuning-and-monitoring) +Related guide: [Node tuning and monitoring](/run-arbitrum-node/operation/node-tuning-and-monitoring)
node flags (408) @@ -920,7 +920,7 @@ Related guide: [Docker and CLI binaries](/run-arbitrum-node/nitro/docker-and-cli ## pprof -Related guide: [Node tuning and monitoring](/run-arbitrum-node/nitro/node-tuning-and-monitoring) +Related guide: [Node tuning and monitoring](/run-arbitrum-node/operation/node-tuning-and-monitoring)
pprof flags (1) @@ -933,7 +933,7 @@ Related guide: [Node tuning and monitoring](/run-arbitrum-node/nitro/node-tuning ## pprof-cfg -Related guide: [Node tuning and monitoring](/run-arbitrum-node/nitro/node-tuning-and-monitoring) +Related guide: [Node tuning and monitoring](/run-arbitrum-node/operation/node-tuning-and-monitoring)
pprof-cfg flags (2) @@ -961,7 +961,7 @@ Related guide: [Configuration system](/run-arbitrum-node/reference/configuration ## validation -Related guide: [Node tuning and monitoring](/run-arbitrum-node/nitro/node-tuning-and-monitoring) +Related guide: [Node tuning and monitoring](/run-arbitrum-node/operation/node-tuning-and-monitoring)
validation flags (26) diff --git a/redirects.config.js b/redirects.config.js index d547a8a858..eab2aae469 100644 --- a/redirects.config.js +++ b/redirects.config.js @@ -455,5 +455,9 @@ export const redirects = [ from: '/run-arbitrum-node/assign-node-roles', to: '/run-arbitrum-node/operation/assign-node-roles', }, + { + from: '/run-arbitrum-node/nitro/node-tuning-and-monitoring', + to: '/run-arbitrum-node/operation/node-tuning-and-monitoring', + }, // AUTO-GENERATED REDIRECTS END ]; diff --git a/sidebars.js b/sidebars.js index a64f737e77..b32334c74c 100644 --- a/sidebars.js +++ b/sidebars.js @@ -869,7 +869,7 @@ const sidebars = { }, { type: 'doc', - id: 'run-arbitrum-node/nitro/node-tuning-and-monitoring', + id: 'run-arbitrum-node/operation/node-tuning-and-monitoring', label: 'Node tuning and monitoring', }, { diff --git a/vercel.json b/vercel.json index b78dab2bb6..0416b5b1a8 100644 --- a/vercel.json +++ b/vercel.json @@ -576,6 +576,11 @@ "destination": "/run-arbitrum-node/operation/assign-node-roles", "permanent": false }, + { + "source": "/run-arbitrum-node/nitro/node-tuning-and-monitoring", + "destination": "/run-arbitrum-node/operation/node-tuning-and-monitoring", + "permanent": false + }, { "source": "/__redirects-autogen-end__", "destination": "/", "permanent": false }, { "source": "/(anytrust/?)", From 0b4283c331587cb264f7a58e225083ffba6b460d Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 8 Sep 2026 13:54:35 -0500 Subject: [PATCH 5/9] Moved how-to-convert-databases-from-leveldb-to-pebble to run-arbitrum-node/operation --- .../how-to-convert-databases-from-leveldb-to-pebble.mdx} | 0 redirects.config.js | 4 ++++ sidebars.js | 2 +- vercel.json | 5 +++++ 4 files changed, 10 insertions(+), 1 deletion(-) rename docs/run-arbitrum-node/{nitro/04-how-to-convert-databases-from-leveldb-to-pebble.mdx => operation/how-to-convert-databases-from-leveldb-to-pebble.mdx} (100%) diff --git a/docs/run-arbitrum-node/nitro/04-how-to-convert-databases-from-leveldb-to-pebble.mdx b/docs/run-arbitrum-node/operation/how-to-convert-databases-from-leveldb-to-pebble.mdx similarity index 100% rename from docs/run-arbitrum-node/nitro/04-how-to-convert-databases-from-leveldb-to-pebble.mdx rename to docs/run-arbitrum-node/operation/how-to-convert-databases-from-leveldb-to-pebble.mdx diff --git a/redirects.config.js b/redirects.config.js index eab2aae469..2dbedd0e87 100644 --- a/redirects.config.js +++ b/redirects.config.js @@ -459,5 +459,9 @@ export const redirects = [ from: '/run-arbitrum-node/nitro/node-tuning-and-monitoring', to: '/run-arbitrum-node/operation/node-tuning-and-monitoring', }, + { + from: '/run-arbitrum-node/nitro/how-to-convert-databases-from-leveldb-to-pebble', + to: '/run-arbitrum-node/operation/how-to-convert-databases-from-leveldb-to-pebble', + }, // AUTO-GENERATED REDIRECTS END ]; diff --git a/sidebars.js b/sidebars.js index b32334c74c..e00f895494 100644 --- a/sidebars.js +++ b/sidebars.js @@ -864,7 +864,7 @@ const sidebars = { }, { type: 'doc', - id: 'run-arbitrum-node/nitro/how-to-convert-databases-from-leveldb-to-pebble', + id: 'run-arbitrum-node/operation/how-to-convert-databases-from-leveldb-to-pebble', label: 'Convert databases from LevelDB to Pebble', }, { diff --git a/vercel.json b/vercel.json index 0416b5b1a8..65eef3fca3 100644 --- a/vercel.json +++ b/vercel.json @@ -581,6 +581,11 @@ "destination": "/run-arbitrum-node/operation/node-tuning-and-monitoring", "permanent": false }, + { + "source": "/run-arbitrum-node/nitro/how-to-convert-databases-from-leveldb-to-pebble", + "destination": "/run-arbitrum-node/operation/how-to-convert-databases-from-leveldb-to-pebble", + "permanent": false + }, { "source": "/__redirects-autogen-end__", "destination": "/", "permanent": false }, { "source": "/(anytrust/?)", From 79edfe7c08f57b3df25f3f8d330f82a8ecf193cb Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 8 Sep 2026 14:01:28 -0500 Subject: [PATCH 6/9] Moving migrate-state-and-history-from-classic to run-arbitrum-node/operation --- .../migrate-state-and-history-from-classic.mdx} | 0 .../partials/run-full-node/_path-node-parameters.mdx | 2 +- redirects.config.js | 4 ++++ sidebars.js | 2 +- vercel.json | 5 +++++ 5 files changed, 11 insertions(+), 2 deletions(-) rename docs/run-arbitrum-node/{nitro/02-migrate-state-and-history-from-classic.mdx => operation/migrate-state-and-history-from-classic.mdx} (100%) diff --git a/docs/run-arbitrum-node/nitro/02-migrate-state-and-history-from-classic.mdx b/docs/run-arbitrum-node/operation/migrate-state-and-history-from-classic.mdx similarity index 100% rename from docs/run-arbitrum-node/nitro/02-migrate-state-and-history-from-classic.mdx rename to docs/run-arbitrum-node/operation/migrate-state-and-history-from-classic.mdx diff --git a/docs/run-arbitrum-node/partials/run-full-node/_path-node-parameters.mdx b/docs/run-arbitrum-node/partials/run-full-node/_path-node-parameters.mdx index aebef6abee..51db1f4767 100644 --- a/docs/run-arbitrum-node/partials/run-full-node/_path-node-parameters.mdx +++ b/docs/run-arbitrum-node/partials/run-full-node/_path-node-parameters.mdx @@ -6,7 +6,7 @@ These flags apply only when you set `--execution.caching.state-scheme=path`. Selects the TrieDB implementation Nitro uses to store its state trie. Set it to `path` to enable PathDB; the default is `hash`. -The two schemes are not interchangeable. A node can only start from a snapshot created with the same state scheme, so you cannot convert an existing database. To move to PathDB, either start from a `path`-scheme snapshot or sync from genesis. On Arbitrum One, syncing from genesis also requires a [Classic state import](/run-arbitrum-node/nitro/02-migrate-state-and-history-from-classic.mdx#step-3-initialize-your-nitro-node-importing-the-exported-data). +The two schemes are not interchangeable. A node can only start from a snapshot created with the same state scheme, so you cannot convert an existing database. To move to PathDB, either start from a `path`-scheme snapshot or sync from genesis. On Arbitrum One, syncing from genesis also requires a [Classic state import](/run-arbitrum-node/operation/migrate-state-and-history-from-classic.mdx#step-3-initialize-your-nitro-node-importing-the-exported-data). ### `--execution.caching.state-history` diff --git a/redirects.config.js b/redirects.config.js index 2dbedd0e87..dbc2619812 100644 --- a/redirects.config.js +++ b/redirects.config.js @@ -463,5 +463,9 @@ export const redirects = [ from: '/run-arbitrum-node/nitro/how-to-convert-databases-from-leveldb-to-pebble', to: '/run-arbitrum-node/operation/how-to-convert-databases-from-leveldb-to-pebble', }, + { + from: '/run-arbitrum-node/nitro/migrate-state-and-history-from-classic', + to: '/run-arbitrum-node/operation/migrate-state-and-history-from-classic', + }, // AUTO-GENERATED REDIRECTS END ]; diff --git a/sidebars.js b/sidebars.js index e00f895494..f4b5d0fc78 100644 --- a/sidebars.js +++ b/sidebars.js @@ -854,7 +854,7 @@ const sidebars = { }, { type: 'doc', - id: 'run-arbitrum-node/nitro/migrate-state-and-history-from-classic', + id: 'run-arbitrum-node/operation/migrate-state-and-history-from-classic', label: 'Migrate to Nitro from Classic', }, { diff --git a/vercel.json b/vercel.json index 65eef3fca3..e10b648ecf 100644 --- a/vercel.json +++ b/vercel.json @@ -586,6 +586,11 @@ "destination": "/run-arbitrum-node/operation/how-to-convert-databases-from-leveldb-to-pebble", "permanent": false }, + { + "source": "/run-arbitrum-node/nitro/migrate-state-and-history-from-classic", + "destination": "/run-arbitrum-node/operation/migrate-state-and-history-from-classic", + "permanent": false + }, { "source": "/__redirects-autogen-end__", "destination": "/", "permanent": false }, { "source": "/(anytrust/?)", From 95123894a1cf157feb1c8df8356e19227531098e Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 8 Sep 2026 14:04:52 -0500 Subject: [PATCH 7/9] Moving build-nitro-locally to run-arbitrum-node/ --- .../extend-the-protocol/precompiles.mdx | 4 ++-- docs/launch-arbitrum-chain/extend-the-protocol/stf.mdx | 2 +- .../01-build-nitro-locally.mdx => build-nitro-locally.mdx} | 0 .../sequencer/03-run-sequencer-coordination-manager.mdx | 2 +- redirects.config.js | 4 ++++ sidebars.js | 2 +- vercel.json | 5 +++++ 7 files changed, 14 insertions(+), 5 deletions(-) rename docs/run-arbitrum-node/{nitro/01-build-nitro-locally.mdx => build-nitro-locally.mdx} (100%) diff --git a/docs/launch-arbitrum-chain/extend-the-protocol/precompiles.mdx b/docs/launch-arbitrum-chain/extend-the-protocol/precompiles.mdx index b8d98ed329..f6d72b3e1b 100644 --- a/docs/launch-arbitrum-chain/extend-the-protocol/precompiles.mdx +++ b/docs/launch-arbitrum-chain/extend-the-protocol/precompiles.mdx @@ -232,7 +232,7 @@ Our function now emits an event, which means that when calling it, the state wil function sayHi() external returns(string memory); ``` -Next, build Nitro by following the instructions in [How to build Nitro locally](/run-arbitrum-node/nitro/01-build-nitro-locally.mdx). Note that if you've already built the Docker image, you still need run the last step to rebuild. +Next, build Nitro by following the instructions in [How to build Nitro locally](/run-arbitrum-node/build-nitro-locally.mdx). Note that if you've already built the Docker image, you still need run the last step to rebuild. Run Nitro with the following command: @@ -310,7 +310,7 @@ func (con ArbInfo) GetBalanceCustom(c ctx, evm mech, account addr) (huge, error) To register this new precompile method, refer to Option 1 above. -Next, build Nitro by following the instructions in [How to build Nitro locally](/run-arbitrum-node/nitro/01-build-nitro-locally.mdx). Note that if you've already built the Docker image, you still need run the last step to rebuild. +Next, build Nitro by following the instructions in [How to build Nitro locally](/run-arbitrum-node/build-nitro-locally.mdx). Note that if you've already built the Docker image, you still need run the last step to rebuild. Run Nitro with the following command: diff --git a/docs/launch-arbitrum-chain/extend-the-protocol/stf.mdx b/docs/launch-arbitrum-chain/extend-the-protocol/stf.mdx index c8eb734e5c..9fa15bb3a2 100644 --- a/docs/launch-arbitrum-chain/extend-the-protocol/stf.mdx +++ b/docs/launch-arbitrum-chain/extend-the-protocol/stf.mdx @@ -18,7 +18,7 @@ Before customizing your Arbitrum chain, it's important to understand what the St This guide is only necessary for changes that modify the STF. To customize other node behavior, such as RPC behavior or the sequencer's ordering policy, you can simply -[build your own node](/run-arbitrum-node/nitro/01-build-nitro-locally.mdx) without worrying about the rest of this guide. However, changes that modify the STF require updating the fraud proving system to recognize the new behavior as correct. Otherwise, the fraud prover would side with unmodified nodes, which would win fraud proofs against your modified node. +[build your own node](/run-arbitrum-node/build-nitro-locally.mdx) without worrying about the rest of this guide. However, changes that modify the STF require updating the fraud proving system to recognize the new behavior as correct. Otherwise, the fraud prover would side with unmodified nodes, which would win fraud proofs against your modified node. Here's some examples of modifications that affect the STF: diff --git a/docs/run-arbitrum-node/nitro/01-build-nitro-locally.mdx b/docs/run-arbitrum-node/build-nitro-locally.mdx similarity index 100% rename from docs/run-arbitrum-node/nitro/01-build-nitro-locally.mdx rename to docs/run-arbitrum-node/build-nitro-locally.mdx diff --git a/docs/run-arbitrum-node/sequencer/03-run-sequencer-coordination-manager.mdx b/docs/run-arbitrum-node/sequencer/03-run-sequencer-coordination-manager.mdx index 19e46f804f..b821a2b329 100644 --- a/docs/run-arbitrum-node/sequencer/03-run-sequencer-coordination-manager.mdx +++ b/docs/run-arbitrum-node/sequencer/03-run-sequencer-coordination-manager.mdx @@ -16,7 +16,7 @@ The tool offers keyboard-only support. Any changes you make are stored locally u cd nitro ``` -- Before starting the Sequencer Coordinator Manager, please read and follow the commands in Step 4 - Step 7 of [Build Nitro's binaries natively](../nitro/01-build-nitro-locally.mdx#build-nitros-binaries-natively) to install the necessary dependencies. +- Before starting the Sequencer Coordinator Manager, please read and follow the commands in Step 4 - Step 7 of [Build Nitro's binaries natively](../build-nitro-locally.mdx#build-nitros-binaries-natively) to install the necessary dependencies. - Here is an example of how to start the Sequencer Coordinator Manager and connect to a local Redis server: ```shell diff --git a/redirects.config.js b/redirects.config.js index dbc2619812..008f36bf4f 100644 --- a/redirects.config.js +++ b/redirects.config.js @@ -467,5 +467,9 @@ export const redirects = [ from: '/run-arbitrum-node/nitro/migrate-state-and-history-from-classic', to: '/run-arbitrum-node/operation/migrate-state-and-history-from-classic', }, + { + from: '/run-arbitrum-node/nitro/build-nitro-locally', + to: '/run-arbitrum-node/build-nitro-locally', + }, // AUTO-GENERATED REDIRECTS END ]; diff --git a/sidebars.js b/sidebars.js index f4b5d0fc78..710fc0b84a 100644 --- a/sidebars.js +++ b/sidebars.js @@ -849,7 +849,7 @@ const sidebars = { }, { type: 'doc', - id: 'run-arbitrum-node/nitro/build-nitro-locally', + id: 'run-arbitrum-node/build-nitro-locally', label: 'Build Nitro locally', }, { diff --git a/vercel.json b/vercel.json index e10b648ecf..95b69884fa 100644 --- a/vercel.json +++ b/vercel.json @@ -591,6 +591,11 @@ "destination": "/run-arbitrum-node/operation/migrate-state-and-history-from-classic", "permanent": false }, + { + "source": "/run-arbitrum-node/nitro/build-nitro-locally", + "destination": "/run-arbitrum-node/build-nitro-locally", + "permanent": false + }, { "source": "/__redirects-autogen-end__", "destination": "/", "permanent": false }, { "source": "/(anytrust/?)", From d3d34714bce8d7114ce4525cb3b3a0d79846c6bb Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 8 Sep 2026 14:07:13 -0500 Subject: [PATCH 8/9] moving docker-and-cli-binaries to run-arbitrum-node/reference --- docs/run-arbitrum-node/operation/assign-node-roles.mdx | 2 +- docs/run-arbitrum-node/reference/cli-flags-reference.mdx | 6 +++--- .../{nitro => reference}/docker-and-cli-binaries.mdx | 0 redirects.config.js | 4 ++++ vercel.json | 5 +++++ 5 files changed, 13 insertions(+), 4 deletions(-) rename docs/run-arbitrum-node/{nitro => reference}/docker-and-cli-binaries.mdx (100%) diff --git a/docs/run-arbitrum-node/operation/assign-node-roles.mdx b/docs/run-arbitrum-node/operation/assign-node-roles.mdx index fd793976b6..50e3178a6e 100644 --- a/docs/run-arbitrum-node/operation/assign-node-roles.mdx +++ b/docs/run-arbitrum-node/operation/assign-node-roles.mdx @@ -169,7 +169,7 @@ On the main node (`nitro` binary): The validation server holds no wallet and posts no bond, and it is stateless — it runs with an ephemeral data directory, so you can replace a server in place, or add servers with a node restart, without losing any validation progress. The `--auth.*` flags exist on both binaries with the same defaults; on the main node they back the default `self-auth` loopback. Switching between in-process and split validation is a configuration change plus a restart; no database migration is involved. -For Docker images, Helm charts, and the full setup, see [Run a split validator node](/launch-arbitrum-chain/run-a-node/split-validator-node.mdx) and [Docker images and CLI binaries](/run-arbitrum-node/nitro/docker-and-cli-binaries.mdx). +For Docker images, Helm charts, and the full setup, see [Run a split validator node](/launch-arbitrum-chain/run-a-node/split-validator-node.mdx) and [Docker images and CLI binaries](/run-arbitrum-node/reference/docker-and-cli-binaries.mdx). ## Feed relay diff --git a/docs/run-arbitrum-node/reference/cli-flags-reference.mdx b/docs/run-arbitrum-node/reference/cli-flags-reference.mdx index 65a3d8bff3..dd85c67597 100644 --- a/docs/run-arbitrum-node/reference/cli-flags-reference.mdx +++ b/docs/run-arbitrum-node/reference/cli-flags-reference.mdx @@ -19,7 +19,7 @@ import { VanillaAdmonition } from '@site/src/components/VanillaAdmonition/'; This page lists every CLI flag accepted by the Nitro node binary. For explanations, examples, and recommended configurations, see the curated guides: - [Configuration system](/run-arbitrum-node/reference/configuration-system) -- [Docker and CLI binaries](/run-arbitrum-node/nitro/docker-and-cli-binaries) +- [Docker and CLI binaries](/run-arbitrum-node/reference/docker-and-cli-binaries) - [Node tuning and monitoring](/run-arbitrum-node/operation/node-tuning-and-monitoring) - [DA tools reference](/run-arbitrum-node/reference/da-tools-reference) @@ -346,7 +346,7 @@ Related guide: [Configuration system](/run-arbitrum-node/reference/configuration ## init -Related guide: [Docker and CLI binaries](/run-arbitrum-node/nitro/docker-and-cli-binaries) +Related guide: [Docker and CLI binaries](/run-arbitrum-node/reference/docker-and-cli-binaries)
init flags (29) @@ -900,7 +900,7 @@ Related guide: [Configuration system](/run-arbitrum-node/reference/configuration ## persistent -Related guide: [Docker and CLI binaries](/run-arbitrum-node/nitro/docker-and-cli-binaries) +Related guide: [Docker and CLI binaries](/run-arbitrum-node/reference/docker-and-cli-binaries)
persistent flags (8) diff --git a/docs/run-arbitrum-node/nitro/docker-and-cli-binaries.mdx b/docs/run-arbitrum-node/reference/docker-and-cli-binaries.mdx similarity index 100% rename from docs/run-arbitrum-node/nitro/docker-and-cli-binaries.mdx rename to docs/run-arbitrum-node/reference/docker-and-cli-binaries.mdx diff --git a/redirects.config.js b/redirects.config.js index 008f36bf4f..1892576484 100644 --- a/redirects.config.js +++ b/redirects.config.js @@ -471,5 +471,9 @@ export const redirects = [ from: '/run-arbitrum-node/nitro/build-nitro-locally', to: '/run-arbitrum-node/build-nitro-locally', }, + { + from: '/run-arbitrum-node/nitro/docker-and-cli-binaries', + to: '/run-arbitrum-node/reference/docker-and-cli-binaries', + }, // AUTO-GENERATED REDIRECTS END ]; diff --git a/vercel.json b/vercel.json index 95b69884fa..23ab76c495 100644 --- a/vercel.json +++ b/vercel.json @@ -596,6 +596,11 @@ "destination": "/run-arbitrum-node/build-nitro-locally", "permanent": false }, + { + "source": "/run-arbitrum-node/nitro/docker-and-cli-binaries", + "destination": "/run-arbitrum-node/reference/docker-and-cli-binaries", + "permanent": false + }, { "source": "/__redirects-autogen-end__", "destination": "/", "permanent": false }, { "source": "/(anytrust/?)", From 18cb615d6fa4582673ab9afd27d8779d4e9e7ad2 Mon Sep 17 00:00:00 2001 From: Pete Date: Wed, 9 Sep 2026 06:55:44 -0500 Subject: [PATCH 9/9] Adjusting sidebars; moving data-availability to HAW --- .../01-inside-arbitrum-nitro.mdx | 2 +- .../deep-dives}/data-availability.mdx | 0 .../deep-dives/finality.mdx | 2 +- .../costs/custom-gas-token-rollup.mdx | 2 +- .../run-a-node/run-full-node-with-helm.mdx | 2 +- .../data-availability/run-feed-relay.mdx | 2 +- .../more-types/02-run-validator-node.mdx | 2 +- .../operation/assign-node-roles.mdx | 2 +- .../sequencer/04-run-sequencer-node.mdx | 4 +- redirects.config.js | 4 + sidebars.js | 158 ++++++++++-------- vercel.json | 5 + 12 files changed, 110 insertions(+), 75 deletions(-) rename docs/{run-arbitrum-node => how-arbitrum-works/deep-dives}/data-availability.mdx (100%) diff --git a/docs/how-arbitrum-works/01-inside-arbitrum-nitro.mdx b/docs/how-arbitrum-works/01-inside-arbitrum-nitro.mdx index fbf9e64a73..e77690e0dd 100644 --- a/docs/how-arbitrum-works/01-inside-arbitrum-nitro.mdx +++ b/docs/how-arbitrum-works/01-inside-arbitrum-nitro.mdx @@ -163,7 +163,7 @@ AnyTrust enables cost-optimized data availability with a mild trust model that r Keysets define member keys and thresholds; DACerts include hashes, expirations, and signatures; and servers support various storage, such as local files or Amazon S3. The Sequencer sends batches to the committee, gathers signatures for DACerts, and posts them to Layer 1, defaulting to full data if the required signatures are not present. Ideal for low-cost apps like gaming. -For a more complete understanding of AnyTrust, refer to the [AnyTrust protocol documentation](/how-arbitrum-works/deep-dives/anytrust-protocol.mdx). For the operator-side view of running a DAS, see the [data availability node guide](/run-arbitrum-node/data-availability.mdx). +For a more complete understanding of AnyTrust, refer to the [AnyTrust protocol documentation](/how-arbitrum-works/deep-dives/anytrust-protocol.mdx). For the operator-side view of running a DAS, see the [data availability node guide](/how-arbitrum-works/deep-dives/data-availability.mdx). ## Related topics diff --git a/docs/run-arbitrum-node/data-availability.mdx b/docs/how-arbitrum-works/deep-dives/data-availability.mdx similarity index 100% rename from docs/run-arbitrum-node/data-availability.mdx rename to docs/how-arbitrum-works/deep-dives/data-availability.mdx diff --git a/docs/how-arbitrum-works/deep-dives/finality.mdx b/docs/how-arbitrum-works/deep-dives/finality.mdx index fd6a1d1865..3c47ff3104 100644 --- a/docs/how-arbitrum-works/deep-dives/finality.mdx +++ b/docs/how-arbitrum-works/deep-dives/finality.mdx @@ -66,7 +66,7 @@ Hard finality occurs when batched transactions are posted to the parent chain an - **Strong security guarantees**: When included in blocks on the parent chain, transactions inherit the parent chain’s security assurances. - **Irreversibility**: Once finalized, transactions are immutable and cannot be altered or reversed. -- **Data availability**: In the default [Rollup mode](/run-arbitrum-node/data-availability.mdx#rollup-mode), all transaction data is recorded onchain (via calldata or blobs), ensuring transparency and verifiability. On AnyTrust chains, batch data is instead kept offchain by a Data Availability Committee (DAC), and only a data availability certificate is posted onchain — trading full onchain data availability for lower cost. +- **Data availability**: In the default [Rollup mode](/how-arbitrum-works/deep-dives/data-availability.mdx#rollup-mode), all transaction data is recorded onchain (via calldata or blobs), ensuring transparency and verifiability. On AnyTrust chains, batch data is instead kept offchain by a Data Availability Committee (DAC), and only a data availability certificate is posted onchain — trading full onchain data availability for lower cost. ### Advantages of hard finality diff --git a/docs/launch-arbitrum-chain/chain-config/costs/custom-gas-token-rollup.mdx b/docs/launch-arbitrum-chain/chain-config/costs/custom-gas-token-rollup.mdx index 8d96a8c1b1..e7f0896569 100644 --- a/docs/launch-arbitrum-chain/chain-config/costs/custom-gas-token-rollup.mdx +++ b/docs/launch-arbitrum-chain/chain-config/costs/custom-gas-token-rollup.mdx @@ -8,7 +8,7 @@ content_type: how-to import CustomGasTokenNote from '../../partials/_custom-gas-token-note.mdx'; -When deploying an Arbitrum chain in [Rollup mode](/run-arbitrum-node/data-availability.mdx#rollup-mode), you can use a custom **ERC-20** token as the native gas token. This token is usable for Transaction fees on that specific Arbitrum chain and reimbursing the [Batch Poster](/how-arbitrum-works/deep-dives/assertions.mdx) for data posted to Ethereum. An example would be an L2 Rollup that uses **USDC** as its custom gas token but pays **ETH** to post data to L1 Ethereum. +When deploying an Arbitrum chain in [Rollup mode](/how-arbitrum-works/deep-dives/data-availability.mdx#rollup-mode), you can use a custom **ERC-20** token as the native gas token. This token is usable for Transaction fees on that specific Arbitrum chain and reimbursing the [Batch Poster](/how-arbitrum-works/deep-dives/assertions.mdx) for data posted to Ethereum. An example would be an L2 Rollup that uses **USDC** as its custom gas token but pays **ETH** to post data to L1 Ethereum. Enabling a custom fee token for a Rollup chain requires additional configuration compared to an [AnyTrust chain](/launch-arbitrum-chain/chain-config/costs/custom-gas-token-anytrust.mdx); it also introduces important exchange-rate considerations. This guide outlines specific implementation steps and operational considerations for chain owners or operators to consider when enabling a custom fee token for Rollups. diff --git a/docs/launch-arbitrum-chain/run-a-node/run-full-node-with-helm.mdx b/docs/launch-arbitrum-chain/run-a-node/run-full-node-with-helm.mdx index 9e385d8288..18f9f6a86c 100644 --- a/docs/launch-arbitrum-chain/run-a-node/run-full-node-with-helm.mdx +++ b/docs/launch-arbitrum-chain/run-a-node/run-full-node-with-helm.mdx @@ -91,7 +91,7 @@ configmap: helm install mychain-fullnode offchainlabs/nitro -f values-mychain.yaml ``` -If the parent chain is Ethereum, also set `configmap.data.parent-chain.blob-client.beacon-url`. AnyTrust chains additionally need a Data Availability configuration (`node.da.anytrust.*`, including a `rest-aggregator`); see [Data Availability](/run-arbitrum-node/data-availability.mdx). The older `node.data-availability.*` flags still work but are deprecated in Nitro and will be removed in a future release. +If the parent chain is Ethereum, also set `configmap.data.parent-chain.blob-client.beacon-url`. AnyTrust chains additionally need a Data Availability configuration (`node.da.anytrust.*`, including a `rest-aggregator`); see [Data Availability](/how-arbitrum-works/deep-dives/data-availability.mdx). The older `node.data-availability.*` flags still work but are deprecated in Nitro and will be removed in a future release. diff --git a/docs/run-arbitrum-node/data-availability/run-feed-relay.mdx b/docs/run-arbitrum-node/data-availability/run-feed-relay.mdx index fa711e6d6d..f79c09f947 100644 --- a/docs/run-arbitrum-node/data-availability/run-feed-relay.mdx +++ b/docs/run-arbitrum-node/data-availability/run-feed-relay.mdx @@ -13,7 +13,7 @@ Feed endpoints will soon require compression with a custom dictionary, so if con ::: -For context on where the feed relay fits into Arbitrum's overall data flow, see [Data availability](/run-arbitrum-node/data-availability.mdx#how-full-nodes-sync-the-data-from-the-sequencer-feed). For the wire format the feed delivers, see [How to read the sequencer feed](/run-arbitrum-node/sequencer/02-read-sequencer-feed.mdx). For how the feed relay compares to the other Nitro node roles, see [How to assign roles to a Nitro node](/run-arbitrum-node/operation/assign-node-roles.mdx). +For context on where the feed relay fits into Arbitrum's overall data flow, see [Data availability](/how-arbitrum-works/deep-dives/data-availability.mdx#how-full-nodes-sync-the-data-from-the-sequencer-feed). For the wire format the feed delivers, see [How to read the sequencer feed](/run-arbitrum-node/sequencer/02-read-sequencer-feed.mdx). For how the feed relay compares to the other Nitro node roles, see [How to assign roles to a Nitro node](/run-arbitrum-node/operation/assign-node-roles.mdx). The feed relay is in the same Docker image as the Nitro node. diff --git a/docs/run-arbitrum-node/more-types/02-run-validator-node.mdx b/docs/run-arbitrum-node/more-types/02-run-validator-node.mdx index 2b83ace23e..54383baf52 100644 --- a/docs/run-arbitrum-node/more-types/02-run-validator-node.mdx +++ b/docs/run-arbitrum-node/more-types/02-run-validator-node.mdx @@ -15,7 +15,7 @@ This how-to assumes that you're familiar with the following: - How to run a full node (see instructions [here](/run-arbitrum-node/02-run-full-node.mdx)) - [How the Rollup protocol works](/how-arbitrum-works/01-inside-arbitrum-nitro.mdx) - [How BoLD works](/how-arbitrum-works/bold/bold-technical-deep-dive.mdx#how-bold-leverages-ethereum), if you're running a validator for a chain that has BoLD activated -- [Data availability](/run-arbitrum-node/data-availability.mdx), for how Rollup-mode and AnyTrust-mode chains differ in the data your validator must reconstruct +- [Data availability](/how-arbitrum-works/deep-dives/data-availability.mdx), for how Rollup-mode and AnyTrust-mode chains differ in the data your validator must reconstruct - [How to assign roles to a Nitro node](/run-arbitrum-node/operation/assign-node-roles.mdx), for how the validator role relates to the other node roles and what converting a node to a validator involves ## Validation strategies diff --git a/docs/run-arbitrum-node/operation/assign-node-roles.mdx b/docs/run-arbitrum-node/operation/assign-node-roles.mdx index 50e3178a6e..26fc3622fb 100644 --- a/docs/run-arbitrum-node/operation/assign-node-roles.mdx +++ b/docs/run-arbitrum-node/operation/assign-node-roles.mdx @@ -212,4 +212,4 @@ Role-specific conversion notes: - **Moving validation to a separate machine (split validation):** start `nitro-val` on the new machine with the validation machine folders and a reachable `--auth.addr`, share the JWT secret file between the two processes, and point the node's `--node.block-validator.validation-server.url` and `.jwtsecret` at the server (the full guide uses the equivalent `--node.block-validator.validation-server-configs-list` JSON form, which is also how you configure multiple servers). Validation progress stays in the node's database, so this is a flags-and-restart change in both directions. - **Decommissioning an active validator:** do not simply kill the node. On pre-BoLD chains, a staker that keeps running with its wallet and an active strategy (`defensive` keeps the wallet loaded without seeking new bonds) automatically returns its old deposit and withdraws the funds once the assertion it bonded on is confirmed; only then switch to `watchtower` or disable the staker and shut down. Switching to `watchtower` too early doesn't work: it loads no wallet, so nothing can withdraw. On BoLD chains, withdrawing the bond is a manual onchain operation. Either way, stopping the node early leaves the bond locked onchain until you withdraw it. -For background on how nodes fit together, see the [Nodes overview](/run-arbitrum-node/01-overview.mdx) and, for the data flow between the sequencer, feed, and full nodes, [Data availability](/run-arbitrum-node/data-availability.mdx#how-full-nodes-sync-the-data-from-the-sequencer-feed). +For background on how nodes fit together, see the [Nodes overview](/run-arbitrum-node/01-overview.mdx) and, for the data flow between the sequencer, feed, and full nodes, [Data availability](/how-arbitrum-works/deep-dives/data-availability.mdx#how-full-nodes-sync-the-data-from-the-sequencer-feed). diff --git a/docs/run-arbitrum-node/sequencer/04-run-sequencer-node.mdx b/docs/run-arbitrum-node/sequencer/04-run-sequencer-node.mdx index b4c029c5c6..5a125060bf 100644 --- a/docs/run-arbitrum-node/sequencer/04-run-sequencer-node.mdx +++ b/docs/run-arbitrum-node/sequencer/04-run-sequencer-node.mdx @@ -15,7 +15,7 @@ We also provide a [guide for running a high-availability sequencer node for an A This how-to provides step-by-step instructions for running a sequencer node on your local machine. -For background on how sequencers fit into Arbitrum's data flow (batch posting, the sequencer feed, and how full nodes consume sequencer output), see [Data availability](/run-arbitrum-node/data-availability.mdx). For how the sequencer role relates to the other Nitro node roles and the flags that define them, see [How to assign roles to a Nitro node](/run-arbitrum-node/operation/assign-node-roles.mdx). +For background on how sequencers fit into Arbitrum's data flow (batch posting, the sequencer feed, and how full nodes consume sequencer output), see [Data availability](/how-arbitrum-works/deep-dives/data-availability.mdx). For how the sequencer role relates to the other Nitro node roles and the flags that define them, see [How to assign roles to a Nitro node](/run-arbitrum-node/operation/assign-node-roles.mdx). ## Minimum hardware configuration @@ -108,7 +108,7 @@ Enable your node to feed out transactions so full node can receive queued transa :::note -This step is only required in Anytrust mode. For an explanation of AnyTrust mode and the role of the Data Availability Committee (DAC), see [AnyTrust Mode](/run-arbitrum-node/data-availability.mdx#anytrust-mode). +This step is only required in Anytrust mode. For an explanation of AnyTrust mode and the role of the Data Availability Committee (DAC), see [AnyTrust Mode](/how-arbitrum-works/deep-dives/data-availability.mdx#anytrust-mode). As of Nitro v3.10.0, these settings live under `--node.da.anytrust.*` (the previous `--node.data-availability.*` namespace is deprecated), and the node no longer takes `sequencer-inbox-address` or `parent-chain-node-url` in this section — it uses the chain info and the `--parent-chain.connection.url` configuration instead. diff --git a/redirects.config.js b/redirects.config.js index 1892576484..130ce39278 100644 --- a/redirects.config.js +++ b/redirects.config.js @@ -475,5 +475,9 @@ export const redirects = [ from: '/run-arbitrum-node/nitro/docker-and-cli-binaries', to: '/run-arbitrum-node/reference/docker-and-cli-binaries', }, + { + from: '/run-arbitrum-node/data-availability', + to: '/how-arbitrum-works/deep-dives/data-availability', + }, // AUTO-GENERATED REDIRECTS END ]; diff --git a/sidebars.js b/sidebars.js index 710fc0b84a..ae05709ff0 100644 --- a/sidebars.js +++ b/sidebars.js @@ -719,11 +719,6 @@ const sidebars = { id: 'run-arbitrum-node/run-full-node', label: 'Run a full node', }, - { - type: 'doc', - id: 'run-arbitrum-node/operation/assign-node-roles', - label: 'Assign node roles', - }, { type: 'doc', id: 'run-arbitrum-node/run-local-full-chain-simulation', @@ -743,23 +738,18 @@ const sidebars = { }, { type: 'doc', - id: 'run-arbitrum-node/reference/l1-ethereum-beacon-chain-rpc-providers', - label: 'L1 Ethereum RPC providers', - }, - { - type: 'doc', - id: 'run-arbitrum-node/data-availability', - label: 'Data Availability', + id: 'run-arbitrum-node/build-nitro-locally', + label: 'Build Nitro locally', }, { type: 'doc', - id: 'run-arbitrum-node/data-availability/run-feed-relay', - label: 'Run a feed relay', + id: 'run-arbitrum-node/troubleshooting', + label: 'Troubleshooting', }, { type: 'doc', - id: 'run-arbitrum-node/data-availability/beacon-nodes-historical-blobs', - label: 'Historical blobs', + label: 'FAQ', + id: 'node-running/faq', }, { type: 'category', @@ -803,6 +793,23 @@ const sidebars = { }, ], }, + { + type: 'category', + label: 'Data availability', + collapsed: true, + items: [ + { + type: 'doc', + id: 'run-arbitrum-node/data-availability/beacon-nodes-historical-blobs', + label: 'Historical blobs', + }, + { + type: 'doc', + id: 'run-arbitrum-node/data-availability/run-feed-relay', + label: 'Run feed relay', + }, + ], + }, { type: 'category', label: 'More node types', @@ -825,6 +832,70 @@ const sidebars = { }, ], }, + { + type: 'category', + label: 'Operation', + collapsed: true, + items: [ + { + type: 'doc', + id: 'run-arbitrum-node/operation/assign-node-roles', + label: 'Assign node roles', + }, + { + type: 'doc', + id: 'run-arbitrum-node/operation/how-to-convert-databases-from-leveldb-to-pebble', + label: 'Convert LevelDB to PebbleDB', + }, + { + type: 'doc', + id: 'run-arbitrum-node/operation/migrate-state-and-history-from-classic', + label: 'Migrate state history from Classic', + }, + { + type: 'doc', + id: 'run-arbitrum-node/operation/node-tuning-and-monitoring', + label: 'Node tuning and monitoring', + }, + ], + }, + { + type: 'category', + label: 'Reference', + collapsed: true, + items: [ + { + type: 'doc', + id: 'run-arbitrum-node/reference/cli-flags-reference', + label: 'CLI flags', + }, + { + type: 'doc', + id: 'run-arbitrum-node/reference/configuration-system', + label: 'Configuration system', + }, + { + type: 'doc', + id: 'run-arbitrum-node/reference/da-tools-reference', + label: 'DA tools', + }, + { + type: 'doc', + id: 'run-arbitrum-node/reference/docker-and-cli-binaries', + label: 'Docker and CLI binaries', + }, + { + type: 'doc', + id: 'run-arbitrum-node/reference/l1-ethereum-beacon-chain-rpc-providers', + label: 'Ethereum beacon chain RPC providers', + }, + { + type: 'doc', + id: 'run-arbitrum-node/reference/nitro-database-snapshots', + label: 'Database snapshots', + }, + ], + }, { type: 'category', label: 'Sequencer', @@ -847,56 +918,6 @@ const sidebars = { }, ], }, - { - type: 'doc', - id: 'run-arbitrum-node/build-nitro-locally', - label: 'Build Nitro locally', - }, - { - type: 'doc', - id: 'run-arbitrum-node/operation/migrate-state-and-history-from-classic', - label: 'Migrate to Nitro from Classic', - }, - { - type: 'doc', - id: 'run-arbitrum-node/reference/nitro-database-snapshots', - label: 'Database snapshots', - }, - { - type: 'doc', - id: 'run-arbitrum-node/operation/how-to-convert-databases-from-leveldb-to-pebble', - label: 'Convert databases from LevelDB to Pebble', - }, - { - type: 'doc', - id: 'run-arbitrum-node/operation/node-tuning-and-monitoring', - label: 'Node tuning and monitoring', - }, - { - type: 'doc', - id: 'run-arbitrum-node/reference/configuration-system', - label: 'Configuration system', - }, - { - type: 'doc', - id: 'run-arbitrum-node/reference/da-tools-reference', - label: 'DA tools reference', - }, - { - type: 'doc', - id: 'run-arbitrum-node/reference/cli-flags-reference', - label: 'CLI flags reference', - }, - { - type: 'doc', - id: 'run-arbitrum-node/troubleshooting', - label: 'Troubleshooting', - }, - { - type: 'doc', - label: 'FAQ', - id: 'node-running/faq', - }, ], }, { @@ -1048,6 +1069,11 @@ const sidebars = { label: 'Gas and fees', id: 'how-arbitrum-works/deep-dives/gas-and-fees', }, + { + type: 'doc', + label: 'Data availability', + id: 'how-arbitrum-works/deep-dives/data-availability', + }, { type: 'doc', label: 'STF inputs', diff --git a/vercel.json b/vercel.json index 23ab76c495..43788cf18e 100644 --- a/vercel.json +++ b/vercel.json @@ -601,6 +601,11 @@ "destination": "/run-arbitrum-node/reference/docker-and-cli-binaries", "permanent": false }, + { + "source": "/run-arbitrum-node/data-availability", + "destination": "/how-arbitrum-works/deep-dives/data-availability", + "permanent": false + }, { "source": "/__redirects-autogen-end__", "destination": "/", "permanent": false }, { "source": "/(anytrust/?)",