分布式基础——PBFT共识算法

共识

基本解释：在多server（服务器）的情况下，server需要达成一致性的认识。

以下为常见的共识算法：

共识算法分类

• 非拜占庭容错（CFT）：Paxos，Raft

只能保证分布式系统中节点发生宕机等错误时整个分布式系统的可靠性(用于私有链，企业内部)

• 拜占庭容错（BFT）：PBFT、BFT-Smart

分布式系统中节点发生了任意类型(宕机、篡改、重放…的错误,只要发生错误的节点少于一定比例，都能保证系统的可靠性(用于联盟链，各节点缺少信任)

PBFT

共识过程

老大向我发送命令时，当我认为老大的命令是有问题时，我会拒绝执行。就
算我认为老大的命令是对的，我还会问下团队的其它成员老大的命令是否是
对的，只有大多数人(2f+1) 都认为老大的命令是对的时候，我才会去执
行命令。

• request：客户端-1给主节点0发消息。

• Pre-Prepare：主节点收到后，将消息编号排序，并将消息封装为Pre-Prepare消息分发给其他节点。

• Prepare：其他节点收到消息后，会验证是否由主节点签名，是否被篡改过等。然后分发给其他节点，其他的非主节点会验证消息是否一致。这一阶段主要表明自己是没有问题的，但不确定其他节点有没有问题。

• Commit：收集满2*f+1个Prepare（包括自己的）签名包，认为没有问题，广播Commit包，会在本地存储数据。这一阶段主要是各个节点之间确定相互之间是没有问题的。

需要至少f+ 1个可信节点对本地要提交的请求的序号取得共识，需要注意的是这些请求在每个节点可能是在不同的视图号中提交的。

• Reply：当收到2*f+1个Commit包后，会回复给客户端

主节点宕机、出错

当有从节点发现主节点有问题时，会发出ViewChange，希望改变主节点

V：新主节点收到的(包括自己发送的) ViewChange的消息集合

O：PRE- PREPARE状态的消息集合，保证视图变更后P集合中的消息安全

从节点接收到NewView消息后，校验签名, V和O中的消息是否合法，验证通过，主节点和副本都进入视图l+1

参考

PBFT共识算法（组会分享），欢迎批评，讨论_哔哩哔哩_bilibili