[PBFT]Practical Byzantine Fault Tolerance[二]视图更换理解

一、视图更换的必要性

 视图更换是系统由于Primary出故障而能够保证可用性（liveness）的手段，可用性指操作能够在有效时间内完成。
checkpoint, stable checkpoint

the states produced by the excution of these requests : checkpoint
a checkpoint with a proof : stable checkpoint
proof指节点达成2f+1的共识，达成全网共识的checkpoint就是stable checkpoint。

 checkpoint是对于单个节点来说的,其设置是周期性的，比如说节点每当消息序号n是100的倍数设置一次，每个节点设置checkpoint相互独立，chekpiont消息带有请求的序列号，水位线机制确保了最低chekpoint和最高checkpoint的间隔。节点在确立检查点的时候会多播消息给其他节点；stable checkpoint是对于全网节点来说的，达到全网共识的checkpoint就是stable checkpoint。
 checkpoint的作用：减少内存占用。

二、视图更换的流程

 backup在收到有效请求但并未执行的时候就会进行等待，这期间会开始计时（starts a timer），计时在等待时启动，非等待状态会停止。

1. 节点检查到timer超期会停止接受消息并多播一个视图更换消息给所有的replica。n代表i当前所知道的最新稳定检查点s（stable checkpoint）的消息序号，C是2f+1个能够证明s正确的有效的检查点消息集合,集合P由P_m构成，m是所有大于n的消息的序列号，集合P_m是由在i中达成prepared状态的消息的集合，P_m的内容包括关于m的pre-prepare消息和2f个prepare消息。

2. 当下一个视图确定的primary p收到2f+1个视图更换消息后，就会多播一个的消息给所有的节点，V是p收到和发出的有效的 消息的集合，O是pre-prepare状态的消息的集合。
    O的确定，p根据收到的 消息可以得知min_s和max_s。min_s是p收到的所有 消息中最新的稳定检查点的消息序号n，max_s指的是 消息中已知是prepare状态的最大消息序号（由集合P得到）。确定min_s和max_s之后，p就为这些消息创建pre-prepare消息。

3. p将所有的O中的消息写入自己的日志，其他节点在对O验证之后就接受 消息。到这里就完成了视图的更换，之后的流程与三阶段消息就一样了。

其他优化

 1. 为了节省网络带宽和CPU占用，通过client指定一个replica存储计算结果，其它replica存储计算结果的摘要，如果验证后发现结果不正确，再重新提交请求，要求所有节点都提交完整信息。
 2. 当不发生视图更换的时候，节点到达prepare状态之后，会执行节点的请求并发送临时结果给client，当client收到2f+1个相同的临时性结果时就可以接受。这一步利用了从prepare到commit之间的等待时间。

参考文献

https://www.jianshu.com/p/fb5edf031afd
https://www.cnblogs.com/gexin/p/10242161.html
https://lessisbetter.site/2020/03/22/why-pbft-needs-viewchange/
https://zhuanlan.zhihu.com/p/35847127