区块链共识机制深度解析：PBFT、Tendermint 与 DAG
聊起区块链，共识机制是绕不开的核心。它解决的是在不可信、分布式且可能存在恶意节点的环境中，如何让所有节点对'账本状态'达成一致的问题。
我们从拜占庭容错（BFT）理论出发，梳理三类极具代表性的共识机制：经典的 PBFT、工程化落地的 Tendermint，以及突破线性结构的新兴 DAG 共识。结合 HotStuff 系列研究，看看它们在安全性与活性之间是如何取舍的。
一、共识问题与拜占庭容错基础
1. 什么是共识？
分布式系统中的共识，抽象来说就是：多个节点在消息可能丢失、延迟、篡改，甚至部分节点作恶的情况下，仍然对同一个值达成一致。 在区块链里，这个'值'通常是下一笔交易、某个高度的区块内容，或者状态机的输入序列。
2. 拜占庭故障模型
拜占庭故障指节点可能出现任意行为，比如宕机、发送错误消息、恶意串谋，或者对不同节点发送不同信息。
学界有个经典结论：在完全拜占庭环境中，要保证安全性与活性，必须满足 n ≥ 3f + 1。其中 f 是最多可容忍的恶意节点数。这也是 PBFT、Tendermint 等协议共同遵循的基础假设。
二、PBFT：经典 BFT 共识的原点
1. 基本思想
PBFT（Practical Byzantine Fault Tolerance）由 Castro 和 Liskov 于 1999 年提出，是第一个可工程落地的拜占庭容错共识算法。它的核心目标是在异步或部分同步网络中，容忍最多 f < n/3 个恶意节点，实现单次共识的最终性。
PBFT 并不依赖区块链结构，本质上是一个状态机复制协议。
2. 三阶段协议
PBFT 的一次共识包含三个阶段：
- Pre-Prepare（预准备）：主节点提出提案。
- Prepare（准备）：副本节点广播 Prepare 消息，收集到
2f个 Prepare 后进入 Commit。 - Commit（提交）：节点广播 Commit，收集到
2f + 1个 Commit 后正式提交。
该设计确保任意两个已提交值，至少有 f + 1 个诚实节点交集，恶意节点无法制造冲突提交。
3. View Change 与通信复杂度
PBFT 的核心瓶颈在于 View Change（主节点切换）。新 Leader 需要收集 2f + 1 个节点的锁状态，并将这些状态广播给所有节点。这导致视图切换通信复杂度为 O(n²)，整体最坏情况复杂度甚至达到 O(n³)。这也是 PBFT 难以扩展到大规模区块链网络的根本原因。
4. 流程示意
Client -> Primary (Request)
Primary -> Replicas (Pre-Prepare)
Replicas -> Replicas (Prepare)
Replicas -> Replicas (Commit)
Replicas -> Client (Reply)
要点在于：Prepare 阶段本质是锁定 proposal，Commit 阶段是达成不可逆共识。View Change 极其昂贵，这是实际工程中需要优化的地方。
三、Tendermint：工程化 BFT 区块链共识
1. 定位
Tendermint 并不是单一算法，而是一套完整的 BFT 共识引擎和应用接口（ABCI）。它的目标是将'共识'与'应用状态'彻底解耦，成为通用的 BFT 区块链内核。Cosmos 生态正是建立在 Tendermint 之上。
2. 两阶段投票
在每个区块高度下，Tendermint 通过多个 Round 进行尝试：
- Pre-vote：节点对提案投票。
- Pre-commit：在形成超过
2/3Pre-vote 后进入提交投票。 当某个区块在同一 Round 中获得超过2/3投票权的 Pre-commit，则该区块被最终确定。
