拜占庭容错（BFT）共识算法的演进，从PBFT到HotStuff

admin 欧易中心 2026-06-09 5

目录导读

拜占庭容错（BFT）共识算法概述
PBFT（实用拜占庭容错）算法的核心原理与局限
BFT演进中的关键突破：从三阶段到两阶段优化
HotStuff共识算法：基于线性视图变更的现代BFT
PBFT与HotStuff的对比分析
BFT在区块链生态中的未来方向
常见问题解答（FAQ）

拜占庭容错（BFT）共识算法概述

拜占庭容错（Byzantine Fault Tolerance，简称BFT）是分布式计算领域解决“拜占庭将军问题”的核心算法体系，其名称源自莱斯利·兰波特1982年提出的经典思想实验：在存在叛徒或故障节点的情况下，如何确保分布式系统就某一决策达成一致。

拜占庭容错（BFT）共识算法的演进，从PBFT到HotStuff-第1张图片-欧易交易所

在区块链与加密货币领域,BFT共识算法是保障网络安全性、一致性与活性的基石，不同于比特币的工作量证明（PoW）依赖算力竞争，BFT类算法通过节点间的多轮消息传递实现确定性共识，具有低延迟、高吞吐量、最终确定性等优势，因而被主流数字资产交易平台广泛应用。

对于投资者而言,理解BFT共识机制有助于评估不同区块链项目的安全性与性能，在欧易交易所官网（网址：https://oe-okor.com.cn/）上，用户可以查阅各类数字资产的技术白皮书，其中许多项目采用BFT或其衍生变体作为共识核心，如果您想在欧易交易所下载最新版本的APP，也建议先了解其底层技术逻辑。

PBFT（实用拜占庭容错）算法的核心原理与局限

1 PBFT的提出背景

1999年,Miguel Castro和Barbara Liskov在MIT提出了实用拜占庭容错（Practical Byzantine Fault Tolerance，PBFT）算法，标志着BFT从理论模型走向工程实践，PBFT首次将拜占庭容错的通信复杂度从指数级降低到多项式级，使其能在真实网络中运行。

2 PBFT的三阶段共识流程

PBFT的核心流程包含三个阶段：

预准备（Pre-Prepare）：主节点（Leader）向所有备份节点发送带有视图编号、序列号和请求内容的预准备消息。
准备（Prepare）：收到预准备消息的节点广播准备消息，并收集来自其他节点的准备确认，当节点收到超过2f+1个（f为可容忍的拜占庭节点数量）准备消息后，进入提交阶段。
提交（Commit）：节点广播提交消息，并等待收集2f+1个提交确认后，最终执行请求并回复客户端。

3 PBFT的主要局限

尽管PBFT具有O(n²)的通信复杂度（n为节点数），使其相比早期BFT有了质的飞跃，但其在实际应用中仍面临显著限制：

视图变更成本高：当主节点发生故障或作恶时，视图变更需要O(n³)甚至更高的通信复杂度，导致系统在异常情况下性能骤降。
节点规模受限：PBFT在节点数超过100时性能急剧下降，不适用于大规模网络，以欧易交易所为代表的中心化交易平台虽不直接运行PBFT，但其底层技术研究团队常将PBFT作为评估新一代公链共识机制的基准。
无区块化结构：PBFT设计初衷是为复制状态机服务，不天然支持区块链的链式结构，需要额外改造才能融入去中心化账本。

BFT演进中的关键突破：从三阶段到两阶段优化

1 减少消息轮数的尝试

此后十余年间,学术界针对PBFT的改进主要围绕以下方向：

Zyzzyva（2010年）：引入投机执行机制，将共识从三阶段简化为两阶段（预准备+提交），在无故障时显著提升性能，但回滚复杂度上升。
SBFT（2018年）：采用收集器（Collector）角色聚合签名，将通信复杂度降至线性。
Tendermint（2014年）：将BFT与区块链结构融合，首创基于轮次（Round）的主节点切换机制，但视图变更仍需全局重同步。

2 线性视图变更的探索

PBFT的高开销视图变更是改进核心,2016年，一项名为“Streamlet”的简化BFT提出使用固定顺序的主节点轮换，但牺牲了活性保证，另一种基于阈值签名的思路开始成型：通过聚合签名将视图变更消息体压缩，使其与正常共识具有相同的通信复杂度。

HotStuff共识算法：基于线性视图变更的现代BFT

1 HotStuff的诞生

2018年,由VMware团队在论文《HotStuff: BFT Consensus with Linearity and Responsiveness》中正式提出HotStuff算法，该算法随后成为Facebook（现Meta）Libra区块链（后改为Diem）的初版共识基础，并演变为DiemBFT，许多主流公链如Aptos、Sui等均以HotStuff及其变体为核心。

2 HotStuff的核心创新

流水线共识（Pipelining）：HotStuff将PBFT的三阶段（prepare、pre-commit、commit）转化为三个连续的提议-投票循环，形成类似流水线的工作模式，每轮只需广播O(n)条消息，且视图变更与正常共识共享相同结构。
阈值签名（Threshold Signature）：使用BLS阈值签名将多个节点的投票聚合为单一签名，消息广播量从O(n²)降至O(n)。
响应式领导（Responsive Leader）：主节点可根据实际网络延迟动态设定区块时间，而非固定超时，最大化吞吐量。

3 HotStuff的共识流程

以HotStuff的经典实现“Chained HotStuff”为例，每轮操作如下：

提议：Leader生成新区块，附带上一个区块的证明（QC，Quorum Certificate，即2f+1个签名）。
投票：验证节点检查区块合法性后，发送签名给Leader。
聚合：Leader收集2f+1个签名，生成新的QC。
决定：当连续三轮QC形成“三链”结构时，第一个区块成为最终确认。

这种机制使确认延迟仅为3轮网络往返（3Δ），且视图变更只需1轮额外通信（即1Δ）。

4 HotStuff的优势

消息复杂度为O(n)：支持节点规模从数十扩展到数百甚至数千。
简洁的视图变更：不再需要复杂的新主选举协议，当Leader长时间未提案时，任何节点可发起超时证明，推动新一轮提案。
高吞吐量与低延迟：在无故障条件下，HotStuff的理论吞吐量可达PBFT的2-3倍，这与欧易交易所下载（https://oe-okor.com.cn/）平台的交易所需的高性能匹配——该平台对撮合引擎的延迟要求达到微秒级，而HotStuff的轻量级设计非常适合作为高频交易应用的底层共识。

PBFT与HotStuff的对比分析

对比维度	PBFT	HotStuff
消息复杂度	O(n²)（正常共识）、O(n³)（视图变更）	正常和视图变更为O(n)
确认延迟	3轮（无故障）、视图变更时更高	3轮（固定）
节点规模扩展性	差（lt;100）	良好（可达1000+）
区块化支持	需额外改造	原生支持链式结构
签名机制	独立签名广播	BLS阈值签名聚合
最终确定性	三阶段提交	三链QC决定