Narwhal & Tusk — 把 BFT 共识拆成『谁说过』和『谁先说』两件事

是什么

Narwhal & Tusk 是一对配套设计，告诉你怎么让一群互不信任的节点又快又稳地达成一致。

日常类比：想象 100 个法官要按时间顺序签发判决。

传统做法（HotStuff / PBFT）：每次都选一个『主审法官』把案子念出来，其他人签字同意。主审一卡，所有人空等。
Narwhal 做法：每个法官自己写当天的案子集合，挂到公告栏，互相引用对方的公告。
Tusk 做法：等公告栏涨到一定厚度，按一个全员都能算出的固定规则读出顺序，不需要再开会。

把『把数据发到全网』（mempool）和『排出顺序』（consensus）拆成两件事——这就是 DAG-BFT 范式的起点。

为什么重要

不理解 Narwhal/Tusk，下面这些事都没法解释：

为什么 Aptos 和 Sui 这两条号称『高吞吐』的链，共识协议不是抄 HotStuff 而是抄它
为什么传统 BFT（PBFT、HotStuff、Tendermint）的吞吐量死活上不去——leader 是单点瓶颈
为什么一个节点掉线，HotStuff 吞吐归零，Narwhal+Tusk 几乎不动
为什么 2022 年之后，所有新做高 TPS 共识的人都在画 DAG

论文实测：HotStuff 故障下 throughput 崩到 0；Narwhal+Tusk 在同等故障下维持 160k tx/s，延迟 < 3 秒。

核心要点

把共识拆成两层

传统 BFT 把『发数据』和『排序』揉在一起：每个 round 都让 leader 既广播交易又主导投票。瓶颈就是 leader 的带宽和延迟。

Narwhal/Tusk 把这两件事物理拆开：

层	名字	职责
下层	Narwhal（mempool）	保证『某交易已经发到全网，且能被读出』
上层	Tusk（consensus）	在 Narwhal 给出的 DAG 上排顺序

Narwhal：造一张『可证明已存在』的 DAG

每轮（round）每个验证人做三件事：

把自己手头的交易打包成一个 block
在 block 里引用上一轮收到的 2f+1 个 certificate（f 是最多容忍的恶意节点）
把 block 广播出去；收到 2f+1 个签名后，block 升级成 certificate of availability——意思是『至少 2f+1 个诚实节点已经存了这份数据』

每轮的 certificate 互相引用，整体形成一张 DAG（有向无环图）。一旦你看到某个 certificate，沿着它的引用回溯，就能拿到完整的因果历史。

Tusk：在 DAG 上做零通信排序

DAG 已经把『谁说过什么』全部记下来了。Tusk 的活就是：给同一张 DAG，让每个节点独立地读出同一个顺序——这一步不发任何额外消息，叫 zero message overhead。

规则（简化）：

每 3 轮叫一个 wave
每个 wave 通过共享随机数选一个 leader block
如果 wave 里有足够多 certificate 引用了这个 leader，就提交它和它的所有因果历史
否则跳过，继续下个 wave

leader 不需要『主持开会』，因为 DAG 已经替它说完了所有话。

实践案例

案例 1：为什么 leader 卡住对 Narwhal 影响很小

HotStuff 流程：leader 收交易 → leader 广播 → 等 2f+1 vote → 下一个 leader。leader 网络一抖，整条链停。

Narwhal 流程：每个验证人同时在写自己的 block，互相引用。某一个节点慢了，DAG 仍然在长，因为别人不必等它——只要还有 2f+1 个能跑，就能继续。

案例 2：worker / primary 拆分让带宽线性扩展

Narwhal 把每个验证人内部再拆成：

primary：负责签名、引用、参与协议（CPU 重）
workers：负责接收和广播交易（带宽重）

加一台 worker 机器，吞吐就涨一截。HotStuff 加机器没用，因为 leader 仍然是单点。论文里 Narwhal 单 worker 推到 ~170k tx/s，10 worker 推到 600k tx/s。

案例 3：Aptos / Sui 落地版本

Aptos 用的叫 bullshark-2022——把 Tusk 从『需要全局同步钟』降成『部分同步』，工业可用
Sui 用 Mysticeti——进一步把 commit 延迟从 3 个 round 压到 1-2 个 round
二者都建立在 Narwhal mempool 之上，把『数据可用性』和『顺序』分层这件事原封不动继承

踩过的坑

DAG ≠ 区块链：Narwhal 的 DAG 是 mempool 的内部数据结构，不是最终账本。最终账本是 Tusk 在 DAG 上读出的线性顺序。新人常把两者搞混。
certificate 不等于 commit：拿到 2f+1 签名只代表『这块数据全网都存了』，不代表它已经被提交进账本。提交是 Tusk 的活。Aptos 早期文档把这两个词混用过，导致开发者误以为 certificate 出现 = 交易已上链。
wave 周期 = 至少 3 轮延迟：Tusk 的 commit 至少要 3 个 round；理想 throughput 高，但单笔延迟比 HotStuff 长。Mysticeti 后来才把这个砍下来。
随机数源是攻击面：选 leader 用的共享随机数如果被预测，恶意节点可以提前组织『不引用 leader』的攻击。论文用 threshold signature 解决，工程上不简单。
DAG 存储成本：每个 certificate 都要持久化原始 block + 引用关系，长跑下来 DAG 历史巨大。生产里要做定期 garbage collection——Tusk 提交后的 block 可以删，但删的时机要算准。

适用 vs 不适用场景

适用：

高 TPS 公链 / 联盟链（Aptos、Sui、Celo 部分组件）
网络稳定但偶有拜占庭节点的环境
需要 throughput >> latency 的场景（比如数据上链不要求秒到）

不适用：

节点数极少（n < 4）→ 用 Raft / Paxos 就够
要求亚秒级 finality → HotStuff / Mysticeti 更合适
完全异步网络 → 需要 DAG-Rider / Aleph 这类异步变种

历史小故事（可跳过）

2018：HotStuff 把 PBFT 的复杂度从 O(n²) 降到 O(n)，被 Diem（前 Libra）选为共识。
2020：Diem / Meta 团队发现 HotStuff 在工程上仍然撞 leader 瓶颈，开始做 mempool / consensus 解耦的研究原型。
2021-05：Narwhal & Tusk 论文挂上 arXiv，作者主要来自 Mysten Labs（后来做 Sui）和 Novi（前 Diem 团队）。
2022-04：论文正式发表在 EuroSys 2022。同年 Aptos 主网上线，共识用 Bullshark（Tusk 的部分同步版）。
2023：Sui 上线 Mysticeti，把这条路线又往前推一步。

学到什么

关注点分离在分布式系统里也成立——把 mempool 和 consensus 拆开，吞吐量天花板立刻消失
leaderless 不等于无序——DAG 替你记录因果，leader 只用来挑哪个 wave 提交，不用主持广播
零消息开销共识听起来魔法，实际上是『把通信成本前置到 mempool 那一层』——总成本不变，但吞吐瓶颈被搬走了
可证明可用性（proof of availability）是 DAG-BFT 的核心安全保证，等价于 PBFT 的 prepare 阶段，但能被复用

关联

hotstuff-2019 —— 上一代 leader-based BFT，被 Narwhal 用 throughput 数据正面对比
pbft-1999 —— BFT 共识鼻祖，Narwhal 的 certificate 概念直接来自它的 prepare 阶段
tendermint-2016 —— 同样是 leader-based BFT，被 Cosmos 采用，遭遇相同的吞吐瓶颈
bullshark-2022 —— Aptos 现役共识，Tusk 的部分同步版本
move-language —— Aptos / Sui 智能合约语言，跑在 Narwhal/Tusk 之上

反向链接

hotstuff-2019 —— HotStuff — 让换领导也只花线性消息的 BFT 共识
move-language —— Move — 资源型智能合约语言
pbft-1999 —— PBFT — 让拜占庭容错从理论变成能跑的工程
tendermint-2016 —— Tendermint — 把拜占庭共识塞进开放区块链的工程模板