MonadBFT: Fast, Responsive, Fork-Resistant, Streamlined Consensus
Category Labs is proud to introduce MonadBFT, the proposed future consensus protocol of the Monad blockchain. MonadBFT is responsible for ensuring that the network aligns on valid proposed blocks efficiently and securely, while supporting 10,000 tx/s and sub-second time to finality. In this inaugural blog post, we provide a quick overview of MonadBFT's key properties and delve more deeply into one particular property of note: tail-forking resistance.
For a full description and deep technical dive into MonadBFT, please refer to our full research paper.
Important: This blog post describes a future improvement over the preliminary version running on the Monad testnet. The documentation here describes the existing implementation.
High level properties
MonadBFT builds on the pipelined Hotstuff family of protocols—a tried-and-tested approach known for achieving low-latency, high-performance, and reliable consensus at scale. MonadBFT extends upon past work by achieving the following combination of properties:
✅ Tail-forking resistance – Prevents forks that disrupt the blockchain and cause delays. In pipelined Hotstuff protocols, a block may be abandoned if the subsequent leader is offline or malicious, even if a supermajority voted for it. MonadBFT prevents such tail-forking events by requiring leaders to repropose blocks that gathered sufficient support.
✅ Single-round speculative finality – Transactions can be processed faster, reducing overall latency. By providing stronger guarantees on inclusion of Voted blocks, MonadBFT unlocks lower latency for apps and users that do not need to wait for full finalization.
✅ Optimistic responsiveness – The core consensus protocol has no artificial delays and can proceed as quickly as the network allows1. This approach reduces latency and enables the system to move forward more efficiently when conditions are favorable.
✅ Linear message and authenticator complexity (on the happy path) – MonadBFT scales efficiently with the number of validators. The leader broadcasts a proposal to all validators, who then send their votes to the next leader. This fan-out and fan-in communication pattern results in a linear network-wide complexity. Furthermore, per-validator complexity is reduced for block propagation by splitting blocks into chunks using erasure encoding. As a result, the bandwidth required for each validator is roughly the same regardless of the total validator count.
By delivering all of the above properties, MonadBFT balances latency, bandwidth, and inclusion guarantees for both users and validators. We devote the remainder of this blog post to a discussion around tail-forking resistance. We will explore the additional properties in future writing.
Tail-forking
Tail-forking is a problem often overlooked in consensus protocol design, despite being one of the most significant issues in Proof-of-Stake (PoS) blockchains. MonadBFT places fork resistance at the core of its design, making block inclusion more reliable, ensuring fairness among validators, and preventing particularly harmful MEV attacks.
Important: Tail-forking occurs when a validated block (a proposal with a supermajority of votes or a majority of honest validators’ votes) is abandoned and replaced by a different block. Depending on the consensus protocol, tail-forking may also be referred to as a chain reorganization (reorg). Tail-forking should not be mistaken for protocol (hard) forks, which occur when a blockchain splits into two independent, functional chains due to disagreements among validators—such as when only a portion of validators adopt changes to the consensus protocol.
Motivation
Here’s a screenshot of the gmonads.com dashboard, which highlights a problem with the current BFT consensus on the Monad testnet. In this scenario, all validators performed perfectly, except for one that was offline. Can you spot what’s wrong in this picture?
There are two failed proposals by two consecutive validators (we’ll call them Valerie and Will respectively), but crucially, only the latter one, Will, was offline. Despite being online and following the protocol honestly, Valerie’s proposal was not finalized, as Will failed to gather attestations for Valerie’s proposal. This is a direct result of the pipelined nature of the existing BFT consensus protocols, as every validator has two responsibilities: proposing a new block and aggregating votes for the previous proposal into a Quorum Certificate (QC). When a validator fails, it not only affects its own proposal but also causes the previous proposal to be abandoned, a property called tail-forking. This issue is not unique to Monad's current consensus protocol; in fact, all currently deployed Proof-of-Stake-based blockchains are susceptible to tail-forking to varying degrees.
This nullification is a huge issue as a validator. Your valid proposal fails (and you lose any associated fees and potential block rewards) because the next leader wasn’t doing their job.
High-performance apps like exchanges, video games, or other real-time systems might choose to prioritize UI responsiveness by speculatively updating based on the Voted state (~500 ms after block proposal) rather than the Finalized state (~1 s after block proposal). If apps are exposing blocks in the Voted state, tail-forking will cause that state to be reverted, leading to confusion and delays. Resilience to tail forking is necessary to offer an excellent user experience. For a thorough explanation of the various states (including Voted and Finalized), see the existing documentation.
The tail-forking MEV attack
While an offline validator nixing the previous leader’s block involuntarily is bad, there is an even worse problem. Validator Will can collude with the next validator Xander, as follows: Will intentionally misses his slot, invalidating Valerie’s proposal and allowing Xander to re-propose that block. When Xander re-proposes the block, he may reorder transactions to extract MEV. This type of inter-block MEV attack can be profitable for the attacker at the expense of the previous leader.
The consequences of tail-forking are severe. When a block is abandoned, the leader of the discarded block does not receive rewards or fees. The existence of MEV opportunities in block building makes tail-forking attacks lucrative: a validator that observes high MEV in the previous block can cause it to be abandoned and claim the MEV rewards for itself (akin to selfish-mining attacks in Bitcoin). But this attack is not zero-sum—it produces negative externalities for the network as blocks are not finalized. In the worst case, this could lead to a chain of tail-forking events by successive malicious validators, which produces a chain outage (see below diagram). In both malicious and unintended cases, tail-forking introduces vulnerabilities in Proof-of-Stake (PoS) consensus protocols, as discussed by (Neuder et al.) (Sarenche et al.) (Schwarz-Schillin et al. 560-576).
The solution
MonadBFT solves the tail-forking problem through inclusion of metadata which guarantees that a proposed block by an honest leader which garners either (a) a supermajority of votes, or (b) a majority of votes from honest validators, will eventually be Finalized (and never abandoned). On the happy path, the leader must propose a block that extends the previous leader’s block. On the unhappy path, timeout messages are broadcast by each validator. In MonadBFT, each validator includes the header of the most recent proposal that it voted for in its timeout messages. The subsequent leader must repropose the most recent proposal embedded in the collected timeout messages, making sure that it is not abandoned. On the other hand, if the subsequent leader proposes a fresh proposal, it must provide signed attestations as proof that the previous leader’s block was not received by the majority of validators.
Here is how the dashboard would look like in the new MonadBFT protocol.
While Will’s outage affects the prior block submitted by Valerie temporarily, the next validator, let’s call him Xander, will repropose Valerie’s block to make sure it does not get abandoned. Xander can then propose his own block after the reproposal of Valerie’s block. This way, every honest, online validator gets to propose exactly one new block, which ensures fairness. Note that in this scenario, Xander is the leader for two rounds.
Conclusion
HotStuff enables linear communication complexity in the happy path, enabling much larger validator sets than quadratic. Pipelined HotStuff is an improvement on HotStuff which increases efficiency by proposing a block at each round of communication, but it introduces the severe downside of tail forking. MonadBFT addresses the problem of tail forking, giving the best of all worlds.
If you’d like to dive deeper, feel free to give the full paper a read and let us know if you have questions! In future posts, we will further explore the MonadBFT protocol, breaking down more of its features. Stay tuned!
Footnotes
1 The Monad testnet currently sets a minimum vote time of 500 ms to encourage validator geodiversity though this is not required for the protocol’s operation. This configuration parameter differs from the maximum wait time, or slot time, used by other protocols, which is required for liveness and/or safety guarantees.
References
Neuder, M., Moroz, D. J., Rao, R., & Parkes, D. C. (03, 02 2021). Low-cost attacks on Ethereum 2.0 by sub-1/3 stakeholders. Arrive. https://arxiv.org/abs/2102.02247
Sarenche, R., Tas, E. N., Monnot, B., Schwarz-Schilling, C., & Preneel, B. (2024, 07 28). Breaking the Balance of Power: Commitment Attacks on Ethereum’s Reward Mechanism. Arrive. https://arxiv.org/pdf/2407.19479
Schwarz-Schillin, C., Neu, J., Monnot, B., Asgaonkar, A., Tas, E. N., Tse, D., Eyal, I., & Garay, J. (2022, 10). Three Attacks on Proof-of-Stake Ethereum. Financial Cryptography and Data Security, 13411(LNCS), 560–576. https://doi.org/10.1007/978-3-031-18283-9_28