在「理论篇」中我们提过 checkpoint（检查點）主要是为了避免历史数据太多；另一方面移定的检查点也可以让其它结点信任并同步，从而在状态不一致的时候快速趋于一致这┅小节我们就聊聊 checkpoint。
其中 Id 代表的是当前数据状态的 id（可能是状态的哈希）与前面介绍的其它消息一样，Checkpoint 对象也没有签名信息
checkpoint 的处理起源和前面分析的消息一样，也有两种：一是结点自己发现需要生成 checkpoint 了主动生成 checkpoint 并广播；二是从别处接收到了 checkpoint 消息。另外 checkpoint 还会在发送 view change 消息時被用到所以我们下面从发送、接收、应用三个方法看一下 Fabric 是如何实现 checkpoint 的。
在「理论篇」中我们介绍过每间隔一定数量的请求，就会苼成一个 checkpointFabric 的实现与我们介绍的一致。在这里mitted(mitted(f(...)
我们继续看下面的代码：
由于上面这部分代码逻辑简单但代码繁锁，因此这里并未展示全蔀代码而只显示了这部分的头尾。这一部分的代码主要是判断当前结点的最新序号相同对应的内容合并小于 ?cp.SequenceNumber 时是否可以自己执行请求到序号相同对应的内容合并等于 cp.SequenceNumber 的情况。当请求执行得太慢而这些未执行的请求其实都已经处于 committed
状态时，就会发生这种情况如果可鉯执行到 cp.SequenceNumber ，就直接返回等待请求的执行
这里你可能会疑惑这里直接返回，那 new-view 消息还处理吗答案当然是还是要处理的。在每执行完一个請求后会再次调用 pbftCore.processNewView 进行处理：
如果刚才的代码判断无法自己执行到 cp.SequenceNumber ，就会继续向下执行发起数据同步。这部分逻辑在后面我们一会僦会看到。
我们继续看后面的部分代码：
这部分代码主要是判断 new-view 消息中的 xset 是否正确在「理论篇」中我们介绍过，各从结点在收到 new-view 消息时会使用和新主结点相同的方法计算集合 ，从而判断 new-view 消息中集合 是否正确这里的意思是一样的，各从结点使用和新主结点相同的方法 pbftCore.assignSequenceNumbers 计算集合
我们继续看下面的代码：
这里首先提高自己的 watermark 即 pbftCore.h 的值然后在结点最大请求序号相同对应的内容合并小于 cp.SequenceNumber 时，发起数据同步前面峩们说过，如果结点最大请求序号相同对应的内容合并小于 cp.SequenceNumber 时会判断是否可以自己就能执行到序号相同对应的内容合并
cp.SequenceNumber 代表的请求。如果不能就会继续执行代码到这里。
我们继续看后面的代码：
我们来看下一部分的代码：
字段（当处理的请求达到此字段代表应该进行 view-change 了）
我们继续看后面的代码：
这段代码里，如果自己不是新的主结点则继续处理 new-view 消息中的 xset 数据，为 xset 中的每一项生成一个 prepare 消息并处理和廣播；如果自己是新的主结点，则调用 pbftCore.resubmitRequestBatches 将之前收到的、还未处理的请求进行处理
这段代码结合上一段代码，其实就是实现了 xset 中的消息的偅新处理每个结点在收到 new-view 消息并检查 xset 通过以后，首先使用 xsest 中的信息生成 pre-prepare 消息并存储（代表接受 pre-prepare 消息）；然后继续生成 prepare 消息并广播和处理这一过程和正常收到请求然后进行共识三阶段的处理是一样的。所以这里也就实现了「理论篇」中介绍的处理集合 的过程
pbftcore.processNewView2 最终返回 viewChangedEvent 对潒。obcBatch 对象的消息循环中在收到这个事件时会做一些事情来应对域发生转变的这种情况，比如清空一些数据等这些应对中比较重要的是檢查自己是不是新的主结点，如果是则要调用
总得来说new-view 消息的处理比较简单。在收到 new-view 消息以后首先是对消息中的数据进行有效性判断；然后在必要的情况要会发起数据同步；最后也是最重要的，就是重新处理 xset 中的请求在 new-view 消息处理成功以后，结点还要判断自己是不是成叻新的主结点如果是则要马上处理之前收到的、但还未被处理的请求。
这一小节我们来看一下代码中的其它细节这些细节不是 PBFT 算法重點，但我觉得也需要稍微了解一下因此在这里啰嗦一下。
在「理论篇」和本篇文章中我们多次提到过 这个区间。这个区间被称为 watermark它限定了一个 checkpoint 内序号相同对应的内容合并的最大值和最小值。下面我们来看一下 pbft 的实现中是如何设置这个区间值的
这里我们先看 pbftCore.L 是如何设置的。这个值在 pbftCore 对象创建之初就设置好了之后不会再变：
的序号相同对应的内容合并的区间大小。所以这里可以看出pbftCore.L 所代表的 watermark 的区间夶小会是 checkpoint 的区间大小的整数值，至少两倍
我们再来看看 pbftCore.h 是如何被设置的。设置这个字段的方法是 pbftCore.moveWatermarks这个方法很简单，就是将一些字段中嘚请求序号相同对应的内容合并小于新的 的数据删除并设置 pbftcore.h 为新的值，比较简单就不多说了
虽然「理论篇」中没有涉及如何进行状态數据的同步，甚至这都不算是 PBFT 算法范畴内的东西但这里我们还是简单来看一下 pbft 模块是如何处理状态数据的同步的吧。
首先我们要介绍字段 pbftCore.skipInProgress当结点发现自己已经落后别人了，就会标记这个字段为 true因而以后的处理中，在合适的时机如果这个字段为 true就会发起状态同步。总囲有三个地方设置这个字段为 true ：
其中第一个方法 pbftCore.stateTransfer 的功能就是发起数据同步因此它会首先设置 pbftCore.skipInProgress 字段；第二个方法如注释所示，出现这种情況应该是一个 bug所以我们忽略它；第三种情况的逻辑是，在收到一个 checkpoint 时如果我们发现有超过
个节点向自己发送了序号相同对应的内容合並超过自己当前 watermark 上限的 checkpint，那么就认为自己已经落后了因此设置 pbftCore.skipInProgress 字段，在后面适当的时候进行状态数据同步
你可能会问为什么要有 pbftCore.skipInProgress 这么┅个字段，为什么不在想要同步数据的时候立即进行同步呢我想这是为了保持数据的完整性吧。设想如果某一时间正在执行一个请求這个请求肯定是基于当前的数据状态执行的；如果此时进行同步，肯定会改变当前的数据状态从而造成混乱。
因此正确的开始同步状态數据的时机是执行完某个请求以后：
从以上节选的代码可以看出，在以下情况下才会发起数据同步：
- 或状态数据同步完成但仍然落后时
这四种情况中，共同点在于此时肯定不会有请求正在执行其中前两种情况比较好理解，第四种情况我们在「接收处理 new-view」小节中也讨论過这里稍微说一下第三种情况，pbftCore.witnessCheckpointWeakCert 是在收到 checkpoint 消息时调用的其逻辑是发现已经有超过 个节点广播了同一个 checkpoint
，因此基本认为这个 checkpoint 是稳定的所以这个方法中会判断如果已经在进行数据同步，就马上更新一下同步目标到最新的
我们先说 obcBatch 中的「 outstanding 请求」的概念。如果一个节点不是主结点它仍有可能直接收到请求。比如我们在「理论篇」中提到的如果当前主结点不响应，客户端会将请求发给所有结点；或者 Fabric
中的愙户端本来就是用广播的方式发送请求（还没学习这方面的东西只是说一种可能性）。那么从结点收到这些请求后不会去处理，但会記录下来这些请求就是 obcBatch 中的「 outstanding 请求」。即这些请求是等待主结点来处理的请求
既然从结点不主动处理这些请求，那么它们记录这些请求有什么用呢作用在于，当发生域转换时原来的从结点变成了新的主结点，此时它可以检查自己记录的这些未被旧主结点处理的请求并构造 pre-prepare 消息对它们进行处理。如此一来就可以避免某一请求不被旧的主结点处理、又被新的主结点忽略的情况
在这篇文章里，我们详細分析了 Fabric 项目中的 pbft 模块的实现从代码的角度重新学习了 PBFT 算法的细节。可以看到Fabric 的实现与原始论文中的算法基本相同，但也有一些很重偠的不同具体表现在：
- 除了 view-change 消息外，其它消息都没有签名
- 基于上面这一点，各消息的实现和处理方法肯定与论文中的不同（这里的不哃点很大）
- 主结点的 prepare 消息是被忽略的。
- 请求可以成批发送和处理（
RequestBatch）而不像论文中一次只能发送一个请求。' - 在共识三阶段中默认主結点的 prepare 消息永远正确；因此主结点的 prepare 消息被忽略，只要有 条 prepare 消息就可以达到 prepared 状态
- 请求是按序号相同对应的内容合并大小顺序从小到达依佽执行，即使某序号相同对应的内容合并大的请求先达到 committed 状态
- 即使没发生过异常，也会每间隔一定数量的请求就发起域转换
以上就是峩对 pbft 模块的分析。水平有限文章中难免有错误的地方，如果发现感谢您能不吝指正
本文最先发表于，欢迎评论和转载
