This document investigates how the current BFT mechanism on the testnet aligns with the approach detailed in [https://www.arxiv.org/pdf/2502.20692]. Initially, we analyzed a single validator’s log and attempted to map the behavior of a single round to the paper’s descriptions. We then extended the analysis to two other validators. However, because the current testnet consensus protocol closely resembles Pipelined HotStuff, some of the information in this Notion document may be inapplicable to the MonadBFT protocol that will be deployed on mainnet. Notably, Monad should now revert two blocks (rather than one) whenever a slot is missed.
The novel Monad BFT protocol (as described in the white paper by Jalalzai, Babel et al, 2/28/2025) is currently not live on Monad Testnet. The consensus protocol currently on Monad Testnet most closely resembles “pipelined hotstuff,” which is exposed to the “Tail Forking” MEV strategy in which a proposer missing round N induces a “reorg” of the block from the proposer of round N-1. This graphic is an illustration of an actual -albeit accidental- occurrence on Testnet. Importantly, the actual Monad BFT protocol is not vulnerable to this attack.
The protocol switches to the unhappy path in two cases:
Specifically, validators enter the unhappy path if they don't receive a valid proposal within the timeout period τ. When this happens, a validator broadcasts a timeout message ⟨view, tip, tc, σ⟩, as shown in Figure 3. After all validators—including the next leader—receive this timeout message, the (next?) leader builds a timeout certificate using 2f + 1 distinct timeout messages.
The normal flow was disrupted by a leader or network failure.
Log Events: "received proposal" (INFO) at 00:17:56.305Z, followed by "proposal message" (DEBUG) at 00:17:56.305Z with detailed block data.
Leader’s Proposal: The node logs that it received a proposal for round N-1. This corresponds to the leader of round N-2 broadcasting a new block proposal to all validators. In MonadBFT (a HotStuff-based protocol), each round’s leader sends out a block along with proof of the previous round’s outcome. Here, the proposal includes a QC for round N-2, as indicated by the qc field in the log’s block header (showing a Vote { ... r: N-2 ... }). A Quorum Certificate (QC) is an aggregated signature from a supermajority (typically ≥2/3) of validators attesting to a block’s validity. Once two-thirds of validators agree on a block, it is considered confirmed, and the next leader includes this QC in its proposal. In the log, last_round_tc: None under the block header confirms the previous round ended with a QC (not a timeout) – the normal happy path condition.
Block Details (Debug): The "proposal message" log entry dumps the proposal’s content. It shows the block’s author (the leader’s identifier), the epoch (E) and round (N), and the block’s IDs. The block_header contains the QC for round N-2 (with sigs: BlsSignatureCollection indicating a threshold BLS signature from validators). This QC serves as proof that the prior block is certified by a quorum. The presence of a QC means the validators’ “high tip” – i.e. the highest block with a certificate known so far – is updated to the block from round N-2.
Relevance: Receiving a proposal means the protocol is in the propose phase of the round. The validator now needs to verify the proposal: check the QC, block validity, etc. If valid, it will move to voting phase. The log’s INFO level “received proposal” confirms the block arrival, and the DEBUG “proposal message” provides insight into the block’s contents (e.g., 80 transactions in the block body, block id: cf2d..3d67, etc.), which we associate with the proposal concept in consensus.