Skip to content
Merged
24 changes: 15 additions & 9 deletions docs/run-arbitrum-node/02-run-full-node.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -33,6 +33,7 @@ Please note that:
- The minimum requirements for RAM and CPU listed here are recommended for nodes that handle a limited number of RPC requests. For nodes that need to process multiple simultaneous requests, both the RAM size and the number of CPU cores should be increased to accommodate higher levels of traffic.
- Single core performance is important. If the node is falling behind and a single core is 100% busy, the recommendation is to upgrade to a faster processor
- The minimum storage requirements will change over time as the chain grows. Using more than the minimum requirements to run a robust full node is recommended.
- Path-based state schemes are supported for Nitro's state trie, but only for full nodes and archive nodes at this time, and not validators yet. As a result, HashDB is still the default state scheme used by Nitro, and you must take explicit action to enable PathDB. You can find more details in the table below for optional parameters.

### Recommended Nitro version

Expand All @@ -48,7 +49,9 @@ Latest [Docker image](https://hub.docker.com/r/offchainlabs/nitro-node/tags): <c

::::info Snapshots availability

Database snapshots are available and located in the [snapshot explorer](https://snapshot-explorer.arbitrum.io/) for Arbitrum One, Arbitrum Nova, and Arbitrum Sepolia. Database snapshots for other Arbitrum chains may be available at the discretion of the team running the chain. Please get in touch with them if you're interested in using a database snapshot for their chains.
Database snapshots are available and located in the [snapshot explorer](https://snapshot-explorer.arbitrum.io/) for Arbitrum One, Arbitrum Nova, and Arbitrum Sepolia. Currently, only archive node snapshots using PathDB are available for Arbitrum One and Arbitrum Sepolia. Pruned PathDB snapshots for full nodes on Arbitrum One and Arbitrum Sepolia will be uploaded soon.

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.

::::

Expand All @@ -60,6 +63,7 @@ We provide a summary of the available parameters here, but we recommend reading
- 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.
- 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.

:::warning Fusaka upgrade: Historical blobs

Expand Down Expand Up @@ -160,18 +164,20 @@ docker run --rm -it -v /Path/to/mount/arbitrum:/home/user/.arbitrum -v /Path/to/

### Pruning

- Pruning a full node refers to removing older, unnecessary data from the local copy of the blockchain that the node maintains, thereby saving disk space and slightly improving the node's efficiency. Pruning will remove all states from blocks older than the latest 128.
- If you are using the default setting `--execution.caching.state-scheme=hash` then you can activate pruning by using the parameter:
- `--init.prune <pruning mode>`
- `minimal`: Only genesis + latest head state is left, takes the least amount of time (several hours for Arbitrum One-sized database)
- `full` : Genesis + head state + state for latest confirmed block (will take a long time ~50 hours or more)
- `validator`: All of above + state of latest validated block (will take a little less than twice what `full` will take)
By default, all node types will use HashDB, go-ethereum's original state trie storage scheme. This will be the case until a path-based state scheme (e.g., PathDB) is supported across all Arbitrum node types. This means that, by default, pruning will continue to be an _manual opt-in_ operation, should an operator decide to do so. As a refresher, pruning a full node means removing older, unnecessary data from the local copy of the blockchain the node maintains, thereby saving disk space and slightly improving the node's efficiency. Pruning will remove all states from blocks older than the latest 128.

For nodes using PathDB, pruning will be automatic, can be done online, and defaults to retaining only the last 24 hours' worth of state history on disk.

:::note
The pruning process occurs when the node starts (upon initialization) and will not serve RPC requests during pruning.
:::

This process occurs when the node starts and will not serve RPC requests during pruning.
If you are using the default storage scheme (HashDB), then you can activate pruning by using the parameter:

:::
- `--init.prune <pruning mode>`, where `<pruning mode>` can be one of:
- `minimal`: The most aggressive prune and retains only the genesis state and the head state (at the latest snapshot). Takes the least amount of time to complete (approx. several hours)
- `full` : Mostly meant for full nodes serving RPC requests, this mode retains the genesis state, the state of the latest confirmed block, and the head state (at the latest snapshot). Will not work if the node is in `validator` mode. This may take a long time (~50hrs)
- `validator`: Meant to be used by validator nodes and requires an RPC URL for L1 Ethereum. This mode retains the genesis state, the state of the latest confirmed block, the latest confirmed assertion root (obtained from L1), the last locally validated block root, and the head state (at the latest snapshot). This mode is expected to take about half as long as `full` pruning mode.

### Transaction prechecker

Expand Down
74 changes: 30 additions & 44 deletions docs/run-arbitrum-node/more-types/01-run-archive-node.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -16,7 +16,7 @@ An Arbitrum **archive node** is a full node that maintains an archive of histori

## Before we begin

Before the Nitro upgrade, Arbitrum One ran on the Classic stack for about one year (before block height 22207817). Although the Nitro chain uses the latest snapshot of the Classic chain's state as its genesis state, **the Nitro stack can serve all but six RPC requests for pre-Nitro blocks. Full details are outlined [here](/run-arbitrum-node/more-types/03-run-classic-node.mdx#do-you-need-to-run-a-classic-node).**.
Before the Nitro upgrade, Arbitrum One ran on the Classic stack for about one year (before block height 22207817). Although the Nitro chain uses the latest snapshot of the Classic chain's state as its genesis state, **the Nitro stack can serve all but six RPC requests for pre-Nitro blocks. Full details are outlined in [Do you need to run a Classic node?](/run-arbitrum-node/more-types/03-run-classic-node.mdx#do-you-need-to-run-a-classic-node).**

Running an Arbitrum One **full node** in **archive mode** lets you access both pre-Nitro and post-Nitro blocks, but it requires you to run **both Classic and Nitro nodes** together. You may not need to do this, depending on your use case:

Expand All @@ -28,46 +28,40 @@ Running an Arbitrum One **full node** in **archive mode** lets you access both p
| Send **pre-Nitro** archive requests | Full node (Classic) | [How to run a full node (Classic, pre-Nitro)](/run-arbitrum-node/more-types/03-run-classic-node.mdx) |
| Send **post-Nitro** _and_ **pre-Nitro** archive requests | Full node (Nitro) _and_ full node (Classic) | That's what this how-to is for; you're in the right place. |

:::info Archive-path node
:::info Archive nodes using PathDB (path-based state scheme)

A Nitro Archive-path node is similar to a hash archive node; with the exception that a Nitro Archive-path Node takes significantly less disk space ~4TB (Arbitrum One). During sync and serving RPC calls it should be equivalent or potentially slightly better than the Archive (hash) node.
A Nitro archive node using PathDB is similar to an archive node using HashDB (default), with the exception that a Nitro archive node using PathDB takes significantly less disk space (~4TB for Arbitrum One). During sync and serving RPC calls, an archive node using PathDB should be equivalent to, or slightly better than, one using HashDB.

The recommendation is to use Nitro >= v.3.9.x to use Archive-path node.
We recommend using PathDB for archive nodes, but only on Nitro versions >= v3.9.x.

**Features**:
**Benefits of PathDB**:

- **Low disk usage**: Under ~4 TB for Arbitrum One
- **Configurable retention**: users can choose how many historical states to retain
- **Lower disk usage**: Under ~4 TB for Arbitrum One
- **Configurable retention**: users can choose how many historical states to retain (using `--execution.caching.state-history`)

**Limitations**:

- block validation in not yet supported with path state scheme
- fast NVME storage is required for reasonable sync speed
- Snapshot auto-download with `--init.latest` is not yet supported
Block validation is not yet supported with the path-based state scheme. In other words, validators cannot use PathDB yet.

:::

## System requirements

:::caution
- Fast, local NVMe SSD storage is required for reasonable sync speed.
- PathDB snapshot auto-downloads with `--init.latest` are not yet supported.

As of May 2024, archive node snapshots for Arbitrum One, Arbitrum Nova, and Arbitrum Sepolia are no longer being updated on https://snapshot-explorer.arbitrum.io/ due to accelerated database and state growth. Teams who use these publicly available archive snapshots will need to wait longer than usual for their nodes to sync up.
To enable PathDB on your archive node, start your node with the following flags:

The Offchain Labs team is actively exploring and working on solutions to address this and will provide an update as soon as possible. In the meantime, the Offchain Labs team continues to recommend that teams periodically create their own snapshots by stopping one of their archive nodes and backing up their database.
```shell
--execution.caching.state-scheme=path
--execution.caching.state-history=0
```

:::

:::caution

The minimum storage requirements will change as the Nitro chains grow (growing rates are specified below). We recommend exceeding the minimum requirements as much as you can to minimize risk and maintenance overhead.
## System requirements

:::
The minimum storage requirements will change as the Nitro chains grow (see the growth rates below). We recommend exceeding the minimum requirements as much as you can to minimize risk and maintenance overhead. The disk size for archive nodes is expected to grow over time. Carefully monitor your node's disk requirements and disk growth rates to ensure your node has adequate resources.

1. **RAM:** 16GB+ for Nitro and 32GB+ for Classic
2. **CPU:** 4+ core CPU
3. **Storage (last updated on April 2024):**
- Arbitrum One: 9.7TB SSD, currently growing at a rate of about 850GB per month
- Arbitrum Nova: 4.3TB SSD, currently growing at a rate of about 1.8TB GB per month
1. **RAM:** 64GB+ for Nitro and 32GB+ for Classic
2. **CPU:** 8+ core CPU
3. **Storage (PathDB, last updated on March 2026):** Arbitrum One: 3.27TB SSD, currently growing at a rate of ~100GB/month.
4. **Docker images:** We'll specify these in the below commands; you don't need to download them manually.
- Latest Docker image for **Arbitrum One Nitro**: <code>@@latestNitroNodeImage=offchainlabs/nitro-node:v3.9.7-75e084e@@</code>
- Latest Docker image for **Arbitrum One Classic**: <code>@@latestClassicNodeImage=offchainlabs/arb-node:v1.4.6-551a39b3@@</code>
Expand All @@ -92,13 +86,16 @@ The minimum storage requirements will change as the Nitro chains grow (growing r

## Review and configure parameters

| Arbitrum Nitro | Arbitrum Classic | Description |
| ---------------------------------------------------------- | ------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `--parent-chain.connection.url=<Layer 1 Ethereum RPC URL>` | `--l1.url=<Layer 1 Ethereum RPC URL>` | Provide an standard L1 node RPC endpoint that you run yourself or from a third-party node provider (see [RPC endpoints and providers](/build-decentralized-apps/reference/01-node-providers.mdx)) |
| `--chain.id=<L2 chain ID>` | `--l2.chain-id=<L2 Chain ID>` | See [RPC endpoints and providers](/build-decentralized-apps/reference/01-node-providers.mdx) for a list of Arbitrum chains and the respective child chain IDs |
| `--execution.caching.archive` | `--node.caching.archive` | Required for running an **Arbitrum One Nitro** archival node and retains past block state |
| - | `--node.cache.allow-slow-lookup` | Required for running an **Arbitrum One Classic** archival node. When this option is present, it will load old blocks from disk if not in memory cache. |
| - | `--core.checkpoint-gas-frequency=156250000` | Required for running an **Arbitrum One Classic** archival node. |
| Arbitrum Nitro | Arbitrum Classic | Description |
| ---------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `--parent-chain.connection.url=<Layer 1 Ethereum RPC URL>` | `--l1.url=<Layer 1 Ethereum RPC URL>` | Provide an standard L1 node RPC endpoint that you run yourself or from a third-party node provider (see [RPC endpoints and providers](/build-decentralized-apps/reference/01-node-providers.mdx)) |
| `--chain.id=<L2 chain ID>` | `--l2.chain-id=<L2 Chain ID>` | See [RPC endpoints and providers](/build-decentralized-apps/reference/01-node-providers.mdx) for a list of Arbitrum chains and the respective child chain IDs |
| `--execution.caching.archive` | `--node.caching.archive` | Required for running an **Arbitrum One Nitro** archival node and retains past block state |
| `--execution.caching.state-scheme` | Default: `hash`. This flag sets the schema used in Nitro's state trie, inherited from Geth. You can set this to `path` to enable PathDB, but note that PathDB isn't yet supported for validators. |
| `--execution.caching.state-history` | Default: ~345,600 blocks, or approximately 24 hours worth of blocks. Number of recent blocks of state history to retain on disk. Set to `0` for unlimited (that is, archive nodes). Only available for PathDB-enabled nodes. |
| `--execution.caching.pathdb-max-diff-layers` | Default: 128 layers. Maximum in-memory diff layers before flushing to disk. Controls the trade-off between memory usage and how often the node flushes its layered diffs to the disk layer. More layers usually imply higher memory usage and lower flush frequency. Only available for PathDB-enabled nodes. |
| - | `--node.cache.allow-slow-lookup` | Required for running an **Arbitrum One Classic** archival node. When this option is present, it will load old blocks from disk if not in memory cache. |
| - | `--core.checkpoint-gas-frequency=156250000` | Required for running an **Arbitrum One Classic** archival node. |
| |

## Run the Docker image(s)
Expand Down Expand Up @@ -127,17 +124,6 @@ To run both Arbitrum Nitro and/or Arbitrum Classic in archive mode, follow one o

Note that the above commands both map to port `8547` on their hosts. To run both on the same host, you should edit those mapping to different ports and specify your Classic node RPC URL as `<classic node RPC>` in your Nitro start command. To verify the connection health of your node(s), see [Docker network between containers - Docker Networking Example](https://www.middlewareinventory.com/blog/docker-network-example/).

:::note Additional flags for Archive-path nodes

For a Nitro path archive node, use the additional flags to start the node:

```shell
execution.caching.state-scheme=path
execution.caching.state-history=0
```

:::

### A note on permissions

The Docker image is configured to run as non-root `UID 1000`. If you're running in Linux and you're getting permission errors when trying to run the Docker image, run this command to allow all users to update the persistent folders, replacing `arbitrum-mainnet` as needed:
Expand Down
Loading
Loading