Skip to main content

​
Overview

This section of the documentation is dedicated to node operators who want to learn about configuring and running nodes on OP Stack networks. Because the OP Stack is an open-source, modular, and extensible stack, there are many different clients, configurations, and requirements depending on your goals and the specific network you’re targeting. The information provided in this section covers standard configurations and features on the OP Stack.

​
Why Run a Node?

Running your own node gives you the benefit of trustless verification, enhanced privacy, and gives you local access to the blockchain. However, it also requires time and resources to set up and maintain. So you should consider your goals and use cases before deciding to run a node because there are many third-party RPC providers available.

​
System requirements

Before you start, check that your machine can handle the network and node type you’re targeting. Requirements scale with both:
  • RAM: 16GB is the suggested minimum for an OP Mainnet node.
  • CPU: A reasonably modern CPU.
  • Disk: An SSD, sized to the network and node type. A full OP Mainnet node needs hundreds of gigabytes and grows steadily; an archive node needs multiple terabytes and grows much faster, so use an NVMe SSD for archive nodes.
Test networks are far lighter than OP Mainnet — an OP Sepolia full node syncs into tens of gigabytes rather than hundreds. If you’re setting up for the first time, start on OP Sepolia to validate your setup before committing OP Mainnet-scale disk. For the current OP Mainnet storage figures and their growth rates, see the hardware requirements in the from-source tutorial.

​
Node Architecture

Regardless of which OP Stack network you’re running a node for, all nodes share the same fundamental two-client architecture. There is the consensus client and the execution client, which communicate via the Engine API with JWT authentication.

​
Consensus Layer (Rollup Node)

The consensus layer builds, relays and verifies the canonical chain of blocks. The following are the most popular implementations: For nodes running multiple chains as part of an interop dependency set, deploy the consensus layer as op-supernode, which hosts an op-node instance for every chain in one process and adds cross-chain message verification. See the supernode configuration guide for recommended settings and the op-supernode configuration reference for the flag catalogue.

​
Execution Layer

The execution layer provides the EVM execution environment. The following are the supported implementations:
  • op-reth — primary supported execution client.
  • Nethermind — alternative execution client.

​
Node Types

Different node types serve different purposes:
  • Full node: keeps a complete copy of the blockchain, validates all transactions and blocks, and participates on the P2P network.
  • Archive node: additionally retains all historical state for every block. On OP Mainnet, archive nodes need to restore from a database snapshot before syncing.
  • Sequencer node: can be a full or archive node, but it can create new L2 blocks.

​
Network upgrades

Network upgrades on OP Stack networks are generally activated by timestamps. Failing to upgrade your node before the activation timestamp causes a chain divergence that requires a resync, so follow the node upgrade process to stay on the canonical chain.

​
Stay up to date

Upgrade announcements, deprecations, and other changes that affect node operators are published on the Network Notices page.

​
Next steps