How many validators a Hyperledger Besu QBFT network needs
Four is the practical minimum for a fault-tolerant QBFT network, but the right count depends on how many validator failures the consortium must survive at the same time. A validator in Besu is a node that proposes and seals blocks under QBFT, the Byzantine fault tolerant proof-of-authority protocol Besu supports for private networks. Validators are set in the genesis file, so the initial count is decided before go-live. Changing that set later is possible through the network's validator management options, but it is a planned change that every member must coordinate, not a quick edit. Treat the count as a governance decision for the whole consortium from the start.
Start from the failure scenario, not from the number of members. Ask each organization how many of its validators can be offline during a planned upgrade while another validator is also unavailable because of an unplanned fault. Then confirm the tolerance for each candidate size against the Besu private networks documentation and in your own test network. Keep in mind that one organization running two or more validators on the same hosts, cloud account or data center concentrates risk, so an outage in that single location can remove several votes at once. Written down, the decision should name the maximum simultaneous failures, the validator owners and the locations where they run.
More validators add coordination work to every block. Each round needs more messages between nodes, so block time and time to finality can change as the set grows across networks and links with different latency. Measure block time with your intended validator count under realistic network conditions before you fix the number. If the network falls below quorum, it stops producing new blocks until enough validators return, so the recovery steps, alerting and contact list for each member should be ready before launch. Confirm the exact quorum behavior and recovery procedure for your Besu version with the vendor documentation and your own rehearsal.
Validator counts compared: tolerance, block time and governance fit
This table compares QBFT validator counts from four to seven, plus larger sets, on failures tolerated, agreement needed and the consortium situations each size suits. Read the tolerance column as the number of validators that can be offline or faulty while the network still produces blocks. The main takeaway is that adding a validator does not always add tolerance, and block time must be measured at the size you pick.
| Validator count | Failures tolerated | Agreement needed | When it fits |
|---|---|---|---|
| 4 validators | 1 | 3 of 4 signatures | The minimum set size. Fits a small consortium where each member runs one validator and each member can keep its node online. |
| 5 validators | 1 | 4 of 5 signatures | Adds a validator without adding failure tolerance. Fits when one more member joins but the set does not yet need two-failure tolerance. |
| 6 validators | 1 | 5 of 6 signatures | Same tolerance as five validators with a higher agreement count. Check that five members can stay online together before choosing this size. |
| 7 validators | 2 | 5 of 7 signatures | First size in this list that tolerates two failures. Fits consortia where at least five independent operators can keep validators online. |
| 8 or more validators | Grows with the set, roughly one for every three validators beyond the first | More than two-thirds of validators | Fits when governance requires wider membership. Each block needs more messages between validators, so confirm block time in testing. |
| Block time at each size | Set by the block period configuration, not by validator count alone | More validators mean more messages per block | Measure block time at your target count in a development cluster before go-live, and confirm the setting with Besu's documentation. |
| Below agreement count | Not applicable, the network has already lost tolerance | Fewer online validators than the agreement count | Block production stops until enough validators return. Confirm the recovery procedure and who can act on it before go-live. |
What each extra validator costs in block time and messages
Adding a validator to a QBFT network raises the number of messages each block needs and the number of machines that must agree before a block is final. The cards below list the factors that make a larger set slower or heavier, and the metrics to check before you fix a validator count for a consortium.
Message volume per block
QBFT validators exchange prepare and commit messages with every other validator in each round, so message count grows with the square of the validator count. Doubling the set roughly quadruples the traffic inside one consensus round. Ask the team that will run the network to model this for your target size, then confirm the count with a test network that has the same number of validators before go-live.
Network latency between organizations
Every validator waits for a quorum of messages, so the slowest links between organizations set the pace of each round. A validator behind a congested WAN link or a distant region can delay agreement even when its hardware is idle. Measure round-trip times between each pair of validator sites, and treat the worst pair as the number that matters.
Block period setting
The block period in the genesis configuration sets how often the proposer is allowed to produce a block. A shorter period leaves less time for messages to arrive, so a larger validator set on a slow network can miss its window more often. Check the block period against the measured latency and the validator count together, not one at a time.
Round changes when a proposer is slow
When the proposer is slow, offline or faulty, validators move to a new round with a different proposer, which adds delay to the block. More validators means more chances that one of them is slow at any given moment, so round changes can become more frequent. Track round change counts and the time spent in each round on the Prometheus metrics that Besu exposes, and compare them across test runs with a simulated slow validator.
Hardware load per validator
Each validator must verify signatures, process transactions and store chain state, so every added validator is another machine to size, patch and monitor. The per-node load does not fall as the set grows, and the total load across the network rises. Measure CPU, memory, disk I/O and peer count on each validator under realistic transaction volume using Prometheus, and size from those readings rather than from a guess.
Operational effort of more key holders
Each validator is a node key that an organization must generate, protect, rotate and back up, and each organization that runs a validator carries its own on-call and upgrade duties. Ask who holds each key, where it is stored, and how a replacement would be voted in if one holder leaves. Node keys in Besu are stored in an unencrypted file unless you add a security module, so key storage choices grow in importance with each added holder.
Choosing and validating the validator count before go-live
This sequence turns the validator count into a tested decision. It starts from the failures the consortium must survive and ends with a rehearsal, measured block production and a signed count that matches the genesis file every member runs.
Define the failure scenarios to survive
Consortium members, together with their operations and risk owners, write down what the network must keep doing when things fail. Typical scenarios include one validator down for planned maintenance, one organization's hosting going offline, and a validator that must be removed after a key compromise. For each scenario, record whether block production must continue or whether halting until recovery is acceptable. This step is done when every scenario has a named owner and an agreed expected outcome.
Decide the validator count for each organization
Each organization states how many validators it will run, where they are hosted and how many can be online at the same time. Test each candidate network size against the scenarios from the previous step: the count must keep the chain producing blocks through the outages you agreed to tolerate, and no single member should be able to halt the chain alone. Confirm the fault-tolerance arithmetic against the QBFT documentation for the Besu version you plan to run. This step is done when a written table of sizes, tolerated failures and hosting is agreed by all members.
Set the initial validator list in genesis
Add the initial validator addresses to the genesis file under the QBFT configuration, in the extraData field. Each organization generates its validator key locally and shares only the derived address, so no private key leaves its infrastructure. Every member must use identical genesis content, and that content is difficult to change once the chain exists. Check that the genesis file hash matches across all members before any node starts, and that the number of addresses equals the agreed validator total.
Run a rehearsal network with a stopped validator
Deploy the agreed validator count in a non-production environment, using the same genesis file and the Besu version you intend to run in production. Stop one validator and confirm that block production continues. Then stop validators until the number offline exceeds your tolerance and confirm that block production halts, as the arithmetic predicts. Restart the stopped nodes and confirm that the chain resumes and the nodes catch up. This step is done when each scenario from the first step has an observed result that matches its expected outcome.
Measure block production with metrics enabled
Start every rehearsal node with
--metrics-enabled, which exposes Prometheus metrics on the default endpoint port 9545. Scrape the metrics and record block height, peer count and the interval between blocks during each scenario. Compare the observed block intervals with the block period set in the genesis file, and investigate any sustained gap before go-live. The Besu documentation includes a sample Grafana dashboard that you can adapt. This step is done when you hold saved timing records for normal operation, a single validator outage and recovery.Confirm the count with all members
Walk every organization through the rehearsal results, including what happened at the tolerance limit and how long recovery took in your own measurements. Ask each member to confirm in writing the validator count, the failure scenarios it covers, the hosting arrangement and the genesis hash. Store the signed record in version control next to the genesis file. This step is done when every sign-off matches the genesis hash deployed in production, and any later change to the validator set goes through the governance process the members agreed.
Validator count questions buyers ask before hiring help
Can we start a Besu QBFT network with only two validators?
Two validators leaves no room for failure, so it is a poor starting point for a consortium network. QBFT finalizes blocks only when more than two thirds of the validator set agrees, so with two validators both must stay online to produce blocks, and losing either one halts the chain. Plan for a set that can lose at least one validator and still make progress. Check the minimum and the fault arithmetic in the Besu private networks documentation for the release you will run. Our design work tests the chosen count against your failure scenarios in a dev cluster before go-live.
What happens to a Besu network that falls below quorum?
Block production stops until enough validators are online and connected again. Nodes keep the chain data they already have and continue to answer read requests, but transactions submitted during the outage wait in pools, and some may be dropped once their pool lifetime ends. Recovery depends on why quorum was lost: a host failure, a network partition, a key or configuration error, or a version mismatch each needs a different response. Ask your partner or your own team to write and rehearse a runbook that covers restoring validators, checking peer connectivity and confirming the chain resumes, and confirm each step against the Besu release you operate.
Does adding a validator to a running QBFT network need a restart?
Adding a validator is a network change, not a single-node edit. The Besu documentation describes QBFT validator management that works on a running network, and you need to confirm which mechanism your network uses and how the new node joins. The genesis file lists the initial validators, and changing that set after launch is handled through a transition rather than by editing the file on each node. Before you change the set, confirm the new validator can reach its peers, has its keys in place, and that every operator agrees to the change. Validator management is covered in more detail in the QBFT validator management content group.
How much effort does the validator sizing decision take, and what does it need from our team?
The effort depends on how many organizations take part, how many failure domains you need (hosts, racks, sites or clouds), and how many validators each operator will run. The work is mostly decision-making and rehearsal rather than configuration. Your team needs an owner for the genesis decisions, people who can operate Linux or container hosts, someone who can read Prometheus metrics for the nodes, and a change process that all participating organizations accept. Ask any partner to list which of these responsibilities it covers, which it expects you to carry, and how long each decision is expected to take in the written scope.
Can our own engineers size and run QBFT validators without a partner?
Your engineers can do this if they have time to read the documentation, build a test network, and rehearse failures. The Besu project is open source and documented, and the release notes describe changes for each version. The harder parts are the decisions that are difficult to reverse, such as the initial validator set and gas settings, and the coordination across organizations. Upgrades also need planning: Besu requires JDK 25, releases arrive roughly monthly, and the Bonsai database upgrades automatically on first start, so a backup taken before each upgrade is the only rollback path. If your team lacks capacity for these tasks, a scoped design engagement can cover them.
What drives the cost of a validator design engagement?
DeployOpen does not publish a price list. Engagements are fixed-scope, and the quote follows from a written scope that states the deliverables, timelines and assumptions before work starts. The main drivers are the number of organizations and validators, the number of sites or clouds you want to test, whether hardware security modules are in scope, how much rehearsal runs in a dev cluster, and whether the design must produce evidence for a compliance assessment. DeployOpen prepares systems and evidence for those assessments, but independent auditors issue the reports. Ask for the deliverables, the environments covered, what you must provide, and whether ongoing support or upgrades should be a separate retainer.
Key custody, ownership and operational risks for validators
Each validator you add is a key, a server and an organization that must stay available. The cards below cover the controls that decide whether a larger validator set adds fault tolerance or just adds more places to fail. Check each one against your chosen validator count before go-live.
Validator key file protection
The local node private key file is not encrypted by Besu, so anyone with read access to the host can copy a validator's identity. A validator that is copied can be impersonated, which weakens the fault model your count depends on. Confirm file permissions, host access controls and who can read the data directory for every validator before you decide how many to run.
Hardware-backed key storage
Where your policy requires hardware-backed storage, the Besu HSM plugin can be loaded through the --security-module option. Using an HSM changes how keys are provisioned, backed up and recovered, and it adds a dependency that must be available when a validator restarts. Ask the plugin provider and your HSM vendor to confirm the supported versions and recovery steps before you commit to this route.
Separate organization per validator
Under QBFT, the validator set only tolerates failures if the validators are run independently. If one organization operates several validators, a single outage, key compromise or administrative mistake can remove more signing power than the count suggests. Record which organization owns each validator, and confirm that no single party controls enough of the set to halt the network.
Missed block monitoring
A validator that stops proposing or signing reduces the margin above quorum even while the chain keeps producing blocks. Metrics exposed through Prometheus let you alert on peer count, block height lag and validator activity per node. Set alerts so that one lost validator is seen within minutes, not during the next review of the network.
Configuration under source control
Genesis, node configuration files and the validator list must match on every node, and a drift between them can split a network. Keeping these files in version control lets you review each change to the validator set, trace who approved it and restore a known state after a failed upgrade. Require a tagged commit for each validator change before it is applied.
Backups before upgrades
Recent Besu releases upgrade the Bonsai database automatically on first start, and older versions cannot open the upgraded database. A validator that is upgraded without a backup cannot be rolled back, which removes it from the set during the period you most need it. Take and test a backup of each validator's data before any version change, and rehearse the restore in a non-production environment.
How the validator count decision fits into a DeployOpen engagement
DeployOpen scopes validator design as part of a fixed-scope written plan, agreed before any build work starts. The validator count, the fault-tolerance target the consortium accepts, and the expected block time all become written decisions in that plan, each with an owner from the participating organizations. The plan also records which organization runs each validator, because a validator count only protects the network if the failures it assumes are independent of one another. Scope, deliverables and timelines are agreed in writing, and the quote follows from that written scope.
The main deliverables for this decision are a documented fault-tolerance analysis, a rehearsal network and a go-live checklist. The analysis sets out the validator count, the number of failures each size tolerates, the quorum threshold and what the network does below quorum, with the reasoning written so that a consortium governance group can review and sign it. The rehearsal network runs the agreed validator set in a separate environment so that stopping validators, adding a validator and recovering from lost quorum can be tested before production. The go-live checklist confirms that these results match the production configuration. Work is delivered inside your own cloud accounts, data centers or closed networks, and DeployOpen does not issue audit reports, attestations or certifications. Independent auditors and certification bodies perform those assessments, and the plan should name who will ask for evidence and in what form.
Monitoring and upgrade support after go-live are available as retainers, and they are separate from the fixed-scope build. Validator availability, missed blocks and peer health need watching from day one, and any change to the validator set after launch needs its own planned transition. Ask any provider to state in the quote which of these items are included, who holds the on-call duty, and what happens when a validator operator leaves the consortium. Confirm the exact retainer terms, response expectations and service levels in writing with DeployOpen, since they are not fixed in this page.
How DeployOpen works on this
DeployOpen plans and delivers the validator design for a Besu QBFT network as a written, fixed-scope engagement inside infrastructure you control. The work starts from your organizations, failure tolerance and block time requirements, and ends with a documented validator set your operators can run and change.
How we scope
- Confirm how many organizations join, and which of them will run a validator each.
- Set the failure tolerance and block time target the consortium must meet before any build starts.
- Record the validator count, quorum arithmetic and recovery assumptions in the written scope.
How we build
- Configure the QBFT genesis and initial validator set in a non-production network first.
- Test validator halts and restarts to confirm the network keeps producing blocks at the agreed count.
- Measure block production and propagation under load using Prometheus metrics from the Besu nodes.
How we hand over
- Deliver a document recording validator count, fault tolerance, quorum thresholds and block time settings.
- Provide runbooks for adding or removing a validator and for responding when quorum is lost.
- Walk your operators through the procedures and confirm they can carry them out without us.
How we support
- Review the validator set again before any change in membership, consensus settings or Besu release.
- Plan and rehearse Besu upgrades on the same validator design so each release is tested first.
- Offer ongoing support, upgrades and continuous testing as a retainer after go-live.
