> 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/multi-validator-consensus.md](https://docs.linea.build/stack/deployment/multi-validator-consensus.md). # Multi-validator consensus This page describes multi-validator consensus for a [Lineth](/protocol/reference/zero-knowledge-glossary#lineth)**Lineth** (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. Multiple [Maru validators](/protocol/reference/zero-knowledge-glossary#maru-validator)**Maru validator** A Maru consensus client that belongs to the QBFT validator set and proposes and votes on blocks. Each Maru validator requires its own dedicated Linea Besu execution client running the sequencer plugins, which builds the payload Maru then signs and broadcasts. A validator can also drive additional follower execution clients. use [QBFT](/protocol/reference/zero-knowledge-glossary#quorum-byzantine-fault-tolerance-qbft)**Quorum Byzantine Fault Tolerance (QBFT)** The Byzantine-fault-tolerant consensus algorithm that Maru implements to let a set of Maru validators produce and finalize blocks. A QBFT validator set requires at least `3f+1` validators to tolerate up to `f` faulty validators. to order blocks together, so the network can keep producing blocks if one validator fails. To set up and operate multiple validators, see [Run multiple Maru validators](/stack/how-to/run-multiple-validators). [Linea Mainnet](/network) runs a single, trusted Maru validator. A Lineth deployment can use a single validator if it accepts that trust model. Use multi-validator consensus when more than one party must participate in block ordering, or when the chain should keep producing blocks if one validator or region fails. Maru is permissioned: [operators](/protocol/reference/zero-knowledge-glossary#operator)**Operator** 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. define the validator set in the genesis file. Distributed sequencing only Multi-validator consensus only improves [sequencer](/protocol/reference/zero-knowledge-glossary#sequencer)**Sequencer** The set of Linea Besu plugins responsible for ordering, building, and executing blocks in a way that allows the subsequent ZK proof to be made, including the tracer. The sequencer is a plugin set rather than a standalone process; a node that runs it alongside a Maru validator is a sequencer node. fault tolerance. The rest of the deployment stays centralized. If the [coordinator](/protocol/reference/zero-knowledge-glossary#coordinator)**Coordinator** 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. goes down, batching, proving, and submission to the [finalization layer](/protocol/reference/zero-knowledge-glossary#finalization-layer)**Finalization 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. stop. For stack-wide high availability, see [High availability](/stack/deployment/high-availability). QBFT consensus The [Besu QBFT documentation](https://docs.besu-eth.org/private-networks/how-to/configure/consensus/qbft) describes the consensus algorithm. Maru manages consensus state independently from [Linea Besu](/protocol/reference/zero-knowledge-glossary#linea-besu)**Linea Besu** A build of the Besu execution client, extended with Lineth plugins such as the sequencer and tracer that add ZK-rollup functionality. Linea Besu is required to propose blocks and to generate traces, so every sequencer node must run it. Nodes that only import blocks or serve standard Ethereum JSON-RPC can run any Ethereum execution client.. Besu-specific details such as `extraData` encoding and JSON-RPC validator management methods do not apply to Maru. ## Sequencer nodes Each Maru validator pairs 1:1 with its own [Linea Besu](/protocol/reference/zero-knowledge-glossary#linea-besu)**Linea Besu** A build of the Besu execution client, extended with Lineth plugins such as the sequencer and tracer that add ZK-rollup functionality. Linea Besu is required to propose blocks and to generate traces, so every sequencer node must run it. Nodes that only import blocks or serve standard Ethereum JSON-RPC can run any Ethereum execution client. execution client running the [sequencer](/protocol/reference/zero-knowledge-glossary#sequencer)**Sequencer** The set of Linea Besu plugins responsible for ordering, building, and executing blocks in a way that allows the subsequent ZK proof to be made, including the tracer. The sequencer is a plugin set rather than a standalone process; a node that runs it alongside a Maru validator is a sequencer node. plugins. Together they form a **sequencer node**. This pairing is what produces canonical blocks: Maru handles consensus, and Linea Besu orders, builds, and executes the block. Multiple Maru validators communicate over a QBFT mesh. Use [direct, static peering](/stack/how-to/run-multiple-validators#set-up-validators) between validators rather than P2P discovery to minimize latency. The Linea Besu clients sync chain data with each other over execution-layer P2P. No coordinator-side changes are required when running multi-validator consensus. The coordinator still connects to a single designated Linea Besu client as its source of truth, not to every sequencer node interchangeably. Multi-validator Maru deployment on LinethFour Maru validators run QBFT consensus in an all-to-all mesh. Each validator pairs one-to-one with its own Linea Besu execution client over the Engine API, and those execution clients stay in sync with each other over peer-to-peer chain sync. A single designated Linea Besu feeds the unchanged downstream Lineth components: coordinator, prover, state manager, RPC nodes, L1 contracts, and bridge.1Consensus layer(Maru)Maruvalidator 0Maruvalidator 1Maruvalidator 2Maruvalidator 32Execution layer(Linea Besu)Engine APIEngine APIEngine APIEngine APILinea Besu0Linea Besu1Linea Besu2Linea Besu3Designated node3DownstreamLineth(unchanged)CoordinatorProverState managerRPC nodesL1 contractsBridgeLegend:QBFT consensus (3 phases)Engine APILinea Besu P2P (chain sync)Unchanged Lineth components_ 4 Maru validators, each paired 1:1 with a Linea Besu execution client. The coordinator reads from a single designated sequencer node. _ ## Validator count In a multi-validator setup, we recommend a minimum of 4 validators. With 2 or 3 validators, the setup provides no fault-tolerance benefit: if one validator goes down, the chain halts. With 4 validators, one can go down while the chain continues. If a validator fails, 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`. For example: - 4 validators tolerate 1 fault (`4=3×1+1`) - 7 validators tolerate 2 faults (`7=3×2+1`) - 10 validators tolerate 3 faults (`10=3×3+1`) note Only 4-validator Lineth 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 constraints, redundancy). Pick a topology that suits those goals, then apply the [latency formula](#block-time-and-latency) to confirm it works. ## 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: ```txt block_building_window = configured_block_time - (3 × inter_validator_latency + ~50ms) ``` `inter_validator_latency` is the one-way latency between two validators, not the 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` plus ~50ms of overhead. note The `3 × latency` overhead is a QBFT property and does not change with [validator count](#validator-count). Adding more validators improves fault tolerance but increases latency variance. The following examples apply the block building window formula at a 1-second configured block time: | Placement | One-way latency | Consensus overhead | Block-building window at 1s | | --- | --- | --- | --- | | Same data center | ~5ms | ~65ms | ~935ms | | Same region (~50ms ping) | ~25ms | ~125ms | ~875ms | | Cross-region, for example EU↔US (~100ms ping) | ~50ms | ~200ms | ~800ms | | Long haul, for example EU↔Asia (~300ms ping) | ~150ms | ~500ms | ~500ms | On a long-haul path, a 1s block time leaves about 500ms of block-building window; use a 2s block time to increase that window to about 1.5s. We recommend setting a 4s block time for a globally distributed validator set. 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. Computationally heavy transactions can exceed the window in narrow configurations. When that happens, the transaction is excluded from the block, remains in the mempool, and is retried on later blocks. If the window stays too narrow, the transaction keeps failing until it is evicted from the mempool. note Longer block times do not reduce throughput. They slow [application-level finality](/stack/deployment/fast-finality): the time before users see their transactions confirmed. Throughput is reduced by inter-validator latency itself. ## See also - [Run multiple Maru validators](/stack/how-to/run-multiple-validators): Procedure for configuring validators, managing the validator set, monitoring Maru, and restoring lost quorum. - [High availability](/stack/deployment/high-availability): Multi-region placement of validators, RPC, and finalization. - [Finality design](/stack/deployment/fast-finality): How QBFT changes application-level finality.