Skip to main content
op-node is the OP Stack’s consensus-layer client, written in Go: the rollup node that derives the canonical L2 chain from L1 data and drives an execution client to process the resulting blocks.

Overview

op-node builds, relays, and verifies the canonical chain of L2 blocks. As a sequencer it builds new blocks; as a verifier it derives blocks from the data the chain posted to L1 and accepts only blocks that can be reproduced from that data. The blocks themselves are executed by an execution client, such as op-reth, which op-node controls through the Engine API; the two run in a one-to-one pairing. op-node also relays the sequencer’s new (unsafe) blocks over a P2P network for low-latency access to the latest state; the relay is optional and never affects the ability to verify. It exists because an OP Stack chain is derived: the canonical chain is defined by data available on L1, and the rollup node is the component that turns that data into verified L2 blocks. It plays the role a beacon node plays on L1, and it implements the rollup node specification. Who runs it: every node operator. Each OP Stack node pairs a rollup node, op-node or kona-node (the Rust implementation of the same role), with an execution client. Chain operators additionally run op-node in sequencer mode to build new blocks.

Get started

How-tos

  • Consensus client configuration: configure op-node (or kona-node) and connect it to your execution client.
  • Using blobs: give op-node the L1 beacon endpoint it needs to fetch blob batch data, including blobs older than the beacon retention window.
  • Node troubleshooting: solutions to common node problems, many of them surfaced in op-node logs.

Configuration & flags reference

Releases