Multi-validator consensus
This page describes Maru multi-validator consensus using Quorum-Based Byzantine Fault Tolerance (QBFT) in a Lineth deployment: when to use it, how it fits the stack, what fault tolerance it provides, and how topology and latency affect block time.
Multi-validator Maru improves sequencer fault tolerance and distributed block ordering. It does not by itself make the coordinator, prover, state manager, RPC nodes, L1 contracts, or bridge highly available.
For setup, monitoring, and recovery steps, see Configure distributed sequencing.
The Besu QBFT documentation
describes the algorithm. Maru manages consensus state independently from Besu.
Besu-specific details such as extraData encoding and JSON-RPC validator
management methods do not apply to Maru.
When to use it
- Multi-party or consortium chains where multiple operators must participate in sequencing.
- Geographic redundancy: the chain continues if one region or one validator goes down.
- Not relevant for standard Linea Mainnet users, or for single-operator chains.
- Maru is fully permissioned: the validator set is fixed in the genesis file, with no permissionless or hybrid mode.
By default, Linea Mainnet runs Maru with a single validator. The multi-validator design on this page applies to Lineth operators running their own chain.
How it fits into Lineth
Maru is the sequencer consensus layer; Besu is the execution layer. Multi-validator Maru changes only sequencer fault tolerance. The prover, coordinator, state manager, RPC nodes, L1 contracts, and bridge are unchanged.
L2 block time is set on Maru. L1 finality cadence is set on the coordinator and is independent.
Each Maru validator pairs 1:1 with a Besu execution node. A single Besu node cannot serve multiple Maru validators.
No coordinator-side changes are required when running multi-validator Maru.
Multi-validator Maru architecture: four QBFT validators, 1:1 paired with Besu nodes, feeding the unchanged downstream Lineth via a single designated Besu.
Scope of fault tolerance
Multi-validator Maru decentralizes block ordering and execution: with 4 validators, block production continues if one validator goes offline. The sequencer is no longer a single point that, if it dies, halts the chain.
The rest of Lineth, including the coordinator, prover, state manager, RPC nodes, L1 contracts, and bridge, is still centralized. The coordinator runs in one place and connects to a single designated Besu node as its source of truth, not to all four interchangeably. If the coordinator goes down, batching, proving, and L1 finality posting stop.
Single-validator to multi-validator migration
Migrating an existing single-validator chain to multi-validator on a running network is supported, but requires a scheduled, coordinated genesis update across all operators. It is not a runtime config change. For the operator procedure, see Configure distributed sequencing.
Block time and latency
QBFT consensus runs in three phases per block, each requiring a one-way message between validators. Block production therefore requires three one-way network hops, plus a small fixed overhead (~50ms) for Engine API communication. The block-building window (the time available for transaction execution after consensus overhead) is:
block_building_window (or effective_block_time) = configured_block_time - (3 × inter_validator_latency + ~50ms)
Where inter_validator_latency is the one-way latency between two
validators, not round-trip ping. If you measure with the ping command,
divide by 2 to get one-way latency.
Before deploying, measure the latency between your validators and pick a
configured block time that absorbs 3 × latency + ~50ms overhead.
Worked examples
- Same data center (~5ms one-way): consensus overhead ~65ms. With a 1s block time, you get ~935ms of block-building window.
- Same region (~25ms one-way, ~50ms ping): consensus overhead ~125ms. With a 1s block time, you get ~875ms of block-building window.
- Cross-region, for example EU↔US (~50ms one-way, ~100ms ping): consensus overhead ~200ms. With a 1s block time, you get ~800ms of block-building window.
- Long haul, for example EU↔Asia (~150ms one-way, ~300ms ping): consensus overhead ~500ms. A 1s block time leaves ~500ms block-building window; use a 2s block time for safety (~1.5s block-building window).
A 4s block time is the recommended setting for global validator distribution. It leaves comfortable block-building window plus safety margin across all tested deployment scenarios.
Topology recommendations
Minimum: 4 validators. With 2 or 3 validators, the setup provides no fault tolerance benefit: as soon as one node goes down, the chain halts. With 4 validators, 1 can go down while the chain continues; expect 1 missed round in every 4 (the offline validator's proposal slot is skipped, so that block's time effectively doubles).
The QBFT fault tolerance threshold is 3f+1: with 4 validators, 1 can fail;
with 7, 2 can fail; with 10, 3 can fail.
The 3 × latency consensus overhead is a fundamental QBFT property and does not
change with validator count. Adding more validators improves fault tolerance but
increases latency variance.
Only 4-validator setups have been tested. Higher counts are expected to work but may require additional LibP2P configuration tuning.
Geographic distribution depends on the operator's goals (latency, regulatory, redundancy). Pick a topology that suits your needs and apply the latency formula above to validate it works.
Things to know before deploying
- Block time vs throughput: longer block times don't reduce throughput. They slow down soft finality, which is the time before users see their transactions confirmed. Throughput is reduced by inter-validator latency itself.
- Block inclusion limits: a transaction's execution time must fit within the block-building window. Simple transactions (e.g. ERC-20 transfers) always fit. Computationally heavy transactions can exceed the window in narrow configurations; when this happens, the transaction is excluded from the block, remains in the mempool, and is retried on subsequent blocks. If the configuration cannot accommodate it (window too narrow), the transaction will keep failing until it's evicted from the mempool.
Allow at least 500ms of block-building window (configured block time minus consensus overhead) so transactions of typical complexity have room to execute.