[翻译]HotStuff: the Consensus Protocol Behind Facebook’s LibraBFT

注：原文 2019.6.26年发布在medium上

最近，Facebook的加密货币项目Libra发布了白皮书，在Github上开源了测试网代码。在白皮书中，我们可以看到Libra使用了LibraBFT，一种拜占庭容错共识协议。因为这个协议来源于Hotstuff协议，因此学习后者可以帮助我们理解LibraBFT。

1、Hotstuff是什么？

Hotstuff是一种基于leader的拜占庭容错协议，由VMware实验室在2018年3月提出。该论文将发布在PODC 2019上。类似于许多共识协议，假设网络是一个可靠和安全的P2P网络，通讯模型采用部分同步模型，这意味着网络存在一个消息传输延迟上限。
本文，将简要介绍Hotstuff的工作原理，以及通过先介绍PBFT来逐渐说明Hotstuff如果打到目的。

2、PBFT是什么？

一般来说，共识协议用来在去中心化网络当中对系统状态达到共识，然后所有诚实的节点可以从一个状态转移到另一个状态。

一般来说，PBFT采用二阶段的P2P消息交换来实现这个目的。
当leader广播它提出的（合法的）状态变化请求给其他节点，一个系统里的诚实节点，首先需要知道有足够多的节点收到了这个请求，这样它可以确认这个请求是合法的。基于这一点，它还需要知道有足够多的节点也确认了这个请求是合法的，因此确认这是一个在足够多的节点间关于状态变化的共识。

当leader在运行协议过程中失败了，比如节点发现无法与leader节点通信，然后需要替换leader，这意味着需要修改view。这时，系统中的节点发出改变view的请求。当一个节点收到足够多的改变view的请求时，发出确认改变view的消息给新的leader。当新的leader收到足够多的确认改变view的消息时，新的view开始产生。

3、Basic HotStuff是什么？

我们相信HotStuff第一个也是最重要的改变是将PBFT的网状通信网络编程星型通信模型，这意味着每次通信只需要依赖leader。节点不再通过P2P网络将信息广播给其他节点，而是发送给leader，由leader处理并发送给其他节点。归功于星型网络模型，系统通信复杂度
大大下降。类似于PBFT，leader提出状态改变请求，其他节点接收到请求后校验请求合法性。

图1 网状网络模型到星型网络模型

HotStuff第二个重要的改变将改变view的过程合并到正常执行过程，这意味着不需要单独的改变view的过程，因此降低了改变view的复杂度。可以看到，在HotStuff里，在改变view过程中，节点不需要在通知新leader以前，确认消息“有足够多的节点想要改变view”，取而代之的是，直接切换到新的view，然后通知新的leader。Hotstuff将确认“有足够多的节点想要改变view”的消息放到正常执行中。这是一个新的方法，但是不可避免的导致对于正常处理过程引入一个新的新的确认阶段。因此，HotStuff扩展PBFT的二阶段到三阶段。
介绍完这两个改变，现在让我们看一下HotStuff的阶段。这个协议中，leader首先收集replica发出的新view的消息。当leader收集到足够多的新view的消息，它开始新的view，提出状态改变请求，然后发送prepare消息给其他节点。接收到prepare消息后，节点校验消息的合法心，然后通过一下三个阶段确认消息：

1. PRE-COMMIT阶段
   当leader接收到当前提案的prepare投票时，组合这些投票到prepare quorum certificate（qc）中，然后在放到precommit消息中，广播给其他节点，这意味着有足够多的节点确认这个状态改变请求。
2. COMMIT阶段
   当leader接收到当前提案的precommit投票时，组合这些投票到precommit quorum certificate（qc）中，然后在放到commit消息中，广播给其他节点。其他replica可以锁定当前状态改变请求，所以可以达到共识结论，即使在一次view改变过程中（？？）。
3. DECIDE阶段
   当leader接收到当前提案的commit投票时，组合这些投票到commit quorum certificate（qc）中，然后在放到decide消息中，广播给其他节点。收到decide消息后，replica可以在已提交分支上执行状态改变，并且开始新的view。
   
   图2 basic HotStuff

什么是门限签名？

为了进一步降低通信复杂度，HotStuff做的第三个改变是引入了一个新的密码学原语：门限签名。

假设在一个(k,n)的门限签名框架里，n个replica共同拥有一个公钥，每个replica拥有一部分的私钥（分片）。只要有k个replica对消息进行了签名，这k个签名就能构造出一个完整的签名，并且可以被公钥验证。

一般来说，完整的签名和replica的数量无关。Hotstuff使用门限签名来降低在共识协议中的签名个数。

我们可以看到在Hotstuff的三阶段确认中，投票就是replica的门限签名过程，然后发送给leader。leader收集到足够多个投票，就生成完整的签名。leader会将签名发到下一个阶段的消息里，发送给replica，并被校验签名。

图3 门限签名

HotStuff的流水线

可以看到Basic HotStuff的三个确认阶段都有相同的结构，节点对消息投票，leader聚合投票，并发送给其他节点。这些阶段可以用通用的方式标识并流水线化。这也是HotStuff的第四个改变，共识阶段的流水线化。

图4 流水线
pipelined HotStuff在Basic HotStuff上做了改进，在每次prepare阶段都改变view。事实上，我们可以看到下一个view的prepare对当前的view的prepare进行确认，就是下一个view的prepare消息里包含了当前view的prepare-commit消息。由于所有阶段的结构都是一致的，所以流水线化可以实现。

问题

1. 为什么需要增加一个阶段？
2. 流水线代码怎么实现？