Mysticeti-FPC: Implicit DAG Consensus

• Mysticeti-FPC is a DAG-based Byzantine consensus protocol that achieves consensus in exactly three message rounds by embedding an implicit certification mechanism within the DAG structure.
• It employs a three-stage pipeline (propose, vote, commit) to optimize cryptographic overheads and maintain high throughput with graceful handling of crash failures and network delays.
• Evaluations on geo-distributed testbeds and production blockchains like Sui demonstrate sub-second commit latency and significant performance improvements over traditional certified-DAG protocols.

Mysticeti-C is a DAG-based Byzantine consensus protocol that achieves the provable lower bound of three message rounds for consensus latency, while simultaneously attaining high throughput, resource efficiency, and censorship resistance. Unlike traditional certified-DAG protocols, Mysticeti-C eschews explicit cryptographic certificates in favor of an implicit certification mechanism embedded within the structure of the directed acyclic graph (DAG), thus enabling every block to be committed without explicit delays. This approach optimizes both latency and cryptographic overheads, offering robust performance even under crash failures and in wide area network (WAN) deployments (Babel et al., 2023).

1. Motivation and Background

Mysticeti-C is a response to the limitations of existing certified-DAG consensus protocols such as Narwhal and Bullshark, which, despite delivering high throughput by permitting each validator to propose a block per "wave," incur significant latency costs. Specifically, in these protocols, each block undergoes a certification phase (by reliable-broadcast signatures, typically three message delays) followed by a recursive commit rule (another ≈3 delays), resulting in WAN latencies of 2–3 seconds.

Contrastingly, classical PBFT-style state-machine replication can achieve consensus in three message delays but restricts to one proposal per round and demonstrates reduced robustness in asynchronous or faulty network regimes. Mysticeti-C's foundational insight is that a DAG composed solely of signed (not explicitly certified) blocks is sufficient to prevent equivocation, ensure data availability, and amortize the cryptographic cost to one signature per block. The protocol employs a three-stage pipeline—propose, vote, commit—without requiring pre-certified blocks, and commits every block in exactly three rounds, even amid crash failures, while preserving O(n) proposals per round and strong censorship resistance.

2. The Uncertified-DAG Commit Rule

Mysticeti-C logically segments time into waves, each comprising three rounds (waveLength = 3). In every round $r$ of wave $w$, up to $S$ proposer-slots are deterministically assigned to validators. An honest proposer at slot $(w, r, \ell)$ incorporates (1) references to its prior block(s) and (2) at least $2f+1$ references to distinct round $r-1$ blocks. Each block is signed and multicast.

Two core DAG patterns per proposer-slot $s = (v, r)$ define implicit certification:

• Certificate pattern: At least $2f+1$ blocks in round $r+1$ “support” a single proposal $B$ at slot $w$0; $w$1 is then implicitly certified.
• Skip pattern: At least $w$2 blocks in round $w$3 omit any proposal for slot $w$4, indicating $w$5 is “skipped.”

The protocol dispenses with explicit $w$6-signature certificates, relying instead on detection of these patterns. The commit rule proceeds sequentially per slot:

A. Direct Decision

• Certificate $w$7 mark "to-commit"
• Skip pattern $w$8 mark "to-skip"
• Otherwise $w$9 remain "undecided"

B. Indirect Decision

• Identify the anchor slot $S$0 (first slot at round $S$1 with a decision)
• If anchor undecided, $S$2 remains undecided
• If anchor is "to-commit" and there exists a DAG path from $S$3’s certificate to anchor, mark $S$4 "to-commit"; otherwise "to-skip"

C. Commit Sequence

• Proceed linearly; commit all marked "to-commit" and skip "to-skip" until encountering the first undecided slot

This commit logic ensures that every honest slot eventually becomes decided, at most one proposal per slot can ever be certified, and all correct validators arrive at the same commit prefix.

3. Latency Analysis and Lower-Bound Attainment

Mysticeti-C meets the Martin & Alvisi (IEEE TDSC ’06) lower bound of three message rounds for Byzantine consensus under partial synchrony. Let $S$5 denote one-way network delay post-GST:

• Latency bound: $S$6
• Message rounds: Three required for steady-state consensus

Protocol operation sequence:

1. Round 1: Proposer block arrives.
2. Round 2: Validators reference it in their $S$7 blocks (implicit votes).
3. Round 3: Validators include at least $S$8 such votes in round $S$9 blocks, forming implicit commit certificates.

Message complexity per block is $(w, r, \ell)$0 in bytes, and $(w, r, \ell)$1 in total point-to-point messages, but the signature overhead per block is $(w, r, \ell)$2 (one signing, one verification), contrasting with the $(w, r, \ell)$3 cryptographic cost in certified-DAG systems. Under crash faults, the skip pattern accelerates "to-skip" or "to-commit" marks, maintaining the three-round steady-state commit path for honest slots.

4. Safety and Liveness Properties

Mysticeti-C maintains Byzantine atomic-broadcast safety and liveness:

• Safety lemmas:
  • Unique-support & Unique-cert: Quorum intersection guarantees at most one certified proposal per slot, as a correct validator never supports two proposals in the same slot.
  • Recursion-safety: Certificate blocks referenced by $(w, r, \ell)$4 subsequent blocks cannot be orphaned.
  • Direct-skip-safety & Direct-commit-safety: A slot's skip/commit decision is unique across validators.
  • Proposer-consistent: The commit prefix of proposer-slots is a prefix of any other’s (total-order property).
• Liveness lemmas:
  • View-sync: Post-GST, honest parties enter rounds in synchrony within $(w, r, \ell)$5.
  • Proposer-proposal & Sufficient-votes: Honest proposals receive $(w, r, \ell)$6 votes within $(w, r, \ell)$7 under $(w, r, \ell)$8 timeouts.
  • Decision-liveness: Within any interval of $(w, r, \ell)$9 rounds, the presence of three consecutive rounds with honest proposers ensures cascading commits, deciding all preceding slots.

All honest proposals therefore achieve commit in three rounds following GST.

5. Performance Evaluation

Empirical evaluation of Mysticeti-C spans 10- and 50-node geo-distributed AWS testbeds (across 13 regions, with two proposer slots per round and 1s timeout for the first slot), processing 512-byte transactions at controlled rates. Key performance metrics are as follows:

Protocol	Validators	WAN p50 Latency	Throughput	Comparison Baseline
Mysticeti-C	10	0.3 s	100k TPS, >400k TPS*	HotStuff/Bullshark: 1–1.6 s
Mysticeti-C	50	0.5 s	100k TPS, ~120k TPS*
Mysticeti-FPC (fast-path)	10, 50	0.25 s (low load)	>175k TPS (<0.5 s)	Zef: 7–20k TPS (<0.5 s)

*At higher latency budgets (e.g., 1.5 s).

In crash-failure scenarios (e.g. $2f+1$0 in a 10-node committee), Mysticeti-C yields sub-second latency up to 50k TPS, and approximately 1 s up to 80k TPS, starkly outperforming Narwhal-related protocols and Bullshark, which exhibit 8–10 s latency under similar conditions.

6. Integration and Impact in Production Blockchains

Mysticeti-C was integrated into the Sui blockchain, supplanting Bullshark in Sui's production codebase (137 validators across 9 regions on Vultr infrastructure). Under sustained 5k TPS load:

Protocol	p50 Commit Latency	p95 Commit Latency
Bullshark	2.89 s	4.60 s
Mysticeti-C	0.65 s	0.975 s

This demonstrates more than a four-fold reduction in median commit latency and enables sub-second finality in mainnet deployment.

7. Significance and Outlook

Mysticeti-C establishes that DAGs without explicit certificates—via implicit certification and a structured commit rule—can simultaneously attain optimal Byzantine consensus latency (three message rounds), efficient n-proposer throughput, $2f+1$1 signature complexity per block, graceful handling of crash faults, and real-world, sub-second WAN finality at 100k+ TPS. Its successful application in Sui points to practical viability for next-generation, high-performance distributed ledgers (Babel et al., 2023).