Light Nodes: Specialize Your Op-Node Fleet

TL;DR

• We're recommending a specialized op-node topology: a small tier of source nodes owns L1 derivation, and the rest of the fleet runs as light nodes that follow those sources via -l2.follow.source.

• Operators get lower L1 RPC spend, independent scaling of read capacity, faster sequencers, and a smaller blast radius for every future protocol upgrade.

• Migration is one flag per node. The legacy homogeneous setup keeps working, and you can migrate one node at a time.

• Specializing now also means a cleaner runway into interop and other upcoming changes to derivation.

Source nodes derive once. Light nodes follow. The fleet runs leaner.

Lightweight, role-specialized node designs have been a long-running area of research across the broader ecosystem. With this release, OP Labs is shipping a production-ready version of that thinking, built specifically for the operational realities of running an OP Stack chain at scale. It's the latest step in our continuous work on op-node and kona-node, and the kind of operator-facing primitive we expect to keep evolving as the stack matures.

Why: the case for specialization

The four benefits compound as your fleet grows.

Lower L1 cost, starting today. Light nodes stop running the L1 derivation pipeline. They keep an L1 RPC connection for the other things op-node needs it for, but the heavy, per-node derivation traffic disappears from the light tier. If you run ten nodes, you stop paying for ten copies of derivation traffic. The work happens once at the source tier, regardless of how many light nodes are scaled behind it. For operators paying per-call to L1 providers, this is the kind of change that pays for itself the day it ships.

Each tier focuses on what it owns. Light nodes put their resources into advancing the unsafe chain and serving RPC. Source nodes focus exclusively on derivation. We've already seen this matter on sequencers, where benchmarks show that removing derivation eliminates real bottlenecks during block production.

Asymmetric scaling. RPC capacity and derivation capacity become independent variables. Need to absorb more reads ahead of a launch? Add light nodes, and L1 load doesn't move. Need more derivation redundancy? Size the source tier separately, on its own SLOs.

Smaller blast radius for future upgrades. Future protocol changes, including interop, will require more sophisticated derivation logic. Centralizing derivation behind a small source tier shrinks the operational surface area affected by those upgrades. The fewer nodes that need to know how derivation works, the cheaper every future rollout becomes.

The last benefit is the quietest, but it's the one that matters most over the long run.

How: source nodes and light nodes

The new topology splits the fleet into two roles.

A source node is a traditional op-node. It derives the full chain from L1 exactly as before. You'll typically run a small, redundant set of them, sized for derivation throughput and failover rather than for read traffic.

A light node is an op-node started with one new flag, --l2.follow.source=<source op-node RPC>. With that flag set, it stops running its own derivation pipeline and instead receives the safe chain from its designated source. Everything else about the node stays the same: it still serves RPC, still participates in gossip, and still drives its connected execution client.

A few things worth saying clearly:

op-node is not being deprecated. The classic homogeneous setup is not being removed. Specializing your fleet is a recommended operational upgrade. Existing deployments keep working, you can migrate one node at a time, and you can roll back just as easily.

Light node mode is also available in Kona, the Rust implementation of op-node, for operators who want to test on that path.

A reference architecture for production

For production, we recommend a three-tier setup that pairs the new design with a consensus-aware proxyd:

A deriver tier sits at the back: a small, redundant set of derivation-enabled op-nodes (your sources), behind a proxyd configured with the consensus_aware_consensus_layer routing strategy. The proxyd aggregates multiple sources into a single highly-available endpoint and hides individual failures or reorgs from anything downstream.

A light-node tier sits in front of the deriver tier: a horizontally scalable pool of light op-nodes pointed at the deriver-tier proxyd. You scale it up and down based on read traffic, and the deriver tier doesn't notice.

An edge tier sits at the front: your user-facing API gateway or proxyd that fronts the light-node tier and handles external RPC, rate limiting, and routing.

The shape generalizes. If your stack already runs behind a different load balancer or service mesh, apply the same idea: a minimal, well-defined deriver tier with a scalable collection of light nodes in front of it.

How to migrate

The migration is incremental and low-risk.

1. Designate your sources. Pick one or more existing op-nodes to keep running with full L1 derivation. Size them for derivation throughput, with redundancy for failover. These are now the most important nodes in your fleet, so treat them that way in your dashboards and alerting.

2. Convert the rest to light nodes, one at a time, by setting -l2.follow.source to a source op-node's RPC endpoint. Make sure each light node has a reliable, low-latency network path to its source.

3. Validate. Confirm each converted light node tracks the safe chain correctly against its source before shifting production traffic to it.

4. Update monitoring. The source tier is now a hard dependency of the light-node tier and should be alerted on as one.

The full set of flags is short:

bash

# On a light node: OP_NODE_L2_FOLLOW_SOURCE=https://your-source-op-node.example/rpc OP_NODE_L2_FOLLOW_SOURCE_RPC_TIMEOUT=10s # default

For chain operators, the same guidance applies, and we specifically suggest pointing sequencer op-nodes at a source via --l2.follow.source as well. The sequencer's job is to extend the unsafe chain, and offloading derivation removes a real bottleneck from block production.

What changes, and what doesn't

What changes

• L1 derivation runs on the source tier only. The light tier no longer carries that load.

• RPC and derivation become independent scaling axes.

• Future derivation-touching upgrades land on the source tier instead of every node.

What doesn't change

• Light nodes still serve RPC, still gossip, and still drive their EL exactly as before.

• Light nodes still keep an L1 RPC connection for non-derivation needs. They just stop hammering it for the derivation pipeline.

• Existing homogeneous deployments continue to work. Migration is opt-in and reversible.

Specializing your fleet is one layer of operational hygiene, not a finish line. Sequencer security, monitoring, redundancy planning, and the rest of the production checklist all still matter.

What this means going forward

Specializing your fleet now sets it up for what's coming next. As the OP Stack evolves, op-node on its own may not remain sufficient as a derivation source for every future feature, and the source role may grow to include additional software running alongside it. Operators who specialize early absorb those changes once, in the deriver tier, instead of across every node in the fleet.

This setup will become required for node operators running OP Mainnet and Unichain nodes in the future. For now, it's a recommendation, and a strong one. Operators who specialize early get the cost wins immediately and walk into every subsequent upgrade with a fleet already shaped for it.

Definition of Done

Your fleet meets the bar when all of these are true:

• One or more op-node instances are designated as source nodes, sized for derivation throughput with failover.

• Every other op-node is started with -l2.follow.source pointed at the source tier.

• Light nodes are tracking the safe chain correctly against their sources.

• In production, the deriver tier sits behind a consensus-aware proxyd, with the light-node tier scaled independently in front of it.

• Sequencer op-nodes use -l2.follow.source to offload derivation.

• Dashboards and alerting treat the source tier as a hard dependency of the light tier.

If any box is unchecked, you're still paying for derivation work you don't need to be doing.

References

• Specialized op-node topology with light nodes — the full notice, including the reference architecture diagram and exact flag definitions.

• Consensus-aware proxyd — required reading for the production architecture.

• Kona — Rust implementation of op-node. Light node mode is also available here for operators who want to test on the Rust path.