MonadBFT is a new generation consensus protocol specifically designed to address the tail forking problem.
Author: michaellwy
The core of blockchain is to achieve a strict global consensus: that is, regardless of where the network nodes are distributed, in which country or time zone, all participants must ultimately agree on a set of objective results.
However, distributed networks in reality are not ideal: some nodes go offline, some nodes lie, and some even intentionally cause disruption. In this case, how does the system maintain a "unified voice" and stay consistent?
This is the problem that consensus protocols aim to solve. Essentially, it is a set of rules that guides a group of independent, and even not entirely trustworthy, nodes on how to reach a unified decision regarding the order and content of each transaction.
Once this "strict consensus" is established, blockchain can unlock many key features, such as digital property protection, anti-inflation currency models, and scalable social cooperation structures. However, the consensus protocol itself must simultaneously ensure two fundamental aspects:
No two conflicting blocks can be confirmed;
The network must continue to progress and cannot get stuck or halt.
MonadBFT represents the latest technological breakthrough in this direction.
A Brief Review of the Evolution of Consensus Protocols
The field of consensus mechanisms has actually been studied for decades. The earliest protocols, such as PBFT (Practical Byzantine Fault Tolerance), could already handle a very realistic situation: as long as no more than 1/3 of the nodes in the network are faulty, malicious, or lying, the system can still reach consensus.
The design of these early protocols was relatively "traditional": each round selects a leader, who initiates a proposal, and other validators vote on this proposal in multiple rounds to confirm the transaction order step by step.
The entire voting process typically goes through several stages, such as pre-prepare, prepare, commit, and reply. At each stage, all validators must communicate with each other. In other words, everyone has to talk to everyone else, leading to an explosive increase in message volume.
The complexity of this communication structure is n²—meaning that if there are 100 validators in the network, nearly 10,000 messages may need to be transmitted in each round of consensus.
This is not a big problem in small networks, but once the number of validators increases, the communication burden on the system quickly becomes unbearable, and efficiency plummets.
Source: https://medium.com/coinmonks/pbft-understanding-the-algorithm-b7a7869650ae
This "everyone has to communicate with everyone" secondary communication structure is actually very inefficient. For example, in a network with 100 validators, each round of consensus may have to handle tens of thousands of messages.
This can be managed in a small circle, but when placed in a global, open-chain network, the communication load becomes unacceptable. Therefore, early BFT protocols like PBFT and Tendermint are usually only used in permissioned scenarios or systems with very few validators, where they can barely function.
To allow BFT protocols to adapt to permissionless, public chain environments, some new generation designs began to adopt a lighter communication method: having each validator communicate only with the leader, rather than everyone communicating with each other.
This reduces the message complexity from n² to n—greatly alleviating the system's burden.
The HotStuff protocol was proposed in 2018 specifically to address this scalability issue. Its design philosophy is very clear: to replace the complex voting process of PBFT with a simpler, leader-driven communication structure.
A key feature of HotStuff is the so-called linear communication. In its mechanism, each validator only needs to send their vote to the current leader, who then packages these votes to generate a Quorum Certificate (QC).
This QC is essentially a collective signature that proves to the entire network: "The majority of nodes agree with this proposal."
In contrast, PBFT's communication model is "everyone broadcasts," where everyone speaks in the group, leading to a chaotic scene. HotStuff's model is more like "one person collects, one time packages," allowing it to maintain efficient operation regardless of how many people are in the network.
The above image compares the fan-out communication structure of HotStuff with the fully interconnected model of PBFT.
Source:
https://www.mdpi.com/1424-8220/24/16/5417
In addition to linear communication, HotStuff can further upgrade to a pipelined version (pipelined HotStuff) to enhance efficiency.
In the original HotStuff, the same validator continuously serves as the leader for multiple rounds until a block is fully confirmed. This process is "one round processes one block," with all efforts focused on advancing the current one.
In pipelined HotStuff, the mechanism becomes more flexible: a new leader is selected for each round, and each leader has two tasks:
One is to package the votes from the previous leader into a Quorum Certificate (QC) and broadcast it to the entire network;
The other is to propose a new block, preparing to start the next round.
In other words, it is no longer "confirm one before processing the next," but rather like an assembly line, where different leaders take turns being responsible for each step. The previous leader proposes a block, the next leader confirms it and continues to propose a new block, and the on-chain consensus is passed like a relay race.
This is the origin of the metaphor "pipeline": the current block is still going through the confirmation process while the next one is already being prepared, allowing for multiple steps to run in parallel and improving throughput efficiency.
In summary, protocols like HotStuff have made significant improvements over traditional BFT in two dimensions:
First, communication is lighter, with each validator only needing to communicate with the leader;
Second, processing efficiency is higher, with multiple block confirmation processes able to run in parallel.
This has made HotStuff a design template for many modern PoS blockchain consensus mechanisms. However, every advantage comes with a disadvantage—the pipelined structure, while powerful in performance, also quietly introduces a structural risk that is not easy to detect.
Next, we will delve into this core issue: tail forking.
The Tail Forking Problem
Although HotStuff—especially its pipelined version—solves the scalability issue of consensus protocols, it also introduces some new challenges. The most critical and easily overlooked is the so-called "tail forking" problem.
What is tail forking? It can be simply understood as: an unexpected block reorganization (reorg) occurs at the "tail" of the blockchain.
Specifically, there is a block that is valid, has already successfully propagated to most validators, and has received sufficient voting support; logically, it should be confirmed and written into the main chain immediately. However, in the end, it is "skipped" and discarded (orphaned), replaced by another new block at the same height.
This is not a bug or an attack, but rather a possibility inherent in the design structure of the protocol itself, which allows for this "tail dropping." Does this sound a bit unfair? So, how does this happen?
As mentioned earlier, each leader in pipelined HotStuff has two tasks:
A. Propose a new block (for example, Bₙ₊₁)
B. Collect votes for the previous leader's block to generate a QC (for example, to complete the final confirmation for Bₙ)
These two tasks are parallel and take turns. But the problem arises here.
For example: suppose Alice is the leader, and she proposes block Bₙ at height n, which receives a supermajority of votes and is "almost confirmed."
Next, it should be Bob's turn to lead, continuing to advance the next block Bₙ₊₁, while also packaging Bₙ's QC (Quorum Certificate) into his proposal to complete the final confirmation of Bₙ.
But if Bob is offline at this time or intentionally does not submit Bₙ's QC, then a problem arises.
Because no one completes the QC packaging for Alice's block, the voting records for Bₙ fail to propagate, and this block that should have been confirmed is thus "cold treated," ultimately ignored by the entire network.
This is the essence of tail forking: the previous leader's block is skipped due to the negligence or malice of the next leader.
Why is tail forking serious?
The tail forking problem mainly focuses on two aspects: 1) the incentive mechanism is disrupted, 2) the system's liveness is threatened.
First, rewards are swallowed:
If a block is abandoned, the leader who proposed it will receive no rewards, neither block rewards nor transaction fees. For example, if Alice proposes a valid block and receives supermajority voting support, but due to Bob's mistake or malicious actions, this block fails to be confirmed, Alice ultimately receives nothing. This leads to a flawed incentive structure: malicious nodes like Bob can "cut off" their opponents' sources of rewards by skipping their blocks. This behavior does not require a technical attack; it only needs intentional "non-cooperation" to undermine competitors' earnings. If this happens repeatedly, over time, it will reduce the overall participation and fairness of the system, and even induce collusion among nodes.
Second, the MEV attack space expands:
Tail forking also brings a more insidious but serious problem: the space for malicious manipulation of MEV (Maximum Extractable Value) increases. For example, suppose Alice's block contains highly valuable arbitrage transactions. If Bob intends to cause trouble, he can collude with the next leader, Carol, to deliberately not propagate Alice's block. Then, Carol can reconstruct a new block at the same height, "stealing" Alice's arbitrage transaction—turning the MEV profit into her own. This practice of "chain head reordering + collusion appropriation" superficially still follows the rules for block production, but in reality, it is a carefully designed plunder. Worse, it can induce leaders to establish "collusive relationships," turning block confirmation into a game of profit distribution rather than a public service.
Third, it undermines finality guarantees and affects user experience:
Compared to Nakamoto-style protocols, a significant advantage of BFT is deterministic finality: once a block is submitted, it cannot be rolled back. However, tail forking undermines this guarantee, especially for blocks that have "received votes but are not yet formally confirmed." Some high-throughput dapps typically hope to read data immediately after block voting passes to reduce latency, but if that block is suddenly discarded, it may lead to user state rollbacks—such as abnormal account balances, recently completed high-leverage trades disappearing without reason, or game states suddenly resetting.
Fourth, it may trigger cascading failures:
Generally, tail forking may only delay the confirmation of a block by one round, which is not a significant impact. However, in some edge cases, if several consecutive leaders choose to skip the previous block, the system may become stagnant, with no one willing to "take on" the previous block. The entire chain's progress could get stuck until a leader finally appears who is "willing to take on the responsibility," allowing the network to continue moving forward.
Although there have been some solutions proposed, such as the tail forking avoidance mechanism in the BeeGees protocol, they often require sacrificing performance, such as reintroducing the complexity of secondary communication, which is not worth the cost.
What is MonadBFT?
MonadBFT is a new generation consensus protocol specifically designed to solve the tail forking problem. Its strength lies in the fact that it addresses structural risks without sacrificing the performance advantages brought by pipelined HotStuff. In other words, MonadBFT does not start from scratch but continues to optimize based on the core framework of HotStuff. It retains three key features:
1) Rotating leader: A new leader is selected in each round to advance the chain;
2) Pipelined commits: Multiple block confirmation processes can overlap;
3) Linear messaging: Each validator only needs to communicate with the leader, saving a significant amount of network overhead.
However, relying solely on these three points is not enough for security. To close the tail forking structural loophole, MonadBFT adds two key mechanisms:
1) Forced Re-Proposal Mechanism
2) No-Endorsement Certificate (NEC)
Re-Proposal Mechanism
In BFT protocols, time is divided into rounds (called views), with one leader responsible for proposing a new block in each round. If the leader fails (for example, fails to propose a block on time or the proposal is invalid), the system switches to the next round and selects a new leader.
MonadBFT adds a mechanism to ensure that any honestly proposed block will not be "dropped" due to leader rotation during the view switch.
When the current round's leader fails, validators will send a signed view change message indicating that the current round has timed out.
Importantly, this message not only indicates "time's up," but must also include the block information of the most recent vote from that validator, essentially saying: "I did not receive a valid proposal; this is the latest block I see."
The new round's leader will collect these timeout messages from a supermajority (2f+1) of validators and merge them into a Timeout Certificate (TC). This TC represents a unified snapshot of the network's understanding of the "chain head block" when the previous round failed. The new leader will select the block with the highest height (or latest view number), known as high_tip.
MonadBFT requires that the new leader's proposal must include a valid TC and must re-propose the highest pending block in the TC, giving that block another chance to be confirmed.
Why? As we mentioned earlier: we do not want a block that is close to being confirmed to simply disappear.
For example: suppose Alice is the leader of view 5, proposes a valid block, and receives majority votes. Next, if the leader of view 6, Bob, goes offline and fails to advance the chain, when Carol takes over as the leader of view 7, according to MonadBFT's rules, she must include the TC and re-propose Alice's block. This way, Alice's honest work will not go to waste.
If Carol does not have Alice's block, she can request it from other nodes. Nodes can:
Provide the block, or
Return a signed "No-Endorsement" (NE) message, indicating they do not have this block (the mechanism will be introduced later). (At most f Byzantine nodes may choose to ignore the request and not respond.)
Once Carol re-proposes Alice's block, she will gain an additional proposal opportunity, ensuring that she will not be "penalized" due to the failure of the previous round's leader.
The purpose of this re-proposal mechanism is clear: to ensure that the chain's progress is fair, and no valid work is quietly discarded due to bad luck or interference.
No-Endorsement Certificate (NEC)
Continuing from the previous example: after Bob's round times out, Carol requests other validators to provide the high_tip block (i.e., Alice's block). At this point, at least 2f+1 validators will respond:
Either provide Alice's block
Or send a signed NE message, indicating they did not receive Alice's block
As long as Carol receives Alice's block, she must re-propose it according to the rules. Only if at least f+1 validators have signed the NE message can Carol skip that block and propose a new one.
Why f+1? In a BFT system composed of 3f+1 validators, at most f can be malicious. If Alice's block indeed received supermajority votes, then at least 2f+1 honest nodes received it.
Therefore, if Carol claims, "I couldn't get Alice's block," she must provide signatures from f+1 validators to prove that these individuals did not receive it. This constitutes a No-Endorsement Certificate (NEC).
NEC is a certificate of "exemption" for the leader: it is a verifiable piece of evidence indicating that the previous block is not yet ready to be confirmed, and that the leader is not maliciously skipping it, but rather has a valid reason to "abandon" it.
Re-Proposal + No-Endorsement Certificate = Solving Tail Forking
MonadBFT establishes a rigorous and clear set of rules for handling chain heads by introducing the Re-Proposal Mechanism and No-Endorsement Certificate (NEC):
Either complete the final submission for the "near-confirmed" block;
Or provide sufficient evidence to prove that the block does not meet the conditions for confirmation,
Otherwise, skipping or replacing the previous block is not allowed.
This mechanism ensures that any block that has received a supermajority vote will not be abandoned due to the leader's mistakes or intentional evasion.
The structural risk of tail forking is systematically resolved, and the protocol can impose clear constraints on improper skipping behavior.
If a leader attempts to skip the previous block without justification but fails to provide NEC evidence, the protocol will immediately recognize and reject that behavior. Jumping without cryptographic evidence will be considered illegal and will not receive network consensus support.
From an economic incentive perspective, this design provides clear protection for validators:
As long as a block is honestly proposed and receives voting support, its rewards will not be stripped away due to failures in subsequent processes;
Even in extreme situations, such as a node intentionally skipping its proposal round to assist others in seizing the previous block's MEV, the protocol will force subsequent leaders to prioritize re-proposing the original block, preventing attackers from gaining economic benefits through skipping the process.
More importantly, MonadBFT does not sacrifice the performance of the protocol to enhance security.
Some previous designs addressing tail forking (such as the BeeGees protocol) may have certain protective capabilities, but they often rely on high communication complexity (n²) or re-enabling communication processes in every round, which significantly increases the system's burden in practice.
MonadBFT's design strategy is more sophisticated:
Additional communication (such as timeout messages, block re-proposals) is only initiated in the event of view failures or anomalies. In the regular path where most honest leaders continuously produce blocks, the protocol still maintains a lightweight and efficient operating state.
This dynamic balance between performance and security is one of the core advantages of MonadBFT compared to previous generation protocols.
Summary
This article reviewed the basic mechanisms of traditional PBFT consensus, outlined the development path of the HotStuff protocol, and focused on how MonadBFT addresses the inherent tail forking problem in pipelined HotStuff from a protocol structural perspective.
Tail forking distorts the economic incentives of block proposers and poses a potential threat to the network's liveness. MonadBFT ensures that any block proposed by honest leaders and receiving supermajority votes will not be abandoned or skipped by introducing the Re-Proposal Mechanism and No-Endorsement Certificate (NEC).
In the next article, we will continue to explore two other core features of MonadBFT:
1) Speculative Finality
2) Optimistic Responsiveness
And further analyze the practical significance of these mechanisms for validators and developers.
To be continued.
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。
