> For the complete Linea documentation index, see [llms.txt](/llms.txt). > Agents can fetch this page as Markdown at [https://docs.linea.build/stack/deployment/distributed-sequencing.md](https://docs.linea.build/stack/deployment/distributed-sequencing.md). # 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](/stack/how-to/distributed-sequencing). note The [Besu QBFT documentation](https://besu.hyperledger.org/private-networks/how-to/configure/consensus/qbft) 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](/stack/deployment/core-components#core-protocol-components), 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](/stack/how-to/distributed-sequencing#validator-set-management). ## 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 formula **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. Minimum block-building window Allow at least 500ms of block-building window (configured block time minus consensus overhead) so transactions of typical complexity have room to execute. ## See also - [Trust and responsibilities](/stack/evaluate/trust-model) - [Finality design](/stack/deployment/fast-finality) - [Configure distributed sequencing](/stack/how-to/distributed-sequencing)