Reviewed and updated: October 19, 2026.
Proof of Authority, or PoA, describes networks in which approved participants have authority to produce or validate blocks. It is an admission and trust model, not one universal algorithm with a guaranteed speed. The agreement protocol, validator independence and rules for changing membership determine much of the actual behavior.
Admission and agreement answer different questions
Admission asks who may validate. Agreement asks how those validators select a block and when they consider it final. Besu's QBFT implementation is one documented PoA example: approved validators take turns proposing blocks and use a supermajority process to commit them. Other PoA designs should be evaluated under their own rules.
Knowing an operator's name can support accountability, but a name does not stop a server outage, stolen signing key or coordinated misconduct. A network's security assessment needs technical controls and governance arrangements in addition to a list of organizations.
A four-validator example
Consider a fictional QBFT network with four validators operated by A, B, C and D. A three-validator commit quorum can tolerate one validator failing within the protocol's assumptions. If two become unavailable, the remaining two cannot produce the required quorum. This illustrates the distinction between keeping conflicting blocks from finalizing and continuing to produce new blocks.
The EEA QBFT specification states its fault assumptions in terms of the validator set and network conditions. Besu's documentation warns that losing more than one-third of validators can stall block production. These guarantees are conditional; they are not promises that any four servers will remain available in every environment.
Count independent failure domains, not just logos
Suppose A and B use the same cloud account and the same administrator. The network still has four validator entries, but a single account compromise or administrative mistake can affect two of them. The numerical quorum has not changed; the probability of a correlated failure has.
Now suppose C and D are separate legal organizations but depend on one shared network gateway. That creates another common dependency. These examples are an operational analysis of a fictional deployment, not a finding about any named network.
A governance and operations worksheet
| Area | Evidence to inspect |
|---|---|
| Admission | Who approves validators and which criteria apply? |
| Removal | Can a compromised validator be removed, and by what vote or contract? |
| Key management | Who can sign, rotate keys or restore a failed operator? |
| Independence | Which operators share hosting, administrators, software or network dependencies? |
| Recovery | What happens if quorum is lost, and who can authorize a restart? |
| Change control | How are protocol upgrades approved and communicated? |
Permissioned does not automatically mean private
Restricting validator membership does not by itself encrypt transaction contents or limit every reader. Besu's educational private-network tutorial explicitly distinguishes an isolated network from a protected deployment. Access controls, network protection and data handling need their own design.
Similarly, avoiding competitive proof-of-work mining does not make infrastructure free or energy use zero. Servers, storage, networking and operational redundancy still consume resources. Performance claims need a workload, hardware configuration and measurement method.
When the model may fit
A consortium may find approved validators useful when participants accept a defined governance process and want shared execution. The comparison should include an ordinary replicated database: if one organization remains the unquestioned administrator, a blockchain may add complexity without changing the underlying trust relationship. PoA is most understandable as an explicit governance choice, not a shortcut to universal decentralization or guaranteed trust.
Sources and scope
- Besu: QBFT consensus documentation source
- Enterprise Ethereum Alliance: QBFT specification v1
- Besu: educational QBFT private-network tutorial and security scope
Continue reading: Delegated validator elections · Proof of stake · Choosing blockchain or a database
Editorial update: Separated validator admission from consensus; removed outdated product examples and zero-cost claims; added quorum arithmetic, correlated-failure analysis and governance checks.