（邹均）LibraBFT共识协议：三难问题平衡术

作者: 大圣2017 | 来源:发表于2019-07-26 15:34 被阅读0次

2019-07-04 运通链邹均 LibraBFT共识协议：三难问题平衡术(1)
2019-07-05 运通链邹均 LibraBFT共识协议：三难问题平衡术(2)
2019-07-08 运通链邹均 LibraBFT共识协议：三难问题平衡术(3)
2019-07-09 运通链邹均 LibraBFT共识协议：三难问题平衡术(4)

参考阅读：

2019.07.10 上交所技术公司朱立对Basic HotStuff 证明的完善
论文：https://tedyin.com/archive/hotstuff-podc2019.pdf 作者主页上的PODC2019论文
论文：https://arxiv.org/pdf/1803.05069.pdf 作者发表在arxiv上的V5版本

Libra平台的技术核心点有两个，一个是智能合约编程语言MOVE，另一个是共识算法LibraBFT。本文将从Libra共识协议、PBFT共识协议、HotStuff共识协议、LibraBFT共识协议及结论五个部分对LibraBFT做一个详细的评述，整篇文章将分为以下4篇连载文章进行发布：

连载文章

连载(1): Libra共识协议介绍
连载(2): PBFT共识协议回顾
连载(3): HotStuff共识协议介绍
连载(4): libraBFT共识协议及结论

连载(1): Libra共识协议介绍

LibraBFT 共识协议的基本设计思想是一个许可链（Permissioned Chain），最初会由Libra基金会授权的成员节点参与共识流程。
LibraBFT协议是**基于一个改进的BFT协议HotStuff【1, 2】。
HotStuff 是一个有Leader的在半同步网络假设下的拜占庭容错协议。

HotStuff有两个重要的特点，

一个是linearity，指的是通信的复杂程度和节点数成线性关系；
另一个是responsiveness，指的是当网络通信成为同步的时候，HotStuff能产生正确的Leader来推动协议在网络延迟的实际值内而非最大值达到共识。

基于这种特性，HotStuff适合于构建大规模的状态复制服务。因此，不难看出，Libra从众多的区块链共识算法中挑选HotStuff，看中的是HotStuff的效率、线性的扩展性，以及拜占庭容错的安全性。这也体现了天秤座的平衡术 – 在去中心、安全、扩展性这个棘手的区块链三难问题上，巧妙的选择一个平衡点。

在LibraBFT 的技术白皮书中【3】，作者们强调LibraBFT对HotSTuff的改进在于引进明确的活性（Liveness）机制，同时提供一个更实际的延迟分析。白皮书的作者们总结LibraBFT共识算法，认为它具有以下属性：

Safety（正确性）: LibraBFT 在诚实的验证节点之间保持一致性，即使不超过1/3之一的验证节点是作恶节点。
Asynchrony（异步）: 一致性能在异步网络（异步的定义是没有限制的延迟或网络故障）中仍能保持一致。作者认为构建大规模共识网络，如果依赖于同步网络，那么将会非常复杂和有易受拒绝服务攻击的硬伤。
Finality（最终性）: LibraBFT 支持最终性的概念，也就是交易不可逆的被确认。
Linearity and Responsiveness（线性和响应性）: LibraBFT 有两个在HotStuff协议之前所有的BFT共识协议没有的属性。这两个概念和Leaders关联，这是在部分同步网络中推进共识的重要方法。非正式的说，线性保证即使在Leader轮换的时候交易的确认的复杂度与共识节点数呈线性关系。响应性意味着Leader没有内部延迟步骤，当它收集到其他验证节点的响应时会马上进入下一步。
Simplicity（简易性）和 Modularity（模块化）: LibraBFT核心逻辑允许简单和扎实的实现。

光从字面语义来分析，笔者认为LIbraBFT白皮书中提到的Asynchrony(异步)属性的说法不正确。

首先，根据FLP定律【4】，不可能存在一个确定性的共识算法，在异步通信并存在至少有一个故障进程的情况下，网络在保证活性的同时还能保证正确性。
其次，LibraBFT所基于的HotStuff，也只是在半同步通信环境中才能保证达成共识。

当然也许作者可以争辩在不考虑活性(Liveness)的情况下，说LibraBFT具有Asynchrony属性也没错，但实际上而后的LIbraBFT协议技术细节全是讨论如何在半同步环境中同时保证活性（Liveness）和正确性（Safety）。

有鉴于此，我们不能对Libra白皮书的结论照单全收，有必要对libraBFT的技术白皮书以及HotStuff相关文献进行一个全面的分析，最后来看哪些结论是正确的，哪些有待商榷。

严格说来，LibraBFT是基于HotStuff的一个变种，叫链式HotStuff（Chained HotStuff）。链式HotStuff是在基本HotStuff（Basic HotStuff）上引入流水线概念，进一步提升效率的一个改进共识协议。HotStuff在原先诸多的BFT共识协议中提升了效率，降低了复杂度。

为了让大家更好的理解HotStuff如何提升效率和复杂性，我们有必要对BFT的基础共识协议PBFT做一个回顾。因此本文下节将介绍PBFT，第三节将介绍HotStuff，第四节将回到libraBFT，最后是我们的分析结论。

连载(2): PBFT共识协议回顾

原始的拜占庭容错系统[5]由于需要展示其理论上的可行性而缺乏实用性，另外需要额外的时钟同步机制支持，算法的复杂度也是随节点增加而指数级增加。Castro and Liskov在1999年提出实用拜占庭容错系统（Practical Byzantine Fault Tolerance，PBFT）[6]，降低了拜占庭协议的运行复杂度，从指数级别降低到多项式级别（Polynomial），使拜占庭协议在分布式系统中应用成为可能。

PBFT是一类状态机拜占庭系统，要求整个系统共同维护一个状态，所有节点采取的行动一致。为此，需要运行三类基本协议，包括一致性协议、检查点协议和视图更换协议。

2.1 PBFT一致性协议

一致性协议要求来自客户端的请求在每个服务节点上都按照一个确定的顺序执行。这个协议把服务器节点分为两类：主节点和从节点，其中主节点仅一个。在协议中，主节点负责将客户端的请求排序，从节点按照主节点提供的顺序执行请求。每个服务器节点在同样的配置信息下工作，该配置信息被称为视图（view），主节点更换，视图也随之变化。

一致性协议至少包含五个阶段：请求(request)、序号分配(pre-prepare)、相互交互(prepare) 、序号确认(commit)和响应(reply)等阶段。

PBFT 的一致性协议正常流程如图1所示。PBFT系统通常假定故障节点数有f个，而整个服务节点数为3f + 1个。每一个客户端的请求需要经过5个阶段，通过采用两次两两交互的方式在服务器达成一致之后再执行客户端的请求。由于客户端不能从服务器端获得任何服务器运行状态的信息， PBFT中主节点是否发生错误只能由服务器监测。如果服务器在一段时间内都不能完成客户端的请求，则会触发视图更换协议。

图2-1：PBFT正常流程

图2-1显示了一个简化的PBFT的协议通信模式，其中C为客户端，N0~N3表示服务节点，N0为主节点， “X”表示N3为故障节点。虚线是各阶段边界，箭头表示消息从消息源节点发送到接收节点。整个协议的基本过程如下：

Request请求阶段：客户端发送请给主节点，请求消息m=[op, ts, c-id, c-sig], 其中包含需要执行的操作op, 时间戳ts, cs-id是客户端ID，以及客户端签名 c-sig。时间戳是为了保证命令只被执行一次，客户端的签名是为了客户认证和权限控制。
Pre-Prepare (序号分配)阶段：当主节点接收请求后，主节点给请求赋值一个序列号sn，广播序号分配消息和客户端的请求消息m，并将构造PRE-PREPARE消息[PP, vn, sn, D(m), p-sig, m]给各从节点，其中PP表示Pre-Prepare消息，vn是视图号，D(m) 是客户消息的摘要（哈希值），p-sig是主节点的签名，m是客户消息。序列号是为了保证命令执行的顺序，视图号让从节点记录当前视图。主节点签名是为了让从节点认证主节点身份。消息摘要保证消息没有被篡改。
Prepare(交互)阶段：从节点接收PRE-PREPARE消息，向其他服务节点广播PREPARE消息[P, vn, sn, D(m), b-id, b-sig]，其中P表示Prepare消息，b-id是从节点id，b-sig是从节点签名。
Commit（序号确认）阶段：从节点在收到2f + 1个Prepare消息后，对视图内的请求和次序进行验证，广播COMMIT消息[C, vn, sn, D(m), b-id, b-sig]，其中C表示Commit消息。执行收到的客户端的请求并给客户端以响应
Response（响应）阶段：（1）当各节点收到2f + 1个COMMIT消息后，它将执行操作，并提交。同时把回复返回给客户端。回复消息是[R, vn, ts, b-sig], 其中R表示回复消息。（2）客户端等待来自不同节点的响应，若有f + 1个响应相同，则该响应即为运算的结果。

PBFT能在异步环境下，容忍不足三分之一的总数节点是拜占庭节点，并能够达成共识。表面看起来这和FLP定理的不可能共识结论相违背，但其实如果我们检查其假设条件，可以看到PBFT的异步通信环境假设和FLP的异步通信假设不一样。PBFT中有超时机制，而FLP中假设没有超时机制。在超时机制下，PBFT能够保证safety和liveness。另外在PBFT中，消息的发送者是经过认证的，发送消息的身份可以被确定，节点有没有发消息也可以验证。

2.2 检查点协议

PBFT依赖每个节点在日志中保持每一条消息，只有当它确认请求被f+1个节点执行并收到证据后，它才能删除与请求相关的消息。这也就是如何确定命令执行的最终性（Finality）。如果在每个命令执行后来提供证据，这样开销会很高而效率会很低。因此PBFT提供一个检查点协议（Checkpoint），在请求序号能被某个常数（例如100）整除的时候设立检查点，交易的最终状态在该点被确认。

当一个节点产生检查点，它把<CheckPoint, n, d, i>消息加上签名广播给其它节点，其中n是状态序号，d是状态的哈希，i是节点号。当每个节点收到2f+1个相同状态序号的Checkpoint消息后，该状态将被最终确认。每个节点可以把CheckPoint前的消息从日志中删掉。检查点协议也用来推进低水位标志和高水位标志，低水位和高水位用来限制哪些消息能被接收。低水位标志等于最后的稳定的检查点序号，高水位标志可定于一个合适数字，例如如何每一百个请求做Checkpoint，那么高水位可以定在200。

2.3 视图转换协议

视图转换协议保证共识协议的活性（liveness）。当主节点出故障时能保证共识能继续进行。每个备份节点收到一个请求是都会开始一个定时器。如果在一个视图内，时钟超时，该备份节点会发起一个视图转换的消息。它将广播一个<view-change, v+1, n, C, P, i>加上签名的消息给各节点。其中n是当前节点i所知道的上个稳定检查点状态s的序号，C是一个集合，里面有2f+1个检查点证明s是正确消息，然后P是一个Pm的集合，Pm里面有每个从i节点中大于n的请求消息m的pre-prepare, 和2f个匹配的被各节点签名的prepare消息。

当v+1视图的主节点收到其它2f个节点的正确的view-change消息后，它将广播<new-view, v+1, V, O>加上签名的消息给所有节点。其中V是主节点收到的view-change消息，加上它自己发的view-change消息，O是一个pre-prepare的消息集合。O是为每个在从低水位标志到高水位标志之间序号n建立的新的pre-prepare的消息。这样新的主节点可以继续的推进共识。

在这里，我们可以看到，PBFT的视图转换协议是非常复杂的，涉及到很多消息的重传。HotStuff的最重要的改进，主要是针对视图更换的协议。

连载(3): HotStuff共识协议介绍

HotStuff的基本假设是系统有固定的节点数n = 3f+1，其中f是系统能容忍的最大拜占庭节点数。系统通信是点对点的认证和可靠通信。网络通信的假设是半同步，也就是说，网络有一个知道的延迟D，以及一个不知道的全网稳定时间（Global Stabilization Time，简称GST），当GST过后，任意两个节点之间的通信都将在D时间内完成。HotStuff能总保证正确性（safety），在GST后的消息时延在一定限度（D）内能保证活性（liveness）。

HotStuff采用门限签名机制【7】，门限设置是（k, n）。n个节点中所有的节点共用一个公钥，但每一个节点有自己的私钥。每个节点用自己的私钥签名消息m，叫部分签名消息，多个节点的部分签名消息可以用来生成一个联合签名消息，当至少有k = 2f+1个节点提供部分签名消息时，其它任何一个节点能用公钥验证该联合签名消息。其中f是系统能容忍的拜占庭节点总数，n = 3f+1。

HotStuff【1, 2】论文中提出一个“认证复杂度”的概念。认证复杂度简单来说，统计协议交互时通信的认证消息数，也就是部分签名或联合签名消息的个数。以这个角度出发，HotStuff作者们对一些BFT协议作了分析，把主要BFT协议的通信认证复杂度列出如表3-1：

表3-1：BFT协议认证复杂度对比

从表3-1可看到，在正常情况下，PBFT的认证复杂度是O(n平方)，在视图更换时一般情况是O(n立方)，当视图更换时出现最坏情况，也就是连续f个Leader都出故障时，PBFT的认证复杂度是O(n四次方)。而HotStuff则是O(n)线性复杂度。即使在有f个leader出故障时，仍能保持O(fn)的线性认证复杂度。

在HotStuff中，每个视图有一个所有共识节点都知道的唯一的Leader，视图的序号是递增的。每个共识节点保存有一个树形结构，该树形结构里的每一个node（简称图节点），保存有该共识节点接收到的命令请求，以及相应的元数据，还有指向父图节点的哈希指针。HotStuff协议的进程就是不断确认树形结构里的分支。

Leader在提议分支时，必须收到（n-f）个节点的投票才能确认该分支。这个（n-f）的投票叫法定节点数证书（quorum certificate，简称QC）。QC是与特定图节点以及视图序号相关联。

HotStuff协议分为基本HotStuff（Basic HotStuff）和链式HotStuff（Chained HotStuff）协议。我们下面分别介绍这两种协议。

3.1 基本HotStuff协议

我们先来看基本HotStuff（Basic HotStuff）的共识流程。图3-2是HotStuff的一个正常情况的流程。流程分为四阶段：prepare，pre-commit，commit和decide阶段。

图3-2：HotStuff 基本流程

Prepare阶段：首先一个新的Leader需要收集（n-f）个共识节点发出的new-view消息。共识节点在转到新的视图时，会发new-view消息，包含该节点所有的最高prepareQC。Leader处理这些收到的消息，在其中选择最高视图的prepareQC，称为highQC，它可以断定没有比这个更高的视图能达到确认状态。因此，在highQC图节点所在的分支状态是正确的（safe）。这个时候，Leader用createLeaf方法来在highQC.node的尾部延伸分支，建立一个新的图子节点，并嵌入指向父图子节点的哈希指针。然后向各节点发出prepare消息，包含highQC作为正确性的证明。当其它共识节点收到prepare消息后，每个共识节点用safeNode判断方法来判断是否接受它。在每个共识节点的本地树形结构中，有自己的一个锁定图节点（lockedNode）。它首先判断接收到的新的图子节点是否是从锁定图节点后延伸的，另外就是接收到的视图号码是否比锁定图节点的视图号要高。如果两者都满足，该共识节点将接受提议，并返回给主节点一个投票，并用自己的私钥给投票消息签名。
Pre-commit 阶段：当Leader接收到（n-f）个prepare vote 投票消息后，他会把投票放进prepareQC, 然后Leader会广播包含prepareQC的pre-commit消息。副本会回复对pre-commit的投票消息pre-commit vote并将消息的摘要上签名。
Commit 阶段：该阶段和pre-commit阶段类似，当Leader 接收到（n-f）pre-commit vote投票消息后，它会将消息放进precommitQC, 然后Leader连同commit message广播给所有副本。特别重要的是，副本在收到precommitQC时把它的LockedQC置为precommitQC。这个对保证正确性至为重要。副本节点会返回commit vote签名消息给Leader。
Decide阶段：当Leader收到（n-f）个共识节点的commit vote消息后，它将这些消息联合起来放在commitQC中，然后广播给所有共识副本节点。副本节点收到commitQC后，会认定在commitQC中的命令进入确认状态，并开始执行确认分支中的命令。最后递增viewNumber，并开始下一个视图。

在以上阶段中，副本节点会有一个定时器，如果在一个视图中超时，将递增viewNumber，开启一个新的视图更换。

对比PBFT，可以看到，HotStuff的通信是由Leader主节点广播，副本节点之间并不广播消息，而是由副本节点直接回复给主节点，主节点利用门限签名把各副本节点的签名信息联合成一个签名信息，再在下个阶段作为证据发给所有副本节点。因此，HotStuff在消息往返里避免了副本之间的广播消息，在Leader不出故障情况下，把复杂度从PBFT的O(n平方)降低到O(n)。而最为重要的是，HotStuff将视图转换融入正常流程，大大简化了视图转换的复杂度。在PBFT中，视图转换需要把从检查点以后的所有消息集合重传，认证消息复杂度升到O(n立方)，特别是在最坏情况下（f个Leader连续出故障），复杂度升到O(n四次方)。而HotStuff即使在最坏情况下，能始终保持线性复杂度。

3.2 链式HotStuff

在基本HotStuff中，Leader主节点需要三个阶段来确认一个请求提交。这些阶段都非常相似，除了收集其它副本节点的投票外，大部分没有做多少实际工作。

链式HotStuff （Chained HotStuff）提升基本HotStuff的效用并同时并大大简化其流程。方法是在每个Prepare阶段，都主动的转换视图。具体说来，在链式HotStuff，对Prepare阶段的投票，由下一个在prepareQC的视图的Leader来收集。同样，依此类推，pre-commit和commit阶段的投票也由与之相应的下一个视图的leader来收集。这样，新Leader在视图v+1的prepare提议阶段，同时作为视图v的pre-commit阶段。而新的Leader在视图v+2的prepare提议阶段，同时可以作为视图v+1的pre-commit阶段，以及视图v的commit阶段。因为所有阶段的数据结构都一样，因此可以用流水线的方式来提升共识的效率。图3-3展示了链式HotStuff的基于Basic HotStuff的流水线形式。

图3-3: 链式HotStuff_基础HotStuff流水线

视图 v1, v2, v3作为v1提交的命令cmd1的prepare，pre-commit和commit阶段。cmd1命令在v4里确认。视图v2,v3,v4作为v2提交的cmd2的三个基础HotStuff的阶段，cmd2在v5里得到确认。依此类推。

因此链式HotStuff中，只有两类型的消息，一种是new-view，一种是generic-phase的generic消息。genericQC实现所有不同阶段的功能。

链式HotStuff中，如果图节点b’中的QC直接对应父图节点b，这样形成了One-Chain; 如果在One-Chain的基础上，下一个图节点b‘’中的QC直接对应b’，这样就形成了Two-Chain，在这个基础上，下一个图节点b*中的QC直接对应b’’, 这样就形成了Three-Chain。图3-4显示视图v4，v5，v6形成了一个Three-Chain。

图3-4:Three-Chain示意图

如果图节点b*形成Three-Chain,那么图节点b的确认已完成。

3.3 PaceMaker

在HotStuff中，Pacemaker是用来保证共识流程的活性。

Pacemaker通过两方面来实现。

一方面是“同步”，也就是在一个足够长的时间内，把所有正确的副本节点和主节点的本地树结构更新到一致的高度。主节点的选择一般是从一个预先制定的表中轮流选出主节点。
Pacemaker的另一方面是主节点需要能选择让正确的副本节点接受的提议。HotStuff的new-view消息正是让主节点能选择正确的提议的方法。

连载(4): Libra共识协议及结论

Part 1：LibraBFT共识协议

4.1基本介绍

LibraBFT基本上基于链式HotStuff，其本身的创新点不多。libraBFT最初会选择一些在不同地理上分布的创始成员做共识节点，以后逐渐的，共识节点会对外开放，并基于libra稳定币的多少来选择共识节点，也就是转变成PoS机制。

libraBFT的共识流程是分为不同轮次（rounds），每一轮中一个Leader主节点被选出。主节点会提议一个区块，里面包括交易·。该区块将广播给其它共识节点。其它共识节点会验证区块里的交易，并对其投票。主节点收到大多数（超过2f+1，f是系统中能容忍的拜占庭节点数）节点的投票后，主节点把确认消息发给所有共识节点确认。如果主节点没收到大多数投票，或者主节点出现故障，副本共识节点的定时将超时，副本节点会发起新的一轮提议。

libraBFT在HotStuff基础上的改进主要在于提供一个详细的参与同步轮次的Pacemaker设计和实现。并提供对实际交易确认的活性分析。LibraBFT提供对共识节点投票权力的重配置机制。同时它给出了对提议节点和投票节点激励的机制。白皮书给出了如何检测投票节点破坏正确性的行为，为今后在协议中加入惩罚机制打下基础。同时白皮书也详细讨论如何做同步，使得投票节点能同步它们的状态。libraBFT白皮书采用Rust语言来描述协议。

libraBFT采用一个epoch的概念。每个命令执行状态包含一个epoch_id, 新的命令将有一个新的epoch。

4.2 共识协议和libra区块链的集成

图4-1展示的是libra共识协议和libra区块链的集成。

图4-1：libra共识协议和libra区块链的集成

其中SMR是libra的共识模块。命令发到SMR模块进行共识排序，最后的执行由Exec模块完成。Exec模块通过基于Move的智能合约引擎完成执行。每个给到智能合约引擎的命令都有一个执行时间，libra保证该时间在所有的执行同一命令的SMR节点上一致。

4.3 Libra客户端

客户端发的交易首先通过mempool（交易池）协议给共识节点共享。共识节点通过签名的确认证书来确认命令的执行状态。客户端需要知道共识节点的公钥来验证共识节点的确认证书。将来libra将提供一个安全的协议来让libra客户端获得共识节点的公钥。

4.4 Libra区块链结构

图4-2：libra的链式记录

LibraBFT节点的核心状态由一组记录组成。libraBFT有四种数据结构记录：

区块（blocks）：由主节点leader提议的区块，包括一个轮次序号和需要执行的命令。
投票（votes）：副本节点对区块和执行状态的投票。
法人节点数证书（quorum certificates, QCs）: 对区块和执行状态具有大多数（2f+1）节点的投票证书。
超时（timeouts）：节点用来验证本轮是否超时的值。

图4-2展示的是libra区块链的结构。每个区块后都有一个QC，记录了所有的正确副本节点的投票，QC中包含有被投票区块的哈希，每个区块中也有指向前个QC的哈希，如果是第一个区块，则会指向一个固定的初始哈希hinit。

4.5 Libra点对点通信

libra区块链在共识节点中构建一个点对点的overlay协议，主要有两个功能，一个是针对某个节点定向发送消息send，一个是在所有节点中进行广播broadcast。Libra白皮书没有详细描述其实现，估计和libP2P协议类似。

4.6 LibraBFT共识协议

LibraBFT共识协议和链式HotStuff类似。每个共识节点a(Alpha)在本地保持一个树形记录结构record_store(a)。树根是个初始化的作为QC的哈希值h_init。每个分支是一串记录，由区块B_i和QC C_i间隔链接。这个链接记录可以正式的表示成：h_init¬B₁¬ C_1…¬B_n¬C_n 。

图4-3展示了libra的共识流程。当一个节点作为主节点leader，它必须提议一个新的区块B_n+1，一般是在一个最长的链的QC尾部延伸。假设B_n+1被成功的广播，诚实的副本节点将验证区块里的命令，执行命令并发回一个投票给主节点。在没有执行错误的情况下，诚实的副本节点将对认同B_n+1执行后的状态。当收到足够（2f+1）的投票后，主节点将为该区块建立一个QC，并广播给所有的副本节点。这时链条将延伸到：h_init¬B₁¬C_1… ¬B_n+1¬C_n+1。在这个时候，主节点完成了本轮提议，下一轮提议将由新的一个主节点提交。

图 4-3：Libra共识协议流程

4.7 LibraBFT确认规则

libraBFT的交易确认规则遵从链式HotStuff的three-chain规则。也就是说，对区块B1的确认，必须满足B₁是一个连续轮次的3-chain的头，也就是说，需要有C₁，B₂，C₂，B₃，C₃存在，使得：B₁¬C₁¬B₂¬C₂¬B₃¬C₃，并且：round（B₃）= round（B₂）+ 1 = round（B₁）+2

当节点a(Alpha)看到这个情况，那么区块B₁以及之前的区块都将被确认。

Part 2：结论

我们在上面首先回顾了PBFT共识协议，然后详细介绍了HotStuff协议，HotStuff协议主要是在通信复杂度上比传统BFT协议有很大程度的降低，特别是在视图转换方面，提供了线性复杂度。这是其最大的卖点Linearity属性。另外HotStuff的协议设计是无论是不是出现主节点故障情况，每轮会更换主节点，而且主节点不用等待，只要收到超过2f+1的投票，可以立即广播QC并进入下一轮，因此也提供Responsiveness属性。这是有别于其它BFT共识协议的两大优势。基本HotStuff的改进版链式HotStuff引入流水线概念，把基本HotStuff的三阶段抽象成一个通用的阶段generic，进一步简化共识流程，提升共识效率。HotStuff的线性复杂度，为设计高扩展性的区块链提供了基础，同时也由于提供拜占庭容错机制，在安全方面也有一定保障。

libraBFT基于链式HotStuff，其确认规则遵从3-chain的确认规则。虽然libraBFT在HotStuff上没有多少创新，但有句话说的好：“选择比努力重要”，能在众多的共识协议中选择HotStuff，显示了libra团队的眼光，以及在区块链三难问题上巧妙的平衡术。libraBFT继承了HotStuff，使得它的共识协议具有正确性（safety）,在半同步网络下的活性（Liveness），最终性（Finality）；同时具有通信线性复杂度（linearity）和响应性（responsiveness）。Libra的实现也展示了简易性（simplicity）和模块化（modularity）的实现。同时也体现了sustainability（可持续性），不需要工作量证明以降低能耗。

Libra区块链的设计是基于许可的联盟链。目前的设计中包括了奖惩机制，同时他们也考虑未来使用可验证随机函数（Verifiable Random Function）来随机选择主节点，并隐蔽主节点以免受黑客的攻击。未来，它可以逐渐增加共识节点，走向PoS机制，逐渐向非许可的公链过渡，真正实现公平、普惠的天秤链。

（完结）原创作者：邹均