MonadBFT Explanation (Part 1): How to Solve the Tail Fork Problem

The core of blockchain lies in achieving a strict global consensus: regardless of the geographical distribution or time zones of network nodes, all participants must ultimately agree on a set of objective results.

However, real-world distributed networks are not ideal: nodes go offline, nodes lie, and some even deliberately cause disruption. In such a situation, how does the system achieve unanimity and maintain consistency?

This is the problem that consensus protocols aim to solve. Essentially, it is a set of rules guiding a group of independent and potentially untrustworthy nodes to reach a unified decision on the order and content of each transaction.

Once this "strict consensus" is established, blockchain can unlock many key features, such as digital property rights protection, inflation-resistant monetary models, and scalable social collaboration structures. However, the premise is that the consensus protocol itself must simultaneously ensure two fundamental aspects:

• No two conflicting blocks can be confirmed;
• The network must continue to progress without getting stuck or halting.

MonadBFT represents the latest technological breakthrough in this direction.

Because no one completed the QC packaging for Alice's block, Bₙ's voting record could not be propagated, and this block that should have been confirmed was thus "cold-treated" and ultimately ignored by the entire network.

This is the essence of tail Fork: the previous leader's block is skipped due to the negligence or malice of the next leader.

Why is Tail Fork Serious?​

The problem of tail Fork is mainly concentrated in two aspects: 1) the incentive mechanism is destroyed, 2) the system's liveness is threatened.

First, rewards are swallowed: If a block is abandoned, the leader who proposed it will not get any rewards. Neither block rewards nor transaction fees. For example, Alice proposed a legitimate block and received super-majority vote support, but due to Bob's mistake or malicious operation, this block could not be confirmed, and Alice ultimately earned nothing. This will lead to an incorrect incentive structure: malicious nodes like Bob can "cut off" their opponents' reward sources by skipping their blocks. This behavior does not require technical attacks, just deliberately "not cooperating" can weaken competitors' earnings. If this happens repeatedly, it will eventually reduce the system's participation and fairness, and even induce collusion among nodes.

Second, MEV attack space expands: Tail Fork also brings a more covert but serious problem: the space for maliciously manipulating MEV (Maximum Extractable Value) becomes larger. For example: Suppose Alice's block contains a highly valuable arbitrage transaction. If Bob wants to cause trouble, he can collude with the next leader Carol to deliberately not propagate Alice's block. Then Carol reconstructs a new block at the same height, "stealing" Alice's original arbitrage transaction - turning the MEV revenue into her own. This method of "chain head reorganization + collusive misappropriation" appears to follow the rules of block production but is actually a carefully designed plunder. Worse, it will induce "collusive relationships" among leaders, turning block confirmation into an interest distribution game rather than a public service.

Third, destroying finality guarantee and affecting user experience: Compared to Nakamoto-style protocols, one of BFT's advantages is deterministic finality: once a block is committed, it cannot be rolled back. However, tail Fork destroys this guarantee, especially for blocks that have received votes but are not yet officially confirmed. Some high-throughput dapps usually hope to read data immediately after block voting to reduce latency, but if the block is suddenly discarded, it may cause user state rollback - such as abnormal account balance, recently completed high-leverage transactions disappearing for no reason, game state suddenly resetting, etc.

Fourth, potential chain reaction failures: Generally, tail Fork might only delay block confirmation by one round, which is not a big impact. But in edge cases, if several consecutive leaders choose to skip the previous block, the system might fall into a stagnant state, with no one willing to "take over" the previous block. The entire chain's progression would be stuck until a leader finally appears who is willing to "take responsibility", and the network can move forward again.

Although there were some solutions before, such as the tail Fork avoidance mechanism proposed by the BeeGees protocol, they often require sacrificing performance, such as reintroducing secondary communication complexity, which is not worth it.

What is MonadBFT?​

MonadBFT is a new generation Consensus protocol specifically designed to solve the tail Fork problem. Its brilliance lies in solving structural vulnerabilities without sacrificing the performance advantages brought by pipelined HotStuff. In other words, MonadBFT does not start over but continues to optimize based on HotStuff's core framework. It retains three key characteristics:

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 lot of network overhead.

But these three points alone are not enough to be secure. To plug the structural loophole of tail Fork, MonadBFT added two key mechanisms:

1. Forced Re-Proposal Mechanism
2. No-Endorsement Certificate (NEC)

Why f+1? In a BFT system with 3f+1 validators, at most f can be malicious. If Alice's block indeed receives a supermajority vote, at least 2f+1 honest nodes have received it.

Therefore, if Carol claims "I cannot get Alice's block", she must provide signatures from f+1 validators proving that these people did not receive it. This constitutes a No-Endorsement Certificate (NEC).

NEC is a "liability exemption" credential for the leader: it is a verifiable evidence indicating that the previous block was not ready to be confirmed, and the leader is not maliciously skipping but "abandoning" with valid reasons.

Re-Proposal + No-Endorsement Certificate = Resolving Tail Fork​

MonadBFT introduces a Re-Proposal mechanism and No-Endorsement Certificate (NEC), establishing a rigorous and clear chain head processing rule:

Either complete the final submission for a block "close to being confirmed"; or provide sufficient evidence 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 obtained a legal majority vote will not be abandoned due to leader mistakes or intentional avoidance. The structural risks of tail forks are systematically resolved, and the protocol can form clear constraints on improper skipping behaviors.

If a leader tries to skip the previous block without reason and cannot provide NEC evidence, the protocol will immediately identify and reject such behavior. Jumps 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 deprived due to subsequent stage failures;
• Even in extreme scenarios, such as a node deliberately skipping its proposal round to help others seize the MEV of the previous block, the protocol will force the subsequent leader to prioritize re-proposing the original block, preventing attackers from obtaining economic benefits by skipping the process.

More importantly, MonadBFT does not sacrifice the protocol's performance to enhance security.

Some previous designs for addressing tail forks (such as the BeeGees protocol) have certain protective capabilities but often rely on high communication complexity (n²) or enable re-communication processes in each round, which would significantly increase system burden in practice.

MonadBFT's design strategy is more sophisticated:

Additional communication (such as timeout messages, block re-proposal) is only initiated when the view fails or anomalies exist. On the regular path where honest leaders produce blocks continuously, 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 protocols.

Summary​

This article reviews the basic mechanisms of traditional PBFT Consensus, outlines the development path of the HotStuff protocol, and focuses on how MonadBFT resolves the inherent tail fork problem of pipeline HotStuff at the protocol structural level.

Tail forks can distort block proposers' economic incentives and pose potential threats to network liveness. MonadBFT ensures that any block proposed by honest leaders and obtaining a legal majority vote 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.