MonadBFT: Fast, Responsive, Fork-Resistant Streamlined Consensus

TL;DR

MonadBFT addresses the challenge of achieving fast, fair, and scalable Byzantine fault-tolerant consensus for blockchains by integrating rotating leaders, pipeline-based progress, tail-forking resistance, speculative finality, and rapid recovery. It introduces reproposals via high-tip selection and backup QCs to prevent tail-forking, satellite NECs for unrecoverable blocks, and fast-recovery mechanisms that preserve progress without sacrificing safety. The protocol operates with optimistic responsiveness on the happy path and quadratic communication on the unhappy path, while guaranteeing safety through quorum-intersection arguments and a two-QC commit rule. Practically, MonadBFT enables low-latency confirmations (speculative finality) and robust recovery with leader-fault isolation, making it appealing for high-throughput, latency-sensitive blockchain applications.

Abstract

This paper introduces MonadBFT, a novel Byzantine Fault Tolerant (BFT) consensus protocol that advances both performance and robustness. MonadBFT is implemented as the consensus protocol in the Monad blockchain. As a HotStuff-family protocol, MonadBFT has linear message complexity in the common case and is optimistically responsive, operating as quickly as the network allows. A central feature of MonadBFT is its tail-forking resistance. In pipelined BFT protocols, when a leader goes offline, the previous proposal is abandoned. Malicious leaders can exploit this tail-forking behavior as a form of Maximal Extractable Value (MEV) attack by deliberately discarding their predecessor's block, depriving that proposer of rewards and enabling transaction reordering, censorship or theft. MonadBFT prevents such tail-forking attacks, preserving both fairness and integrity in transaction execution. Another related feature of MonadBFT is its notion of speculative finality, which enables parties to execute ordered transactions after a single round (i.e., a single view), with reverts occurring only in the rare case of provable leader equivocation. This mechanism reduces user-perceived latency. Additionally, we introduce the leader fault isolation property, which ensures that the protocol can quickly recover from a failure. To our knowledge, no prior pipelined, leader-based BFT consensus protocol combines all of these properties in a single design.

Figures (10)

• Figure 2: In standard pipelined BFT, a single offline leader (Validator 2) causes two views to time out, as Validator 2 not only fails to make a proposal, but also fails to collect votes for Validator 1's block proposal P1. Furthermore, Validator 1's block is lost when Validator 3 makes its own proposal P3.
• Figure 3: In MonadBFT, a single offline leader (Validator 2) causes only one view to time out, as Validator 1 collects backup votes (thin dashed blue) and broadcasts a backup QC (thick dashed blue) for its own block proposal P1, allowing the view to complete successfully. Validator 3, recovering from the failure, can build directly on the backup QC of P1, ensuring that P1 (Validator 1's block) is not abandoned. To rule out tail-forks, Validator 3 must prove that Validator 2 did not produce a block that received sufficient support. This figure illustrates MonadBFT's fast recovery (introduced later in the paper), which avoids reproposals.
• Figure 4: Happy path workflow in MonadBFT. Note that validator sends votes to both the current (dashed, blue) and the next leader (solid, black). Each validator speculatively commits the parent block of a proposal after observing a QC from the previous round for the parent, and commits the grandparent block if the parent and grandparent have QCs from consecutive views. For simplicity, we omit the dissemination of the backup QC, as it is not required in this example.
• Figure 5: Happy path workflow in MonadBFT using backup QC. In this scenario, votes sent to the current leader, Validator 2, are arbitrarily delayed (dotted, red), preventing the formation of a QC. In this case, the old leader, Validator 1, will construct a QC using the backup votes (dashed, blue) and broadcast it to all validators, including the next leader (bold dashed, blue). This enables the next leader to extend the proposal. Although some messages are lost, this example belongs to the happy path, as a QC is successfully constructed and a timeout is avoided. Validators 3 and 4 also forward the backup QC received from Validator 1 to Validator 2. For simplicity, we omit this, as it is not required in this example.
• Figure 6: Unhappy path, but fast recovery workflow in MonadBFT, illustrating formation of a QC from tip votes. In this scenario, votes for proposal $P_1$, sent to both the current and next leader (dotted, red), are delayed. Consequently, no QC can be build for the proposal and the view times out. Upon timing out, validators broadcast timeout messages (solid, red), which also include their votes for $P_1$. The next leader (validator 2) then aggregates these votes to form a QC for $P_1$ and extends it with a new proposal $P_2$. This example also illustrates that a validator can cast both a vote and a timeout message in the same view and that both a QC and a TC can be formed in the same view.

Theorems & Definitions (84)

• remark 1
• remark 2
• lemma 1
• proof
• lemma 2
• proof
• lemma 3
• proof
• proof
• lemma 4