Tusk Asynchronous Consensus Protocol

• Tusk is an asynchronous Byzantine Fault Tolerant protocol that decouples reliable transaction dissemination from block ordering using a two-layer, leaderless architecture with Narwhal.
• It achieves high throughput (over 160,000 tps) and robust performance under adversarial network delays by leveraging threshold-shared randomness and pipelined commit waves.
• Scalability challenges arise from O(n³) authenticator overhead, motivating future work on signature aggregation to reduce CPU and network costs.

The Tusk Asynchronous Consensus Protocol is a Byzantine Fault Tolerant (BFT) protocol designed to provide scalable, wait-free consensus in fully asynchronous distributed environments. It is architected atop a DAG-based mempool (Narwhal) and achieves high throughput and robustness by decoupling reliable transaction dissemination from block ordering. Tusk is notable for eliminating extra consensus communication beyond data dissemination, delivering performance previously unavailable for asynchronous BFT in both theory and practice (Danezis et al., 2021).

1. Architectural Structure and Design Tenets

Tusk utilizes a two-layered architecture, with Narwhal providing a high-throughput, DAG-based mempool and Tusk implementing consensus over references ("digests") to these transaction blocks. The system is leaderless and operates under the permissioned BFT model, with up to $f < n/3$ Byzantine validators among a known set of $n$ nodes.

• Narwhal DAG Layer: Responsible solely for reliable, high-performance dissemination and causal storage of transaction batches; ensures block availability and redundancy.
• Tusk Consensus Layer: Orders the digests of available blocks, using information solely available through the Narwhal DAG structure.
• Commit Protocol: Divides operation into proposal and commit "waves," pipelined and overlapped for high throughput.
• Zero Message Overhead: Tusk introduces no additional consensus messages; all ordering decisions are derived from local DAG interpretation.
• Full Asynchrony: Guaranteed liveness and safety in the presence of unbounded, adversarial network delays (independent of partial synchrony assumptions).

Compared to protocols such as HotStuff, Tusk avoids the pitfalls of leader-based bottlenecks and stalls due to network partitions, and unlike previous asynchronous DAG-based protocols (e.g., DAG-Rider, Honeybadger), achieves higher practical throughput through these architectural choices (Danezis et al., 2021, Cheng et al., 17 Mar 2024).

2. Consensus Algorithm and Commit Rule

Tusk achieves consensus by interpreting the DAG history in "waves," each comprised of three rounds:

1. Round 1 (Proposal): Each validator creates a block referencing $\geq 2f+1$ certificates from previous round's blocks.
2. Round 2 (Voting): Validators reference Round 1 blocks, forming implicit "votes."
3. Round 3 (Coin): Validators contribute to the threshold-shared coin for leader election of a Round 1 block per wave.

Commit Rule:

The commit logic is formalized as:

Upon wave_ready(w): v ← get_wave_vertex_leader(w) if v == ⊥ OR |{v' in DAG_i[round(w,2)] : strong_path(v', v)}| < f+1: return leadersStack.push(v) for wave w' from w - 1 down to decidedWave + 1: v' ← get_wave_vertex_leader(w') if v' ≠ ⊥ and strong_path(v, v'): leadersStack.push(v') v ← v' decidedWave ← w order_vertices(leadersStack)

• The leader in each wave is chosen via a threshold random coin, breaking symmetry and guaranteeing liveness in the face of asynchrony (FLP impossibility).
• A leader is committed if there are at least $f+1$ causal references to it from the next round's validators.
• All preceding leaders are recursively committed and deterministically ordered based on the DAG’s causal structure.
• No extraneous protocol messages—interpretation is strictly local, based on the mempool DAG.

This approach guarantees deterministic, unique ordering and recursive commitment, leveraging shared randomness to ensure progress even with arbitrary message delays.

3. Integration with Narwhal and Garbage Collection

Narwhal, the mempool protocol, specializes in durable, high-performance block dissemination by allowing scale-out at each validator with multiple workers. Each block is certified for availability independently of the consensus protocol, enabling Tusk to order digests and decouple transaction payloads from ordering.

• Garbage Collection: Tusk’s design eliminates the need for "weak links" (used in protocols like DAG-Rider to guarantee liveness/fairness), allowing blocks and their histories to be efficiently trimmed after commitment. Uncommitted transactions are re-inserted into the mempool for future processing.
• Scalability: Multiple Narwhal workers per validator can linearly increase throughput, as the ordering layer is not performance-bound by transaction availability (Danezis et al., 2021).

4. Fault Tolerance, Safety, and Liveness Properties

Under the full-information asynchronous model, Tusk maintains the following properties:

• Safety: If a block leader is committed by any honest node, all honest nodes will eventually commit that leader in the same global order. This derives from quorum intersection guarantees in the causally-linked DAG.
• Liveness: Tusk guarantees progress even in adversarial asynchrony. In expectation, a block leader is committed every ~7 rounds (worst case, adversarial schedule) and every ~4.5 rounds in the common case (random scheduling delays). Probabilistically, the shared coin ensures that a committable leader is chosen with at least 1/3 chance per wave.
• Byzantine Tolerance: Supports up to $f < n/3$ Byzantine nodes with standard quorum intersection.

5. Performance and Experimental Observations

Extensive evaluation in both local and geo-distributed settings demonstrates Tusk’s empirical performance:

Protocol	Throughput	Latency (RTT; no faults)	Latency (faults)	Asynchrony Liveness
HotStuff	1–5k tps	3s	$O(n)$	No
Narwhal-HotStuff	130–140k tps	~4s	$O(n)$	No (liveness lost)
Tusk	160k tps	~4.5s	~4.5–7s	Yes

• WAN (50 validators): Achieves up to 170,000 tx/sec at ~3s median latency.
• WAN (with 3 faults): Throughput holds at ~125k tx/sec; latency increases modestly to ~6s, whereas competitors' throughput collapses and latency rises by orders of magnitude.
• Scale-out: Additional Narwhal workers yield linear throughput growth, e.g., over 500,000 tx/sec with sustained low latency.

These results position Tusk as the first practical asynchronous BFT protocol to reach and sustain high throughput (over 160,000 tps), closing the performance gap relative to synchronous/optimistic protocols (Danezis et al., 2021, Cheng et al., 17 Mar 2024).

6. Scalability and Bottlenecks

Tusk scales efficiently with the number of validators up to moderate committee sizes. However, for very large $n$ (hundreds of nodes), it faces key bottlenecks:

• Authenticator Complexity: Each block must carry a vector of $O(n)$ quorum certificates (QCs) for referenced blocks, which themselves are concatenations of $O(n)$ digital signatures. This leads to $O(n^3)$ authenticator (signature) verification per output block.
• Network and CPU costs: At scale ($n=200$), signature verification can dominate CPU (exceeding 66% runtime) and signatory communication can account for 40% of network bandwidth per decision.
• Practical Limits: These bottlenecks impose a super-linear degradation in throughput and sharp latency increases for $n > 64$ (Cheng et al., 17 Mar 2024).

Subsequent protocols such as FIN-NG and JUMBO address these scaling limits by eliminating or aggregating QCs, reducing per-block overhead from cubic to quadratic or lower.

7. Comparative Analysis and Evolution

Tusk's key innovations—separation of dissemination/ordering, leaderless commit via DAG, and piggybacked consensus—distinguish it from both DAG-based (DAG-Rider, Hashgraph) and classical protocols (PBFT, HotStuff).

Feature	Tusk	FIN-NG	JUMBO
Message Complexity	$O(n^2)$	$O(n^3)$	$O(n^2)$
Authenticator/QC	$O(n^3)$	Signature-free	$O(n^2)$ (agg BLS/multisig)
Asynchronous Liveness	Yes	Yes	Yes
Scaling (large n)	Poor (>64)	CPU-bounded	Good (hundreds)

Tusk's approach is well-suited to moderate-sized permissioned blockchains prioritizing throughput and latency, with current limits in large-scale deployments addressed by later protocols leveraging signature aggregation and advanced dispersal (Cheng et al., 17 Mar 2024).

8. Practical Implications and Applications

The Tusk protocol enables high-throughput, low-latency blockchain applications where strong asynchronous liveness and Byzantine fault tolerance are non-negotiable. Its integration with a robust mempool (Narwhal) and ability to pipeline waves make it ideal for systems where transaction volume is high and global ordering must be preserved under all network conditions.

Tusk's commitment to zero extra consensus messages, deterministic ordering, and full asynchrony forms a reference point for new asynchronous BFT designs. Its limitations for very large validator sets have driven subsequent protocol evolution focused on reducing signature and network overhead without compromising the wait-free and robust consensus guarantees.