In support of MIP-9, with a suggestion to use testnet more aggressively
This MIP is well-scoped. The 50% increment is a reasonable step and the rationale is sound.
One observation worth noting: the primary cost of increasing ACTIVE_VALSET_SIZE in MonadBFT is not bandwidth — it is signature aggregation latency at the leader. MonadBFT operates on O(n) message complexity in the happy path; each validator sends a signed vote directly to the next leader, who must aggregate those into a QC before proceeding. At 300 validators and 400ms block times, this is unlikely to be the bottleneck under nominal load. Under sustained peak throughput, however, the relationship between n and round latency has not been empirically characterized at this scale on a live network.
A proposal for the testnet phase: rather than validating 300, CONSIDER targeting 500 as the testnet ceiling. Additionally, it would be informative to have a subset of willing operators run two consensus nodes under the same stake weight — this artificially increases the signature surface seen by the leader per round without requiring additional stake, and would surface degradation in QC collection time during view changes and reproposals.
For context: the HotStuff protocol family was originally specified with an explicit design target of 500–1,000 validators, and subsequent implementations have validated this range in production environments. MonadBFT’s improvements over baseline pipelined HotStuff — specifically its tail-forking resistance via mandatory reproposal and the NEC mechanism — do not introduce additional per-validator overhead in the happy path. There is therefore no architectural reason Monad cannot reach 1,000+ validators incrementally. The question is empirical, and the testnet is the right place to resolve it.
Suggested trajectory: ACTIVE_VALSET_SIZE = 300 for this MIP → testnet experiment at 500 with dual-node operators → data-informed follow-on MIP.
1 Like