#PBFT #BFT

Let us first return to a very practical question. In the previous article, we mentioned a conclusion given by Byzantine Fault Tolerance theory: if there are f malicious nodes in a system, then at least 3f + 1 nodes are required for the system to operate securely.

This conclusion is mathematically correct. However, theory is theory, and reality often presents many problems that theory does not address, such as:

• The theory does not tell you how nodes should communicate

• It does not tell you who proposes blocks first

• It does not explain how to deal with network latency or message loss

• Even less does it explain how to make the system actually run in a real network

Early BFT algorithms were almost unusable in the real world: too many messages, overly complex communication, and extremely low efficiency. As a result, a very practical question was placed in front of engineers:

Is there a Byzantine fault-tolerant solution that is not perfect, but can actually run?

This is the background against which PBFT emerged.

The name PBFT already clearly defines its positioning: Practical Byzantine Fault Tolerance. From the name alone, it is clear that PBFT is not designed to remain optimal under all extreme conditions, but instead aims at a more important goal: achieving stable consensus in real networks, with limited nodes and a controlled environment.

Therefore, PBFT is built on several highly “engineering-oriented” assumptions:

• The number of nodes is limited and known

• Node identities are deterministic (not fully anonymous)

• The network is “eventually reachable” (messages may be delayed, but will not be lost forever)

• Up to 1/3 of the nodes are allowed to behave maliciously

You will notice that these assumptions closely match the early real-world conditions of many public blockchains.

There is a “leader” in the system. In PBFT terminology, one node is selected as the Primary, while the others are Replicas. The responsibility of the primary node is simple: it proposes a transaction order or a block proposal. Note that this is not a decision, but merely a proposal.

First Round: Pre-Prepare

The process is as follows: the primary node proposes a block and broadcasts the proposal to all other nodes. Each replica then checks:

• Is the proposal valid?

• Is the transaction order correct?

• Is the primary node behaving obviously maliciously?

If everything checks out, the process moves to the next step.

Second Round: Prepare

Each node performs one key action: it broadcasts a message saying “I approve this proposal” to all other nodes.

The critical point here is that nodes do not reply only to the primary. Instead, they broadcast to each other. When a node receives at least 2f Prepare messages, it concludes that “at least two-thirds of the nodes approve this proposal.”

Third Round: Commit

Next, the nodes perform another round of confirmation:

• Broadcast Commit messages

• Collect at least 2f Commit messages

Only at this point will the node actually execute the block and write it into the system state. A block is considered final only after both rounds of majority confirmation have been completed.

This step is the core of PBFT’s security.

Overall, the key to understanding PBFT is not memorizing the names Pre-Prepare, Prepare, and Commit, but understanding one fundamental principle: PBFT does not trust any single point, including the primary node itself.

All of its design revolves around one sentence:

“Even if the primary node is malicious, the system must continue to operate correctly.”

This is one of the most confusing points for newcomers to PBFT. Intuitively, the following seems sufficient: Primary proposes → majority agrees → execute

The problem is that in an asynchronous network with delays and inconsistent views, this “majority” itself may be an illusion.

The reason PBFT uses three rounds is essentially to separate two distinct problems:

• The Prepare phase solves whether nodes agree on the same proposal

• The Commit phase solves whether nodes confirm that others have also confirmed

These are two completely different security layers.

During the Prepare phase, nodes do not simply say “I agree.” Instead, they broadcast a message stating “I agree with this specific proposal” to all other nodes.

This has a crucial effect: if the primary node attempts to send different versions of a proposal to different nodes, these discrepancies will be quickly exposed during the Prepare broadcasts.

Once a node discovers that “others received a different proposal than I did,” it can immediately determine that the primary is malicious and refuse to proceed.

Thus, the essence of the Prepare phase is to align all nodes’ perspectives and ensure that everyone is discussing the same thing.

Even after receiving enough approvals in the Prepare phase, PBFT does not execute immediately. This is because distributed systems face a dangerous scenario:

“I think everyone has agreed, but in reality, some nodes have not yet seen the confirmations.”

If execution occurs at this stage, part of the system may have already written the block while other nodes remain in an old state, which is fatal for financial systems.

The purpose of the Commit phase is to add another layer of assurance: not just “I have seen enough approvals,” but “I am certain that others have also seen enough approvals.”

Only when at least 2f nodes explicitly send Commit messages is the block considered irreversible.

Here, f represents the maximum number of malicious nodes the system can tolerate. PBFT assumes that in a system of 3f + 1 nodes, at most f nodes may behave maliciously.

When you see the conditions:

• Prepare ≥ 2f

• Commit ≥ 2f

This means that even if f nodes are fully malicious, there are still at least f + 1 honest nodes participating in the confirmation process.

This guarantees two outcomes:

• A maliciously forged block cannot be approved

• Once approved, a block cannot be rolled back

This is the fundamental reason why PBFT has stronger finality than PoW or PoS.

In engineer-friendly terms, the three PBFT phases can be summarized as:

• Pre-Prepare: proposal broadcast

• Prepare: view alignment

• Commit: irreversible confirmation

PBFT may appear slow and complex, but in exchange it provides:

• No forks

• Strong finality

• High tolerance for malicious nodes

This is precisely why it has become one of the most common underlying consensus mechanisms for consortium chains, financial blockchains, and permissioned networks.

PBFT’s security comes from three design principles:

The primary node cannot deceive just one participant. In every round, nodes verify each other, and malicious information is voted down by the majority of honest nodes.

As long as malicious nodes account for less than one-third of the total, they can never fabricate enough Prepare or Commit messages.

PBFT provides strong finality:

• No “longest chain”

• No probabilistic confirmation

• Once confirmed, the state is final

This property is critical for financial, payment, and settlement systems.

PBFT looks elegant, but it has a fatal drawback: its communication complexity is O(n²).

What does that mean?

• In each round

• Every node

• Must communicate with every other node

As the number of nodes grows:

• 10 nodes → manageable

• 50 nodes → barely acceptable

• 100 nodes → heavy pressure

• 1,000 nodes → almost unusable

This is why PBFT is ideal for consortium and permissioned blockchains, but inherently unsuitable for fully open and anonymous public blockchains. This limitation is also what led to the emergence of many “improved BFT” variants.

After the discussion above, it should be clear that PBFT itself is rarely used “as-is” today, and is not well suited to the current overall blockchain ecosystem.

However, its ideas have influenced almost the entire evolution path of blockchain consensus.

Tendermint is essentially PBFT + PoS + rotating leaders, addressing several PBFT pain points:

• Leader selection based on stake weight

• Controlled validator set size

• Retained strong finality

Cosmos, Kava, and Osmosis all clearly reflect PBFT’s underlying logic.

HotStuff is a structural redesign of PBFT:

• Compresses three phases into a pipeline

• Reduces communication rounds

• Increases throughput

Facebook (now Meta) designed HotStuff for Libra with a clear goal: push performance to the limit while preserving BFT security. Today, Aptos and Sui inherit this design path.

In the real world:

• Bank settlement chains

• Cross-institution ledgers

• Government blockchain systems

Almost all adopt PBFT or its variants. The reason is simple: controllable identities, limited nodes, and a strong demand for finality. In these scenarios, PBFT is actually the optimal solution.

PBFT is not the “ultimate consensus,” but it taught the industry an important lesson:

Blockchains do not run solely on computing power or token game theory. They are a combined product of network engineering, distributed systems, protocol design, and assumptions about human behavior.

Starting from PBFT, the blockchain world gradually realized that consensus does not need to be “pure,” but needs to be able to run.

If Byzantine Fault Tolerance is the theoretical foundation of blockchain security, then PBFT is the first time this theory truly entered the real world.

It is imperfect, but it transformed blockchains from academic papers into real systems. What you see today —

• PoS

• Modular consensus

• High-performance Layer 1s

• Consortium-chain financial applications

Almost all of them can trace their origins back to PBFT.

#PBFT #BFT

Let us first return to a very practical question. In the previous article, we mentioned a conclusion given by Byzantine Fault Tolerance theory: if there are f malicious nodes in a system, then at least 3f + 1 nodes are required for the system to operate securely.

This conclusion is mathematically correct. However, theory is theory, and reality often presents many problems that theory does not address, such as:

• The theory does not tell you how nodes should communicate

• It does not tell you who proposes blocks first

• It does not explain how to deal with network latency or message loss

• Even less does it explain how to make the system actually run in a real network

Early BFT algorithms were almost unusable in the real world: too many messages, overly complex communication, and extremely low efficiency. As a result, a very practical question was placed in front of engineers:

Is there a Byzantine fault-tolerant solution that is not perfect, but can actually run?

This is the background against which PBFT emerged.

The name PBFT already clearly defines its positioning: Practical Byzantine Fault Tolerance. From the name alone, it is clear that PBFT is not designed to remain optimal under all extreme conditions, but instead aims at a more important goal: achieving stable consensus in real networks, with limited nodes and a controlled environment.

Therefore, PBFT is built on several highly “engineering-oriented” assumptions:

• The number of nodes is limited and known

• Node identities are deterministic (not fully anonymous)

• The network is “eventually reachable” (messages may be delayed, but will not be lost forever)

• Up to 1/3 of the nodes are allowed to behave maliciously

You will notice that these assumptions closely match the early real-world conditions of many public blockchains.

There is a “leader” in the system. In PBFT terminology, one node is selected as the Primary, while the others are Replicas. The responsibility of the primary node is simple: it proposes a transaction order or a block proposal. Note that this is not a decision, but merely a proposal.

First Round: Pre-Prepare

The process is as follows: the primary node proposes a block and broadcasts the proposal to all other nodes. Each replica then checks:

• Is the proposal valid?

• Is the transaction order correct?

• Is the primary node behaving obviously maliciously?

If everything checks out, the process moves to the next step.

Second Round: Prepare

Each node performs one key action: it broadcasts a message saying “I approve this proposal” to all other nodes.

The critical point here is that nodes do not reply only to the primary. Instead, they broadcast to each other. When a node receives at least 2f Prepare messages, it concludes that “at least two-thirds of the nodes approve this proposal.”

Third Round: Commit

Next, the nodes perform another round of confirmation:

• Broadcast Commit messages

• Collect at least 2f Commit messages

Only at this point will the node actually execute the block and write it into the system state. A block is considered final only after both rounds of majority confirmation have been completed.

This step is the core of PBFT’s security.

Overall, the key to understanding PBFT is not memorizing the names Pre-Prepare, Prepare, and Commit, but understanding one fundamental principle: PBFT does not trust any single point, including the primary node itself.

All of its design revolves around one sentence:

“Even if the primary node is malicious, the system must continue to operate correctly.”

This is one of the most confusing points for newcomers to PBFT. Intuitively, the following seems sufficient: Primary proposes → majority agrees → execute

The problem is that in an asynchronous network with delays and inconsistent views, this “majority” itself may be an illusion.

The reason PBFT uses three rounds is essentially to separate two distinct problems:

• The Prepare phase solves whether nodes agree on the same proposal

• The Commit phase solves whether nodes confirm that others have also confirmed

These are two completely different security layers.

During the Prepare phase, nodes do not simply say “I agree.” Instead, they broadcast a message stating “I agree with this specific proposal” to all other nodes.

This has a crucial effect: if the primary node attempts to send different versions of a proposal to different nodes, these discrepancies will be quickly exposed during the Prepare broadcasts.

Once a node discovers that “others received a different proposal than I did,” it can immediately determine that the primary is malicious and refuse to proceed.

Thus, the essence of the Prepare phase is to align all nodes’ perspectives and ensure that everyone is discussing the same thing.

Even after receiving enough approvals in the Prepare phase, PBFT does not execute immediately. This is because distributed systems face a dangerous scenario:

“I think everyone has agreed, but in reality, some nodes have not yet seen the confirmations.”

If execution occurs at this stage, part of the system may have already written the block while other nodes remain in an old state, which is fatal for financial systems.

The purpose of the Commit phase is to add another layer of assurance: not just “I have seen enough approvals,” but “I am certain that others have also seen enough approvals.”

Only when at least 2f nodes explicitly send Commit messages is the block considered irreversible.

Here, f represents the maximum number of malicious nodes the system can tolerate. PBFT assumes that in a system of 3f + 1 nodes, at most f nodes may behave maliciously.

When you see the conditions:

• Prepare ≥ 2f

• Commit ≥ 2f

This means that even if f nodes are fully malicious, there are still at least f + 1 honest nodes participating in the confirmation process.

This guarantees two outcomes:

• A maliciously forged block cannot be approved

• Once approved, a block cannot be rolled back

This is the fundamental reason why PBFT has stronger finality than PoW or PoS.

In engineer-friendly terms, the three PBFT phases can be summarized as:

• Pre-Prepare: proposal broadcast

• Prepare: view alignment

• Commit: irreversible confirmation

PBFT may appear slow and complex, but in exchange it provides:

• No forks

• Strong finality

• High tolerance for malicious nodes

This is precisely why it has become one of the most common underlying consensus mechanisms for consortium chains, financial blockchains, and permissioned networks.

PBFT’s security comes from three design principles:

The primary node cannot deceive just one participant. In every round, nodes verify each other, and malicious information is voted down by the majority of honest nodes.

As long as malicious nodes account for less than one-third of the total, they can never fabricate enough Prepare or Commit messages.

PBFT provides strong finality:

• No “longest chain”

• No probabilistic confirmation

• Once confirmed, the state is final

This property is critical for financial, payment, and settlement systems.

PBFT looks elegant, but it has a fatal drawback: its communication complexity is O(n²).

What does that mean?

• In each round

• Every node

• Must communicate with every other node

As the number of nodes grows:

• 10 nodes → manageable

• 50 nodes → barely acceptable

• 100 nodes → heavy pressure

• 1,000 nodes → almost unusable

This is why PBFT is ideal for consortium and permissioned blockchains, but inherently unsuitable for fully open and anonymous public blockchains. This limitation is also what led to the emergence of many “improved BFT” variants.

After the discussion above, it should be clear that PBFT itself is rarely used “as-is” today, and is not well suited to the current overall blockchain ecosystem.

However, its ideas have influenced almost the entire evolution path of blockchain consensus.

Tendermint is essentially PBFT + PoS + rotating leaders, addressing several PBFT pain points:

• Leader selection based on stake weight

• Controlled validator set size

• Retained strong finality

Cosmos, Kava, and Osmosis all clearly reflect PBFT’s underlying logic.

HotStuff is a structural redesign of PBFT:

• Compresses three phases into a pipeline

• Reduces communication rounds

• Increases throughput

Facebook (now Meta) designed HotStuff for Libra with a clear goal: push performance to the limit while preserving BFT security. Today, Aptos and Sui inherit this design path.

In the real world:

• Bank settlement chains

• Cross-institution ledgers

• Government blockchain systems

Almost all adopt PBFT or its variants. The reason is simple: controllable identities, limited nodes, and a strong demand for finality. In these scenarios, PBFT is actually the optimal solution.

PBFT is not the “ultimate consensus,” but it taught the industry an important lesson:

Blockchains do not run solely on computing power or token game theory. They are a combined product of network engineering, distributed systems, protocol design, and assumptions about human behavior.

Starting from PBFT, the blockchain world gradually realized that consensus does not need to be “pure,” but needs to be able to run.

If Byzantine Fault Tolerance is the theoretical foundation of blockchain security, then PBFT is the first time this theory truly entered the real world.

It is imperfect, but it transformed blockchains from academic papers into real systems. What you see today —

• PoS

• Modular consensus

• High-performance Layer 1s

• Consortium-chain financial applications

Almost all of them can trace their origins back to PBFT.