web3中的共识：PBFT、Tendermint 与 DAG 共识
区块链共识机制全景解析：PBFT、Tendermint 与 DAG 共识
关键词：BFT、PBFT、Tendermint、HotStuff、DAG 共识、区块链安全、一致性协议
区块链系统的本质，是在一个不可信、分布式、可能存在恶意节点的环境中，就“账本状态”达成一致。而支撑这一目标的核心技术，就是共识机制（Consensus Mechanism）。
本文将从拜占庭容错（BFT）理论出发，系统性介绍三类在区块链与分布式账本中极具代表性的共识机制：
- PBFT（Practical Byzantine Fault Tolerance）：经典 BFT 共识的起点
- Tendermint：工程化落地最成功的 BFT 区块链共识之一
- DAG 共识：突破“区块链线性结构”的新一代共识范式
同时，我们将结合 HotStuff / HotStuff-2 等研究工作，解释这些协议在**安全性（Safety）与活性（Liveness）**之间的权衡逻辑。
一、共识问题与拜占庭容错基础
1. 什么是共识？
在分布式系统中，共识问题可以抽象为：
多个节点在消息可能丢失、延迟、篡改，甚至部分节点作恶的情况下，仍然对同一个值达成一致。
在区块链语境下，这个“值”通常是：
- 下一笔交易 / 区块
- 某一高度（Height）的区块内容
- 某个状态机的输入序列
2. 拜占庭故障模型（Byzantine Fault Model）
拜占庭故障指的是节点可能出现任意行为，包括：
- 宕机
- 发送错误消息
- 恶意串谋
- 对不同节点发送不同信息
经典结论：
在完全拜占庭环境中，若系统要保证安全性与活性，必须满足：
n≥3f+1n \ge 3f + 1n≥3f+1
其中 (f) 是最多可容忍的恶意节点数。
这也是 PBFT、Tendermint、HotStuff 等协议共同遵循的基础假设。
二、PBFT：经典 BFT 共识的原点
1. PBFT 的基本思想
PBFT（Practical Byzantine Fault Tolerance）由 Castro 和 Liskov 于 1999 年提出，是第一个可工程落地的拜占庭容错共识算法。
其核心目标是：
- 在 异步或部分同步网络 中
- 容忍最多 (f<n/3)(f < n/3)(f<n/3) 个恶意节点
- 实现单次共识的最终性（Single-Slot Finality）
PBFT 并不依赖区块链结构，本质是一个状态机复制（State Machine Replication）协议。
2. 三阶段协议（Three-Phase Protocol）
PBFT 的一次共识包含三个阶段：
- Pre-Prepare（预准备）
- 主节点（Primary）提出提案
- Prepare（准备）
- 副本节点广播 Prepare 消息
- 收集到 (2f) 个 Prepare 后进入 Commit
- Commit（提交）
- 节点广播 Commit
- 收集到 (2f + 1) 个 Commit 后正式提交
该设计确保：
- 任意两个已提交值，至少有 (f+1) 个诚实节点交集
- 恶意节点无法制造冲突提交
3. View Change 与通信复杂度
PBFT 的核心瓶颈在于 View Change（主节点切换）：
- 新 Leader 需要收集 (2f+1) 个节点的“锁状态（Lock/QC）”
- 并将这些状态广播给所有节点
这导致：
- 视图切换通信复杂度为 (O(n^2))
- 整体最坏情况复杂度甚至达到 (O(n^3))
👉 这也是 PBFT 难以扩展到大规模区块链网络 的根本原因。
4. PBFT（三阶段 + View Change）
核心关键词：Pre-Prepare → Prepare → Commit，O(n²) 广播
Replica 3Replica 2Replica 1PrimaryClientReplica 3Replica 2Replica 1PrimaryClientRequestPre-Prepare (v, n, m)Pre-PreparePre-PreparePreparePreparePreparePreparePreparePrepareCommitCommitCommitCommitCommitCommitReplyReplyReply
📌 解释重点
- Prepare 阶段本质是锁定 proposal
- Commit 阶段是达成不可逆共识
- View Change 极其昂贵（没画出来，但你文中可以点）
三、Tendermint：工程化 BFT 区块链共识
1. Tendermint 的定位
Tendermint 并不是单一算法，而是一套完整的：
- BFT 共识引擎（Tendermint Core）
- 应用接口（ABCI）
它的目标非常明确：
将“共识”与“应用状态”彻底解耦，成为通用的 BFT 区块链内核。
Cosmos 生态正是建立在 Tendermint 之上。
2. 两阶段投票：Pre-vote / Pre-commit
在每个区块高度（Height）下，Tendermint 通过多个 Round 进行尝试：
- Pre-vote：节点对提案投票
- Pre-commit：在形成 (>2/3) Pre-vote 后进入提交投票
当某个区块在同一 Round 中获得：
- 超过 (2/3) 投票权的 Pre-commit
则该区块被最终确定（Finality）。
3. 锁定规则（Locking Rules）
Tendermint 的安全性依赖一套严格的锁定规则：
- 一旦节点 Pre-commit 某区块，即被锁定
- 只能在**更高 Round 出现合法 Polka（(>2/3) Pre-vote）**时解锁
这正是经典的：
Lock–Commit（或 Commit–Adopt）范式
4. 活性与 Δ 等待
与 PBFT 不同，Tendermint 在 View Change（Round 切换）中：
- 不携带完整的锁状态证书
- 而是通过 等待一个 (O(Δ)) 的超时，确保新提议者看到所有诚实节点的状态
结果是：
- ✅ View Change 通信复杂度降为 (O(n))
- ❌ 协议 不具备响应性（Non-Responsive）
这也是 Tendermint 在论文与工程上一个非常清晰的取舍。
5. Tendermint（两阶段 + Lock + 超时）
核心关键词：Propose → Prevote → Precommit，锁规则 + 超时驱动
2/3 prevote
timeout
2/3 precommit
timeout
Propose
Prevote
Precommit
Commit
📌 解释重点
- Prevote ≈ PBFT Prepare（但更弱）
- Lock 发生在 Precommit
- 超时（Δ）是 Tendermint 能前进的前提
- Safety > Liveness（工程上非常重要）
四、从 HotStuff 到 HotStuff-2：两阶段是否足够？
1. 活性问题的本质
在 PBFT / Tendermint / HotStuff 这类协议中，系统在 Leader 失败时可能处于三种状态：
- 无人锁定、无人提交
- 少数节点锁定，但无人提交
- 超过 (2f+1) 节点锁定，部分节点已提交
由于节点无法区分自己处于哪种状态，协议必须“偏向安全性”：
默认假设最坏情况（状态 3）
这正是 View Change 复杂性的根源。
2. HotStuff：三阶段换线性视图切换
HotStuff 通过引入 额外的 Key 阶段，建立新的不变量：
- 如果某个锁存在
- 则至少 (2f+1) 节点“知道”它的存在
这样，新 Leader 无需等待 Δ，即可安全推进。
代价是：
- 协议从 2 阶段 → 3 阶段
3. HotStuff-2 的关键洞察
HotStuff-2 重新审视了问题，提出一个极其“简单但深刻”的观察：
如果 Leader 能拿到前一 View 的锁证书，就无需等待；否则等待 Δ 也不损失响应性。
即：
- 有证书 → 响应式推进
- 无证书 → 明确等待 Δ
最终结论是：
- 两阶段足够实现 BFT
- 同时满足：
- 线性 View Change
- 响应性
- 最坏 (O(n^2)) 通信复杂度
4. HotStuff（三阶段 → 管道化 → Leader 线性）
核心关键词：Prepare → Pre-Commit → Commit，QC + 单向通信
Validator 3Validator 2Validator 1LeaderValidator 3Validator 2Validator 1LeaderQC 驱动下一轮\n形成流水线Propose(B1)Propose(B1)Propose(B1)Vote(B1)Vote(B1)Vote(B1)QC(B1)QC(B1)QC(B1)
📌 解释重点
- 把 PBFT 的三阶段压缩到多个区块之间
- 不再是全网广播，而是：
- Validator → Leader
- Leader → Validator
- View Change 变成 Leader rotation
👉 这是 Tendermint → HotStuff 质变的地方
五、DAG 共识：打破“区块线性化”的新范式
1. 为什么需要 DAG？
传统区块链的核心限制在于：
- 全网一次只能产生一个区块
- 吞吐量、确认延迟受限于链结构
DAG（Directed Acyclic Graph）通过允许：
- 多个交易 / 事件并行产生
- 通过偏序关系而非线性链排序
显著提升了吞吐能力。
2. DAG 共识的典型特征
- 数据结构：有向无环图，而非区块链
- 共识方式：
- Gossip 协议
- 虚拟投票（Virtual Voting）
- 拓扑排序
代表项目包括：
- Hedera Hashgraph
- IOTA Tangle
- Nano
3. DAG vs Blockchain
| 维度 | Blockchain | DAG |
|---|---|---|
| 数据结构 | 线性区块链 | 有向无环图 |
| 并发性 | 低 | 高 |
| 吞吐 | 受限 | 高 |
| 最终性 | 明确 | 依赖算法 |
| 去中心化 | 更容易 | 常依赖委员会 |
DAG 并非“取代区块链”，而是：
在高吞吐、低费用、企业级场景中的一种重要补充。
4. DAG 共识（并行区块 + 因果顺序）
核心关键词：Partial Order，不是“没有共识”
Block A
Block B
Block C
Block D
Block E
Block F
📌 解释重点
- 没有单一链头
- 共识的是：
- 哪些区块被接受
- 因果关系
- 全序（Total Order）通常：
- 事后计算
- 或弱化（虚拟投票 / 费用排序）
六、总结：共识机制的演化脉络
从 PBFT 到 Tendermint，再到 HotStuff / DAG，我们可以清晰看到一条演进主线：
降低通信复杂度
线性 Leader + QC
并行化数据结构
PBFT
Tendermint
HotStuff
DAG
- 理论可行 → 工程可用 → 高性能可扩展
- 持续优化：
- 通信复杂度
- Leader 切换成本
- 响应性
- 并行度
共识机制从来不是“银弹”，而是：
在安全性、活性、性能、去中心化之间不断权衡的工程艺术。
