---
title: 'Mysticeti: Optimal DAG-Based Byzantine Consensus'
url: https://www.emergentmind.com/topics/mysticeti
type: topic
---

# Mysticeti: Optimal DAG-Based Byzantine Consensus

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 [2310.14821][2511.15517].

## 1. System Model and Problem Setting

Mysticeti operates in the DLS model for partially-synchronous Byzantine fault tolerance (BFT), assuming $n = 3f + 1$ validators, with up to $f$ 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 [2310.14821][2511.15517].

## 2. Mysticeti-C: Uncertified DAG Consensus

### 2.1 DAG Construction and Structure

Time is divided into logical rounds $r=0,1,2,\dots$; each honest validator proposes exactly one signed block per round. Each block $B = (\text{author}, r, \text{parents}, \text{txs})$ references at least $2f+1$ parent hashes from round $r-1$. There are no explicit certificates; support patterns in the DAG act as implicit quorum confirmations.

### 2.2 Implicit Support and Commitment

Let $\text{IsVote}(b_\text{vote}, B)$ hold if $b_\text{vote}$'s DFS in its parents "first sees" $B$ at $(B.\text{author}, B.\text{round})$. A block $C$ at round $r+2$ implicitly certifies proposer block $B$ at round $r$ if
$$
|\{ p \in C.\text{parents} : \text{IsVote}(p, B) \}| \ge 2f+1
$$
This forms the "implicitly certified DAG."

### 2.3 Commit Rule and Latency

Proposer-slots (validator, round) receive status $s \in \{\text{to-commit}, \text{to-skip}, \text{undecided}\}$ over three-round "waves":
- **Direct-commit**: round $r+2$ sees $2f+1$ implicit certificates.
- **Direct-skip**: round $r+1$ 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 $3\Delta$, saturating the known BFT lower bound [2310.14821].

### 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 $O(1)$ 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 $T$ are endorsed as validators include $T$ in their next blocks (implicit vote). Explicit votes (block, index) are subsequently included as other validators process $T$'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 $T$ or a single implicitly-certifying block for $T$ appears in the DAG of a Mysticeti-C commit. Signature operations are amortized across blocks rather than incurred per transaction, yielding $O(1)$ 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 $r_b$ and up to $B_{txs}$ transactions per block:
$$
\text{Fast-path throughput} \approx r_b \cdot B_{txs}
$$
Mysticeti-FPC achieves significantly higher per-host throughput versus protocols with per-transaction signatures [2310.14821].

## 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 $3\Delta$ 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 [2310.14821].

## 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 [2511.15517].

### 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 ($TR_i[j]$), enabling exclusion of low-reputation authors from parent selection. Latency for optimistic block relay is $\delta$.
- **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 $3\delta$ consensus latency, sustaining up to $300\,000$ tx/s at $0.5-0.8$ s latency at scale.
- **Adversarial-case**: Under targeted pull-induction attacks, Beluga bounds consensus latency at $2\delta$, with throughput remaining above $200\,000$ 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 $0.5\,$s at $50-100\,000$ 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 $80\,000$ TPS with sub-second latency and $p50<1$ 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 $>4\times$ reduction with equivalent throughput and safety properties. With Beluga, mainnet attack resistance improved further: 95th percentile latency improved $5\times$, 75th percentile $2\times$, median $25\%$.

| 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 [2511.15517].

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.

Source: https://www.emergentmind.com/topics/mysticeti