web3中的共识：PBFT、Tendermint 与 DAG 共识

#WEB3

区块链共识机制全景解析：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 \geq 3 f + 1]$

其中 (f) 是最多可容忍的恶意节点数。

这也是 PBFT、Tendermint、HotStuff 等协议共同遵循的基础假设。

二、PBFT：经典 BFT 共识的原点

1. PBFT 的基本思想

PBFT（Practical Byzantine Fault Tolerance）由 Castro 和 Liskov 于 1999 年提出，是第一个可工程落地的拜占庭容错共识算法。

其核心目标是：

在 异步或部分同步网络 中
容忍最多 $(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²) 广播

sequenceDiagram
    participant C as Client
    participant P as Primary
    participant R1 as Replica 1
    participant R2 as Replica 2
    participant R3 as Replica 3

    C->>P: Request
    P->>R1: Pre-Prepare (v, n, m)
    P->>R2: Pre-Prepare
    P->>R3: Pre-Prepare

    R1->>R2: Prepare
    R1->>R3: Prepare
    R2->>R1: Prepare
    R2->>R3: Prepare
    R3->>R1: Prepare
    R3->>R2: Prepare

    R1->>R2: Commit
    R1->>R3: Commit
    R2->>R1: Commit
    R2->>R3: Commit
    R3->>R1: Commit
    R3->>R2: Commit

    R1->>C: Reply
    R2->>C: Reply
    R3->>C: Reply

📌 解释重点

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，锁规则 + 超时驱动

stateDiagram-v2
    [*] --> Propose
    Propose --> Prevote

    Prevote --> Precommit : 2/3 prevote
    Prevote --> Propose : timeout

    Precommit --> Commit : 2/3 precommit
    Precommit --> Propose : timeout

    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 + 单向通信

sequenceDiagram
    participant L as Leader
    participant V1 as Validator 1
    participant V2 as Validator 2
    participant V3 as Validator 3

    L->>V1: Propose(B1)
    L->>V2: Propose(B1)
    L->>V3: Propose(B1)

    V1->>L: Vote(B1)
    V2->>L: Vote(B1)
    V3->>L: Vote(B1)

    L->>V1: QC(B1)
    L->>V2: QC(B1)
    L->>V3: QC(B1)

    Note over L,V3: QC 驱动下一轮\n形成流水线

📌 解释重点

把 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，不是“没有共识”

graph TD
    A[Block A] --> B[Block B]
    A --> C[Block C]
    B --> D[Block D]
    C --> D
    B --> E[Block E]
    C --> F[Block F]

📌 解释重点

没有单一链头
共识的是：
- 哪些区块被接受
- 因果关系
全序（Total Order）通常：
- 事后计算
- 或弱化（虚拟投票 / 费用排序）

六、总结：共识机制的演化脉络

从 PBFT 到 Tendermint，再到 HotStuff / DAG，我们可以清晰看到一条演进主线：

graph LR
    PBFT -->|降低通信复杂度| Tendermint
    Tendermint -->|线性 Leader + QC| HotStuff
    HotStuff -->|并行化数据结构| DAG

理论可行 → 工程可用 → 高性能可扩展
持续优化：
- 通信复杂度
- Leader 切换成本
- 响应性
- 并行度

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

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