[Paper] Majorum: Ebb-and-Flow Consensus with Dynamic Quorums

Source: arXiv - 2601.03862v1

Overview

The paper introduces Majorum, a new “ebb‑and‑flow” consensus construction that blends a dynamically‑available quorum‑based protocol (TOB‑SVD) with a lightweight finality layer. The design lets a blockchain keep making progress even when honest nodes drop off and later re‑join, while still guaranteeing that once a block is finalized it can never be reverted—something that pure dynamic‑availability protocols struggle to achieve during network partitions.

Key Contributions

• Ebb‑and‑flow design built on TOB‑SVD: Integrates a quorum‑based, dynamically‑available core with a partially‑synchronous finality component, achieving both liveness under churn and strong safety.
• Fast optimistic finality: Under good network conditions a block can be finalized in as few as three slots with only one voting phase per slot.
• Single‑phase per‑slot voting: Eliminates the multi‑round voting pipelines common in many BFT protocols, reducing latency and implementation complexity.
• Dynamic quorum management: Allows the set of voting participants to shrink or grow on‑the‑fly without sacrificing safety, addressing the “dynamic availability” problem head‑on.
• Formal safety & liveness proofs: Provides rigorous arguments that Majorum maintains safety across partitions and eventually finalizes all blocks when the network becomes partially synchronous again.

Methodology

1. Base protocol (TOB‑SVD):

   • Operates as a total order broadcast where each node maintains a local view of a quorum (a subset of participants whose votes are sufficient).
   • Quorum size can adapt dynamically based on which nodes are currently online, using a view‑change mechanism that re‑computes the quorum when membership changes.

2. Ebb‑and‑flow overlay:

   • Ebb phase: The TOB‑SVD core runs continuously, producing a stream of tentative blocks even when many nodes are offline.
   • Flow phase: A lightweight finality gadget runs in parallel, collecting votes on the latest tentative block and irrevocably committing it once a partially‑synchronous network condition is detected (i.e., messages are delivered within a known bound).

3. Slot‑based operation:

   • Time is divided into slots. In each slot every active validator casts a single vote for the block they consider the head of the chain.
   • After three consecutive slots (optimistic case) the finality gadget has gathered enough overlapping votes to certify the block, allowing the next slot to start building on the newly finalized block.

4. Safety argument:

   • The finality gadget only finalizes a block when a quorum intersection property holds: any two quorums that could have voted in overlapping slots share at least one honest validator. This guarantees that two conflicting blocks cannot both reach finality.

5. Evaluation:

   • The authors implement a prototype and run simulations under varying churn rates, network latency, and partition lengths. Metrics include block finalization latency, throughput, and the size of the quorum needed in each scenario.

Results & Findings

• Fast finality: In the best‑case the protocol finalizes a block after just three voting rounds, matching or beating many existing BFT designs that need 4‑5 rounds.
• Robustness to churn: Even when a sizable fraction of validators go offline, the quorum adapts and the system continues to make progress, albeit with slightly higher latency.
• Safety under partitions: No two conflicting blocks ever achieve finality, thanks to the quorum‑intersection guarantee.

Practical Implications

• Blockchain platforms: Majorum’s low‑latency finality makes it attractive for permissioned or consortium chains that need fast transaction confirmation (e.g., supply‑chain, finance) while still tolerating validator churn.
• Distributed databases: Systems that replicate logs across data centers can adopt the ebb‑and‑flow pattern to keep ingesting writes during temporary outages, only committing them once a stable network slice returns.
• Edge‑centric networks: IoT or edge‑computing clusters often suffer from intermittent connectivity; Majorum’s dynamic quorum lets edge nodes join/leave without halting the whole system.
• Simplified implementation: The single‑vote‑per‑slot design reduces the engineering burden compared to multi‑phase BFT protocols (e.g., PBFT, HotStuff), potentially lowering bug surface and audit costs.

Limitations & Future Work

• Partial synchrony assumption for finality: The safety guarantee hinges on eventually obtaining a known message‑delay bound; in prolonged asynchrony the system can only provide tentative blocks.
• Quorum reconfiguration overhead: While dynamic, the view‑change process still incurs a cost (extra messages) that can become noticeable under very high churn rates.
• Scalability of quorum intersection: As the validator set grows to thousands, maintaining sufficient quorum overlap may require larger quorums, which could erode the latency benefits.
• Prototype scope: The evaluation is based on simulations and a modest prototype; real‑world deployment on a public network would surface networking and cryptographic overheads not captured in the paper.

Future directions suggested by the authors include exploring hierarchical quorum structures to keep intersection guarantees cheap at scale, integrating cryptographic aggregation (e.g., BLS signatures) to further shrink message size, and testing Majorum in a production‑grade blockchain testnet.

Authors

• Francesco D’Amato
• Roberto Saltini
• Thanh-Hai Tran
• Yann Vonlanthen
• Luca Zanolini

Paper Information

• arXiv ID: 2601.03862v1
• Categories: cs.DC
• Published: January 7, 2026
• PDF: Download PDF