High availability

This page describes how a LinethLineth (Formerly the Linea Stack) The open-source ZK-rollup stack, codebase, and technical protocol that's the foundation of Linea Mainnet. Operators can deploy this stack to launch their own Ethereum-compatible L2 or L3 networks. deployment can be designed for high availability (HA). It uses an example that spans multiple cloud regions: the chain keeps producing blocks if one region fails, moves finalization to a standby region when needed, and stops safely if two regions fail at once.

Detailed production topology and supported tooling for a given deployment can be confirmed with the Lineth team in enterprise engagements.

Example multi-region design​

An example HA topology includes four independent cloud regions, which is the smallest QBFTQuorum Byzantine Fault Tolerance (QBFT) The Byzantine-fault-tolerant consensus algorithm that Maru implements to let a validator set produce and finalize blocks. A QBFT validator set requires at least 3f+1 validators to tolerate up to f faulty validators. validator set that can tolerate the loss of one region (n=4, f=1).

In this example, each region is a self-contained deployment. Two of the four regions (primary and warm standby) run the finalization pipeline. Deployment management and observability operate separately from the transaction-processing path. The diagram shows these as the deployment control plane and observability plane.

Each region runs a MaruMaru Lineth's consensus layer client. Maru runs on every node, paired with an execution client, and implements the QBFT consensus algorithm. Validator nodes use Maru to propose and vote on blocks; follower nodes use it to receive blocks from peers and pass them to the execution client. In both roles, Maru provides peer-to-peer networking for block propagation and exposes API endpoints for monitoring and control. consensus client paired with a Linea BesuLinea Besu The execution client that Linea Mainnet and other Lineth deployments run to execute transactions and maintain EVM state. Linea Besu is a build of the Besu execution client, extended with plugins such as the sequencer and tracer that add ZK-rollup functionality. execution client (one QBFTQuorum Byzantine Fault Tolerance (QBFT) The Byzantine-fault-tolerant consensus algorithm that Maru implements to let a validator set produce and finalize blocks. A QBFT validator set requires at least 3f+1 validators to tolerate up to f faulty validators. validator per region). Each region also runs public and/or private JSON-RPC gateways in front of RPC nodesRPC node A node configured to expose JSON-RPC APIs to applications, users, or internal services, optionally behind load balancers and RBAC. Any node can serve RPC; RPC nodes differ in how much state history they retain, from current state and recent history by default up to a full archive node., with access control where required. For QBFT topology, latency, and setup, see Multi-validator consensus and Set up distributed sequencing.

Only the primary and standby regions also run the finalization pipeline: the coordinatorCoordinator Lineth's coordination module for batching, proof generation, and finality submission. The coordinator monitors block production, manages conflation deadlines, batches blocks, combines batches into blobs, orchestrates execution, compression, and aggregation proofs, and submits proofs and data to the finalization layer., proversProver The Lineth component that generates ZK proofs of state transitions, handling proof-generation requests from the coordinator and Linea Besu. The prover produces three types of proofs (execution, compression, and aggregation) and combines them into a zk-SNARK that the finalization layer verifies. Provers may be scaled horizontally to meet throughput requirements., and supporting services that batch blocks, generate proofs, and submit them to the finalization layerFinalization layer The blockchain where a Lineth deployment submits proofs and state commitments for verification and hard finality. If the finalization layer is Ethereum (an L1), the deployment is an L2. If the finalization layer is Linea (an L2), the deployment is an L3..

Losing the control plane or observability plane does not stop the running network. Those planes can be rebuilt independently.

This table summarizes which components run in which regions:

Traffic and RPC​

In the example design, public RPC enters through a global entry point that routes each client to the nearest healthy region (for example, AWS Global Accelerator), protected by a web application firewall, then a regional load balancer, reverse proxy with RBAC, and JSON-RPC routers to near-head and archive nodes. Private RPC can use private connectivity into each region (for example, AWS PrivateLink).

Unhealthy regions are drained automatically and traffic redistributes to healthy regions without client reconfiguration. Consensus peer-to-peer traffic stays on a path separate from this RPC routing so RPC failover does not disturb validator communication.

Finalization failover​

Unlike validators and RPC nodes, the coordinator that submits data and finalization proofs must not run as two live submitters at once. Only one region may actively submit to the finalization layer at a time.

In the example design, finalization runs in the primary region, with a warm standby in the secondary region ready to take over if the primary fails. Failover from primary to standby is an automated process:

1. The standby monitors primary availability and finalization progress on the finalization layer over an observation interval.
2. When the primary region is lost, RPC drains from that region and redistributes to healthy regions while the chain keeps producing blocks.
3. The standby detects the finalization stall, promotes the replicated coordinator database, and scales up the finalization stack.
4. Finalization resumes from the standby and catches up; users see an uninterrupted chain.

If both regions briefly submit during the handoff, duplicate submissions are rejected by the onchain contract rather than corrupting state. A manual override remains available for planned failovers. Failback to the original primary region is typically a controlled operatorOperator The entity or consortium responsible for deploying, administering, and running the network infrastructure, contracts, keys, access controls, and operational procedures for a network built on Lineth. step after the incident is resolved.

Finalization failover depends on keeping the right data available in the standby region, and on choosing what to replicate versus rebuild:

• Operational databases: Cross-region replication (for example, Amazon Aurora Global Database) keeps standby lag low and supports automatic promotion during finalization failover.
• Intermediate proving artifacts: Regenerate on demand instead of keeping a cross-region copy of large proving artifacts. Within a region, a shared file system (for example, Amazon EFS) can still let coordinatorCoordinator Lineth's coordination module for batching, proof generation, and finality submission. The coordinator monitors block production, manages conflation deadlines, batches blocks, combines batches into blobs, orchestrates execution, compression, and aggregation proofs, and submits proofs and data to the finalization layer., tracerTracer The Linea Besu plugin, part of the sequencer, that generates the execution traces the prover needs to create zero-knowledge proofs. The tracer provides trace counts for batch-size calculations and produces conflated trace files as prover input., and proverProver The Lineth component that generates ZK proofs of state transitions, handling proof-generation requests from the coordinator and Linea Besu. The prover produces three types of proofs (execution, compression, and aggregation) and combines them into a zk-SNARK that the finalization layer verifies. Provers may be scaled horizontally to meet throughput requirements. workloads share traces and related files.
• State snapshots: Checkpoint chain state so services can restore from a trusted snapshot instead of replaying from genesis. Design snapshot frequency with database backups and, for private validiumValidium A deployment model in which a Lineth network proves state transitions with zk-SNARKs but keeps transaction data in a private data availability layer instead of publishing it to the finalization layer. Only state commitments and proofs are posted onchain, so participants without access to the offchain data can't independently reconstruct or verify the full transaction history. deployments, data availability redundancy.

Key custody​

Signing keys for platform transactions on the finalization layer should use hardware-backed key management (for example, cloud KMS with HSM, integrated through Web3SignerWeb3Signer An open-source, remote signing service that externalizes private key management from nodes. Web3Signer integrates with enterprise-grade key stores and exposes HTTP-based signing APIs so consensus and execution clients can obtain signatures on blocks, attestations, and transactions without directly holding the private keys.). Private key material stays in the HSM boundary. Multi-region keys let primary and standby sign from the same onchain address after failover, without a new key ceremony, and access stays least-privilege and auditable.

Failure scenarios​

In the example design, failures resolve as follows:

Within-region redundancy​

Multi-region high availability still depends on within-region design:

• Run multiple replicas of RPC nodes, proxies, and other stateless or horizontally scalable services across availability zones (AZ).
• Use multi-AZ managed databases inside a region as well as cross-region replicas for finalization failover.
• Keep shared proving storage local to the region that runs coordinatorCoordinator Lineth's coordination module for batching, proof generation, and finality submission. The coordinator monitors block production, manages conflation deadlines, batches blocks, combines batches into blobs, orchestrates execution, compression, and aggregation proofs, and submits proofs and data to the finalization layer. and proverProver The Lineth component that generates ZK proofs of state transitions, handling proof-generation requests from the coordinator and Linea Besu. The prover produces three types of proofs (execution, compression, and aggregation) and combines them into a zk-SNARK that the finalization layer verifies. Provers may be scaled horizontally to meet throughput requirements. workloads.
• Monitor service health, finalization lag, and storage capacity.

See also​

• Learn how multi-validator consensus improves sequencerSequencer The component of the Lineth execution client responsible for ordering, building, and executing blocks in a way that allows the subsequent ZK proof to be made. It's implemented as a set of plugins extending Linea Besu, including the tracer. There's typically one sequencer per network. fault tolerance and learn how to set up distributed sequencing.
• Understand data availability redundancy and backup responsibilities for private validiumValidium A deployment model in which a Lineth network proves state transitions with zk-SNARKs but keeps transaction data in a private data availability layer instead of publishing it to the finalization layer. Only state commitments and proofs are posted onchain, so participants without access to the offchain data can't independently reconstruct or verify the full transaction history. deployments, where participants cannot reconstruct full history from the finalization layer alone.