技术摘要：
本发明提供一种水线高度更改设置方法，其特征在于，记录得到第i次视图转换时的第一数值及第i 1次视图转换时的第二数值，所述i为正整数；由第i 1次视图转换后的主共识节点根据所述视图转换时记录的第一数值、第二数值及预设规则计算新的水线高度，并将所述新的水线高度  全部
背景技术：
在实用性拜占庭容错PBFT(Practical  Byzantine  FaultTolerance)的共识过程 中，客户端向共识系统不断地推送新请求，经过共识系统的共识过程，不断地有请求被共识 节点执行，例如上链的操作，在客户端接收到一定数量的一致性结果之后，该请求即通过共 识系统完成了一个共识周期。在共识过程中，共识节点需要储存共识过程的状态信息的历 史记录，当共识节点执行完请求之后，为了节省存储空间，需要把之前记录的与请求相关的 状态信息历史记录清除掉。然而，单个共识节点并不能在自己执行完或不执行请求的操作 之后，直接删除相关状态信息的历史记录，这是因为此时该共识节点的共识集合(Quorum) 与其他共识节点的共识集合并不保证具有一致性，而一致性是实用性拜占庭容错达成共识 的必要条件。如果由于缺乏一致性而回退到准备阶段，例如在视图转换过程中，要求VIEW- CHANGE消息携带尚未达成一致的请求的准备阶段信息，假设上一个视图中请求的准备阶段 信息在视图变换前被共识节点当作历史记录直接删除，则VIEW-CHANGE消息不能携带准确 和完整的请求的准备阶段信息，造成了在视图变换的时候出现系统错误。因此，在设计实用 性拜占庭容错的共识系统时，制定了相应的规则来确保能够安全地清除已经执行完成的请 求的状态信息。 理论上，当共识节点执行完一条请求之后，可以通过例如以下方式删除该请求的 状态信息，例如，该共识节点向其他共识节点征求是否达成共识的消息，即是否能够形成一 定数量的一致性执行结果，如果形成了一致性的执行结果，即可以删除该请求的相关信息。 然而，如果采用这种方式，那么在共识节点每执行完一个请求之后，都要进行一次广播，并 且每个执行完请求的共识节点都会发送同样的广播，同时每个共识节点还要接收其他共识 节点的广播消息，以确认在本共识节点上，是否就该请求达成了一致性共识，从而进一步可 以删除该请求的状态信息。可见，这种方式每执行一条请求，就在共识系统内发送广播和接 收广播，非常消耗通信资源，占用了共识过程的大量时间。 因此，在设计实用性拜占庭容错的时候，一种普遍的方法是，共识节点连续执行了 N个请求，并且在共识节点执行完第N个请求之后，向其他共识节点进行广播，通知其他共识 节点已经就N个请求达成一致性结果，并且等待接收其他共识节点的广播，或者，在接收其 他共识节点广播之后，核实是否自己已经就N个请求接收了一致性结果，并已经执行完毕。 通过以上过程，如果共识系统的一定数量的共识节点针对N个请求的执行结果，达到一致性 的要求，那么就可以在相应的共识节点上删除N个请求的状态信息。综上，在每执行完N个请 求之后，在共识系统中进行广播的操作，被称为发送检查点CHECKPOINT消息，而在收到一定 数量共识节点同样广播的消息后，就表示该N个请求已经被一定数量的共识节点执行完毕， 获得了一定数量共识节点的共识，此时形成了一个稳定CHECKPOINT(STABLE  CHECKPOINT)。 4 CN 111586168 A 说　明　书 2/14 页 在实际的共识过程中，假设某个共识节点执行完了N个请求，并且向共识系统内发 出CHECKPOINT消息的广播，然而，此时其他共识节点并没有同样执行完N个请求，因此，没有 执行完N个请求的其他共识节点不能及时地发送自己的CHECKPOINT消息的广播，导致已经 执行完N个请求的共识节点不能确定是否能够获得一定数量共识节点的共识，从而不能删 除N个请求的状态信息。同时，已经执行完N个请求的主共识节点将继续分配接下来的请求， 或者已经执行完N个请求的副本共识节点将继续接收接下来的请求，这会导致已经执行完N 个请求的主共识节点不受限制地分配大量的请求编号，或者导致已经执行完N个请求的副 本共识节点远超出其他副本共识节点的请求编号，甚至发送多个CHECKPOINT消息的广播， 积压和阻塞了大量的共识进程。 在实际操作中，为了避免以上情况，设定了水线(WATERMARK)的概念，分别有以下 三个参数：低水线L、水线高度K、高水线H。通常地，低水线L设定为最近的稳定CHECKPOINT的 请求编号；水线高度K是在低水线的基础上，可以允许上浮的请求数量，一般为经验值，根据 目前相关文献公开的情况，在相关文献中通常选取100、或200、或400等数值；高水线H＝L K，即高水线H为低水线L与水线高度K的和。采用这种方式，为请求编号的分配以及请求的执 行数量设定了一个数值区间，保证请求分配的编号以及请求的执行数量处于有限的范围。 当主共识节点为接收的请求分配编号的时候，如果即将分配的编号大于高水线H，则暂停分 配编号，等待稳定CHECKPOINT和低水线L的更新，更新之后重新开始分配编号；当副本共识 节点按编号顺序执行请求时，如果即将执行的请求编号大于高水线H，则暂停执行请求，等 待稳定CHECKPOINT和低水线L的更新，更新之后重新开始执行请求。 综上可知，为了节约存储空间，实用性拜占庭容错采取了基于固定水线高度K的删 除状态信息或控制共识过程的工作模式，然而，固定的水线高度并不利于共识系统高效地 运行，主要将导致以下几个问题。 一是将会受到网络环境的影响。不同的网络环境使得各个共识节点的发送或接收 信息的速度不一样，有些时候共识节点的发送或接收信息的速度快，有些时候速度慢，如果 采用固定水线高度，那么在速度快的网络环境下，共识节点原本应该大量实施共识过程并 大量执行请求，但由于固定的水线高度，网络速度更快的共识节点不得不停下来，等待其他 网络速度慢的共识节点完成操作，造成这些共识节点的空转，反过来，由于网络速度慢的共 识节点等待接收的消息时间更长，同样导致了网络速度快的共识节点长期处于等待的状 态，浪费了宝贵的处理时间。 二是将会受到机器性能的影响。共识节点往往是高性能计算机，随着时间的推移， 这些共识节点更换机器的时机可能并不同步，往往一部分共识节点先更换了机器，另一部 分共识节点没有更换，而不同批次的计算机处理速度和性能不一样，如果一部分共识节点 的处理速度比其他共识节点更快，那么这部分共识节点将会更快到达高水线，等待其他共 识节点处理完毕的时间就会更长，浪费了宝贵的处理时间。 三是将会受到硬件更新的影响。根据经验，硬件更新换代的速度要超过软件，因 此，在硬件速度或性能不断提升的情况下，软件的各项设置或者功能相对较为稳定，即软件 更新周期将比硬件更新周期更长，这造成了原先设置的水线高度K并不适用于硬件性能已 经整体提高的情况，例如当机器处理速度和性能出现了倍增，而水线高度K仍然维持在慢速 条件下设置的数值，在这种情况下，共识节点处理的请求将很快达到高水线，可能造成部分 5 CN 111586168 A 说　明　书 3/14 页 共识节点频繁中断共识过程，不利于共识系统顺畅地工作。
技术实现要素：
为了解决