Web3 共识机制解析：PBFT、Tendermint 与 DAG

3. View Change 与通信复杂度

PBFT 的核心瓶颈在于 View Change（主节点切换）：

• 新 Leader 需要收集 2f+1 个节点的'锁状态（Lock/QC）'
• 并将这些状态广播给所有节点

这导致：

• 视图切换通信复杂度为 O(n²)
• 整体最坏情况复杂度甚至达到 O(n³)

👉 这也是 PBFT 难以扩展到大规模区块链网络的根本原因。

4. PBFT（三阶段 + View Change）

核心关键词：Pre-Prepare → Prepare → Commit，O(n²) 广播

Replica 3 | Replica 2 | Replica 1 | Primary | Client
Request -> Pre-Prepare (v, n, m) -> Prepare -> Prepare -> Prepare
Prepare -> Prepare -> Prepare -> Commit -> Commit -> Commit
Commit -> Commit -> Commit -> Reply -> Reply -> 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，锁规则 + 超时驱动

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²) 通信复杂度

4. HotStuff（三阶段 → 管道化 → Leader 线性）

核心关键词：Prepare → Pre-Commit → Commit，QC + 单向通信

Validator 3 | Validator 2 | Validator 1 | Leader
QC 驱动下一轮 -> 形成流水线
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 C -> Block E
Block B -> Block D -> Block F

📌 解释重点

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

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

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

降低通信复杂度 -> 线性 Leader + QC -> 并行化数据结构

PBFT -> Tendermint -> HotStuff -> DAG

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

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

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