PBFT算法

在我的博客中对于RAFT算法也有详细的介绍，raft算法包含三种角色，分别是：跟随者（ follower ），候选人（candidate ）和领导者（ leader ）。集群中的一个节点在某一时刻只能是这三种状态的其中一种，这三种角色是可以随着时间和条件的变化而互相转换的。

raft 算法主要有两个过程：一个过程是领导者选举，另一个过程是日志复制，其中日志复制过程会分记录日志和提交数据两个阶段。raft 算法支持最大的容错故障节点是（N-1）/2，其中 N 为集群中总的节点数量。

国外有一个动画介绍raft算法介绍的很透彻，链接地址为：http://thesecretlivesofdata.com/raft/。这个动画主要包含三部分内容，第一部分介绍简单版的领导者选举和日志复制的过程，第二部分内容介绍详细版的领导者选举和日志复制的过程，第三部分内容介绍的是如果遇到网络分区（脑裂），raft 算法是如何恢复网络一致的。有兴趣的朋友可以结合这个动画以及我的博客来更好的理解raft算法。这篇博客主要来讲解学习PBFT算法。

RAFT共识-CSDN博客https://blog.csdn.net/qq_45875349/article/details/139673531

1. 背景

pbft 算法的提出主要是为了解决拜占庭将军问题。什么是拜占庭将军问题呢？拜占庭位于如今的土耳其的伊斯坦布尔，是古代东罗马帝国的首都。拜占庭罗马帝国国土辽阔，为了达到防御目的，每块封地都驻扎一支由将军统领的军队，每个军队都分隔很远，将军与将军之间只能靠信差传递消息。在战争的时候，拜占庭军队内所有将军必需达成一致的共识，决定是否有赢的机会才去攻打敌人的阵营。但是，在军队内有可能存有叛徒和敌军的间谍，左右将军们的决定影响将军们达成一致共识。在已知有将军是叛徒的情况下，其余忠诚的将军如何达成一致协议的问题，这就是拜占庭将军问题。

详细的内容可以看我的博客：有趣的拜占庭将军问题与BFT算法-CSDN博客

拜占庭将军问题最早是由 Leslie Lamport 与另外两人在 1982 年发表的论文《The Byzantine Generals Problem 》提出的，他证明了在将军总数大于 3f ，背叛者为f 或者更少时，忠诚的将军可以达成命令上的一致，即 3f+1<=n 。算法复杂度为 o（n^(f+1)) 。而 Miguel Castro (卡斯特罗)和 Barbara Liskov （利斯科夫）在1999年发表的论文《 Practical Byzantine Fault Tolerance 》中首次提出 pbft 算法，该算法容错数量也满足 3f+1<=n ，算法复杂度为 o（n^2）。

2. PBFT算法的最大容错节点

pbft 算法的除了需要支持容错故障节点之外，还需要支持容错作恶节点。假设集群节点数为 N，有问题的节点为 f。有问题的节点中，可以既是故障节点，也可以是作恶节点，或者只是故障节点或者只是作恶节点。那么会产生以下两种极端情况：

第一种情况，f 个有问题节点既是故障节点，又是作恶节点，那么根据小数服从多数的原则，集群里正常节点只需要比f个节点再多一个节点，即 f+1 个节点，确节点的数量就会比故障节点数量多，那么集群就能达成共识。也就是说这种情况支持的最大容错节点数量是 f =（n-1）/2 ,2f + 1 = n
第二种情况，故障节点和作恶节点都是不同的节点。那么就会有 f 个问题节点和 f 个故障节点，当发现节点是问题节点后，会被集群排除在外，剩下 f 个故障节点，那么根据小数服从多数的原则，集群里正常节点只需要比f个节点再多一个节点，即 f+1 个节点，确节点的数量就会比故障节点数量多，那么集群就能达成共识。所以，所有类型的节点数量加起来就是 f+1 个正确节点，f个故障节点和f个问题节点，即 3f+1=n。

3. 算法核心流程

pbft 算法的基本流程主要有以下四步：

客户端发送请求给主节点
主节点广播请求给其它节点，节点执行 pbft 算法的三阶段共识流程。
节点处理完三阶段流程后，返回消息给客户端。
客户端收到来自 f+1 个节点的相同消息后，代表共识已经正确完成。

为什么收到 f+1 个节点的相同消息后就代表共识已经正确完成？从上一小节的推导里可知，无论是最好的情况还是最坏的情况，如果客户端收到 f+1 个节点的相同消息，那么就代表有足够多的正确节点已全部达成共识并处理完毕了。

4. 算法核心三阶段流程

下面介绍 pbft 算法的核心三阶段流程，如下图所示：

算法的核心三个阶段分别是 pre-prepare 阶段（预准备阶段），prepare 阶段（准备阶段）， commit 阶段（提交阶段）。图中的C代表客户端，0，1，2，3 代表节点的编号，打叉的3代表可能是故障节点或者是问题节点，这里表现的行为就是对其它节点的请求无响应。0 是主节点。整个过程大致是如下：

首先，客户端向主节点发起请求，主节点 0 收到客户端请求，会向其它节点发送 pre-prepare 消息，其它节点就收到了pre-prepare 消息，就开始了这个核心三阶段共识过程了。

1. Pre-prepare 阶段：节点收到 pre-prepare 消息后，会有两种选择，一种是接受，一种是不接受。什么时候才不接受主节点发来的 pre-prepare 消息呢？一种典型的情况就是如果一个节点接受到了一条 pre-pre 消息，消息里的 v 和 n 在之前收到里的消息是曾经出现过的，但是 d 和 m 却和之前的消息不一致，或者请求编号不在高低水位之间（高低水位的概念在下文会进行解释），这时候就会拒绝请求。拒绝的逻辑就是主节点不会发送两条具有相同的 v 和 n ，但 d 和 m 却不同的消息。

在PBFT（Practical Byzantine Fault Tolerance）算法中，v、n、d 和 m 是消息中的关键字段，分别代表以下内容：

v（View Number）：表示当前视图编号。PBFT 算法通过视图编号来区分不同的主节点（Primary）。每个视图都有一个唯一的主节点，负责协调共识过程。如果主节点出现问题，系统会切换到新的视图，视图编号会递增。
n（Sequence Number）：表示请求的序列号。每个客户端请求都会被分配一个唯一的序列号，用于确保请求的顺序性。序列号帮助节点确定请求的处理顺序，并防止重复处理。
d（Digest）或者D(m)：表示请求消息的摘要（哈希值）。摘要用于唯一标识请求的内容，确保消息的完整性和一致性。节点可以通过比较摘要来验证消息是否被篡改。
m（Message）：表示实际的请求消息内容。这是客户端发送的原始请求，包含了具体的操作或指令。
i：节点的编号

如果节点之前已经收到过具有相同 v 和 n 的消息，但 d 和 m 不同，这意味着主节点可能发送了不一致的消息，或者存在恶意行为。此时，节点会拒绝该消息。

2. Prepare 阶段：节点同意请求后会向其它节点发送 prepare 消息。这里要注意一点，同一时刻不是只有一个节点在进行这个过程，可能有 n 个节点也在进行这个过程。因此节点是有可能收到其它节点发送的 prepare 消息的。在一定时间范围内，如果收到超过 2f 个不同节点的 prepare 消息，就代表 prepare 阶段已经完成。

3. Commit 阶段：于是进入 commit 阶段。向其它节点广播 commit 消息，同理，这个过程可能是有 n 个节点也在进行的。因此可能会收到其它节点发过来的 commit 消息，当收到 2f+1 个 commit 消息后（包括自己），代表大多数节点已经进入 commit 阶段，这一阶段已经达成共识，于是节点就会执行请求，写入数据。

处理完毕后，节点会返回消息给客户端，这就是 pbft 算法的全部流程。为了更清晰的展现这个过程和一些细节，下面以流程图来表示这个过程：

5. checkpoint 、stable checkpoint和高低水位

Checkpoint 是系统在某个时刻的状态快照。它记录了当前所有已达成共识的请求及其执行结果。检查点的主要作用是减少系统恢复时的开销，因为节点不需要从初始状态重新执行所有请求。假设系统已经处理了 100 个请求（序列号 1 到 100），节点会生成一个检查点，记录这 100 个请求的执行结果。如果系统在后续运行中崩溃，节点可以从这个检查点恢复，而不需要重新执行前 100 个请求。

那什么是 stable checkpoint （稳定检查点）呢？stable checkpoint 就是大部分节点（2f+1）已经共识完成的最大请求序号。假设系统中有 4 个节点（f = 1，因为 2f + 1 = 3），节点 A、B、C 和 D 都生成了序列号为 100 的检查点。如果至少 3 个节点（例如 A、B、C）确认了这个检查点，那么它就成为稳定检查点。此时，系统可以安全地清理序列号 1 到 100 的日志。

高低水位 是 PBFT 算法中用于限制请求序列号范围的机制。它们确保节点只处理一定范围内的请求，防止恶意节点通过发送大量无效请求耗尽序列号空间。