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 reach a consensus on a set of objective results.

But the reality of distributed networks is not ideal: nodes go offline, nodes lie, and some even intentionally sabotage. In this case, how does the system “speak with one voice” and maintain consistency?

This is the problem that the consensus protocol aims to solve. It is essentially a set of rules to guide a group of independent and even partially untrusted nodes on how to reach a unified decision on the order and content of each transaction.

And once this ‘strict consensus’ is established, the blockchain can unlock many key features, such as digital property rights protection, anti-inflation currency models, and scalable social collaboration structures. But the premise is that the consensus protocol itself must ensure two fundamental aspects at the same time:

• Two conflicting blocks cannot both be confirmed;
• The network must continue to move forward and cannot get stuck or stop.

MonadBFT is the latest technological breakthrough in this direction.

A brief review of the evolution of consensus protocols

In the field of consensus mechanism, it 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 drop the chain, behave maliciously, or talk nonsense, as long as they do not exceed one-third of the total number, the system can still reach consensus.

The design of these early protocols is more “traditional”: a leader is selected in each round to initiate a proposal, and other validators vote on this proposal in multiple rounds to gradually confirm the transaction order.

The entire voting process usually goes through several stages, such as pre-prepare, prepare, commit, and reply. At each stage, all validators need to communicate with each other. In other words, everyone has to tell everyone else, and the message volume grows explosively in a ‘mesh’ pattern.

The complexity of this communication structure is n² - that is to say, if there are 100 validators in the network, each round of consensus may require transmitting nearly 10,000 messages.

In a small network, this is not a problem, but once the number of validators increases, the system’s communication burden will quickly become unbearable, directly affecting efficiency.

Source of information:https://medium.com/coinmonks/pbft-understanding-the-algorithm-b7a7869650ae

The ‘everybody talks to everybody’ 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 still be managed in a small circle, but when placed in a global, open chain network, the communication load immediately becomes unacceptable. So early BFT protocols like PBFT and Tendermint are usually only used in permissioned networks or systems with very few validators to barely function.

In order to allow the BFT protocol to adapt to permissionless, public chain environments, some next-generation designs are moving towards lighter communication methods: allowing each validator to communicate only with the leader, rather than with all members.

This optimizes the message complexity from the original n² to n, greatly reducing the system burden.

The HotStuff protocol was proposed in 2018 to address this scalability issue. Its design philosophy is very clear: to replace PBFT’s complex voting process with a more concise, leader-driven communication structure.

One of the key features 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, proving to the entire network: ‘Most nodes agree to this proposal.’

In contrast, the communication mode of PBFT is ‘broadcast to all’, where everyone speaks in the group, leading to a chaotic scene at times. HotStuff’s mode is more like ‘one gathers, one packages at a time’, which can maintain efficient operation regardless of how many people are on the network.

The figure compares the fan-out communication structure of HotStuff with the fully interconnected mode of PBFT Source:

https://www.mdpi.com/1424-8220/24/16/5417

In addition to linear communication, HotStuff can be further upgraded to a pipelined version, used to improve efficiency.

In the original HotStuff, the same validator will serve as the leader for multiple rounds in a row, until a block is fully confirmed. This process is ‘processing one block per round’, with all efforts focused on advancing the current one.

In the HotStuff pipeline, the mechanism is even more flexible: a new leader is selected in each round, and each leader has two tasks:

• Pack the last round of votes into a Quorum Certificate (QC) on one side and broadcast it to the entire network;
• On one side, propose a new block, ready to start the next round.

In other words, it is no longer “confirm one before processing the next”, but like a production line, different leaders take turns to be responsible for each step. The previous one proposes a block, the next one confirms it and continues to propose new blocks, and the consensus on the chain is passed on like a relay race.

This is the origin of the metaphor of “assembly line”: the current block is still in the confirmation process, while the next one is already in preparation, multiple steps are parallel, increasing throughput efficiency.

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

• First, the communication is lighter, with each validator only needing to communicate with the leader;
• Second, 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 everything has its pros and cons - while the pipeline structure is powerful in performance, it also quietly introduces a not easily discoverable structural risk.

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

Tail-Forking issue at the end

Although HotStuff, especially its pipelined version, solves the scalability problem of the consensus protocol, it also introduces some new challenges. The most crucial and easily overlooked is the so-called “Tail Forking” problem.

What is a tail fork? It can be simply understood as: a blockchain experiences an accidental block reorganization at the ‘tail’ of the chain.

Specifically, there is a block that is valid, has been successfully propagated to the majority of validators, and has received enough votes. In theory, it should be confirmed and written into the main chain immediately. However, in the end, it is “skipped,” orphaned, and replaced by another new block at the same height.

This is not a Bug, nor an attack, but because in the design structure of the protocol itself, there is a possibility of this ‘chain tailing’. Does this sound a bit unfair? So, how does this happen?

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

• A. Propose a new block (such as Bₙ₊₁)
• B. Collect votes for the block of the previous leader to generate QC (e.g., to finally confirm Bₙ)

These two tasks are parallel, taking turns to relay. But the problem arises here.

For example, suppose Alice is the leader, and she proposed block Bₙ at height n, which received a supermajority of votes and is “almost confirmed”.

Next, it should be Bob’s turn to take on the role of leader, continue to advance to the next block Bₙ₊₁ of the chain, and also include the QC (Qualified Commitment) of Bₙ in his proposal to complete the final confirmation of Bₙ.

But if Bob is offline at this time, or intentionally does not submit the QC of Bₙ, then there is a problem.

Because no one packaged Alice’s block with QC, the voting record of Bₙ did not spread out. This block, which should have been confirmed, was thus ‘cold processed’ and ultimately ignored by the entire network.

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

Why is the tail fork so severe?

The problem of tail fork mainly focuses on two aspects: 1) the incentive mechanism is disrupted, 2) the system’s activity is threatened.

First, rewards are swallowed:

If a block is abandoned, the leader who proposed it will not receive any rewards, either block rewards or transaction fees. For example, if Alice proposed a valid block and received overwhelming support in the vote, but due to Bob’s mistake or malicious operation, the block could not be confirmed, Alice will not receive a penny in the end. This will lead to a flawed incentive structure: malicious nodes like Bob can ‘cut off’ their reward source by skipping their opponent’s blocks. This behavior does not require technical attacks, only deliberate ‘non-cooperation’ to weaken the profits of competitors. If this happens repeatedly, over time, the participation and fairness of the entire system will decline, and even trigger collusion among nodes.

Second, MEV attack surface expands:

Tail forks also pose a more insidious but serious problem: there is more room for MEV (Maximum Extractable Value) to be maliciously manipulated. Here’s an example: Let’s say Alice has a valuable arbitrage trade in her block. If Bob wants to make trouble, he can collude with the next leader, Carol, and deliberately not spread Alice’s block. Carol then reconstructs a new block at the same height, “stealing” Alice’s original arbitrage trade - making the MEV gain his own. This practice of “chain head rearrangement + collusion and appropriation” is still a block according to the rules on the surface, but it is actually a well-designed plunder. Worse still, it induces “collusion” between leaders, turning block confirmation into a benefit-sharing game rather than a public service.

Third, undermine the finality guarantee, affecting user experience:

Compared to Nakamoto-like protocols, one major advantage of BFT is deterministic finality: once a block is committed, it cannot be rolled back. However, tail fork disrupts this guarantee, especially on blocks that are ‘pre-committed but not formally confirmed.’ Some high-throughput dapps often want to read data immediately after block voting to reduce latency, and if the block is suddenly discarded, it may cause user state rollback—such as abnormal account balances, high leverage trades that were just completed disappearing for no reason, or sudden game state resets.

Fourth, may cause a chain reaction failure:

In general, a tail fork may only delay the confirmation of a block for a round, which is not a big impact. However, in some edge cases, if several leaders in a row choose to skip the previous block, the system may be stuck, and no one is willing to “take over” the previous block. The entire chain is stuck until a leader who is willing to take responsibility finally appears, and the network will continue to move forward.

Although there have been 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 the loss.

What is MonadBFT?

MonadBFT is a new generation consensus protocol designed specifically to address the tail fork problem. Its strength lies in: while addressing structural vulnerabilities, it does not sacrifice the performance advantages brought by the HotStuff pipeline. In other words, MonadBFT is not starting over, but rather continuing to optimize based on the core framework of HotStuff. It retains three key characteristics:

1) Rotating leader: Select a new leader for each round to drive the chain forward;
2) Pipelined commits: Multiple block confirmation processes can overlap;
3) Linear Communication (linear messaging): Each validator only needs to communicate with the leader, saving a lot of network overhead.

But just relying on these three points is not secure enough. In order to plug the structural vulnerability of the tail 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 on time or with an invalid proposal), the system switches to the next round and selects a new leader.

MonadBFT has added a mechanism to ensure that any honestly proposed blocks during the view switch process will not ‘drop the chain’ due to leader rotation.

When the current leader fails, the validators will send a signed message for a round switch (view change), indicating that the current round has timed out.

In particular, this message not only indicates ‘time out’, but must also include the block information of the validator’s recent vote, which is equivalent to saying, ‘I did not receive a valid proposal, this is the latest block I currently see.’

The new round of leaders will collect these timeout messages from the supermajority (2f+1) validators and merge them into a Timeout Certificate (TC). This TC represents the unified cognitive snapshot of the ‘chain head block’ of the entire network when the previous round fails. The new leader will select the block with the highest height (or the latest view number), known as the high_tip, from it.

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

Why? As mentioned earlier: we do not want a block that is close to being confirmed to disappear.

For example, suppose Alice is the leader of view 5, proposed a valid block, and received a majority of the votes. Next, when the leader of view 6, Bob, is offline and fails to advance the chain process, by the time Carol takes over as the leader of view 7, according to the rules of MonadBFT, she must include TC and repropose Alice’s block. In this way, Alice’s honest work will not be in vain.

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 that the sender does not have this block (its mechanism is explained later). (Up to f Byzantine nodes may choose to ignore the request and not respond.)

Once Carol re-proposes Alice’s block, she will get an extra proposal opportunity to ensure that she is not ‘implicated’ due to the failure of the previous leader.

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

Non-Endorsable Certificate (NEC)

Continuing with the previous example: After Bob’s turn 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 blocks
• 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 repropose it according to the rules. Carol can only skip the block and propose a new one when at least f+1 validators have signed the NE message.

Why f+1? In a BFT system composed of 3f+1 validators, at most only f may be malicious. If Alice’s block did indeed receive a supermajority of votes, then at least 2f+1 honest nodes received it.

Therefore, if Carol claims, “I can’t get Alice’s block,” she must produce f+1 validator signatures to prove that none of them have received it. This constitutes a No-Endorsement Certificate (NEC).

NEC is a leader’s “disclaimer” credential: it is a verifiable evidence that the previous block is not ready to be confirmed, not maliciously skipped, but “abandoned” with reasons.

Re-proposal + Unendorsed certificate = Resolve the tail fork

MonadBFT introduces a set of rigorous and clear chain head processing rules by introducing the re-proposal mechanism and the No-Endorsement Certificate (NEC).

Either finally commit to the ‘close to being confirmed’ block;

Either provide sufficient evidence to prove that the block is not yet ready to be confirmed,

Otherwise, it is not allowed to skip or replace the previous block.

This mechanism ensures that any block that has received a legal majority of votes will not be abandoned due to leader mistakes or intentional circumvention.

The structural risks of the tail fork are systematically resolved, and the protocol can clearly constrain improper skipping behavior.

If a leader attempts to skip the previous block without providing NEC evidence, the protocol will immediately recognize and reject the behavior. 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 the block is honestly proposed and receives voting support, its reward will not be deprived due to subsequent failures.
• Even in extreme situations, such as when a node deliberately skips its own proposal round and tries to assist others in seizing MEV from the previous block, the protocol will force the subsequent leader to prioritize re-proposing the original block, preventing the attacker from gaining economic benefits by skipping the process.

More importantly, MonadBFT did not sacrifice protocol performance in order to enhance security.

Some designs that address tail forks (such as the BeeGees protocol) in the past have certain protective capabilities, but often rely on high communication complexity (n²) or enable heavy communication processes in each round, which significantly increases the system burden in practice.

The design strategy of MonadBFT is more sophisticated:

Additional communication (such as timeout messages, block re-proposals) is only initiated when the view fails or anomalies exist. On the regular path where most honest leaders continuously produce blocks, the protocol still maintains a lightweight and efficient operating state.

The dynamic balance between performance and security is precisely one of the core advantages of MonadBFT over its predecessor protocols.

Summary

This article reviews the basic mechanism of the traditional PBFT consensus, sorts out the development path of the HotStuff protocol, and focuses on how MonadBFT solves the inherent tail fork problem of the HotStuff pipeline at the protocol layer structure.

Rear forks can distort the economic incentives of block proposers and pose a potential threat to network activity. MonadBFT ensures that any block proposed by honest leaders and approved by a statutory majority vote will not be abandoned or skipped by introducing a re-proposal mechanism and Non-Endorsed Certificate (NEC).

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

1）Speculative Finality
2）Optimistic Responsiveness

Further analysis of these mechanisms and their practical significance for validators and developers.

Statement:

1. This article is reprinted from [michael_lwy], the copyright belongs to the original author [michael_lwy]，if you have any objections to the reprint, please contact Gate Learn Team)，the team will handle it as soon as possible according to the relevant process.
2. Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
3. The article’s other language versions are translated by the Gate Learn team, without mentioningGate.ioDo not copy, distribute, or plagiarize translated articles without permission.