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 的一次共识包含三个阶段：

1. Pre-Prepare（预准备）
   • 主节点（Primary）提出提案
2. Prepare（准备）
   • 副本节点广播 Prepare 消息
   • 收集到 (2f) 个 Prepare 后进入 Commit
3. 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 失败时可能处于三种状态：

1. 无人锁定、无人提交
2. 少数节点锁定，但无人提交
3. 超过 (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

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 切换成本
  • 响应性
  • 并行度

共识机制从来不是“银弹”，而是：

在安全性、活性、性能、去中心化之间不断权衡的工程艺术。