关于区块链:PBFTPractical-Byzantine-Fault-Tolerance二ViewChange视图更换理解

50次阅读

共计 1539 个字符，预计需要花费 4 分钟才能阅读完成。

视图更换是零碎因为 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 的距离。节点在确立检查点的时候会多播 <CHECKPOINT,n,d,i> 音讯给其余节点；stable checkpoint 是对于全网节点来说的，达到全网共识的 checkpoint 就是 stable checkpoint。
checkpoint 的作用：缩小内存占用。

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

节点查看到 timer 超期会进行承受音讯并多播一个视图更换音讯 <VIEW-CHANGE,v+1,n,C,P,i> 给所有的 replica。n 代表 i 以后所晓得的最新稳固检查点 s（stable checkpoint）的音讯序号，C 是 2f+ 1 个可能证实 s 正确的无效的检查点音讯 <CHECKPOINT,n,d,i> 汇合, 汇合 P 由 P _m形成，m 是所有大于 n 的音讯的序列号，汇合 P _m是由在 i 中达成 prepared 状态的音讯的汇合，P_m的内容包含对于 m 的 pre-prepare 音讯和 2f 个 prepare 音讯。
当下一个视图确定的 primary p 收到 2f+ 1 个视图更换音讯后，就会多播一个 <NEW-VIEW,v+1,V,O> 的音讯给所有的节点，V 是 p 收到和收回的无效的 <VIEW-CHANGE> 音讯的汇合，O 是 pre-prepare 状态的音讯的汇合。

O 的确定，p 依据收到的 <VIEW-CHANGE> 音讯能够得悉 min_s 和 max_s。min_s 是 p 收到的所有 <VIEW-CHANGE> 音讯中最新的稳固检查点的音讯序号 n，max_s 指的是 <VIEW-CHANGE> 音讯中已知是 prepare 状态的最大音讯序号（由汇合 P 失去）。确定 min_s 和 max_s 之后，p 就为这些音讯创立 pre-prepare 音讯。

p 将所有的 O 中的音讯写入本人的日志，其余节点在对 O 验证之后就承受 <NEW-VIEW> 音讯。到这里就实现了视图的更换，之后的流程与三阶段音讯就一样了。

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