Mysticeti: Optimal DAG-Based Byzantine Consensus
- Mysticeti is a DAG-based Byzantine consensus protocol featuring uncertified DAG consensus, embedded fast-path, and strong safety guarantees in partially-synchronous networks.
- It achieves optimal commit latency within 3Δ message rounds and high throughput by utilizing O(1) signature operations per block.
- The protocol integrates the Beluga block synchronizer to ensure reliable block dissemination and defend against adversarial pull-induction attacks.
Mysticeti is a class of DAG-based Byzantine consensus protocols developed to reach optimal network latency in state machine replication, serving as the consensus core for high-performance blockchains such as Sui. It is architected for partially-synchronous adversarial environments with strong safety, liveness, and performance guarantees, achieving both optimal commit latency and substantial resource efficiency by avoiding explicit certificate construction. Key components include Mysticeti-C (uncertified DAG consensus), Mysticeti-FPC (embedded fast-path), and the Beluga block synchronizer for resilience under adverse network conditions (Babel et al., 2023, Kichidis et al., 19 Nov 2025).
1. System Model and Problem Setting
Mysticeti operates in the DLS model for partially-synchronous Byzantine fault tolerance (BFT), assuming validators, with up to controlled by a computationally bounded, adaptive adversary. Reliable, authenticated point-to-multipoint channels and cryptographic primitives with existential unforgeability are assumed. The protocol aims for atomic broadcast—ensuring total order, agreement, integrity, and validity—while minimizing commit latency and maximizing throughput. In the optimistic path, Mysticeti targets the BFT lower bound of three message rounds; in the fast path, it optimizes for low-latency, single-owner asset transfer (Babel et al., 2023, Kichidis et al., 19 Nov 2025).
2. Mysticeti-C: Uncertified DAG Consensus
2.1 DAG Construction and Structure
Time is divided into logical rounds ; each honest validator proposes exactly one signed block per round. Each block references at least $2f+1$ parent hashes from round . There are no explicit certificates; support patterns in the DAG act as implicit quorum confirmations.
2.2 Implicit Support and Commitment
Let hold if 's DFS in its parents "first sees" at . A block at round implicitly certifies proposer block at round if
This forms the "implicitly certified DAG."
2.3 Commit Rule and Latency
Proposer-slots (validator, round) receive status over three-round "waves":
- Direct-commit: round sees $2f+1$ implicit certificates.
- Direct-skip: round has $2f+1$ parents not voting any proposal in that slot.
- Indirect: iterates via recursion to later decision anchors.
Failure-free steady-state latency is limited by message propagation delays , saturating the known BFT lower bound (Babel et al., 2023).
2.4 Resource Efficiency
The protocol requires only one signature operation per block, regardless of committee size. Only a single signed block message type and simple multicast are used. Signature and computation costs are per block.
3. Mysticeti-FPC: Embedded Fast-Path
Mysticeti-FPC augments Mysticeti-C to support "fast" reliable-broadcast for single-owner transactions.
3.1 Woven Votes and Certification
Fast-path transactions are endorsed as validators include in their next blocks (implicit vote). Explicit votes (block, index) are subsequently included as other validators process 's DAG history. A fast-path transaction is certified upon gathering $2f+1$ votes.
3.2 Finalization and Cryptographic Operations
Finality occurs if either $2f+1$ blocks in the DAG certify the proposer of or a single implicitly-certifying block for appears in the DAG of a Mysticeti-C commit. Signature operations are amortized across blocks rather than incurred per transaction, yielding signature-op per block and eliminating per-transaction cryptographic overhead present in alternatives such as Zef or FastPay.
| Protocol | Latency p50 | Max TPS (small net) | Max TPS (large net) |
|---|---|---|---|
| Zef | 0.25 s | 20 k | 7 k |
| Mysticeti-FPC | 0.25 s | 175 k | 80 k |
3.3 Throughput and Performance
For block rate and up to transactions per block:
Mysticeti-FPC achieves significantly higher per-host throughput versus protocols with per-transaction signatures (Babel et al., 2023).
4. Formal Guarantees
Mysticeti provides formal proofs of safety and liveness for both consensus and fast-path layers:
- Mysticeti-C Safety: No two correct validators commit different blocks for the same proposer-slot, guaranteed by unique vote and quorum intersection.
- Mysticeti-C Liveness: Any honest proposer's block commits within post-GST, with eventual decision for prior undecided slots, by honest scheduling and vote patterns.
- Mysticeti-FPC Safety: No two conflicting fast-path transactions are finalized due to voting quorum intersection and anchoring in the consensus DAG.
- Mysticeti-FPC Liveness: Any honest fast-path transaction reaches finalization after $2f+1$ votes.
These properties hold in the standard DLS model (Babel et al., 2023).
5. Block Synchronization and the Beluga Protocol
5.1 Block Synchronizer Abstraction
A block synchronizer modularizes reliable broadcast at the base of the consensus stack. Mysticeti requires all blocks (and their causal ancestors) to be reliably available to enable DAG-based commit rules. APIs include block announcements, digest availability, and verification of causal ancestry (Kichidis et al., 19 Nov 2025).
5.2 Design and Attack Considerations
Naïve push-pull schemes are vulnerable to adversarial "pull-induction" attacks, wherein a Byzantine node withholds blocks, triggering excessive and redundant block pulls, potentially leading to bandwidth exhaustion and severe retardation in consensus progress.
5.3 Beluga Instantiation
Beluga provides a resource- and scarcity-aware synchronizer:
- Push protocol: Admission control maintains per-validator reputations (), enabling exclusion of low-reputation authors from parent selection. Latency for optimistic block relay is .
- Hybrid Pull Protocol (with ImPoA): Distinguishes "live" (on-path, round-critical) and "bulk" (off-path, archival) pulls, leveraging implicit proof-of-availability patterns (ImPoA) for efficient recovery. Live pulls ensure deterministic completion, whereas bulk pulls minimize on-path resource use.
- Defense: Repeated misbehaviors penalize validator reputation, reducing selection as parents and thus bounding pull amplification.
5.4 Latency and Performance Under Adversity
- Optimistic-case: Mysticeti with Beluga achieves consensus latency, sustaining up to tx/s at $0.5-0.8$ s latency at scale.
- Adversarial-case: Under targeted pull-induction attacks, Beluga bounds consensus latency at , with throughput remaining above tx/s and latency reduced 25× relative to baseline Mysticeti.
6. Experimental Evaluation and Deployment
Mysticeti protocols were evaluated on geo-distributed AWS infrastructure:
- Baseline Performance: Mysticeti-C achieves p50 consensus latency of s at TPS (50 validators). Competing protocols (HotStuff, Narwhal-HotStuff, Bullshark) exhibit $1.2-2.5$ s latency under similar load.
- Crash Fault Resilience: Mysticeti-C maintains up to TPS with sub-second latency and  s for 3 crash faults, outperforming HotStuff and Narwhal-HotStuff/Bullshark.
- Real-World Mainnet: On Sui mainnet (135-137 validators), Mysticeti-C reduced p50 consensus latency from $2,890$ ms to $650$ ms and p95 from $4,600$ ms to $975$ ms for $5,000$ TPS—a reduction with equivalent throughput and safety properties. With Beluga, mainnet attack resistance improved further: 95th percentile latency improved , 75th percentile , median .
| Protocol | p50 Latency | p95 Latency |
|---|---|---|
| Bullshark | 2 890 ms | 4 600 ms |
| Mysticeti-C | 650 ms | 975 ms |
7. Architectural Role in Sui and Future Directions
Mysticeti forms the consensus core in the Sui (Aquarium) architecture, consuming a continually-growing DAG, applying threshold-quorum voting on blocks, and exposing a totally ordered stream to the execution layer. Beluga, as the block synchronizer abstraction, has been integrated as a robust, resource-aware foundation for reliable broadcast, delivering bounded latency and amplification even in adversarial conditions (Kichidis et al., 19 Nov 2025).
A plausible implication is that further research may examine applying Mysticeti’s implicit certification approach and the Beluga synchronizer in broader BFT or DAG-consensus environments, or as resilient modules in modular blockchain stacks. Performance under active network asynchrony remains a salient concern for production systems leveraging these protocols.