MonadBFT: Redefining Blockchain Consensus Security, Saying Goodbye to Tail Fork Risks
TechFlow Selected TechFlow Selected
MonadBFT: Redefining Blockchain Consensus Security, Saying Goodbye to Tail Fork Risks
MonadBFT is a new-generation consensus protocol specifically designed to address the tail forking problem.
Navigating Web3 tides with focused insightsAuthor: michaellwy
The core of blockchain lies in achieving a strict global consensus: regardless of where network nodes are located—across countries or time zones—all participants must ultimately agree on a set of objective outcomes.
However, real-world distributed networks are far from ideal: nodes go offline, some lie, and others deliberately cause disruptions. In such conditions, how does the system still manage to maintain “unanimous agreement”?
This is precisely the problem that consensus protocols aim to solve. At their core, they are rule sets guiding a group of independent—and potentially untrusted—nodes to reach a unified decision on the order and content of every transaction.
Once this "strict consensus" is established, blockchains unlock key features like digital property rights, inflation-resistant monetary models, and scalable social coordination structures. But this requires the consensus protocol itself to guarantee two fundamental properties:
-
No two conflicting blocks can both be confirmed;
-
The network must continue progressing without getting stuck or halting.
MonadBFT represents the latest technical breakthrough toward this goal.
A Brief Review of Consensus Protocol Evolution
The field of consensus mechanisms has been studied for decades. Early protocols like PBFT (Practical Byzantine Fault Tolerance) could already handle a realistic scenario: as long as malicious or faulty nodes don’t exceed one-third of the total, the system can still reach agreement—even if some nodes fail, lie, or behave arbitrarily.
These early designs followed a more "traditional" approach: each round selects a leader, who proposes a block, while other validators vote through multiple phases—pre-prepare, prepare, commit, reply—to gradually confirm the transaction order.
In each phase, all validators must communicate with each other. In other words, everyone talks to everyone else, causing message volume to grow in a “mesh” pattern.
This communication structure has O(n²) complexity—if there are 100 validators, nearly 10,000 messages may be transmitted per consensus round.
This works fine in small networks, but as validator count increases, the communication burden quickly becomes unsustainable, crippling efficiency.
Source:
https://medium.com/coinmonks/pbft-understanding-the-algorithm-b7a7869650ae
This "everyone must talk to everyone" quadratic communication model is highly inefficient. For example, in a 100-validator network, tens of thousands of messages might be exchanged per round.
This is manageable in small groups, but becomes unacceptable in large-scale, open, global blockchain networks. As a result, early BFT protocols like PBFT and Tendermint are typically limited to permissioned systems or those with very few validators.
To adapt BFT protocols to permissionless, public-chain environments, newer designs have adopted lighter communication patterns—requiring validators to only communicate with the leader, not with all peers.
This reduces message complexity from O(n²) to O(n), significantly lowering system overhead.
The HotStuff protocol, introduced in 2018, was designed specifically to address this scalability challenge. Its design principle is clear: replace PBFT’s complex voting process with a simpler, leader-driven communication structure.
HotStuff’s key innovation is linear communication. In this model, each validator sends its vote only to the current leader, who aggregates them into a Quorum Certificate (QC)—a collective signature proving that “a majority of nodes have agreed on this proposal.”
In contrast, PBFT uses an “all-to-all broadcast” model, where everyone speaks simultaneously—leading to chaos. HotStuff operates more like "one collector, one package", maintaining high efficiency regardless of network size.
The diagram above compares HotStuff's fan-out communication structure with PBFT's fully connected mesh
Source:
https://www.mdpi.com/1424-8220/24/16/5417
Beyond linear communication, HotStuff can be further enhanced into a pipelined version (pipelined HotStuff) to boost performance.
In basic HotStuff, the same validator often acts as leader across multiple rounds until a block is finalized—a process of "one block at a time," focusing all resources on advancing just one block.
In pipelined HotStuff, the mechanism becomes more flexible: a new leader is elected every round, and each leader has two tasks:
-
Package votes from the previous round into a Quorum Certificate (QC) and broadcast it;
-
Propose a new block to initiate the next round.
Rather than waiting to finalize one block before starting the next, it operates like an assembly line: different leaders handle different stages in sequence. One proposes a block, the next confirms it and proposes a new one—the consensus process passes like a baton in a relay race.
Hence the term “pipeline”: while one block is being confirmed, the next is already being prepared, enabling parallel processing and higher throughput.
In summary, protocols like HotStuff represent major improvements over traditional BFT in two dimensions:
-
Lighter communication: each validator only communicates with the leader;
-
Higher processing efficiency: multiple block finalizations can proceed in parallel.
This makes HotStuff a foundational blueprint for many modern PoS blockchain consensus systems. However, every advantage comes with trade-offs: the pipeline architecture, while powerful, subtly introduces a structural risk that’s easy to overlook.
Next, we dive into this core issue: Tail Forking.
The Tail-Forking Problem
While HotStuff—especially its pipelined variant—solves scalability issues in consensus protocols, it also introduces new challenges. The most critical and often overlooked is the so-called “tail-forking” problem.
What is tail-forking? Simply put, it refers to an unexpected block reorganization (reorg) occurring at the “tip” of the blockchain.
Specifically, a block that is valid, successfully propagated to most validators, and has received sufficient voting support—should be about to be confirmed and written into the main chain—ends up being “skipped,” orphaned, and replaced by another block at the same height.
This isn’t a bug or an attack, but rather a possibility embedded in the protocol’s own design. Sounds unfair? So how does this happen?
Recall that in pipelined HotStuff, each leader has two responsibilities:
-
A. Propose a new block (e.g., Bₙ₊₁)
-
B. Collect votes for the prior leader’s block and generate a QC (e.g., finalize Bₙ)
These tasks run in parallel, passed like a baton. But here lies the problem.
Suppose Alice is the leader at height n and proposes block Bₙ, which receives overwhelming votes—just shy of confirmation.
Next, Bob becomes the leader and should propose Bₙ₊₁ while including the QC for Bₙ to finalize it.
But if Bob goes offline or deliberately omits Bₙ’s QC, problems arise.
Since no one packages the votes for Alice’s block, the voting record for Bₙ fails to propagate. The block, though nearly confirmed, gets “cold-shouldered” and eventually ignored by the network.
This is the essence of tail-forking: a prior leader’s block is skipped due to the next leader’s failure or malice.
Why Is Tail-Forking Serious?
The tail-forking problem primarily affects two areas: 1) incentive misalignment and 2) threats to system liveness.
First, rewards are lost:
If a block is discarded, its proposer earns no reward—neither block reward nor transaction fees. For instance, Alice proposes a valid block with strong voting support, but due to Bob’s negligence or malice, it’s not confirmed—Alice gets nothing. This creates perverse incentives: malicious nodes like Bob can suppress competitors’ rewards simply by refusing to cooperate. No technical attack is needed—just non-collaboration—potentially reducing participation, fairness, and encouraging collusion among validators.
Second, expanded MEV attack surface:
Tail-forking enables a subtler but serious issue: increased manipulation of MEV (Maximal Extractable Value). Suppose Alice’s block contains a high-value arbitrage trade. Bob, acting maliciously, could collude with the next leader Carol to withhold Alice’s block. Carol then constructs a new block at the same height, copying the profitable trade and claiming the MEV for herself. This “head reordering + collusion” appears compliant on the surface but is actually a carefully orchestrated theft. Worse, it incentivizes leaders to form collusive relationships, turning block confirmation into a profit-sharing game rather than a public service.
Third, compromised finality and degraded user experience:
Compared to Nakamoto-style protocols, BFT’s major advantage is deterministic finality: once a block is committed, it cannot be rolled back. Tail-forking undermines this guarantee, especially for blocks that have received votes but not yet formal confirmation. High-throughput dApps often rely on reading data immediately after voting to reduce latency. If such a block is suddenly discarded, users may experience state rollback—such as incorrect account balances, vanished leveraged trades, or reset game states.
Fourth, potential for cascading failures:
Typically, tail-forking only delays a block by one round—minor impact. But in edge cases, if several consecutive leaders skip prior blocks, the chain may stall entirely, with no one willing to “pick up” the previous block. Progress halts until a cooperative leader finally steps in.
Prior solutions, such as the tail-forking mitigation in the BeeGees protocol, often sacrifice performance—e.g., reintroducing O(n²) communication—making them impractical.
What Is MonadBFT?
MonadBFT is a next-generation consensus protocol specifically designed to solve the tail-forking problem. Its brilliance lies in eliminating structural vulnerabilities without sacrificing the performance gains of pipelined HotStuff. In other words, MonadBFT doesn’t start from scratch—it builds upon HotStuff’s core framework, refining it. It retains three key features:
1) Rotating leader: a new leader is elected each round to advance the chain;
2) Pipelined commits: multiple block finalization processes can overlap;
3) Linear messaging: each validator only communicates with the leader, drastically reducing network overhead.
Yet these alone aren’t enough for full security. To close the tail-forking structural loophole, MonadBFT adds two critical mechanisms:
1) Forced Re-Proposal Mechanism (Re-Proposal)
2) No-Endorsement Certificate (NEC)
Re-Proposal Mechanism
In BFT protocols, time is divided into rounds (called views), each led by one proposer. If the leader fails (e.g., misses proposing or submits an invalid block), the system switches to the next view and elects a new leader.
MonadBFT introduces a mechanism to ensure that any honestly proposed block won’t be dropped during view changes due to leadership rotation.
When the current leader fails, validators send a signed view-change message, indicating the round has timed out.
Critically, this message doesn’t just say “timeout”—it must include the most recent block the validator voted for, effectively saying: “I didn’t receive a valid proposal; this is the latest block I’ve seen.”
The new leader collects these timeout messages from a supermajority (2f+1) of validators and forms a Timeout Certificate (TC). The TC represents the network’s collective snapshot of the “head block” when the prior round failed. The new leader selects the highest block (by height or view number) from the TC—called the high_tip.
MonadBFT mandates that the new leader’s proposal must include a valid TC and must re-propose the highest pending block from the TC, giving it another chance to be confirmed.
Why? Because, as previously noted, we don’t want a nearly confirmed block to vanish.
For example, suppose Alice is the leader in view 5, proposes a valid block, and receives majority votes. Then Bob, the view 6 leader, goes offline and fails to advance the chain. When Carol becomes the view 7 leader, under MonadBFT rules, she must include the TC and re-propose Alice’s block—ensuring Alice’s honest work isn’t wasted.
If Carol lacks Alice’s block, she can request it from other nodes. They can either:
-
Provide the block, or
-
Return a signed “No-Endorsement (NE)” message stating they don’t have it (mechanism detailed later). (Up to f Byzantine nodes may ignore requests.)
Once Carol re-proposes Alice’s block, she gains an additional proposal opportunity, ensuring she isn’t penalized for the prior leader’s failure.
The purpose of the re-proposal mechanism is clear: to ensure fair chain progression—no valid work is silently discarded due to bad luck or sabotage.
No-Endorsement Certificate (NEC)
Continuing the example: after Bob’s view times out, Carol requests the high_tip block (Alice’s block) from other validators. At least 2f+1 validators respond by either:
-
Providing Alice’s block, or
-
Sending a signed NE message stating they did not receive it
If Carol receives Alice’s block, she must re-propose it per protocol. Only if at least f+1 validators sign NE messages can Carol skip the block and propose a new one.
Why f+1? In a BFT system with 3f+1 validators, at most f can be malicious. If Alice’s block truly received supermajority votes, at least 2f+1 honest nodes must have received it.
Thus, if Carol claims “I couldn’t obtain Alice’s block,” she must present signatures from f+1 validators confirming they never received it. This forms a No-Endorsement Certificate (NEC).
NEC serves as the leader’s免责 (liability waiver): it’s a verifiable proof that the prior block wasn’t ready for confirmation—not a malicious omission, but a justified abandonment.
Re-Proposal + NEC = Solving Tail-Forking
By introducing the Re-Proposal mechanism and No-Endorsement Certificate (NEC), MonadBFT establishes rigorous and explicit rules for handling the chain tip:
Either finalize a “nearly confirmed” block,
Or provide sufficient evidence that it’s not ready for confirmation.
Otherwise, skipping or replacing the prior block is not allowed.
This ensures: any block that has received a quorum of votes cannot be abandoned due to leader failure or deliberate avoidance.
The structural risk of tail-forking is systematically eliminated, and the protocol explicitly constrains improper skipping behavior.
If a leader attempts to skip a prior block without providing NEC proof, the protocol immediately detects and rejects it. Skipping without cryptographic evidence is deemed invalid and will not gain network consensus.
From an economic incentive perspective, this design offers clear protection for validators:
-
Any block honestly proposed and backed by votes will not lose its rewards due to downstream failures;
-
Even in extreme scenarios—e.g., a node intentionally skips its turn to help another steal MEV from a prior block—the protocol forces the next leader to re-propose the original block, preventing attackers from profiting via skipping.
More importantly, MonadBFT enhances security without sacrificing performance.
Previous tail-forking mitigations (like BeeGees) offered some protection but often relied on high communication complexity (O(n²)) or triggered heavy re-communication every round, imposing significant overhead in practice.
MonadBFT’s design is more elegant:
Extra communication (e.g., timeout messages, block re-proposal) is only activated upon view failure or anomalies. Under normal operation—with honest leaders producing blocks consecutively—the protocol remains lightweight and efficient.
This dynamic balance between performance and security is one of MonadBFT’s core advantages over earlier protocols.
Summary
This article reviewed the fundamentals of traditional PBFT, traced the evolution of the HotStuff protocol, and focused on how MonadBFT structurally resolves the inherent tail-forking issue in pipelined HotStuff.
Tail-forking distorts proposer incentives and poses latent threats to network liveness. MonadBFT addresses this by introducing the Re-Proposal mechanism and No-Endorsement Certificate (NEC), ensuring that any block proposed by an honest leader and supported by a quorum of votes will not be abandoned or skipped.
In the next part, we’ll explore two other core features of MonadBFT:
1) Speculative Finality
2) Optimistic Responsiveness
And analyze their practical implications for validators and developers.
To be continued.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
