技术指南|软硬件协同一致算法设计——以fastbft为例

阅读指南

我们知道，与公链相比，联盟链中使用的拜占庭容错（BFT）算法可以有效提高区块链的交易处理能力。然而，传统的BFT算法，如pbft[1]，需要保证系统中的节点总数至少为3F+1，才能容忍f个拜占庭错误节点。相比之下，raft[2]等共识算法可以容忍f个停机错误（CFT），只需要2F+1个节点就可以正常工作。所以我们不禁要想，能不能让一个拜占庭系统只需要总共2F+1个节点就能抵御拜占庭攻击？

幸运的是，这种方法是存在的。在可信硬件的帮助下，我们可以消除拜占庭节点的模糊性，因此只需要2F+1节点就可以有效地防止拜占庭攻击[3]。

本文以fastbft[4]为例，介绍了fastbft如何借助可信硬件实现比传统BFT算法更好的性能。

受信任的硬件

fastbft算法中使用的可信硬件是intelsgx（softwareguard extensions）[5]，它是继Intel第六代CPU之后的一组扩展指令集。目前，许多个人计算机和服务器都可以支持SGX相关功能。在SGX编程模中，程序分为可信代码和非可信代码。SGX确保enclave中运行的代码和数据不会被其他程序（包括操作系统和虚拟机监视器）访问和篡改。此外，通过enclave写入磁盘的数据将被加密，只有enclave可以读取。不可信代码只能调用Enclave提供的有限可信函数接口来改变Enclave的内部状态，获取Enclave的内部信息。

因此，fastbft的代码也分为两部分，如下图所示：

技术指南|软硬件协同一致算法设计——以fastbft为例

其中，fastbft不可信代码负责一致消息的发送和接收以及一致状态的转换。Fastbft enclave码负责密钥生成、加解密、安全通道建立和一致状态变量维护。

节点类

与pbft算法类似，fastbft算法可分为主节点和从节点。不同的是，fastbft算法进一步将从节点分为f个主动节点和f个被动节点。传统的fastbft算法只需要F+1个活动节点（包括主节点）参与一致消息的发送和接收。被动节点只需要处理来自主节点的回复消息就可以更新自己的状态。只有当错误发生时，这些f被动节点才需要参与协商一致过程。

可信变量和函数接口

在fastbft中，每个节点的飞地都有自己的公钥-私钥对，并记录其他节点的公钥。此外，每个节点需要维护和持久化以下变量：counter值C、view值V、active node list和session key。其中，C和V是一致性相关的状态变量。只有当系统处于视野变化时，V值才会增加。当系统平稳运行时，C将继续增加。

Fastbft enclave提供以下受信任的功能接口：be primary、update view、preprocessing、request counter、verify counter、update counter和reset counter

▲主视图、更新视图功能

beprimary是节点成为主节点后需要调用的enclave方法。它的功能是重置C，更新活动节点列表，并用活动节点重新生成会话密钥。

update View是在接收到主节点被选中的消息后，更新从节点的enclave状态的一种方法。该方法接受的参数包括主节点的C和V以及加密的会话密钥。确认主节点选择的消息是可信的后，从节点调用enclave View方法的更新，重置enclave的C和V，获取与主节点通信的会话密钥。

这两个函数是fastbft视图更改过程中需要调用的方法。本文篇幅有限，不作讨论。

▲预处理、请求计数器并验证计数器功能

预处理是主节点需要调用的一种方法，以实现有效的消息聚合和飞地间的秘密共享。Enclave首先通过哈希函数将C、V与随机生成的原始密钥s绑定，并将承诺记录为H，然后通过基于XOR的密钥共享方案，将原始密钥随机划分为F+1子密钥Si，通过XOR操作恢复。**，它返回到主节点h、C和V，以及只能由相应从节点的enclave解密的加密节点。此外，为了避免每次消息聚合前的密钥共享，调用此方法后，将批量生成从C+1到C+m的m组消息。随后的m一致消息不再需要该方法。

请求计数器是主节点在启动建议消息之前需要调用的方法。该方法接受传入的参数X。Enclave首先将C+1相加，然后对该对进行签名并返回签名。有了这个签名，你就可以绑定到X。

验证 Counter是活动节点从主节点接收到prepare消息和commit消息后需要调用的方法。该方法传入的参数包括主节点包体签名生成的参数和主节点包体预处理方法生成的参数。来自节点的enclave需要保证签名中的C和V与解密得到的C和V一致，C比本地C大1，验证后enclave local C+1返回Si，H，通过这种方法，活动节点的C与主节点的C同步，返回的Si使主节点能够恢复原始密钥s，H使活动节点能够确认原始密钥s的真实性。

以上三个功能都是fastbft的常规过程所需要的，这对于读者理解fastbft算法尤为重要。

▲更新计数器和重置计数器功能

updateCounter是被动节点从主节点收到应答消息后调用的方法。它更新被动节点enclave的C值。

resetCounter是一种方法，需要在节点关闭并重新启动后调用，然后再重新加入一致网络。它的功能是接收来自不同飞地的F+1一致的C、V、状态信息，并同步本地飞地的C和V。

fastbft算法的程序流程

fastbft算法的常规过程分为五个阶段：预处理、请求、准备、提交和回复。整个过程如下：

技术指南|软硬件协同一致算法设计——以fastbft为例1

在预处理阶段，主节点通过调用enclave的预处理方法获取密钥共享消息。然后将这些密钥共享消息发送到每个活动节点。

当主节点收到来自客户端的请求时，它将进入请求阶段。此时，主节点需要调用enclave的请求，counter方法获得请求enclave的签名C+1和V，然后将请求和enclave签名作为prepare消息的内容发送给活动节点。

当活动节点从主节点接收到prepare消息时，它进入提交阶段。此时，活动节点将验证主节点enclave的签名以及从处理阶段获得的相应密钥共享消息，计数器方法通知enclave。在飞地验证通过后，主动节点将子密钥Si和H通知给主动节点，然后主动节点将Si发送回主节点。在主节点从活动节点收集F+1子密钥Si后，可以重构原始密钥s。之后，主节点可以执行请求并再次调用enclave的请求uuCounter方法，以获得res、C+1和V的签名，即enclave执行请求的结果。然后，将消息作为提交消息的内容发送到活动节点。

当活动节点从主节点接收到提交消息时，它进入应答阶段。此时，主动节点通过将散列值与enclave返回的散列值H进行比较来判断主节点是否成功地恢复了原始密钥。然后，主动节点还执行请求，以判断执行结果是否与主节点的一致。然后调用verifyCounter方法，获取C+1对应的子密钥Si’和原密钥的绑定H’，并将Si’发送回主节点。在主节点从活动节点收集F+1子密钥Si’后，它可以重构原始密钥s’。然后将请求、res、s、s’以及密钥共享信息和来自enclave的前两个签名作为回复消息的内容发送给客户端和被动节点。被动节点接收到回复消息后，首先验证消息的真实性。验证完成后，调用Update of enclave两次，counter方法更新enclave中的C和V值。

快BFT在哪

从以上过程可以看出，fastbft算法的“快”主要体现在以下几个方面：通过可信硬件减少系统中的节点总数；通过轻量级密钥共享方案实现高效的消息聚合；通过划分主动节点减少与被动节点的通信和被动节点。

首先，我们看到在fastbft算法中，只需要2F+1个节点。更少的节点意味着更快的响应时间。在正常过程中，主节点只需要发送F+1消息和接收F+1消息即可进入下一阶段。在pbft和其他算法中，节点需要广播3F+1消息并接收至少2F+1消息才能进入下一阶段。

其次，在pbft等经典算法中，从节点从主节点接收到prepare消息后，需要向所有节点广播prepare消息，消息总数为O（n^2）。在传统的fastbft过程中，所有从节点只需向主节点发送子密钥，消息总数为O（n）。这大大减轻了互联网的压力。

此外，在hotstuff[6]等一致性算法中，消息聚合是通过基于椭圆曲线的聚合签名来实现的。然而，基于椭圆曲线的聚合签名速度慢，影响了协商的效率。Fastbft采用基于XOR的密钥共享方案，只需f个XOR操作即可完成消息聚合，大大提高了协商的效率。值得注意的是，fastbft之所以能够使用如此简单的方法来完成消息聚合，是因为它支持可信硬件。由于密钥分割是在enclave内部进行的，拜占庭节点无法获得原始密钥和子密钥，也不能对其进行篡改。只有这样才能保证消息聚合的安全性。

**，将节点分为主动节点和被动节点后，被动节点只需要接收回复消息来更新其一致性状态，不需要发送任何消息。这进一步降低了网络带宽的消耗和系统的运行成本。

摘要

作为一种基于软硬件协同设计的一致性算法，fastbft向我们展示了如何利用可信硬件突破传统一致性算法理论的局限性。可见，基于可信硬件的fastbft大大降低了系统的部署成本，显著提高了协商一致的效率。

如果您对本文或区块链算法感兴趣，欢迎您加入交流群，加入小助理橙色微信：18458407117。

**套餐

fastbft的正确性

由于完整的fastbft算法还涉及到异常的进程视图变化，这超出了本文的研究范围，因此本文仅对fastbft的安全性做一个简单的论证，以便读者了解一般情况。

首先，我们可以发现每一对只能绑定一条信息。这是因为每当主节点在counter方法之后调用enclave的request时，enclave中记录的C将增加1。此外，一旦视图发生更改，enclave会将V添加到1。这样可以确保同一对不会被重复使用。因此，有效地防止了拜占庭节点向不同的节点发送不同的建议消息，消除了拜占庭节点的模糊性。

其次，在正常过程中，C每次增加1，enclave的verifythe counter方法还将确定C是否比前一个C大1，这进一步限制了一致消息的顺序。

第三，我们可以看到，在fastbft中，提案需要两轮类似pbft的广播才能达成共识。与pbft的区别在于fastbft的仲裁是F+1，pbft是2F+1。由于所有的共识信息都包含在飞地中，拜占庭节点不能随意构造虚假信息。Fastbft的视图更改流程可以确保即使只有F+1视图更改消息，也可以恢复一致建议请求，从而确保请求将被执行。

然后，所有正确的节点将以相同的顺序执行相同的建议请求。

fastbft的其他优化

除了上述优化之外，fastbft还引入了广播树来减轻主节点的通信压力。如下图所示：

技术指南|软硬件协同一致算法设计——以fastbft为例2