【BFT帝国】20250409更新PBFT总结

$$2411$$

Zhang G R, Pan F, Mao Y H, et al. Reaching Consensus in the Byzantine Empire: A Comprehensive Review of BFT Consensus Algorithms[J]. ACM COMPUTING SURVEYS, 2024,56(5).出版时间: MAY 2024
索引时间（可被引用）: 240412
被引: 9'ACM COMPUTING SURVEYS'
卷56期5 DOI10.1145/3636553
出版商名称: ASSOC COMPUTING MACHINERY期刊影响因子 ™
2023: 23.8
五年: 21.1JCR 学科类别
COMPUTER SCIENCE, THEORY & METHODS
其中 SCIE 版本
类别排序 类别分区 
1/144	Q1

Toward More Efficient BFT Consensus

一、PBFT Practical Byzantine fault tolerance-1999

Miguel Castro, Barbara Liskov, et al. 1999. Practical Byzantine fault tolerance. In OSDI, Vol. 99. 173–186.

角色介绍：

客户端 Client：向区块链网络 发起交易或状态更新请求，等待共识结果。

主节点 Leader/Primary：负责 接收请求「交易排序」，协调共识。（轮换时同步状态）

副本节点 Replica：负责 备份请求，促进共识达成。「验证合法，维护一致」

故障节点 Byzantine Fault：负责 选择性响应，篡改数据。【何不直接剔除，因设计目标为容忍而非实时剔除】

正常流程：客户端请求 → 主节点排序广播 → 副本节点三阶段验证 → 客户端确认。

1.请求 $Invoke$

客户端 Client 向Primary(ld)发送调用请求Req，并启动计时器 Timer。【OP: 时间戳】

Client 收到来自不同的 Replicas 的仅 F+1个回复 Reply，即可判定操作完成，停止计时 Timer。

否则直到计时器到期，认为调用失败。【原因1：内部错误只能等待。原因2：链接不可靠未达Primary，广播】

2.协商（共识）

1.Pre-prepare阶段

1> 分配唯一序列号 Sequence，范围[h, h+k]（h为最后一个稳定检查点的 Seq，k为限增值）

2> 将ViewNum、Seq、对请求Req的摘要hash组成PRE-PREPARE，然后签名Sig。（搭载原生Req）

3> 发给所有 Backups==Replicas。

总结，指定一个编号Seq，把请求打包发送给所有节点。

2.Prepare阶段

1> 验证Sig。

2> 检查ViewNum是否处于同一视图。

3> 检查Seq未分配给其他Req。

4> 验证hash。

广播PREPARE消息，收集满2F个消息后，造一个（都已准备）谓词Prepared Predicate。【共识基本达成】

总结，检验消息包后广播「没问题，我已准备提交」，满2F个后达成共识。

3.Commit阶段

1> 通过广播COMMIT消息，（广播谓词Prepared Predicate）。

2> 收集满2F个消息后，造另一个谓词committed-local predicate。【仲裁证书提供安全属性：正确副本执行方式相同】

总结，上阶段满2F个准备消息后，广播「我已提交」，再满2F个后达成共识。

4.Reply阶段

向Client发送REPLY消息 (resultOfOp=true)。

Weak Certificate 弱证书，仅需F+1个回复。

总结，上阶段满2F个提交消息后，向客户端回复调用完成。

检查点 $CheckPoint$

通过周期性状态同步，解决日志膨胀问题。【我理解为状态确认稳定后即可删除多余「过期」日志】

当Req被Commit时的 execute 会更新节点的状态，该状态需要确保所有正确副本一致性，通过检查点机制。

$Oncearequestiscommitted,theexecutionoftherequestreflectsthestateofareplica.$

算法定期对一系列 exe 生成证明，称为检查点。

同样的，在广播CHECKPOINT并收集2F个回复后，进化成稳定检查点。【水位范围同上述Seq】

总结，节点「已提交」后会更新状态，通过CheckPoint消息将其状态广播，满2F个后确认状态稳定。

3.视图切换 $ViewChange$

当Primary故障或共识超时，启动切换协议。【确保故障时系统活性】

视图切换期间，节点处于异步状态（i.e., 没有完全同步）。协议来自论文¹：但可能需要无限空间。

副本节点在收到 Req 后，启动一个 「节点Timer」等待 Req 被提交 Commit。

Commit 完成，则 Timer 终止；$RestartstheTimerifthereareoutstandingvalidrequeststhathavenotbeencommitted.$

若 Timer 到期，则认为 Primary 故障，广播VIEWCHANGE消息，引发视图切换。

该消息包含三个参数：$CPQ$.

选主公式：p = v mod |R| 。【R为节点总数】

各副本节点收到VIEWCHANGE后。

1> 验证：生成PQ的视图小于v。

2> 发送VIEWCHANGE-ACK消息给v+1的Primary（新主）「支持视图切换」。【包含节点ID、摘要及发送方ID】

3> Primary在收集 2F-1 条VIEWCHANGE和*-ACK后，确认更改，将VIEWCHANGE*加入集合$S$.【至少F+1条】

生成一个仲裁证书， view-change certificate。

总结：通过超时检测和多方认证，切换Ld「视图+1」。

Primary 将 ID 与$S$中的 msg 配对后，加入集合$V$.

选择检查点最高值h。

提取[h, h+k]之间未提交的 Req，加入集合 $X$.【请求已在v或仲裁证书中准备好】

Backups 检查 $V、X$中 msg 是否支持新主的【选择检查点和延续未提交请求】的决定。若不支持则切换视图至v+2.

终止 View-Change 协议。

视图切换期间异步处理请求。

总结，副本节点超时触发视图切换，新主节点基于最高检查点恢复未完成请求。

4.优缺点

开创异步网络中BFT的实用方案，启发高效BFT算法时代。

二次消息复杂性，阻碍其在大规模网络中的应用。

$faultyclientsuseaninconsistentauthenticatoronrequests.$ 会导致系统重复视图切换而卡死。

二、SBFT Scalable-2019

Guy Golan Gueta, Ittai Abraham, Shelly Grossman, Dahlia Malkhi, Benny Pinkas, Michael Reiter, Dragos-Adrian Seredinschi, Orr Tamir, and Alin Tomescu. 2019. SBFT: a scalable and decentralized trust infrastructure. In 2019 49th Annual IEEE/IFIP international conference on dependable systems and networks (DSN). IEEE, 568–580.

$Ascalableanddecentralizedtrustinfrastructure$.

共3f + 2c + 1个 Servers。【f为拜占庭故障，c为崩溃或流浪】

拥有Fast、Slow两种模式，前者需要无故障节点、同步环境；后者就是线性PBFT。

利用门限签名（阈值签名，$threshold$）解决了二次拜占庭广播问题。（其中阈值表示签名者数量）

1.快速通道 $Fastpath$​

1.Pre-Prepare 阶段

Primary 向所有 Servers 发送指令。

Servers 将回复发给 CommitCollector。

2.Full-commit-Proof 阶段

C-Collector 将收集到的 $signedreplies$ 转换成一个门限签名 msg，并发给所有 Servers。

3.Full-execute-Proof 阶段

Servers 将回复发给 ExecutionCollector。

E-Collector 将收集到的 $signedreplies$ 转换成一个门限签名 msg，并发给所有 Servers，包括 Client。【对比PBFT的F+1条确认】

2.线性PBFT $linear-PBFT$

将所有 Collector 聚合到 Primary。【权柄收回】

$ifSBFTusesonlytheprimaryasall“local”leadersineachphase$​.

那么工作流就类似PBFT。

但是拥有门限签名。

给定视图

Primary 根据视图号选择。

Collectors 根据视图号和 Seq（commit state index）选择。

SBFT 建议随机选择二者。

线性PBFT模式下，Primary总是选最后一个Collector。

当视图切换时，Servers 的角色更改。

3.视图切换 $ViewChange$​

View Change Trigger 阶段

两种情况会导致视图切换：

• Timeout.
• 收到 F+1 个节点的质疑（主有问题）。

View Change 阶段

$ls$：最后稳定 Seq（$laststablesequence$​）。【因部分同步可能不一致】

$win$：用于限制未完成块数量，预定义值。【因此 Seq 在$ls\sim ls+win$】

Seq 可以指明 Server 的状态。

触发 ViewChange 的 Server 会发送VIEWCHANGE消息给新主。【包含$ls$和到$ls+win$之间的状态摘要】

New View 阶段

收集满 2F+2C+1 后，启动新视图，并将其广播。

Accept a New-view 阶段

节点们接受$ls\sim ls+win$间的Seq，或一个安全的、可用于未来交易的Seq。

4.优缺点

两种模式下均可实现线性消息传输，并且 Reply 阶段的通信为O(1)。

继承PBFT缺点，Client 完全可以只与F+1部分节点通信，触发不必要的视图切换。

关于实验

实验设置

• 部署规模：在真实世界规模的广域网（WAN）上部署了200个副本。每个区域使用至少一台机器，每台机器配置32个VCPUs，Intel Broadwell E5-2686v4处理器，时钟速度2.3 GHz，通过10 Gigabit网络连接。
• 故障容忍：所有实验都配置为能够承受f=64个拜占庭故障。
• 客户端请求：使用公钥签名客户端请求和服务器消息。

实验方法

• 微基准测试：简单的Key-Value存储服务，每个客户端顺序发送1000个请求。
• 智能合约基准测试：使用以太坊的50万笔真实交易数据，副本通过运行EVM字节码执行每个合约，并将状态持久化到磁盘。

- 无批处理模式：每个请求是一个单次put操作，写入随机值到随机键。
- 批处理模式：每个请求包含64个操作，模拟智能合约工作负载。
'客户端请求'：客户端通过将交易分批成12KB的块（平均每批约50笔交易）发送操作。

三、HotStuff-2019⭐️

Maofan Yin, Dahlia Malkhi, Michael K Reiter, Guy Golan Gueta, and Ittai Abraham. 2019. HotStuff: BFT consensus with linearity and responsiveness. In Proceedings of the 2019 ACM Symposium on Principles of Distributed Computing. 347–356

共3F+1个Servers。

达成活跃性、安全性无需同步假设。乐观响应：前2F+1个消息即可进行共识决策。

采用轮换 Primary 保证链质量。

采用门限签名达到共识线性。（最坏情况，连续Primaries故障，复杂度为f*n）

1.请求

Client向所有Servers发送Req。

同PBFT，等待F+1个Reply，操作完成。

客户端请求失败处理部分，引用了文献：

Alysson Bessani, Joao Sousa, and Eduardo EP Alchieri. 2014. State machine replication for the masses with BFT-SMART. In 2014 44th Annual IEEE/IFIP International Conference on Dependable Systems and Networks. IEEE, 355–362.
Miguel Castro, Barbara Liskov, et al. 1999. Practical Byzantine fault tolerance. In OSDI, Vol. 99. 173–186.

2.共识

1.Prepare阶段

Primary在收到Req后，向节点（Replica）广播PREPARE消息。

节点验证消息：

1. 为上次提交的msg的扩展（无间隔）
2. 最高View（最新视图）

验证后，用部分签名对PREPARE-VOTE消息签名，并发给Primary。

Primary在等待2F+1后，生成仲裁证书（Quorum Certificate，QC），记为 PrepareQC。【可以理解为完成】

2.Pre-Commit 阶段

广播带有 PrepareQC 的msg，节点将其存储。

将COMMIT-VOTE消息签名后发给Primary。

Primary在集齐2F+1后，形成 Pre-CommitQC。

3.Commit 阶段

广播带有 Pre-CommitQC 的msg。

节点回复COMMIT给Primary，并且更新变量 lockedQC。【保存QC计数/Req】

$keepscountingthenumberofreceivedQCsforarequest$.

4.Decide 阶段

Primary在收到2F+1后，广播DECIDE给Replicas。

节点认为共识达成，开始执行请求。

然后ViewNum++。【视图切换开始】

然后发送New-View给新主。

三个变量

• $prepareQC$：当前节点已知的最高锁定 PREPARE msg（最新）。

• $lockedQC$：已知最高锁定 COMMIT msg（最新）。

• $viewNum$：节点当前所处视图。

新主收到2F+1个New-View后，在$prepareQC$基础上扩展。（理解为+1）

若未能及时收满2F+1，则触发超时，视图切换。

3.视图切换 $ViewChange$

为了确保链质量，HotStuff可以更频繁的切换试图。

通过广播协调消息和收集门限签名进行共识。因此视图切换被包含于HotStuff的核心流程。

新主选择方式为 $p=v\mathrm{mod}n$。

4.优缺点

使用门限签名，实现线性消息传递。

每个阶段的收集投票，构建门限签名，可以被流水线化$pipelined$。从而简化HotStuff协议的构建，例如Casper：（同时降低O(n)）

Vitalik Buterin and Virgil Griffith. 2017. Casper the friendly finality gadget. arXiv preprint arXiv:1710.09437 (2017).

还可以用延迟塔$delaytowers$扩展到公有链：

Shashank Motepalli and Hans-Arno Jacobsen. 2022. Decentralizing Permissioned Blockchain with Delay Towers. (2022).
arXiv:2203.09714

在failures情况下，HotStuff吞吐量显著下降（不能达成共识）。

关于实验

• 使用Amazon EC2 c5.4xlarge实例，每个实例有16个vCPU，由Intel Xeon Platinum 8000处理器支持。
• 所有核心的Turbo CPU时钟速度高达3.4GHz。
• 每个副本运行在单个VM实例上。

网络配置：

• 测得的TCP最大带宽约为1.2 Gbps。（使用iperf工具）
• 网络延迟小于1毫秒。

实验设置：

• 实验中使用了4个副本，配置为容忍单个故障（即f = 1）。
• 使用了空操作请求和响应，没有触发视图更改。
• 实验中使用了不同的批次大小（100、400和800）和不同的有效负载大小（0/0、128/128和1024/1024字节）。

软件和工具：

• HotStuff的实现使用了大约4K行C++代码，核心共识逻辑大约200行。
• 使用secp256k1进行数字签名。
• 使用NetEm工具引入网络延迟。

使用BFT-SMaRt的ThroughputLatencyServer和ThroughputLatencyClient程序测量吞吐量和延迟。

---

四、ISS: Insanely Scalable State Machine Replication-2022

Chrysoula Stathakopoulou, Matej Pavlovic, and Marko Vukolić. 2022. State machine replication scalability made simple. In Proceedings of the Seventeenth European Conference on Computer Systems. 17–33.
会议17th European Conference on Computer Systems (EuroSys)欧洲计算机系统会议，顶级学术会议
地点Rennes, FRANCE
日期APR 05-08, 2022
赞助方Assoc Comp Machinery; ACM SIGOPS; USENIX; Huawei; Stormshield; Microsoft; Protocol Labs Res; Red Hat; Amazon; Meta; Google; Intel; Cisco

共3F+1节点。

是一个通用框架，

通过划分工作负载，并且关联 SB（Sequenced Broadcast） 实例与Leader，

将传统的单Leader的 TOB（Total Order Broadcast） 协议扩展为多Leader的协议。

达成PBFT的37倍，Raft的55倍，Chained HotStuff的56倍。

1.初始配置

日志log：该节点接收的所有消息，由Req组成，被批处理以降低消息复杂性。

SN（Sequence Number）序列号：相对于日志开头的偏移量。

将日志分成epoch，按SN以轮询方式分配给Leader，再将epoch分成segment，这样与Leader相对应。

所有Req基于modulo哈希函数分类到桶bucket中，再将桶分配给Leader。

段、Leader、桶，一一对应。

2.复制协议$ReplicationProtocol$​

初始配置阶段

1> 选中N123三个节点为Leader。

2> 分别分配segment 1、2、3。

分别对应SN1 4，2 5，3。

3> 分桶给Leader，包含用于提出提议的Req批次$requestbatches$。

分别为B1、2、3。

等待Req 阶段

通过多SB实例（共识实例）达成共识。

SB实例与一个Leader及其Segment相关联。

等待客户端发送请求，记为$SMR-CAST|<r_x>$，散列到本地桶队列中。直到：

• 桶满（预定义大小）如$|B_i|=3$.
• 预定时间（距上次提案）。

将桶里的Req请求打包为一批次${\beta }_i$。然后广播$SB-CAST<1,{\beta }_A>$消息。

共识阶段

每个Leader运行底层包装的TOB协议，就其提议的SB实例达成共识。【可并行non-blocking】

• 共识成功，将SB中承载的一批Req交付。
• 共识失败，log中记录⊥。

TOB可以保证，成功时所有正确节点中的序列号与批次一致。

当一个epoch的所有SN号对应的log都被填满时，节点向Client发送$SMR-DELIVERED$，收满$aquorum$即完成。

3.多领导选择$MultipleLeaderSelection$

$LeaderSelectionPolicy,LE$​选主策略可以自定义，只要能保证活性：each bucket will be assigned to a segment with a correct leader infinitely many times in an infinite execution将桶分配给正确Leader的段。

例如：保证足够多的正确Leader.

Zarko Milosevic, Martin Biely, and André Schiper. 2013. Bounded delay in byzantine-tolerant state machine replication. In 2013 IEEE 32nd International Symposium on Reliable Distributed Systems. IEEE, 61–70

Leader 故障检测

每个SB实例用==$FailureDetector$==，用来检测quiet nodes。

ISS会从集合移除故障Leader，用LE再选个主。

4.优缺点

Pros

• 吞吐量，因为并行。
• 对客户端高响应，可立即执行Req。
• 资源不浪费，Req仅入一个桶。

Cons

• 共识延迟，引入额外开销。
• 故障时，SB实例高概率共识失败。（任何Leader故障，新主，并重新提出未提交的Req）
• Req需要发到所有节点，以确保Req放入正确桶。

五、DAG-Rider-2021

Idit Keidar, Eleftherios Kokoris-Kogias, Oded Naor, and Alexander Spiegelman. 2021. All you need is dag. In Proceedings of the 2021 ACM Symposium on Principles of Distributed Computing. 165–175.

$Directedacyclicgraph(DAG)$.有向无环图。

图中为完整的消息传播历史，包含：遍历的路径、因果关系$causalhistory$.

传统的Leader服务器承担：

• tx分发。$transactiondistribution$
• 达成共识。 $consensusphase$

两项责任，巨大工作量导致tx积压、系统瓶颈。

而DAG-based算法将二者分离，在tx分发阶段无需Leader（吞吐量显著增加），在共识阶段每个实例都有一个Leader。

1.系统模型&服务属性$Systemmodelandserviceproperties.$

DAG-Rider是一种异步拜占庭原子广播协议（$asynchronousByzantineAtomicBroadcast,BAB$）。

以最佳时间和消息复杂度实现了后量子安全。

分为两层：

1. 基于轮的结构化DAG，分发tx用。
2. 零开销的共识协议，独立确定提交消息顺序。

使用Bracha广播。

共3F+1个节点。

假设了一个全局完美硬币（$globalperfectcoin$）来确保活性。允许在wave的实例上独立选择一个Leader.

2.DAG流水线 $Pipelining$

节点独立维护自己的DAG，用一个数组[]存储。（所有节点间消息传播拓扑）

以轮$round$为单位。

强边：分发相同的msg，直链（directly linked in the previous round）。

弱边：没有直链。

协议流程

验证器一直等待客户端发送交易（请求、顶点），存储于缓冲区buffer，并监视：

定期检查，若其所有前导顶点都已成功接收，则加入DAG[]，并根据round组织起来。

当满2F+1个顶点时，进入下一轮r+1。（下一波？虽然首轮也是下轮）

生成新的顶点v：r+1，弱边，并广播。

因为网络部分同步，可能有不同的DAG出现，但BAB会保证最终收敛。

4.共识$ConsensusinDAGs$ 「我也不知3跑哪了」

利用全局完美硬币，节点可以独立检查DAG，推断需交付的区块及其提交顺序。（无需额外协调）

在DAG于节点中发送顶点完毕后，系统启动共识旨在确保分发的tx完成提交aimed at deterministically finalizing the commit of the disseminated transactions.

在这个过程中，DAG被分为波waves，每波有4个轮次rounds。

利用完美硬币在第一轮中随机选择Leader（满2F+1强边）。

按照预先确定的顺序交付顶点块。交付区块时，会将其因果关系历史上的值也一并提交。

5.优缺点

Pros.

• 吞吐量显著提升。
• DAG达成消息分发和促进共识两种目的$dualpurpose$​。
• 更稳定的提交。

Cons.

• 因为分离，延迟激增$O(n3log(n)+nM)$​ 。

六、Narwhal and Tusk-2022

George Danezis, Lefteris Kokoris-Kogias, Alberto Sonnino, and Alexander Spiegelman. 2022. Narwhal and tusk: a dag-based mempool and efficient bft consensus. In Proceedings of the Seventeenth European Conference on Computer Systems. 34–50.

将tx传播与tx排序分离，实现高效共识。

Mempool负责可靠传播，少量元数据用来排序。

1.系统模型&服务属性

共3F+1节点。

Mempool是一个KV键值存储$(d,b)$。

K：digest.

V：交易块block。

服务属性

• 完整性：（d，b）。
• 可用性：写入（d，b）后。
• 包含性$Containment$：后块包含前块。
• $2/3$因果性：后块包含至少$2/3$前块。
• $1/2$链质量：至少有一半causal history是诚实者所写入。

2.复制协议

替换Bracha广播。

用固有DAG+证书实现。

blocks包含

• hash sig。
• tx list。
• 证书certificates of availability。

证书包含：hash、2F+1 sig、round。

原理

1. 收集tx —— tx list 和 证书list。
2. r-1 主收集2F+1证书 —— r，新块广播。
3. 验证sig、含2F+1、唯一块，签名（确认）。
4. 满2F+1， 造一个证书并广播，此时停止广播新块。

3.Tusk共识

• 选主同DAG-Riders。
• 一波三轮。
• 一三🉑重叠，4.5rounds。

4.优缺点

Pros.

• 一个基于DAG的BFT算法的具体实现。
• 吞吐量优势。

Cons.

• 高延迟（提交区块前等待多轮）。
• 未满足标准的tx需要等更多wave。

---

$$End.$$

---

1. Miguel Castro and Barbara Liskov. 2002. Practical Byzantine fault tolerance and proactive recovery. ACM Transactions on Computer Systems (TOCS) 20, 4 (2002), 398–461. ↩︎