Skip to main content

Frequently asked questions: Run a node

How do I run a node?​

See instructions here!

How to verify the integrity of the Nitro database I currently have?​

We have an accumulator hash on all messages, which means that a message can't be added to the database without the previous message being correct.

To confirm that everything's working properly, you could just make sure that it's syncing and that the latest block is consistent with other Arbitrum nodes; e.g., you could check it against Arbiscan (note that Arbiscan's search field doesn't support searching by block hash).

How can I check if the node is running properly and diagnose the issue if it is not?​

We have trace-level logging RPC request implemented on our node. You could use it to log all requests and responses at the trace level. (The performance impact of this should be negligible compared to the network overhead of an RPC request in the first place, especially considering that the request/response will only be serialized for logging if that log level is enabled.)

Why do I need an L1 node to run an Arbitrum node?​

On the node syncing stage, Arbitrum nodes read transactions from batches that were previously posted on L1 and have been executed. They then connect to the Sequencer feed to receive new incoming batched transactions that have not yet been posted on L1.

When fully synced, the Arbitrum node uses the State Transition Function (STF) to consume transactions coming from the Sequencer feed and creates a new state. It also waits for the L1 batch to be posted. If the L1 batch that is finalized on L1 is different from what the Sequencer published, the node will change the state based on the L1 batched transactions.

Can I run an Arbitrum node in p2p mode?​

Arbitrum doesn't have a consensus mechanism, so "p2p mode" doesn't apply. For nodes to sync to the latest chain state, they connect to an L1 node to sync the chain's history that's been posted in calldata and connect to the Sequencer feed for the transactions that have yet to be posted in batches. In no case do nodes need to peer up and sync with each other.

How do I read messages from the Sequencer feed?​

Running an Arbitrum relay locally as a Feed Relay lets you subscribe to the Sequencer feed for real-time data as the Sequencer accepts and orders transactions off-chain. Visit How to read the sequencer feed for a detailed how-to.

How do I run a node locally for development?​

See instructions here.

We recommend running nitro nodes via docker; to compile directly / run without docker, you can follow the steps in this file then run the executable directly.

Is there any way to retrieve pre-Nitro archive data from a Nitro node?​

The pre-nitro stack is also referred to as a "classic" stack. Full nitro nodes start with a database that contains the information from the "classic" era. However, it is not possible for a nitro node to query archive information contained in "classic" blocks right away. To do that, you need to also run a classic node (instructions here) and set the parameter —node.rpc.classic-redirect=your-classic-node-RPC.

Keep in mind that this information only applies to Arbitrum One nodes. Arbitrum Nova and Arbitrum Goerli nodes started with a Nitro stack from the beginning, so they don't have "classic" data.

How can I verify that my node is syncing at a desirable speed?​

Syncing speed can vary depending on multiple factors. You can find the minimum hardware requirements to run your node in this page. You should also verify your network and disk speed.

How can I verify that my node is fully synced?​

You can make an eth_syncing RPC call to your node. When a nitro node is fully synced, eth_syncing returns the value false (just like a normal Geth node).

When a nitro node is still syncing, eth_syncing returns a map of values to help understand why the node is not synced. Nitro execution and bottleneck are different from a normal Geth node, so eth_syncing output is unique to nitro. Here, we provide more details:

Messages, Batches, and Blocks:

Nitro node reads messages from the parent chain an optionally from the message feed. It executes these messages and produces blocks. Each message produces exactly one block (a message may contain multiple transactions). In most nitro chains, message number and block number are the same. However, Arbitrum One chain has pre-nitro blocks, so for that chain message 0 produced block #XXXX, the offset between message and block number is constant in the chain.

On the parent chain, messages appear in batches. The number of messages per batch changes between batches.

eth_syncing Fields:

⚠️ Note that the exact output for eth_syncing RPC call of an out-of-sync nitro node is not considered a stable API. It is still being actively developed and modified without notice between versions.

  • batchSeen is the last batch number observed on the parent chain
  • batchProcessed is the last batch that was processed on the parent chain. Processing means dividing the batch into messages
  • messageOfProcessedBatch is the last message in the last processed batch
  • msgCount specifies the number of messages known/queued by the nitro node
  • blockNum is the last block created by the nitro node (up-to-date L2 block the node is synced to)
  • messageOfLastBlock is the message that was used to produce the block above
  • broadcasterQueuedMessagesPos If ≠0, this is expected to be > msgCount. This field notes a message that was read from the feed but not processed because earlier messages are still missing
  • lastL1BlockNum, lastl1BlockHash The last block number and hash from parent chain that nitro sees. This is used to debug the parent-chain connection

⚠️ Note that if the sync process encounters an error while trying to collect the data above (not expected) this error will be added to the response.

Expected Stages of Syncing Nodes:

  • batchSeen > batchProcessed Some batches were still not processed
  • msgCount > messageOfLastBlock Some messages were processed but not all relevant blocks were built (usually the longest stage while syncing a new node)
  • broadcasterQueuedMessagesPos > msgCount Feed is ahead of last message known to the node

Is there an alternative to docker when running a node?​

We recommend running nitro nodes via docker, using the guides provided within our documentation. However, you can try to compile the code directly by following the steps described in the Dockerfile, or following this guide for Debian.

What are the minimum hardware requirements to run a full node?​

You can see the minimum hardware configuration in this section.