今天，我将概述一个新的算法基础，称为“ Hot-Stuff the Linear，Optimal-Resilience，One-Message BFT Devil ”（简称Hot-Stuff），与我的同事Ittai Abraham 和 Guy Gueta共同开发，以及它解释了Casper the Friendly Finality Gadget的安全性和活力。

关键的收获是：

我们为拜占庭容错 （或 BFT）提供了很好的基础，但在竞技场中实际上却发生了令人难以置信的创新。
乍一看，区块链时代的BFT协议，例如 Tendermint， Casper the Friendly GHOST和 Casper the Friendly Finality Gadget，与DLS， PBFT 等经典解决方案有着截然不同的“感觉” 。特别是，这些协议中的新提议者提出了一个命题而没有明确的安全证明。这是传统BFT解决方案复杂性的主要来源，显然威胁社区之外的人们。然而，我们最近能够阐明一个名为Hot-Stuff的统一基础，它可以捕捉这两个世界。
Hot-Stuff可以用来推理Casper，给出一个简单的安全论据，并表达严谨的生活条件。
Hot-Stuff包含一个可插入的“beacon”抽象，一个触发提议的机制和策略。特别地，我们描述了一种实现，其使用旋转提议器，其实现了比先前已知的BFT解决方案更好的通信复杂性。

在以后的文章中，我将讨论终端小工具与他们最终确定的PoW链的安全性之间的相互作用。

区块链和BFT

区块链是具有3层架构的 状态机复制（SMR）引擎。该基础是一个共识核心，它对共享状态的不可变更新序列形成协议。这被称为 拜占庭容错 问题或BFT。在比特币的共识算法，中本聪共识，解决了BFT为 permissionless 设置，与参会的未知宇宙的行为是不可信的。

在BFT之上是一个层，它指定用于更新的状态机API。比特币的状态机和状态更新使用有限的脚本语言; 以太坊使用图灵完全抽象（其资源有界）扩展状态机和状态更新。

顶层代表比特币中的应用程序，它是数字资产的共享起源跟踪，而在以太坊中，可以是分散的任何东西。

BFT问题模型

BFT解决方案的经典设置是n = 3f + 1个副本的许可集合，其中2f + 1的阈值被假定为根据规范行为而不是失败。这些被称为正确的副本。其他f复制品称为拜占庭。许可模型与设置比特币区块链以解决共识问题的设置完全不同，其中参与者是未知的，并且他们在没有明确许可的情况下被接纳（因此他们被称为无权限）。参与取决于工作证明（PoW）。从基础的角度来看，这两个模型非常接近，既解决了弹性阈值的共识，拜占庭复制品数量的许可模型，拜占庭矿工累积计算能力的PoW模型。

BFT问题定义的关键要素是关于通信延迟的 部分同步模型。这个假设值得关注：

同步模型假定传输延迟的已知上限。实际上，对于这种在大规模分散系统中的假设，界限必须非常高。在每个步骤上等待这个限制提供了最坏情况的上限，但它也确定了（悲观的）下限。
另一方面，如果传输延迟没有已知的界限，那么理论上算法可能会继续进入对抗性调度，这将阻止它收敛（参见着名的 FLP 不可能性结果）。

1988年，在DLS 中给出了一种美妙的解决方案方法，它在这两个极端之间实现了实际的路径。DLS保证即使在异步期间也不会损害安全性。在同步期间保证进步。这种解决方案非常强大。首先，它允许以网络速度进步，而不是以锁步悲观方式进行。其次，它允许设置非常保守的同步边界，这使得部分同步假设是现实的。

尽管不同步，安全性是另一个关键方面，其中许可BFT模型的解决方案与无许可方案中的解决方案不同。PoW模型本质上是同步的，因此在异步攻击下可能会失去安全性。出于同样的原因，如上所述，诸如Nakamoto Consensus的同步设置中的解决方案固有地遭受高延迟。

重温BFT

重新审视BFT有多种原因：

无限的区块链。

在无权限的环境中，人们正在寻找利用BFT来缓解中本共识的各种不足的方法。开发了几种“混合”方案，将PoW链与BFT相结合，以提高吞吐量，减少最终的延迟，并促进公平性。 Byzcoin， Bitcoin-NG和 Hybrid Consensus 使用无权限链来确定可重构BFT引擎中的参与者/提议者轮换。 Solida / Solidus 是一种 无链接 BFT协议，在无权限的设置中使用PoW生成命题和旋转成员。 Thunderella 是一个BFT引擎，它使用一个无权链来从故障中恢复。 Casper the Friendly Finality Gadget 和 Casper the Friendly GHOST 使用BFT引擎作为无权链上的最终权威。

许可的区块链。

人们重新燃起了对传统BFT解决方案的兴趣，以获得许可/“联盟”设置。他们重新审视了经典基础，例如 PBFT 和 BFT-SMaRt，以及发明针对性能，公平性和隐私问题的新许可解决方案，例如 Tendermint， Honey Badger和 Algorand。

从PBFT到Hot-Stuff到Casper

BFT文献明确谈到了轮次和信息; 相反，我们将逐级查看一系列命题，如下所示：

上图显示，在链的每个级别，可能存在一个或多个命题。因为我们处于拜占庭模型中，所以冲突的命题既代表了错误的提议者的情况，也代表了同时竞争的提议者的情况。从安全的角度来看，这些情况之间确实没有区别，算法必须保持安全，防止冲突的命题。只有活着才需要（最终）一个无争议的领导者（或命题）。

在 PBFT中，在每个级别，提议者试图在“准备”和“提交”两个阶段中获得“锁定”的唯一值。首先，提议者试图获得2f + 1准备。一组2f + 1签名的准备被称为'提交证书'。在第二阶段，副本提交到提交证书。如果2f + 1个副本提交到证书，则它将成为已提交的决策。

在下一个级别，该级别的提议者也试图做出决定。提议者需要选择一个分支来扩展。例如，在上面描述的场景中，如果X1 在级别1达到决策，则级别2提议者必须选择扩展X“分支”。

在PBFT中，新的提议者从2f + 1个副本收集提交证书。集合中最高的提交证书是一个可扩展的安全分支。提议者发送一组2f + 1提交证书作为 安全证明 以及新命题。副本只有在携带此类证据时才接受来自新提议者的命题。

在我们的示例中，由于2f + 1个副本已提交 X1，因此级别2的仲裁将与X1 在至少一个正确副本中提交的仲裁相交。因此，第二个提议者必须选择分支' X'。

与良性SMR的线性解决方案（例如，Paxos 和 Raft）相比，具有签名的PBFT二次（全部）交换提交投票具有一定的不良声誉，因为其成本高且不切实际。另外，新的提议者证明每个提议者替换会产生O（n 3）的通信成本。即使系统是同步的，f级联的故障也可能导致提议者替换和四次通信成本O（n 4）。

为了完整起见，让我简单提一下PBFT建议的两类改进。第一个由PBFT作者在 PBFT，ACM TOCS版本中介绍。它用带有双向验证器的向量替换消息上的签名。有利有弊：双向验证器的计算和验证速度要快得多，但协议复杂化，并且通信复杂度增加了n倍。第二个是一系列作品，它们引入了 乐观快速的 决策轨道。这可能比看起来更棘手。我们最近在ArXiv的一篇关于重新审视最先进解决方案中的快速PBFT安全性和活跃性问题的说明中出现过。我们建立了一个名为SBFT的系统正确实现快速决策跟踪。SBFT大大改善了PBFT的性能和扩展。在随附的ArXiv说明中，我们提供了关于Thelma，Velma和Zelma 乐观快速BFT协议的基本指南。所有这些改进都优化了良好的条件，但他们的提议者替换协议仍然与PBFT相同。

Hot-Stuff“伪代码”

整个Hot-Stuff协议是单消息交换。Hot-Stuff框架明确地分离了一个抽象的进度机制，称为“信标”，允许不同的可插入实现：

信标功能：

propose: ( level, commit-certificate, new command )

通常，信标必须广播两个连续级别的独特命题，这些命题不会与最高级别的现有提交证书冲突。

副本功能：

vote: ( level, commit-certificate, new command )

副本功能与之前相同，只是将一个级别的准备与前一级别的（可选）提交合并。和以前一样，如果复制品与它们持有的最高级别提交证书冲突，则它会拒绝该命题。

完整的细节描述在Hot-Stuff的ArXiv 手稿中。完整的手稿详细阐述了信标功能的几种可能实现：硬件时钟，提议器旋转和PoW。

卡斯帕

我们首先将Casper视为纯粹的BFT引擎，但通过将参与者称为“验证者”而不是复制品来暗示其预期用例。介绍了Hot-Stuff后，我们可以通过一步完善来描述Casper BFT协议。它的要点很简单。Casper 将负责将提交证书从信标功能推送到验证器之间的点对点传播。

更具体地说，每个验证器签署其投票并将其直接发送给验证器的随机子集。验证者将他们随机收到的投票转发一段时间。这种八卦式传播策略很可能保证所有验证者都能在合理的时间范围内收集提交证书。

一旦副本获得提交证书，它就会在下一级别的投票中引用它。下图描绘了Casper，并突出了与Hot-Stuff的不同之处：

从提议者角色中删除责任以收集和分发提交证书是Casper解决的设置所固有的，如下所述。

这种变化是安全的，复制品确实可以在他们之间传播投票。它是实时的，但就像Hot-Stuff和PBFT一样，进步取决于某些同步性。在Hot-Stuff中，提议者（偶尔）需要从前一级别收集提交证书才能取得进展。在Casper中，提议者不会收集或传播提交证书。相反，提议者必须（偶尔）等待足够长的时间让验证者在他们之间分配投票并获得提交证书以取得进展。这要求提议者（偶尔）延迟最坏情况下的传播限制。回想一下我上面所说的：依赖同步提供最坏情况的上限，但设置（悲观）下限。

如上所述，完整的Hot-Stuff解决方案通过应用阈值加密技术实现了通信复杂性的因素n改进。这种改进依赖于提议者的积极参与。

卡斯珀终极引擎

Buterin在一篇名为Minimal Slashing Conditions的文章中给出了最终引擎的动机。在PoW链中，没有明确的块决策。当一个块被深埋在链条中时，将链条分叉到块的深度以下变得更加困难。因此，块的“终结性”程度与其深度成比例。终结引擎的想法是在任意深度的块上提供BFT引擎的伴随决策。BFT引擎提供的保证不受块的深度的影响。

从技术上讲，Casper和PoW链之间的相互作用如下。Casper是一种BFT机制，旨在与PoW一起作为“信标”。公共PoW链为 BFT引擎提供建议，引擎在单链上形成协议。为了使其工作，终结引擎不需要对公共链进行任何格式或内容的更改。这已在上面说明，只需用辅助源替换内部提议者。如上所述，“信标”功能的这种实现是安全的。

为了提供进步，产生BFT引擎命令的PoW链必须满足信标活跃度条件。Casper规定PoW链保持以下三个条件，共同保证信标的活跃度：

1. 首先，命题需要从最高级别的提交块扩展分支，因为最终引擎的决策是不可逆转的。
2. 其次，产生命题的来源必须（偶尔）留出时间让验证者在命题之间传播投票和收集提交证书。

在（短）' X'分支上形成提交证书。通过对此提交证书进行投票来“捕获”一个正确的验证器。在这种情况下，Casper诫命禁止该验证者参与Y“分支机构的投票”。因此，PoW链必须扩展' X'分支，否则，Casper可能会卡住。

最后，从最后一次承诺中获取最长的链是不够的，这可能是很自然的预期。PoW链必须扩展包含具有最高级别的提交证书的分支。（参见右边这种情况的说明。）

在上述三个条件下，卡斯帕提供了活力。

结语

当我们开始探索像Tendermint和Casper这样的新波BFT协议时，它们似乎与传统的BFT协议（如DLS和PBFT）截然不同。我希望Hot-Stuff提供了一个有用的算法框架来讨论这两个世界。

HotStuff和Casper