In previous educational articles, SuperEx Academy listed as many as 72 common forms of blockchain attacks, so that everyone could build a basic awareness of hacking attacks and learn how to prevent them. But did you notice something? Those 72 attacks all come from external intrusions—so what about the blockchain itself? Can the blockchain itself have problems?
Just like our title says: why must a blockchain assume someone will act maliciously—could some problems come from the inside?
In fact, in the blockchain world, there is a concept that is almost impossible to avoid, yet is frequently misunderstood—Byzantine Fault Tolerance, abbreviated as BFT. The first time many people hear this term, they usually have two questions:
Why is it called “Byzantine”?
Why does a blockchain need to “tolerate faults,” and even “tolerate malicious behavior”?
The truth is: BFT is the core underlying logic that allows blockchains to operate in an “untrusted environment.” Without Byzantine fault tolerance, there is no decentralization in the true sense of the word.
Byzantine Fault Tolerance Comes From an Experiment
The Byzantine problem originally comes from a classic computer science thought experiment: multiple Byzantine armies are stationed outside a city from different directions, and they must act in a unified way to win. They can only communicate through messengers, but some of them may be traitors who will deliver false messages. The question is: in the presence of traitors, how can the loyal generals reach agreement?
Mapped to a real system, this problem becomes:
Nodes may crash
Nodes may respond with delays
Nodes may send incorrect information
Nodes may act maliciously and deceive the entire system
And blockchain happens to run in exactly such an environment:
Nodes come from all over the world
There is no single unified root of trust
Anyone can join or leave
You cannot assume “everyone is a good person”
Therefore, a blockchain is not trying to “prevent errors,” but rather designing a mechanism where even if someone acts maliciously, the system can still operate correctly—this is exactly the meaning of Byzantine fault tolerance.
What Is the Core Goal of Byzantine Fault Tolerance (BFT)?
Summed up in one sentence: under the condition that at most a portion of nodes are malicious or fail, ensure the system can still reach a consistent result. Specifically, a BFT system typically must satisfy three basic conditions:
1. Consistency
All honest nodes must eventually see the same result—there cannot be some nodes seeing A while others see B.
2. Liveness
As long as the majority of nodes are functioning normally, the system will not “freeze,” and transactions will eventually be processed.
3. Fault Tolerance
Even if some nodes are malicious, the system still will not be manipulated or destroyed. In classic BFT theory, there is a very important conclusion: in a system, to tolerate f Byzantine nodes, at least 3f + 1 nodes are required.
This is why many BFT consensus mechanisms emphasize:
More than 2/3 honest nodes
Less than 1/3 malicious nodes
The derivation logic behind this conclusion is that when the system has 3f+1 nodes, even if f nodes are fully malicious and may send incorrect information or coordinate attacks, the remaining 2f+1 honest nodes can still use majority voting to exclude malicious interference and ensure the system reaches the correct consensus result.
For example, in the voting process, malicious nodes may send different voting results to different honest nodes, but honest nodes will exchange information with each other and count the true voting situation. Since the number of honest nodes (2f+1) exceeds two-thirds of the total nodes, the true voting result must occupy the majority in the count, thereby guaranteeing the accuracy and security of the consensus outcome.
This theory provides a solid mathematical foundation for the design of BFT consensus mechanisms, enabling the system to remain stable and reliable even when facing malicious behavior from some nodes.
The Relationship Between BFT and Blockchain Consensus Mechanisms
Many people confuse “consensus mechanisms” with “Byzantine fault tolerance,” but the relationship between the two is: a consensus mechanism = a specific way to implement Byzantine fault tolerance.
Different blockchains choose different BFT implementation paths.
1. PoW: Probabilistic Byzantine Fault Tolerance
PoW systems represented by Bitcoin do not pursue “instant consistency.” Instead, through hashpower competition, they make the cost of malicious behavior extremely high. As the number of block confirmations increases, the probability of tampering decreases exponentially—this is BFT in a probabilistic sense.
Characteristics:
Extremely high degree of decentralization
Strong security
But low performance, slow confirmation, and high energy consumption
In the PoW mechanism, the so-called “probabilistic” aspect is reflected in the fact that the consensus result is not absolutely immutable, but as the blockchain continues to grow longer, the difficulty of changing historical blocks increases exponentially, making the possibility of malicious tampering approach zero.
Specifically, after a block is added to the blockchain, each subsequent new block provides additional “confirmation” for it. For example, in the Bitcoin network, a transaction is usually considered effectively final after it has been confirmed by 6 subsequent blocks, because the probability of tampering becomes so low that it can be ignored.
This is because to tamper with a historical block, an attacker must recompute the hash value of that block and all blocks after it, which requires controlling more than 51% of the total network hashpower—i.e., a “51% attack.” As the number of blocks increases, the required hashpower and time costs become extremely high, and are almost impossible to achieve in reality.
This method of gradually increasing the credibility of the consensus result by relying on hashpower and the passage of time is the core expression of PoW as a probabilistic Byzantine fault tolerance mechanism. It transforms hashpower competition into an economic game, making honest mining the rational choice for miners, and thus solves the Byzantine fault tolerance problem in a probabilistic way under the premise of decentralization.
2. PoS / DPoS: Economically Constrained BFT
PoS systems no longer use hashpower, but use economic stake as a constraint:
Malicious actors will be slashed and lose their staked assets
Node identities are relatively clearer
Consensus is faster
This is: “using economic penalties to constrain Byzantine behavior”—and on top of BFT theory, game theory is layered in.
Among them, PoS (Proof of Stake) requires nodes to stake a certain amount of tokens in order to qualify as validators. The more tokens staked and the longer the staking time, the higher the probability of becoming a validator and participating in block production and validation, in many designs. When a validator attempts malicious behavior—such as double-spending attacks, producing invalid blocks, and so on—their staked tokens face the risk of being confiscated by the system. This direct economic loss forms a powerful constraint, pushing nodes to follow protocol rules.
DPoS (Delegated Proof of Stake) is a further optimization based on PoS. It allows token holders to vote to elect a certain number of representative nodes (such as witnesses or super nodes), and these representative nodes are responsible for the concentrated completion of block production, validation, and consensus.
Compared with PoS, where there may be a large number of potential validators, DPoS screens out a smaller number of more professional and reputable representative nodes through elections. This not only reduces communication costs and complexity in the consensus process, but also further improves consensus efficiency.
At the same time, because representative nodes have publicly known and elected identities, malicious behavior is easier to detect and hold accountable. Whether it is the stake they risk losing, or the loss of community trust leading to election failure, both become high costs of wrongdoing.
This model combining economic constraints and delegated agency enables DPoS to achieve faster transaction confirmation speeds and higher system throughput while maintaining relatively high security, balancing decentralization, security, and performance. Therefore, it has been widely adopted in many blockchain projects that pursue efficient operation.
3. Classic BFT / Improved BFT (PBFT, Tendermint, etc.)
In consortium chains, early-stage public chains, and some high-performance chains, it is common to see:
PBFT
Tendermint
HotStuff
IBFT
These mechanisms are characterized by:
A relatively limited number of nodes
Multi-round voting communication
Achieving “deterministic finality”
Advantages:
Once confirmed, it cannot be rolled back
Extremely low latency
Very suitable for finance, payments, and settlement scenarios
Disadvantages:
High communication complexity
Difficult for the number of nodes to scale infinitely
Although they are also in the category of economically constrained BFT, the form of economic constraint is different from PoS/DPoS.
In classic BFT and improved BFT mechanisms, although nodes may also need to pledge some assets as a threshold for becoming validator nodes or as collateral against wrongdoing, the core driving force of their consensus process relies more on predefined voting protocols and interactive verification among nodes, rather than dynamically selecting validator nodes through token-holder voting and delegation, and imposing the primary economic incentives and penalties like PoS/DPoS.
This economic constraint is more reflected in admission mechanisms and post-event punishment for malicious behavior, rather than being embedded throughout the entire process of validator election and power assignment.
Therefore, while classic BFT/improved BFT enjoy deterministic finality and low-latency advantages, their degree of decentralization and node scalability are limited by communication complexity. PoS/DPoS, meanwhile, by emphasizing the central role of stake in consensus participation and node management, attempts to balance performance and a degree of decentralization within an economic incentive framework.
There Is a Very Interesting Saying: Blockchains “Naturally Assume Human Nature Is Not Trustworthy”
The design premise of traditional internet systems is: servers are trustworthy, users are untrustworthy
Blockchain is exactly the opposite: nodes are untrustworthy, only the rules are trustworthy
The underlying philosophy of Byzantine fault tolerance is essentially:
Do not trust morality
Do not rely on goodwill
Do not assume “everyone will follow the rules”
Instead, use mechanisms to force everyone into a reality where “malicious behavior is not worth it”
This is also why blockchain systems emphasize incentives and punishments so strongly, emphasize verifiability, traceability, and immutability—because blockchains do not need to “trust an institution.”
The Real-World Significance of BFT: Not Only for Blockchains
Although BFT became widely known because of blockchains, its applications go far beyond that:
Distributed databases
Financial clearing systems
Cloud computing underlying architectures
Decentralized AI networks
Cross-border payments and settlement networks
Any system that is both “high-value” and “cannot fully trust participants” will ultimately move toward BFT design.
Final Words
If you truly understand Byzantine fault tolerance, you will understand:
Why blockchains are costly to run
Why “efficiency” and “decentralization” are always in conflict
Why consensus mechanisms are not chosen casually
Why security is always ranked ahead of performance
More importantly, you will realize: blockchains are not created to make the world more efficient, but to maintain order even in an environment of distrust—and Byzantine fault tolerance is the starting point of all of it.
