【论文分享.01】Scalable Byzantine Fault Tolerance via Partial Decentralization-CSDN博客

本文链接：https://blog.csdn.net/weixin_43911869/article/details/131538746

【论文分享.01】Scalable Byzantine Fault Tolerance via Partial Decentralization

$\quad$ 该论文由弗吉尼亚理工大学发表在VLDB 2022上，作者是Balaji Arun和Binoy Ravindran。
$\quad$ 论文链接：https://www.vldb.org/pvldb/vol15/p1739-arun.pdf

$\quad$ 摘要：该工作研究拜占庭环境下共识算法扩展性问题。提出DQBFT多主共识范式（Paradigm），以解决现有共识协议三个主要的性能和扩展性方面的挑战：地理分布式共识时的高通讯开销；共识过程中节点间不均衡的资源利用率；在节点状态和网络波动情况下的性能降低。采用的策略是将共识解耦合为“消息复制”和“全局消息排序”两部分。另外，采用可信硬件降低共识时的Quorum size，采用门限签名降低通讯复杂度。综合所有设计策略，设计了Destiny共识协议。在300个地理分布式节点部署环境下，设计的协议获得了接近3倍的吞吐提升，50%的延时降低。

1. DQBFT多主共识范式

$\quad$ 大部分确定性拜占庭共识协议采用primary-backup共识模式：由primary向backups有序广播复制客户端提交的请求，backups对请求投票，若干轮投票后，该请求在节点间达成一致，之后节点提交执行。此种模式存在诸多弊端：primary压力大，易成为瓶颈；backups资源未充分利用；客户端请求都需要转发给primary，在geo-distributed环境下，延时高；单点故障。
$\quad$ 为解决上述问题，出现了多主共识模式（multi-primary），多个节点担任primary，每个primary都向其他节点广播复制自己收到的客户端请求，节点也对每个primary广播的请求投票（一个primary对应一个共识instance），所有instance完成之后统一打包提交执行。但受节点实际运行状态和网络波动影响，运行慢的instance会影响其他运行快的instance（不是直接影响，而是慢的instance未完成，快的instance运行完成后也无法提交执行），最终导致性能降低。

$\quad$ 针对上述这些问题，作者将消息复制和全局排序解耦合：

$\quad$ $\quad$ $\quad$ $\quad$ $\quad$ $\quad$ $\quad$ $\quad$
$\quad$ $\quad$ $\quad$ $\quad$ $\quad$ 在这里插入图片描述

$\quad$ D-instance负责对消息进行可靠广播，同时存在多个；O-instance负责对D-instance广播的消息排序，每时只有一个。
$\quad$ 每个节点都可作为D-instance的primary向其他节点广播复制消息，其他节点投票，若干轮投票后，实现消息的可靠广播。
$\quad$ 之后，O-instance的primary会将可靠广播之后的消息打包排序广播出去，其他节点投票，最终实现所有D-instance消息排序。
$\quad$ D-instance和O-instance可采用现有拜占庭共识协议实现，e.g. PBFT。
在这里插入图片描述

$\quad$ 本质上，该工作也是采用多主共识模式，只不过就是在多个instance之后加了一个排序instance，排序instance可以根据D-instance实际运行情况进行排序，不受D-instance运行快慢影响，显得更灵活。
$\quad$ 但另一方面，先D-instance，后O-instance，不可避免延时会升高。针对这个问题，设计了Optimistic和Pessimistic Ordering模式：
$\quad$ 在Optimistic Ordering模式下，O-instance的primary收到D-instance primary广播的消息之后，不等D-instance完成就对其打包排序（打包的是序号，不是原始消息），实现D-instance和O-instance 并行运行。如果D-instance失败，通过view-change对D-instance进行恢复，之后再去提交，这种情况会使Optimistic Ordering模式等同于现有的多主共识工作，O-instance的优势体现不出来。
于是，如果Optimistic Ordering模式下频繁发生O-instance完成排序，但最终D-instance没有完成的情况，则回退到Pessimistic Ordering模式，即D-instance和O-instance串行进行。

2. Destiny（基于可信执行环境和门限签名的DQBFT范式实例）

$\quad$ TEE：可信执行环境（Trusted Execution Environment，TEE）是一种具有运算和储存功能，能提供安全性和完整性保护的独立处理环境，独立于操作系统，其内容受到保护，不能被本身以外的任何进程存取，包括以更高权限级别运行的进程，TEE是可信的。

$\quad$ 若基于PBFT实例化DQBFT，PBFT高通讯复杂度、不易扩展的特点使得DQBFT的扩展性不能充分发挥。
$\quad$ 针对这个问题，本文借鉴Hybster，采用可信执行环境优化共识过程。本文假设每个replica有一个trusted subsystem，trusted subsystem只会宕机，不会作恶。trusted subsystem内部可以进行密码学操作（哈希，签名）。共识过程中，trusted subsystem负责投票过程，trusted subsystem不会作恶，共识算法也因此从BFT优化到CFT。Quorum size从2f+1降低到了f+1，投票轮次从PBFT的三轮降低到了两轮。

$\quad$ 门限签名：一种分布式多方签名协议，包含有分布式密钥生成，签名和验签算法。
$\quad$ 分布式密钥生成：基于安全参数构造一种分布式密钥生成协议 DKG，协议运行输出一个共同的公钥 pk 和分属不同参与方各自所有的私钥份额 ski，聚集起满足阈值数量的私钥份额可以构建出真正的私钥 sk。
$\quad$ 门限签名与验签：基于分布式通信网络，各参与方通过自己的私钥份额 ski 完成对消息 m 的分布式协作签署并输出最终的可验证签名 Sig(sk, m)，这个签名跟单独用 sk 私钥签出的一模一样，可以用所基于的基础签名机制里的验证函数进行本地验证，无需走通信交互验证。【https://blog.csdn.net/jingzi123456789/article/details/105711613】

$\quad$ 为进一步提升算法的扩展性，本文利用门限签名优化投票过程，将复杂度从O（N2）降低到O（N），N为节点个数。
$\quad$ 为保证唯一性和单调性，对每个消息签名时，都附加一个单调递增的counter值，这种方式也避免了rollback attack。流程如下图所示。
$\quad$ $\quad$ 在这里插入图片描述

实验
$\quad$ 实验实现了一些已有工作的single-primary和multi-primary共识算法，并和本文设计的算法进行了对比。实验主要回答以下问题：

Batch对算法性能的影响
geo-distributed部署下节点从数十到数百个扩展时的性能
副本失败对性能的影响
DQBFT协议相比于其他multi-primary的性能表现

实验配置与参数设置：

SGX-enabled virtual machines (VMs) available on Microsoft’s Azure platform
VMs from ten different datacenter regions: six in North America, three in Europe, and one in South East Asia
Each VM consists of 8 vCPUs and 32GB of memory
The network latencies between regions are in【https://learn.microsoft.com/en-us/azure/networking/azure-network-latency】
The bandwidth between replicas ranged from 400 Mb/s (between US and Asia) and 6 Gb/s (within same region).
The workload is 100% put operations with 20-byte keys and random values. The command payload size is 512 bytes. Unless otherwise stated, each batch contains 200 commands producing a proposal size of ≈106kB. The size of other protocol messages are around 100B for DQPBFT and 300B for Destiny.

1） Batch对算法性能的影响

$\quad$ $\quad$ $\quad$ $\quad$ $\quad$ $\quad$ $\quad$ $\quad$ $\quad$ 在这里插入图片描述

$\quad$ 由于Multi-primary的并行性，Multi-primary相比于single-primary有数倍性能提升，另外消息复制和共识的解耦合，使得系统性能不会收到慢的instance的影响，Destiny表现出了较好的性能。Chain-hotstuff由于并行性受到限制，其性能相比于其他算法较差。

2） geo-distributed部署下节点从数十到数百个扩展时的性能

$\quad$ $\quad$ $\quad$ $\quad$ $\quad$ $\quad$ $\quad$ $\quad$ $\quad$ $\quad$ 在这里插入图片描述

$\quad$ 得益于可信硬件的应用，quorum size降低，门限签名也降低了投票过程的消息复杂度，使得Destiny具有较好的扩展性。SBFT同样采用了门限签名，另外由于fast-path，同样具有较好的性能表现。Chain-hotstuff具有良好的扩展性，性能不会随着节点数量增加显著降低，但是由于受到不能并发的限制，导致其性能较差。

3）副本失败对性能的影响

$\quad$ $\quad$ $\quad$ $\quad$ $\quad$ $\quad$ $\quad$ $\quad$ $\quad$ $\quad$ $\quad$ 在这里插入图片描述
$\quad$ 得益于消息复制和共识的解耦合设计，Destiny相比于RCC，MirBFT等Multi-primary算法，排序过程不会受到消息分发过程的影响，失败D-instance不会影响其他正常运行D-instance。

4） DQBFT协议相比于其他multi-primary的性能表现

$\quad$ $\quad$ $\quad$ $\quad$ $\quad$ $\quad$ $\quad$ $\quad$ $\quad$ $\quad$ $\quad$ 在这里插入图片描述
$\quad$ 该实验中，在（a）点，除一个节点外，为其他每个节点增加一倍的负载，负载增加的节点，会导致这些节点单轮延时增加，但不会影响吞吐。另一方面，单轮延时的增加，降低了低负载节点instance的吞吐。