注：原文 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 音讯 后，节点校验音讯的非法心，而后通过一下三个阶段确认音讯：
- PRE-COMMIT 阶段
当 leader 接管到以后提案的 prepare 投票 时，组合这些投票到 prepare quorum certificate（qc） 中，而后在放到 precommit 音讯中，播送给其余节点，这意味着有足够多的节点确认这个状态扭转申请。 - COMMIT 阶段
当 leader 接管到以后提案的 precommit 投票 时，组合这些投票到 precommit quorum certificate（qc） 中，而后在放到 commit 音讯中，播送给其余节点。其余 replica 能够锁定以后状态扭转申请，所以能够达到共识论断，即便在一次 view 扭转过程中（？？）。 - 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 音讯。因为所有阶段的构造都是统一的，所以流水线化能够实现。
问题
- 为什么须要减少一个阶段？
- 流水线代码怎么实现？