MonadBFT introduces four core innovations based on the pipelined HotStuff-style consensus: resistance to tail forks, single-round speculative finality, optimistic responsiveness, and linear communication.

In Part One, we explored how classic PBFT (Practical Byzantine Fault Tolerance) consensus works and how early versions of HotStuff operate. We also learned how MonadBFT addresses the tail fork issue in HotStuff, which is the problem of valid blocks sometimes being discarded in a pipelined system.

This tail fork issue causes two main problems: 1) it disrupts the rewards for honest block builders, and 2) it can lead to network stagnation.

MonadBFT introduces re-proposal rules and a no-endorsement voting mechanism to eliminate the tail fork problem, ensuring that any properly approved block from honest proposers can enter the chain.

In Part Two, we will explore two additional features of MonadBFT: 1) speculative finality and 2) optimistic responsiveness. We will also discuss the impact of MonadBFT on developers.

Single-Round Speculative Finality

In addition to resisting tail forks, another major feature of MonadBFT is single-round speculative finality.

In practical applications, this means that clients and users can receive transaction confirmations immediately after a block receives a supermajority of votes, even before the next round is completed.

Recall that in the baseline HotStuff protocol, a block typically goes through at least two phases (such as Fast-Hotstuff and Diem-BFT) before being considered finalized (irreversible): one phase obtains a quorum certificate (QC) (locking the block with ≥2f+1 votes), and the second phase is when the next leader builds and submits a block based on that quorum certificate (QC).

This two-phase commit is necessary to ensure safety: once enough honest nodes lock a block, conflicting blocks cannot obtain a quorum, and the submission in the next round will make it permanent. Therefore, clients often have to wait until the next block or the next round is produced to know whether the previous transaction is finalized.

MonadBFT essentially allows transactions to be considered final enough (safe to operate) after just one round of voting. This is known as speculative finality.

When the leader proposes a block and validators vote to form the QC for that block, the block is in a voted state (locked by a quorum). In MonadBFT, once validators form a QC, they immediately execute the transactions of that block and may even send preliminary confirmations to clients indicating that the block is (speculatively) accepted. It’s like saying, “We have a supermajority agreeing on this block. Unless something very unexpected happens, this block can be considered confirmed.”

This immediate confirmation is optimistic. The block has not yet been committed to the ledger. This will occur when the next proposal appears and confirms it (QC-on QC), but under normal circumstances, nothing will revoke it. The only situation that can revoke a speculatively executed block is if the leader performs an equivocation attack (i.e., proposing two different blocks at the same height to split the votes).

You can think of speculative finality as a great byproduct of resisting tail forks. Resistance to tail forks ensures that even if the next leader crashes, the current proposal will not be discarded (thanks to the re-proposal and NEC rules). The only situation where a speculatively executed block can be discarded is if the original proposer performs an equivocation attack (provably malicious double-signing error), and in this case: 1) it can be detected by conflicting QCs; 2) it can be punished; 3) it is extremely rare.

In previous protocols, they did not guarantee that the next leader would re-propose the last block, so tail forks were possible, breaking the speculative assumption.

Optimistic Responsiveness

In most consensus protocols, there is a built-in wait after each round, such as a buffer period or timeout. This is to ensure that all messages have arrived before proceeding. It is a protective mechanism designed to handle worst-case scenarios, such as leader crashes or not sending any information at all.

These timeouts are often overly conservative. If the network is functioning normally and all validators behave correctly, then a fixed wait becomes unnecessary overhead. Blocks could be completed faster, but the protocol delays for precaution.

MonadBFT introduces optimistic responsiveness, which means the protocol can proceed immediately based on network information rather than always relying on fixed timers. The design principle here can be summarized as “go fast when possible, be patient only when necessary.”

The design of MonadBFT allows it not to pause and wait for a predetermined timeout under normal circumstances, even during fault recovery, if it is not necessary.

• On the happy path (meaning we have an honest leader): There are no built-in delays in proposing or voting. Once it is the leader's turn, they will propose a block. Validators will immediately vote as soon as they receive a valid proposal. When the leader (or more precisely, the next leader, since in pipelined HotStuff, votes are sent to the next proposer) collects 2f+1 votes, a QC is formed and can be propagated. In the design of optimistic responsiveness, this will immediately trigger the next phase.

In practice, this means that if the network delay between nodes is 100 milliseconds, consensus may only take a few hundred milliseconds to complete a round (plus computation and aggregation overhead).

If it is not needed, it will not wait, for example, a full second of "slot time." This is different from the slot-and-epoch model adopted by the Ethereum mainnet. In Ethereum, the time interval for block production is fixed at 12 seconds. Even if everyone is prepared in advance, the protocol will still wait.

MonadBFT's approach eliminates unnecessary delays. It retains the pipelined HotStuff structure but removes the hard requirement of “must wait Δ seconds” under normal circumstances. This means it can outperform time-constrained systems in responsiveness without sacrificing safety.

• On the unhappy path (leader failure): In many consensus protocols, when the leader fails to propose a block, other nodes only realize this after a timeout Δ. For example, if Δ is 1 second, that time is essentially wasted. MonadBFT handles this differently. When validators detect a proposal loss, they immediately broadcast a timeout message (TC or timeout certificate). Once 2f+1 timeouts occur, the next leader takes over. The transition to a new view is triggered by quorum-based evidence rather than by a clock.

Comparison with HotStuff-Family Consensus

MonadBFT builds on the HotStuff family of consensus protocols but stands out by implementing a combination of a series of ideal features. Early protocols often optimized for certain dimensions, such as pipelined throughput or linear communication, but had to sacrifice others. MonadBFT uniquely combines linear message complexity, pipelined commits, strong resistance to tail forks, no fixed delay for immediate responsiveness, and efficient recovery mechanisms, while also retaining fast finality and high availability guarantees. The table below summarizes the comparison of MonadBFT with other rotating leader BFT protocols across these key dimensions:

What Does This Mean for Developers and Users? ​

For developers, MonadBFT means several things:

• Simpler finality model: With MonadBFT, you can treat blocks with a QC (supermajority vote) as effectively finalized, as the protocol will finalize it or impose penalties. Developers can operate with high confidence on a 1-block confirmation.
• Improved user experience for applications: If you are building a high-throughput application (exchanges, games, etc.), MonadBFT's low latency and resistance to forks will translate into a smoother user experience. Users can see their actions confirmed almost immediately and will not frequently encounter confusing reorganizations or rollbacks. This allows you to design applications with finality and rapid updates.
• Deterministic behavior: MonadBFT's stricter rules (such as re-proposal requirements) reduce the uncertainty of block inclusion. There are fewer "edge cases" where blocks are included or skipped due to subtle timing factors, such as whether votes or timeouts reach the leader first. MonadBFT replaces this time-sensitive ambiguity with clear rules and verifiable evidence. This makes reasoning about the protocol's correctness and testing easier. It also provides clear grounds for identifying faulty nodes (for example, if someone fails to re-propose or proposes conflicting blocks, you know they have violated the protocol).
• Scalability space: If you are a developer focused on scalability, MonadBFT provides you with more room before hitting bottlenecks. Compared to secondary protocols, you can more easily increase block size or the number of validators. Features like erasure-coded block propagation mean you can push large amounts of data across the network without over-consuming individual nodes. This makes targeting higher throughput possible and opens up design space for more ambitious on-chain applications.

For end users: Ordinary users may not understand any of the content we are discussing here, but they will feel its impact. With MonadBFT as the foundation of the Monad chain, users can expect all the good features below without sacrificing decentralization and resisting censorship.

• Faster confirmations: Transactions (such as sending tokens, exchanging assets, minting NFTs, executing trades) will be confirmed quickly.
• Reduced surprises: The consistency of the chain state is higher because things like tail forks, which are essentially reorganizations, are eliminated.
• Fairness and transparency: Improvements in consensus indirectly mean that the operation of the chain is fairer. No single validator can easily censor transactions or manipulate the ordering between blocks.

Conclusion ​

In summary, MonadBFT introduces four core innovations based on the pipelined HotStuff-style consensus:

Resistance to tail forks: MonadBFT is the first pipelined BFT protocol to eliminate tail fork attacks. It achieves this by having the next leader re-propose the last voted block in the event of the previous leader's failure or by presenting a No-Endorsement Certificate (NEC) to prove that the block lacks support. This ensures that any block that receives a supermajority of support will not be discarded, thus protecting the rewards of honest leaders and preventing malicious reorganizations and cross-block MEV extraction.

Single-round speculative finality: Validators can confirm blocks after a single round of communication (one leader proposal and voting), providing clients with immediate inclusion guarantees. This speculative confirmation will only be reverted in the case of a leader equivocation attack (an act that can be proven and punished), making it a safe assumption in practice.

Optimistic responsiveness: The protocol operates at network speed with no inherent delays. The leader immediately advances consensus upon receiving the necessary votes, and view changes occur immediately upon observing a quorum timeout, rather than waiting for a fixed timeout interval. This optimistic responsiveness design minimizes wait times and maximizes throughput while still being robust in handling asynchrony and failures.

Linear communication: On the happy path (i.e., when the leader is honest), the complexity of messages and validation is linear with respect to the number of validators. MonadBFT retains HotStuff's efficient communication model, using aggregated signatures and simple leader-to-validator broadcasts, allowing the protocol to scale to hundreds of validators without performance bottlenecks.

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。