What Is Byzantine Fault Tolerance (BFT)?

Byzantine Fault Tolerance (BFT) is, in short, a computer network’s ability to keep working correctly when some participants go offline, make mistakes, or intentionally spread false information.

This is especially important for blockchains. A blockchain doesn’t have a central admin deciding which transactions and blocks are valid. Instead, distributed computers, also called nodes or validators, have to reach agreement together on one version of the blockchain.

A validator can run into different kinds of faults, basically a normal fault or a Byzantine fault. With a normal fault, it’s clear to the network that the validator isn’t working properly. For example, the validator goes offline, loses its internet connection, or doesn’t send a message on time. In that case, it doesn’t provide usable information. The blockchain can usually handle this pretty easily. The other validators don’t wait forever, but move on after a certain time without the failed validator. As long as enough other validators are still active, the network keeps processing new blocks.

With a Byzantine fault, a validator doesn’t just act broken, it acts unpredictably. It can still send messages, but provide incorrect or conflicting information. For example, it can tell one validator that block A is valid and tell another validator that block B is valid.

So the difference is:

• With a normal fault, a validator’s information is missing.
• With a Byzantine fault, there is information, but it’s unclear whether it’s correct.

That’s why a Byzantine fault is harder to deal with. The network not only has to keep going without an offline validator, but also needs to prevent incorrect or conflicting messages from leading to a wrong decision.

Byzantine Fault Tolerance describes how a network can still make one shared decision despite these kinds of issues. The protocol uses things like checks, digital signatures, multiple voting rounds, and a high voting threshold.

Many BFT protocols require that more than two-thirds of the total voting power supports the same proposal before a block becomes final. This way, a small group of faulty or malicious validators can’t decide on their own which version of the blockchain is valid.

BFT isn’t a separate consensus mechanism. It’s a property of a network or consensus protocol. Protocols like PBFT, Tendermint, and HotStuff each use their own rules to tolerate Byzantine faults.

Key Takeaways

• Byzantine Fault Tolerance helps a blockchain handle faulty or untrustworthy validators.
• A Byzantine fault can be caused by a technical failure, a software bug, or an intentional attack.
• Validators check proposals and vote on new blocks.
• Many BFT protocols require support from more than two-thirds of the total voting power.
• BFT helps prevent multiple versions of the blockchain from becoming final at the same time.
• PBFT, Tendermint, and HotStuff are examples of BFT protocols.

What does Byzantine Fault Tolerance solve?

Byzantine Fault Tolerance prevents a small group of faulty or malicious validators from deciding on their own which version of the blockchain is valid. It helps the network keep one shared transaction history, even when some participants go offline, don’t respond, or spread incorrect information.

An unreliable validator can, for example, send different blocks to different participants, vote for two conflicting blocks, or try to get an invalid block approved. A validator can also refuse to cooperate and slow down reaching consensus.

Without solid rules, different groups of validators could each end up following a different version of the blockchain. The network would no longer be able to say with certainty which transactions and blocks are valid.

BFT prevents this by only confirming a block when enough validators have checked and supported the same proposal. This means a limited group of unreliable participants can’t trick the network on their own.

Participants don’t need to personally trust each other. They rely on the fixed rules of the consensus protocol, like digital signatures, voting rounds, and a high voting threshold.

This makes it possible to maintain one shared and consistent version of the blockchain without a central admin.

How does Byzantine Fault Tolerance work?

To really understand Byzantine Fault Tolerance, it helps to first know how it differs from a consensus mechanism.

A consensus mechanism is the set of rules that blockchain participants use to agree on new blocks and the network’s valid history. For example, it determines who can propose a block, how validators vote on it, and when a block is confirmed or becomes final.

Byzantine Fault Tolerance is the property that makes sure this process still works when some validators go offline, make mistakes, or send incorrect information.

So BFT is usually not a separate system next to the consensus mechanism. It’s the set of rules inside the consensus process that prevents unreliable validators from misleading the blockchain. Think of things like a high voting threshold, digital signatures, multiple voting rounds, and replacing a validator that doesn’t propose a valid block.

The exact details vary by blockchain, but in many BFT protocols the process looks roughly the same.

One validator is temporarily picked to propose a new block. This validator is often called the proposer or leader. The block includes new transactions and a reference to the previous block. The proposer digitally signs the proposal so other validators can verify who it came from.

The other validators then check whether the block is valid. For example, they check whether transactions follow the rules, whether users have enough balance, and whether the same tokens aren’t being spent twice. They also check whether the block connects to the correct version of the blockchain.

If a validator thinks the block is valid, they cast a digital vote. Thanks to the signature, the network can see who voted, which block the vote was for, and whether a validator also voted for a conflicting block.

This is where Byzantine Fault Tolerance comes in. The network doesn’t trust the decision of a single validator. In many BFT protocols, more than two-thirds of the total voting power must support the same block before it can become final.

This high voting threshold makes sure a small group of faulty or malicious validators can’t decide on their own which block is valid. If a few validators send bad information or don’t respond, the remaining validators can still come to one decision together.

Example: Ethereum uses Proof of Stake and BFT-like rules to make blocks final. Validators lock up ETH and then vote on checkpoints in the blockchain. At least two-thirds of the total staked ETH must support the same checkpoint before it becomes final. If a small portion of validators goes offline or votes incorrectly, Ethereum can still reach finality. If around one-third of the total voting power isn’t participating correctly, finality can temporarily stop. Ethereum deals with this using an inactivity leak: validators who don’t participate for a long time gradually lose some of their stake. This lets active validators eventually represent enough voting power again to reach finality.

In Proof-of-Stake networks, it’s usually not just about the number of validators, but especially their voting power. That voting power depends on how many tokens they’ve staked.

Some consensus protocols use multiple voting rounds. A well-known example is Tendermint, now further developed as CometBFT and used by many blockchains in the Cosmos ecosystem, including Cosmos Hub. Validators first vote on the proposed block and then, in the next round, confirm that enough other validators support the same proposal. That way, the network checks not only that the block is valid, but also that there’s broad agreement on it.

It can also happen that there isn’t enough support. For example, the proposer might be offline, propose an invalid block, or spread conflicting proposals. The consensus mechanism then starts a new round after a set waiting time with a different proposer.

That’s also part of fault tolerance. A single faulty or malicious validator can’t block the network forever.

So the consensus mechanism determines how the blockchain makes decisions together. Byzantine Fault Tolerance makes sure that decision-making stays reliable when not every participant behaves correctly.

In short: how does Byzantine Fault Tolerance work?

1. The consensus mechanism decides which validator can propose a block and how other validators vote on it.
2. The other validators check whether the proposed block is valid.
3. BFT ensures the network doesn’t rely on one validator, and only makes a decision when a large majority supports the same block.
4. Digital signatures make it visible who voted for what, and whether a validator cast conflicting votes.
5. In many BFT protocols, more than two-thirds of the total voting power is needed to make a block final.
6. If a proposer goes offline, lies, or can’t get a valid majority, the protocol starts a new voting round with a different proposer.
7. So BFT’s role is to keep consensus reliable when some validators go offline, make mistakes, or intentionally spread false information.

What are safety and liveness trying to protect?

Byzantine Fault Tolerance needs to keep a blockchain reliable when some validators go offline, make mistakes, or spread false information. The network has to avoid two problems.

First, validators must not end up with two different final versions of the blockchain. Second, as long as it’s possible, the network should keep processing new blocks and transactions.

In BFT, these two goals are called safety and liveness.

Safety: no two different versions

Safety means the network won’t accept two conflicting blocks as final.

Imagine two groups of validators each receive a different block. Without clear rules, both groups might think their own version is valid. The blockchain could then end up with two different transaction histories.

BFT protocols try to prevent this with a high voting threshold, multiple voting rounds, and digitally signed votes. There can also be rules that prevent validators from casually voting for a different block after they’ve already supported a proposal earlier.

So safety ensures honest participants keep following the same final version of the blockchain, even when some validators spread conflicting information.

Liveness: the network keeps moving

Liveness means the network can keep making new decisions.

That means new blocks get produced, transactions get processed, and a faulty or malicious proposer can be replaced if they’re blocking the process.

BFT protocols use things like timeouts and new voting rounds for this. If a proposer doesn’t propose a valid block or doesn’t respond, another validator gets a turn after some time.

Safety and liveness can sometimes clash. If too many validators are offline or are spreading different information, the network might not be able to gather enough trustworthy votes.

The protocol might then choose to temporarily not finalize any blocks. The blockchain stops making progress for a bit, but it avoids approving two different versions.

Because of that, when there’s serious uncertainty, BFT protocols usually prioritize safety. The network would rather pause temporarily than finalize a potentially wrong or conflicting version of the blockchain.

What’s the difference between Byzantine Fault Tolerance and the Byzantine Generals Problem?

The Byzantine Generals Problem and Byzantine Fault Tolerance are related, but they don’t mean the same thing.

The Byzantine Generals Problem is a thought experiment that shows why agreement is hard in a network without a central decision-maker. In the story, several generals have to decide together whether to attack or retreat. They can only communicate by sending messages, while some generals might lie or spread conflicting information.

In a blockchain, it’s basically the same problem. Validators have to decide together which transactions and blocks are valid, without knowing for sure whether every participant is honest and reliable.

Byzantine Fault Tolerance then describes how a network deals with that problem. It makes sure validators can still reach one shared decision, even when some participants go offline, make mistakes, or send incorrect information.

So the Byzantine Generals Problem describes the problem. Byzantine Fault Tolerance is a network’s ability to solve that problem. The specific rules used to do it, like voting rounds, digital signatures, and a high voting threshold, together make up the BFT protocol.

How do blockchains apply Byzantine Fault Tolerance?

Blockchains can apply Byzantine Fault Tolerance in different ways. Not every network uses the same protocol, but the goal is always similar: validators have to choose one valid version of the blockchain together, even if some of them go offline or spread incorrect information.

The differences are mainly in how a validator is chosen to propose a block, how many voting rounds are needed, and when a block becomes final. Each protocol also differs in what happens when validators don’t respond or cast conflicting votes.

Practical Byzantine Fault Tolerance

Practical Byzantine Fault Tolerance, usually shortened to PBFT, is one of the best-known BFT protocols. It was developed by Miguel Castro and Barbara Liskov to make Byzantine Fault Tolerance practical in real computer systems.

PBFT uses one temporary leader who sends a proposal to the other participants. They check the proposal and then share with each other whether they think it’s valid. Next, they confirm that enough participants support the same proposal.

With these different communication rounds, the network can check whether there’s truly broad agreement. PBFT works especially well with a relatively small group of known participants. As the group gets bigger, more and more messages need to be exchanged. That makes the protocol less efficient for blockchains with a huge number of validators.

Tendermint BFT

Tendermint BFT is used by many blockchains in the Cosmos ecosystem. With Tendermint, one validator proposes a block first. Then there are two voting rounds where validators say whether they support the block.

A block only becomes final when more than two-thirds of the voting power agrees. Tendermint also uses a locking mechanism. When a validator sees that a block has enough support, they get effectively locked onto that block.

After that, the validator can’t just vote for a conflicting block. This helps prevent two conflicting blocks from being approved in different rounds.

HotStuff

HotStuff is a more modern BFT protocol that tries to apply the same basic idea in a more efficient way. Here too, a temporary leader proposes blocks and enough validators have to support them.

HotStuff can summarize validator support in a quorum certificate. This is cryptographic proof that enough validators supported the same proposal. Validators still have to send their votes, but the quorum certificate makes it possible to pass around proof of broad support in a compact way. HotStuff is also designed to make communication and leader changes more efficient.

That way, not every single vote has to be processed separately each time. The protocol is also designed to switch leaders faster when the current leader isn’t functioning well.

Several modern blockchain protocols are fully or partially inspired by HotStuff.

Ethereum

Ethereum doesn’t use a classic form of PBFT, Tendermint, or HotStuff. The network uses Proof of Stake, where validators vote with the ETH they’ve staked. Still, you can clearly see BFT principles in how Ethereum reaches finality.

Validators vote on checkpoints in the blockchain. A checkpoint only becomes final when at least two-thirds of the total staked ETH supports it.

If more than one-third of the voting power doesn’t cooperate, finality can temporarily stop. The network then chooses to wait for enough reliable votes, instead of finalizing two different versions.

Validators who can be proven to have voted for conflicting versions can be punished. This is called slashing. The economic penalty supports the BFT rules here: validators can spread incorrect information, but that behavior is visible and can have consequences.

Bitcoin

Bitcoin approaches the same basic problem differently. The network also needs to reach agreement while participants don’t fully trust each other, but it doesn’t use a classic vote-based BFT protocol.

Bitcoin uses Proof of Work. Miners use computing power to produce new blocks, and nodes then check whether those blocks are valid. Miners build on the valid chain that has the most cumulative work invested in it.

A block isn’t immediately final. The chance it gets reversed gets smaller as more blocks get built on top of it. This is called probabilistic finality.

So Bitcoin is trying to solve the same general problem as BFT protocols: how does a network keep one reliable history when not every participant can be trusted? The difference is that Bitcoin uses computing power and economic costs, while classic BFT protocols mainly use explicit voting rounds and a high voting threshold.

What happens when validators don’t cooperate?

What happens when validators go offline or act incorrectly depends on how much voting power they represent together.

If only a small group of validators doesn’t cooperate, the other validators can usually still gather enough support to confirm new blocks. The network keeps working normally, even if not every validator is active or reliable.

The situation changes when more than one-third of the total voting power isn’t participating. In many BFT protocols, the network can’t gather the required support of more than two-thirds anymore. New blocks then can’t be finalized temporarily. This group can block progress, but usually can’t approve a conflicting version of the blockchain on its own.

If a group controls and coordinates more than two-thirds of the voting power, it can form enough support on its own to finalize blocks. That group can then decide which valid blocks reach finality and can censor transactions by not including them. To finalize two conflicting versions, validators would have to clearly break the consensus rules, which in many Proof-of-Stake networks can lead to slashing.

That’s why it’s not just the number of validators that matters, but especially how voting power is distributed. A blockchain can have thousands of validators and still be relatively concentrated if a small number of parties control a large share of the staked tokens.

How are malicious validators punished?

Proof-of-Stake blockchains can punish validators when they can be proven to have broken the consensus rules. This is called slashing.

For example, a validator can be punished if they vote for two conflicting blocks or try to support two different versions of the blockchain. Because every vote is digitally signed, the network can verify which validator committed the violation.

The punishment varies by blockchain. A validator can lose staking rewards, lose part of their staked tokens, or be temporarily removed from the validator set. For serious violations, the removal can last longer or be permanent.

Slashing doesn’t make cheating impossible, but it does increase the financial consequences. A validator who breaks the consensus rules risks losing part of the value they put up themselves.

What are the benefits of Byzantine Fault Tolerance?

Byzantine Fault Tolerance has several benefits:

1. The network can keep working during failures: Not every validator has to always be online or error-free. As long as enough validators keep working correctly, the network can keep processing new blocks.
2. The blockchain keeps one shared history: BFT helps prevent different groups of validators from finalizing conflicting blocks. That way, honest participants keep following the same version of the blockchain.
3. Blocks can become final quickly: Many BFT protocols finalize a block as soon as enough validators support it. That often means users don’t have to wait for lots of extra blocks.
4. Validator behavior can be verified: Votes are digitally signed. That lets the network see which validator voted for which block, and whether someone cast conflicting votes.
5. No central decision-maker is needed: Validators can decide together which blocks are valid, without one central party making all the calls.

What are the downsides of Byzantine Fault Tolerance?

Byzantine Fault Tolerance also has several downsides:

1. The network can temporarily stall: If too few validators participate, the required quorum can’t be formed. The network might still be able to propose blocks, but not finalize them. Transactions stay uncertain longer, and users have to wait until enough validators participate again.
2. Validators have to share a lot of information: During the consensus process, validators have to share proposals, votes, and confirmations with each other. As the number of validators grows, the amount of communication grows too. This can slow the network down and require more bandwidth and computing power.
3. BFT protocols are technically complex: These protocols use multiple voting rounds, timeouts, temporary leaders, and rules that determine when a validator is allowed to change their vote. A mistake in these rules or in the software can cause validators to get stuck, process different information, or temporarily fail to reach consensus.
4. Voting power can get concentrated: A blockchain can have many validators, while a few large staking providers or organizations together control a big share of the voting power. If these parties control more than one-third of the voting power, they could potentially stop finality. With more than two-thirds, they can strongly influence which blocks get finalized.
5. BFT only protects the consensus layer: BFT helps validators agree on the valid blockchain, but it doesn’t protect every part of the network. For example, a transaction can be confirmed correctly while the smart contract used contains a bug. BFT also doesn’t prevent hacked wallets, vulnerable bridges, incorrect price info from oracles, issues at crypto exchanges, or losses from price drops.

Final thoughts

Byzantine Fault Tolerance lets a blockchain keep working reliably when some validators go offline, make mistakes, or intentionally spread false information. The network doesn’t rely on one participant, but uses things like digital signatures, voting rounds, and a high voting threshold to reach one shared decision.

BFT isn’t a separate consensus mechanism, but a property of the consensus process. It helps prevent multiple versions of the blockchain from becoming final at the same time and makes sure the network can keep processing new blocks as long as enough validators participate.

Blockchains apply these principles in different ways. Tendermint uses multiple voting rounds and locking rules, Ethereum uses BFT-like rules for finality, and Bitcoin solves a similar problem with Proof of Work and probabilistic finality.

Byzantine Fault Tolerance doesn’t make a blockchain fully protected against every error and attack. But it does provide an important foundation for networks where participants don’t have to fully trust each other, and can still maintain one valid shared transaction history.