Raspberry Pi running Bitcoin node in a home office setup, small device with status LEDs, ethernet cable, bookshelf background, casual hobbyist setup.
Protocols

Node Configuration Reference and Tuning Guide

Deep-dive into critical configuration parameters, flags, and environment variables for all Linea node types, explaining the impact of tuning options on performance and resource consumption.
introduction
NODE CONFIGURATION REFERENCE AND TUNING GUIDE

Introduction

A technical reference for the critical configuration parameters, flags, and environment variables that govern Linea node behavior, performance, and resource consumption.

This guide provides a deep-dive into the operational levers available to teams running Linea sequencer, prover, and RPC (execution) nodes. It moves beyond a simple list of flags to explain the impact of tuning choices on transaction processing throughput, proof generation latency, state database I/O, and peer-to-peer networking. For infrastructure providers, indexers, and high-throughput RPC services, a misconfigured node can lead to missed attestations, slow JSON-RPC responses, or out-of-memory (OOM) crashes under load. This reference is designed to prevent those failure modes.

The content is structured around distinct node profiles. A sequencer operator optimizing for maximum transactions per second (TPS) will prioritize different parameters than an archive node operator indexing historical state. Key areas covered include JVM heap sizing and garbage collection tuning for the sequencer, prover worker concurrency and GPU offloading flags, and execution client cache sizing for eth_call performance. Each parameter is presented with its default value, valid range, and the operational consequence of deviation, such as increased finality risk or degraded API latency.

This guide does not replace the canonical client documentation but serves as an operational companion for production deployment. Teams should use it to establish a baseline configuration aligned with their specific workload profile. Chainscore Labs can review these configurations against your infrastructure topology to identify single points of failure, resource contention risks, and security misconfigurations before they manifest in production, ensuring your node fleet is resilient and performant under the expected transaction load.

NODE CONFIGURATION REFERENCE AND TUNING GUIDE

Quick Facts

Key operational parameters, their impact on node behavior, and the teams that must act to maintain performance, security, and compatibility.

AreaWhat changesWho is affectedAction

State Sync Mode

Choice between full archive sync, fast sync via snapshots, or checkpoint sync. Affects disk I/O, storage size, and time-to-ready.

Node operators, indexers, infrastructure providers

Benchmark sync modes against hardware profiles; verify snapshot integrity before use.

JSON-RPC API Surface

Endpoints may be added, deprecated, or have modified behavior (e.g., tracing, gas estimation) between client releases.

Wallets, exchanges, DeFi frontends, data indexers

Audit integration code for deprecated methods; test against pre-production staging environments.

Mempool Policy

Sequencer-enforced rules for transaction ordering, gas price minimums, nonce management, and eviction.

Searchers, MEV strategies, DeFi protocols, arbitrage bots

Model inclusion behavior under load; adjust submission strategies to match canonical ordering policy.

Prover Hardware Requirements

Proof generation is resource-intensive; hardware specs directly impact proof submission success and latency.

Decentralized prover network participants

Validate hardware against the current prover compatibility matrix; monitor queue depth and generation time.

WebSocket Subscription Limits

Maximum connections, heartbeat intervals, and supported subscription types are configurable and subject to change.

Real-time dashboards, trading bots, monitoring services

Implement connection management and reconnection logic; test failover behavior under connection limits.

Logging and Tracing Configuration

Log verbosity, rotation policies, and trace collection impact storage and debugging capability.

Node operators, security incident responders

Configure log rotation to prevent disk exhaustion; enable detailed tracing in staging for performance profiling.

Bridge Relayer Configuration

Gas cost management, L1 finality awareness, and reorg handling parameters for the canonical bridge service.

Bridge operators, asset custodians, security watchdogs

Monitor message delivery latency; set alerting thresholds for backlog and gas spikes.

technical-context
OPERATIONAL PRINCIPLES

Configuration Surface and Tuning Philosophy

The architectural principles governing Linea's node configuration surface and the operational philosophy for tuning its zkEVM components.

Linea's node software exposes a configuration surface that directly maps to its unique architecture as a Type 2 zkEVM. Unlike a standard Ethereum execution client, a Linea node's behavior is governed by parameters that control not just networking and state storage, but also the performance characteristics of proof generation, the sequencer's transaction ordering policy, and the bridge's L1 finality awareness. The tuning philosophy is therefore not about generic throughput maximization but about achieving a stable equilibrium between resource consumption, proof latency, and the strict correctness required for a validity rollup. Misconfiguration here does not just degrade performance; it can lead to rejected proofs, missed bridge messages, or a node falling out of sync with the canonical chain.

The configuration surface is intentionally stratified by node role. A sequencer operator tunes for predictable block building and MEV policy enforcement, a prover operator tunes for proof generation throughput and hardware acceleration, and an RPC node operator tunes for query latency, state cache efficiency, and WebSocket subscription stability. Each role has a distinct set of critical parameters—prover.workers, sequencer.tx-pool-size, rpc.batch-limit—that must be understood in the context of Linea's specific constraints, such as the prover's circuit size and the sequencer's L1 data posting cadence. Operators who apply generic Geth or Erigon tuning patterns without accounting for the zkEVM layer risk creating subtle divergence or resource exhaustion.

The operational philosophy emphasizes conservative defaults and explicit opt-in for performance tuning. Linea's client releases ship with parameters that prioritize correctness and stability for the canonical sync path. Operators seeking to optimize for high-throughput RPC serving or archival indexing must explicitly override these defaults and accept the trade-offs in memory pressure, disk I/O, and potential instability during network upgrades. Chainscore Labs can review a node fleet's configuration against this philosophy, identifying parameters that deviate from safe baselines and modeling the failure modes that could emerge under peak load, during a proof system upgrade, or in the event of an L1 reorg.

OPERATIONAL IMPACT BY ROLE

Affected Node Types and Operators

RPC Node Operators

RPC node operators are the most directly affected by configuration changes. Tuning the execution client's cache sizes, database backends, and gas price limits directly impacts API responsiveness and infrastructure costs.

Critical tuning areas:

  • State cache and trie cache sizing to reduce disk I/O during high-throughput request bursts
  • WebSocket connection limits and heartbeat intervals to prevent subscription dropouts
  • JSON-RPC method allowlists to prevent resource exhaustion from eth_call spam

Action items:

  • Benchmark sync times and query latency before deploying new configs to production
  • Monitor eth_call error rates and memory pressure after adjusting EVM timeout values
  • Validate that deprecated API methods are disabled if your user base has migrated

Chainscore can review your RPC node configuration for resource exhaustion risks and API compatibility gaps before production rollout.

implementation-impact
TUNING FOR PRODUCTION

Key Configuration Areas and Impact

Misconfiguration is a primary source of instability, resource exhaustion, and security gaps in Linea node deployments. These areas represent the highest-impact levers for operators to control performance, cost, and reliability.

01

State Database and Storage Engine

The choice of state database backend and its cache allocation directly dictates sync speed, query latency, and disk I/O. Operators must balance memory allocated to the state cache against the working set of RPC queries. Under-provisioning leads to thrashing and request timeouts; over-provisioning starves the OS page cache. For archival nodes, disk throughput and IOPS become the bottleneck. Chainscore can profile your query patterns to right-size the cache and recommend a storage engine configuration that prevents degradation under peak load.

02

Peer Management and Network Topology

The number of peers, their quality, and static node configuration determine how quickly a node receives blocks and propagates transactions. A low peer count or poor peer selection causes sync lag and missed block proposals. Conversely, excessive peers waste bandwidth and CPU on redundant gossip. For sequencer-adjacent infrastructure, latency to the sequencer is critical. Operators should configure a mix of static, bootnode, and trusted peers to ensure resilience. Chainscore can audit your peer topology to eliminate single points of network failure and optimize block propagation latency.

03

JSON-RPC API Surface and Rate Limiting

Exposing debug or trace namespaces without authentication or rate limiting allows resource exhaustion attacks. Heavy methods like trace_block can lock a node for seconds. Operators must explicitly enable only required APIs and configure method-specific rate limits and gas caps. For public endpoints, a reverse proxy with caching for immutable data is essential. Misconfiguration here is the most common vector for denial-of-service. Chainscore can review your API exposure, recommend safe method allowlists, and design a rate-limiting policy that protects node stability without breaking legitimate integrations.

04

Prover Resource Allocation and Job Concurrency

For teams running Linea's prover, the concurrency of proof generation jobs and memory allocation per job are the dominant cost and performance drivers. Over-subscribing CPU cores leads to proof timeouts and wasted work. Under-subscribing leaves expensive hardware idle. The optimal configuration depends on the specific circuit sizes and the prover's pipelining model. Operators must also manage disk space for intermediate witness data. Chainscore can benchmark your prover configuration against expected workload profiles to minimize proof generation costs and prevent missed submission deadlines.

05

Logging, Metrics, and Observability Pipelines

Verbose logging, especially at trace level, can saturate disk I/O and obscure critical errors. Operators must configure structured logging with appropriate rotation and retention policies. Equally critical is exposing the correct Prometheus metrics: block import time, peer count, RPC request duration, and prover queue depth are non-negotiable for alerting. Without these, teams are blind to degradation until users report outages. Chainscore can define a minimal viable observability stack for your node type and build alerting rules that fire before service-level objectives are breached.

06

Transaction Pool and Sequencer Interaction

The transaction pool configuration governs how a node accepts, validates, and propagates transactions to the Linea sequencer. Price bump replacement, nonce gaps, and pool size limits directly affect inclusion guarantees for users and bots. Misconfigured pools can reject valid transactions or hold them indefinitely. For infrastructure that submits high-value transactions, understanding the sequencer's ordering policy and configuring local pool behavior to match is essential to avoid unexpected failures. Chainscore can analyze your transaction submission path to ensure pool settings align with the sequencer's expected behavior.

NODE CONFIGURATION FAILURE MODES

Misconfiguration Risk Matrix

Common misconfigurations across Linea node types and their operational impact on performance, security, and chain compatibility

AreaFailure modeWho is affectedSeverityMitigation

Sequencer RPC endpoint exposure

Unrestricted access to sequencer admin APIs or transaction submission endpoints

Sequencer operators, network users

Critical

Restrict admin APIs to loopback interface; enforce authentication on submission endpoints; audit firewall rules before production deployment

Prover hardware underprovisioning

Insufficient RAM or GPU memory causes proof generation timeouts and missed submission windows

Prover network participants, bridge liveness

High

Benchmark against current proof generation requirements; monitor proof queue depth and generation latency; scale hardware before upgrade activation

Execution client sync mode

Full sync selected without adequate storage provisioning leads to disk exhaustion and node crash

RPC node operators, indexers

High

Verify storage capacity against current state size; use snap sync for rapid bootstrap; monitor disk usage trends with 80% alert threshold

Bridge relayer gas configuration

Static gas limit set too low for L1 state root submission transactions during fee spikes

Bridge operators, asset transfer users

High

Implement dynamic gas estimation with buffer multiplier; monitor L1 gas prices; configure automated gas bumping for stuck transactions

Peer discovery and connection limits

Max peers set too low causing network isolation and delayed block propagation

All node operators

Medium

Set minimum 50 peers for execution nodes; verify bootnode reachability; monitor peer count and block import latency metrics

JSON-RPC batch limit configuration

Default batch limit too permissive allows resource exhaustion via large batch requests

Public RPC providers, wallets

Medium

Cap batch request size at 100; implement rate limiting per IP or API key; monitor request queue depth and response latency

Log level set to debug in production

Excessive logging fills disk and degrades I/O performance during normal operation

All node operators

Low

Set production log level to info; configure log rotation with size-based triggers; reserve debug level for temporary troubleshooting windows

State sync snapshot verification skipped

Untrusted snapshot used for bootstrap introduces corrupted state or malicious data

New node operators, recovery scenarios

Critical

Verify snapshot checksums against canonical source; use only published snapshots from Linea or trusted providers; validate block hash continuity after sync

PRODUCTION READINESS REVIEW

Configuration Hardening Checklist

A systematic checklist for operators to harden their Linea node configurations before production deployment. Each item identifies a critical security or performance parameter, explains the operational risk of misconfiguration, and defines the signal that confirms readiness. Teams preparing for mainnet or high-availability RPC service should validate every item.

What to check:

  • Verify that --maxpeers is set to a value appropriate for your node type (sequencer, RPC, or prover) and network topology.
  • Confirm that static peer entries (--bootnodes) point to trusted, operational nodes and are not stale.
  • Ensure that discovery protocol (e.g., Discv5) is enabled for public-facing nodes but restricted or disabled for sensitive infrastructure like provers with no public transaction role.

Why it matters: An insufficient peer count leads to slow block propagation, increased fork risk, and potential isolation from the canonical chain. Overly permissive peering exposes the node to eclipse attacks or resource exhaustion from malicious peers. For provers, unnecessary peer connections waste bandwidth and CPU that should be reserved for proof generation.

Readiness signal: The node maintains a stable peer count within 10% of the configured maximum for at least one hour under normal network conditions, and eth_syncing returns false.

Chains We Build On

Looking to build on a specific blockchain?

We build smart contracts, DeFi applications, wallets, tokenization platforms, and blockchain infrastructure across the major ecosystems teams choose today. That includes Ethereum, Arbitrum, Optimism, Polygon, Avalanche, Solana, Sui, Aptos, Hedera, Stellar, and NEAR, with support for additional EVM and non-EVM networks based on your product requirements.

EVM ecosystems

  • Ethereum logo
    Ethereum
  • Arbitrum logo
    Arbitrum
  • Optimism logo
    Optimism
  • Polygon logo
    Polygon
  • Avalanche logo
    Avalanche
  • Cronos logo
    Cronos

Non-EVM ecosystems

  • Solana logo
    Solana
  • Sui logo
    Sui
  • Aptos logo
    Aptos
  • Hedera logo
    Hedera
  • Stellar logo
    Stellar
  • NEAR logo
    NEAR

Additional ecosystems

  • Polkadot logo
    Polkadot
  • Cosmos logo
    Cosmos
  • TON logo
    TON
  • Cardano logo
    Cardano
  • Algorand logo
    Algorand
  • Tempo logo
    Tempo

Also available for Base, appchains, custom EVM networks, and cross-chain product architecture.

NODE CONFIGURATION FAQ

Frequently Asked Questions

Common questions from operators tuning Linea nodes for production, covering resource allocation, sync strategy, and performance optimization.

The Linea execution client (Besu) is Java-based, and heap size directly impacts sync performance, state cache efficiency, and garbage collection pauses. Start with 80% of available system memory, capped at 32 GB. Beyond 32 GB, returns diminish due to garbage collection overhead. Monitor GC logs for Full GC events; frequent full collections indicate insufficient heap. For archive nodes, prioritize NVMe storage speed over excessive heap. Verify with --Xmx and --Xms set identically to prevent runtime resizing overhead.

Trusted by Industry Leaders

Delivering blockchain solutions for 5+ years.

We have partnered with 50+ leading DeFi protocols, NFT ecosystems, and fintech innovators to build secure, scalable, and capital-efficient blockchain products.

Selected Partners & Clients

ChainVote logo
Reax logo
Sokail logo
Swapsicle logo
SyntheX logo
Tekika logo
Telos logo
Zexe logo
ChainVote logo
Reax logo
Sokail logo
Swapsicle logo
SyntheX logo
Tekika logo
Telos logo
Zexe logo
ChainVote logo
Reax logo
Sokail logo
Swapsicle logo
SyntheX logo
Tekika logo
Telos logo
Zexe logo
ChainVote logo
Reax logo
Sokail logo
Swapsicle logo
SyntheX logo
Tekika logo
Telos logo
Zexe logo
I've been working with Chainscore Labs for last 3+ years, they've consistently delivered with strong ownership across multiple projects. The team is reliable and detail-oriented.
L
Lee Erswell
CEO, Telos Foundation
how to get started

How to get started?

If you're looking for blockchain integration, ChainScore Labs has 5+ years of experience helping teams build and integrate exchanges, wallets, smart contracts, tokenization solutions, and protocol-connected products, we can help you choose the right path, integrate securely, and get to production faster. Our team consists of experienced blockchain developers and architects who can help you with your blockchain integration needs.

01

Exploration & Strategy

Define your product goals and choose the right blockchain architecture for your use case.

02

Architecture & Design

Design the smart contracts, tokenomics, and security parameters of your system.

03

Development & Integration

Build and integrate with wallets, oracles, and front-end dApps for a seamless experience.

04

Security & Launch

Comprehensive audits followed by a risk-managed mainnet deployment to protect your users.

Start a build

Need a blockchain engineering team?

Send the project context and we will respond with next steps, scope questions, and a practical path to delivery.