我们了解到,PBFT可以防止备份节点作恶,是因为可以切换主节点,是如何切换的主节点的呢?
答案是视图变化,通过领导者选举出新的节点,替换掉作恶的主节点,
其中的试图可以对应着是领导者的任期,不同的视图值对应不同的主节点,比如视图值为1的时候,主节点为A,视图值为2的时候,主节点为B
对于领导者来说,不管是非拜占庭容错算法,还是拜占庭容错算法,领导者选举都是实现容错能力非常重要的一环,比如,Raft而言,领导者选举实现了领导者节点的容错能力,避免因为领导者节点故障整个集群不可用,而对PBFT而言,试图变更,解决了主节点故障和恶意节点的问题
理解视图变更,可以理解拜占庭容错算法如何处理领导者故障和作恶,
我们首先确认下作恶的几种情况,比如:
1.我们提到的,主节点接收客户端请求,不做任何处理,默不作声
2.主节点收到客户端的请求后,给不同的准备请求分配了不同的序号
3.主节点只给部分节点发送了预准备消息
共识是无法达成的,恶意节点当选了主节点,无论忠诚节点有多少,忠诚节点都无法达成共识
我们必须将作恶的主节点替换掉,最终只有忠诚的节点担任主节点,PFBT才能保证当前节点数为3f+1,忠诚节点,才能达成共识
替换作恶的主节点
视图变更是保证PBFT算法能够稳定运行的关键,当出现了异常情况的时候,触发视图变更,通过轮流值岗的方式,(V+1)mod|R| v为当前的试图值,R为节点数, 这样的方式选出了一下个试图的节点,选择一个忠诚的节点作为新的主节点
我们还是拿着苏秦举例,将楚先当做主节点,实际上他是个叛徒
然后向楚国,发送了进攻的请求
当楚国接收到了苏秦的请求,为了达到破坏作战计划的目的,其保持不发送
这就使得客户端一致等待响应,一直等不来,一直到超时
这时候,苏秦会直接向着备份节点发送作战指令
会将作战指令直接发给楚,等待一段时间后,楚没有响应,那么就认为楚已经叛变了,应该发起试图的变更,选出新的大元帅,并且,向着集群发送视图变更消息
这样,大元帅就被替换掉了,最终的大元帅是忠诚派
而且,在其中,当定时器超时触发了试图变更之后,暂时停止接收和处理,除了检查点,视图变更,新视图之外的消息,这个节点现在集群处于异常状态,不会处理客户端的相关信息了
而且,试图自我也会触发视图变更
1.如果备份节点发送了准备消息后,在约定的时间内没有收到其他节点的2f个相同的准备消息
2,备份节点发送了提交消息后,约定时间内没收到其他节点的2f相同的提交消息
3.备份节点收到异常消息,比如视图值,序号,已经接受的消息相同,内容摘要不同
这样还解决了备份节点长时间阻塞等待客户端请求被执行
本章总结一下
客户端通过等待f+1个相同响应消息超时,发现主节点可能在作恶,客户端发送客户端请求给所有集群节点,触发可能的试图变更
Raft在选举时期服务不可用,PBFT在试图变更也类似
而且一般每个节点,都需要持久化保存状态数据,但是随着系统的运行,数据必然会增加越来越多,最后出现存储空间不够用的情况,那么怎么办呢
利用检查点机制,PBFT实现了检查点,定时清理本地缓存不需要的历史数据
那么,一般在实际上,如何使用的PBFT的呢?
一般PBFT的性能不高,我们会考虑将数字签名和消息验证码进行混用,PBFT只有变更了消息或者新视图的时候使用签名消息,其他都是消息验证码,节省大量的加解密的开销
或者使用在可信的,数量有限制的联盟链,Hyperledger Sawtooth
和其他拜占庭算法结合,落地公有链,Zilliqa,将POW和PBFT结合起来,实现公有链的共识协商,POW算法作为认证,PBFT实现共识