MonadBFT: Redefining Blockchain Consensus Security, Saying Goodbye to Tail Fork Risks

Author: michaellwy

The core of blockchain lies in achieving a strict global consensus: that is to say, regardless of where the network nodes are located, in which country or time zone, all participants must ultimately agree on a set of objective results.

However, the distributed network in reality is not ideal: some nodes are disconnected, some nodes lie, and some even deliberately sabotage. In this case, how does the system "all speak" and maintain consistency?

This is the problem that the consensus protocol aims to solve. It is essentially a set of rules designed to guide a group of independent and even potentially untrustworthy nodes in reaching a unified decision on the order and content of each transaction.

Once this "strict consensus" is established, the blockchain can unlock many key features, such as digital property rights protection, an anti-inflation currency model, and a scalable social collaboration structure. However, the premise is that the consensus protocol itself must ensure two fundamental aspects:

Two conflicting blocks cannot both be confirmed.

The network must continue to advance and cannot get stuck or come to a halt.

MonadBFT is 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 batch of protocols, such as PBFT (Practical Byzantine Fault Tolerance), can already handle a very realistic situation: even if some nodes in the network fail, act maliciously, or spread nonsense, as long as they do not exceed 1/3 of the total number, the system can still reach consensus.

The design approach of these early protocols is relatively "traditional": a leader is selected in each round, who initiates a proposal, and the other validators vote on this proposal in multiple rounds to gradually confirm the transaction order.

The voting process usually goes through several stages, such as pre-prepare, prepare, commit, and reply. At each stage, all validators communicate with each other. In other words, everybody has to tell everybody, and the volume of messages is growing explosively in a "net".

The complexity of this communication structure is n²—that is, if there are 100 validators in the network, each round of consensus can pass nearly 10,000 messages.

This is not a big problem in small networks, but once the number of validators increases, the communication burden on the system will quickly become unbearable, and efficiency will directly plummet.

Source:

This "everyone needs to communicate with everyone" secondary communication structure is actually very inefficient. For example, in a network with 100 validators, each round of consensus may need to process tens of thousands of messages.

This can be managed within a small circle, but when placed in a global, open blockchain network, the communication load quickly becomes unacceptable. Therefore, early BFT protocols like PBFT and Tendermint are typically only used in permissioned scenarios or systems with a very small number of validators, where they can barely function.

In order for the BFT protocol to adapt to a permissionless, public chain environment, some new generation designs have begun to move towards a lighter communication method: allowing each validator to communicate only with the leader, rather than having everyone communicate with each other.

This reduces the message complexity from the original n² to n, greatly alleviating the system burden.

The HotStuff protocol was introduced in 2018 to solve this scalability problem. It was designed with a clear idea: to replace the complex voting process of PBFT with a simpler, leader-driven communication structure.

The key feature of HotStuff is the so-called linear communication. In its mechanism, each validator only needs to send their votes to the current leader, who then packages those votes to generate a Quorum Certificate (QC).

This QC is essentially a collective signature that proves to the entire network: "The majority of nodes agreed to this proposal."

In contrast, the communication mode of PBFT is "full broadcast", where everyone speaks in the group, leading to a very chaotic scene at times. The mode of HotStuff is more like "one collects, one packages", which can still maintain efficient operation regardless of how many people are in the network.

The above figure compares the fan-out communication structure of HotStuff with the fully interconnected model of PBFT.

Source:

In addition to linear communication, HotStuff can also be further upgraded to a pipelined version (pipelined HotStuff) to enhance efficiency.

In the original HotStuff, the same validator 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 the HotStuff pipeline, the mechanism becomes more flexible: a new leader is selected in each round, and each leader has two tasks:

On one hand, package the votes from the previous round into a Quorum Certificate (QC) and broadcast it to the entire network;

Propose a new block while preparing to start the next round.

In other words, it is no longer a case of "confirm one before processing the next," but rather like an assembly line where different leaders take turns being responsible for each link. The previous leader proposes a block, the next leader confirms it and continues to propose new blocks, and the on-chain consensus is passed down like a relay race.

This is the origin of the metaphor "assembly line": the current block is still undergoing the confirmation process while the next one is already in preparation, with multiple steps running in parallel to increase throughput efficiency.

In summary, protocols like HotStuff have made significant improvements over traditional BFT in two dimensions:

First, communication is lighter; each validator only needs to communicate with the leader.

Secondly, the processing efficiency is higher, and multiple block confirmation processes can run in parallel.

This makes HotStuff a design template for many modern PoS blockchain consensus mechanisms. But there are pros and cons to everything – while the assembly line structure is powerful, it also quietly introduces a structural risk that is not easy to detect.

Next, we are going to delve into this core issue: Tail Forking.

Tail-Forking

Although HotStuff — especially its pipelined version — addresses the scalability issues of consensus protocols, it also introduces some new challenges. The most critical and often overlooked of these is the so-called "Tail Forking" problem.

What is a tail end fork? It can be simply understood as: an unexpected block reorganization occurred at the "tail" of the blockchain (reorg).

Specifically, there is a block that is valid, has successfully been propagated to most validators, and has received enough voting support. According to the rules, it should be confirmed and written into the main chain immediately. However, in the end, it was "skipped" and orphaned, replaced by another new block at the same height.

This is neither a bug nor an attack, but rather a possibility of "chain tail dropping" due to the design structure of the protocol itself. Doesn't this sound a bit unfair? So, how does this happen?

As we mentioned earlier, each leader in the HotStuff pipeline has two tasks:

A. Propose a new block (for example Bₙ₊₁)

B. Collect votes for the block from the previous leader, generating QC (for instance, completing the final confirmation for Bₙ).

These two tasks are parallel and take turns in a relay. But the problem lies here.

For example: Suppose Alice is the leader, and she proposed block Bₙ at height n. This block received a supermajority of votes and is "almost confirmed."

Next, Bob should take the lead and continue to advance the next block Bₙ₊₁ of the chain, while also packaging the QC (Quorum Certificate) of Bₙ into his proposal to complete the final confirmation of Bₙ.

But if Bob is offline at this time, or deliberately does not submit the QC of Bₙ, then problems will arise.

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

This is the essence of a tail end fork: the block of the previous leader is skipped due to the negligence or malice of the next leader.

Why is the tail fork serious?

The issue of tail branching mainly focuses on two aspects: 1) the incentive mechanism is compromised, 2) the system's activity is threatened.

First, the rewards were swallowed:

If a block is abandoned, its proposer will not receive any rewards, whether it be block rewards or transaction fees. For example, if Alice proposes a valid block and receives supermajority voting support, but due to Bob's mistake or malicious actions, the block fails to be confirmed, Alice ultimately receives nothing. This creates a flawed incentive structure: malicious nodes like Bob can "cut off" their opponents' reward sources by skipping their blocks. This behavior does not require a technical attack; it only requires deliberate "non-cooperation" to undermine a competitor's earnings. If this happens repeatedly, over time it will reduce the overall participation and fairness of the system, and even induce collusion between nodes.

Second, the MEV attack space has expanded:

The tail end forking also brings a more covert but serious issue: the space for MEV (Maximum Extractable Value) to be maliciously manipulated has increased. For example, suppose there is a highly valuable arbitrage trade in Alice's block. If Bob intends to cause trouble, he can collude with the next leader, Carol, and intentionally not propagate Alice's block. Then Carol can reconstruct a new block at the same height and "steal" Alice's original arbitrage trade—turning the MEV profits into her own. This practice of "chain head reordering + collusion to appropriate" appears to follow the rules for block production, but in reality, it is a carefully designed plunder. Worse still, it may induce leaders to establish a "collusive relationship," turning block confirmation into a game of profit distribution rather than a public service.

Third, undermining the finality guarantee affects user experience:

Compared to Nakamoto-style protocols, a major advantage of BFT is deterministic finality: once a block is committed, it cannot be rolled back. However, tail-end forks undermine this guarantee, especially for blocks that have "received votes but are not yet formally confirmed." Certain high-throughput dapps often wish to read data immediately after block voting to reduce latency, and 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 cause, or game states suddenly resetting.

Fourth, it may trigger a chain reaction of failures:

Generally speaking, a tail end fork may only cause a block to be confirmed one round later, which is not a significant impact. However, in some edge cases, if several consecutive leaders choose to skip the previous block, the system may come to a standstill, with no one willing to "take on" the previous block. The entire chain's progress gets stuck until a leader finally appears who is "willing to take on the responsibility," and only then will the network continue to move forward.

Although there have been some solutions previously, such as the tail fork avoidance mechanism proposed by the BeeGees protocol, they often require sacrificing performance, such as reintroducing the complexity of secondary communication, which is not worth the trade-off.

What is MonadBFT?

MonadBFT is a new generation consensus protocol specifically designed to solve the end-of-chain fork problem. Its strength lies in that it addresses structural risks without sacrificing the performance advantages brought by the 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: The confirmation process for multiple blocks can overlap.

3. Linear messaging: Each validator only needs to communicate with the leader, saving a lot of network overhead.

However, relying solely on these three points is not secure enough. To close the structural vulnerability of the tail end fork, MonadBFT has added two key mechanisms:

1. Mandatory Re-Proposal Mechanism (Re-Proposal)

2. No-Endorsement Certificate (NEC)

Re-Proposal Mechanism

In the BFT protocol, time is divided into rounds (referred to as views), with a leader in each round responsible for proposing a new block. If the leader fails (for example, by not proposing a block in time or by submitting an invalid proposal), the system will switch to the next round and elect a new leader.

MonadBFT has added a mechanism to ensure that during view switching, any honestly proposed block will not be "dropped" due to leader rotation.

When the leader of the current round fails, the validators will issue a signed view change message indicating that the current round has timed out.

Notably, this message not only indicates "timeout," but must also include the block information of the validator's most recent vote, which is equivalent to saying: "I did not receive a valid proposal, this is the latest block I see."

The new 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 entire network's recognition of the "chain head block" when the previous round fails. The new leader will select the block with the highest height (or latest view number), referred to as high_tip.

MonadBFT requires: the proposal of the new leader must include a valid TC, and the highest pending block in the TC must be re-proposed to give this block another chance to be confirmed.

Why? As we mentioned earlier: we do not want a nearly confirmed block to just disappear.

For example: Suppose Alice is the leader of view 5, proposes a valid block, and receives a majority vote. Next, the leader of view 6, Bob, goes offline and fails to advance the chain process. When Carol becomes the leader of view 7, according to the rules of MonadBFT, she must include TC and re-propose Alice's block. This way, Alice's honest work will not be wasted.

If Carol does not have Alice's block, she can request it from other nodes. Nodes can:

Provide this block, or

Return a signed "No-Endorsement message" (No-Endorsement, NE), indicating that one does 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 receive an additional proposal opportunity, ensuring that she will not be "guilty by association" due to the previous leader's failure.

The role of this re-proposal mechanism is clear: to ensure that the advancement of the chain is fair, and that no valid work is quietly discarded due to bad luck or interference from others.

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:

Provide Alice's block or not.

Either send a signed NE message indicating that you have not received Alice's block.

As long as Carol receives Alice's block, she must re-propose it according to the rules. Carol can only skip that block and propose a new one if at least f+1 validators have signed the NE message.

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

Therefore, if Carol claims "I can't get Alice's block," she must produce f+1 validator signatures to prove that these people have not received it. This constitutes a No-Endorsement Certificate (NEC).

NEC is the leader's "disclaimer" certificate: it is a verifiable proof that the previous block is not yet ready to be confirmed, and it is not maliciously skipped, but rather "waived" with reason and justification.

Re-propose + No endorsement certificate = Solve tail-end fork

MonadBFT establishes a rigorous and clear set of chain head handling rules by introducing the Re-Proposal mechanism and No-Endorsement Certificate (NEC).

Either complete the final submission for the "nearly confirmed" block;

Either 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 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 is able to impose clear constraints on improper skipping behavior.

If a leader attempts to skip the previous block without cause and fails to provide NEC evidence, the protocol will immediately recognize and reject that action. Jumping behavior 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 phase failures;

Even in extreme situations, such as when a certain node deliberately skips its proposal round in an attempt to help others seize the MEV of the previous block, the protocol will enforce that subsequent leaders prioritize re-proposing the original block, preventing the attacker from gaining economic benefits by skipping the process.

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

Previous designs for handling tail-end forks (such as the BeeGees protocol) have certain protective capabilities, but they often rely on high communication complexity (n²) or enable heavy communication processes in every round, which significantly increases the system burden in practice.

The design strategy of MonadBFT is more sophisticated:

Additional communication (such as timeout messages and block re-proposals) is only initiated when the view fails or exceptions occur. The protocol still maintains a lightweight and efficient operating state along the regular path of most honest leaders continuously producing blocks.

This dynamic balance between performance and security is one of the core advantages of MonadBFT compared to previous-generation 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 addresses the tail fork problem inherent in pipelined HotStuff from a structural protocol layer.

The tail branching can distort the economic incentives of block proposers and poses a potential threat to the network's activity. MonadBFT ensures that any block proposed by honest leaders and receiving a statutory majority vote will not be abandoned or skipped by introducing a re-proposal mechanism and Non-Exculpatory Certificates (NEC).

In the next article, we will continue to explore the other two core features of MonadBFT:

1. Speculative Finality

2. Optimistic Responsiveness

and further analyze the practical implications of these mechanisms for validators and developers.

To be continued.