一文读懂Alaya共识方案（五）：Giskard共识协议机制

验证人替换机制

Giskard共识协议中，每250个区块（称为一个Epoch）就会更新验证人集合，更新规则如下：

新验证人可能由于网络连接或区块不同步等原因不能参与共识，因此我们每次替换不超过8个节点，如果候选验证人不足8个，替换的数量为候选验证人的总数。

使用VRF从候选验证人中随机选出新验证人。

容错恢复（WAL）机制

Giskard共识协议提供了容错恢复机制，也就是WAL模块。该模块不属于严格意义上的预写日志系统，但是借鉴了相关思想，在验证人共识过程中将还未落链区块的共识状态和当前View的共识消息从内存分别持久化到本地数据库和本地文件。在系统crash或者机器掉电重启之后通过磁盘日志数据迅速恢复共识状态。

这里简要介绍一下主要的原理：

区块、viewChange在各验证人间达成共识需要经历验证、投票等阶段，某个区块最终落链前与该区块相关的共识状态、消息都记录在内存中。节点重启也只是需要恢复这部分还未落链区块的内存数据，因此checkpoint恢复点也就是当前blockchain的currentBlock。

链式投票可得，每一区块的投票都是对前一区块的确认，达到第三级，即达到区块的Commit阶段，因此3-chain区块的prepareQC状态在共识中至关重要，必须保证在重启后恢复，这部分数据存储至db。

共识消息只保留最近一轮view相关的，这部分数据存储至文件。

区块同步机制

由于Giskard共识协议的异步并行性，导致最新的区块存储在内存中，并且区块高度有3种高度：最高逻辑区块高度、最高确认区块高度和写入磁盘区块高度，并且三种高度依次递减。因此Giskard中的区块同步机制也在已有的Alaya-P2P的基础上作了适配，调整了区块高度的获取方式。这里概要介绍区块同步机制如下：

新加入节点通过Alaya-P2P利用快速同步或全同步更新至主网高度

共识节点利用Giskard-P2P的心跳机制与其它节点保持块高一致

共识节点区块落后时，会主动减少通信量，全力处理区块同步

同步机制使用BLS签名来减少网络同步消息量

（未完待续）