【Libra 技术解读】详解LibraBFT共识机制

1. PREPARE阶段：该阶段，leader发起一个high的提案（highQC），组成消息，消息内容 m = MSG(PREPARE, curProposal,highQC)，并广播给所有的验证节点；验证节点在收到时上述提案消息后会进行投票，如果m的node超过本地已经判决过的node是则会投票，并返回消息给leader，m' = voteMSG(PREPARE，n.node，⊥)。

2. PRE-COMMIT阶段：该阶段，当Leader收到（n-f）个验证节点的PREPARE阶段的投票信息后，会发起一个 PREPARE的提案（prepareQC），组成消息，消息内容为 m = MSG(COMMIT, ⊥，prepareQC），并广播给所有的验证节点；验证节点在收到上述提案消息后会进行投票，并返回消息给leader，m' = voteMSG(PRE-COMMIT，m.justify.node，⊥)。

3. COMMIT阶段：该阶段，当Leader收到（n-f）个验证节点的PRE-COMMIT阶段的投票信息后，会发起一个 PRE-COMMIT的提案（precommitQC），组成消息，消息内容为 m = MSG(COMMIT, ⊥，precommitQC），并广播给所有的验证节点；验证节点在收到上述提案消息后会进行投票，并返回消息给leader，m' = voteMSG(COMMIT，m.justify.node，⊥)。

4. DECIDE阶段：该阶段，当Leader收到（n-f）个验证节点 COMMIT 的投票后，会生成一个COMMIT的提案（commitQC），组成消息，消息内容为 m = MSG(DECIDE，⊥，commitQC)，并广播给所有的验证者；验证者在收到该消息后，会执行命令，并返回给客户端。

5. FINALLY阶段：如果系统进入下一个View，各个副本会发送一个消息给下一个View的leader，消息内容为 m = MSG(NEW-VIEW，⊥，prepareQC)。

2.2.2 Chained HotStuff

上图中可以看出来Basic HotStuff的各个phase中的流程都非常相似，作者又提出了一种Chained HotStuff来优化和简化Basic HotStuff。改进的点主要是改变每个PREPARE节点的View。这将大大降低通信消息的数量，并且可以对决策进行管道处理。Chained HotStuff的流程如下所示：

上述Figure1可以看出一个节点可以同时处于不同的View，通过链式的结构，一个提案在经过3个块后能够达成共识。其内部有一个状态转换器，通过genericQC实现提案的自动切换。其主要算法流程如下所示：

3. LibraBft改进

Libra 为了更好地适应其生态，对HotStuff进行了相应的优化，主要有5点：

1.首要的是Libra定义了安全的条件，提供了安全性、活性和乐观响应的扩展证明；
2.第二点：Libra 通过让验证器集体对区块的状态而不是事务的顺序进行签名，使得协议会更加鲁棒。同时还允许客户端使用QC验证从数据库里读出的数据。
3.第三点：Libra 设计了一个Pacemaker 来发出显示的超时信号，验证者通过他发出的提案自动进入下一个视图，而不需要一个同步的时钟；
4.第四点：Libra 希望让矿工变得不可预测，它最新提交的区块信息为种子生成一个可验证的随机数VRF，成为下一个矿工；
5.第五点：Libra 使用聚合签名的方式保留QC中验证者的身份，以提高验签效率，同时为这些验证者提供奖励。

—-

编译者/作者：不详

玩币族申明：玩币族作为开放的资讯翻译/分享平台，所提供的所有资讯仅代表作者个人观点，与玩币族平台立场无关，且不构成任何投资理财建议。文章版权归原作者所有。