【论文阅读】Latency performance modeling and analysis for hyperledger fabric blockchain network

hyperledger fabric 区块链网络的延迟性能建模和分析

摘要

区块链一直是许多现代甚至未来应用程序中最具吸引力的技术之一。 Fabric 是一个开源框架，用于实施许可的企业级区块链，越来越受到创新者的关注。延迟性能对于 Fabric 区块链评估其有效性至关重要。进行了许多实证研究来分析基于不同硬件平台的性能。这些实验结果没有可比性，因为它们高度依赖于底层网络。此外，关于 Fabric 区块链延迟的理论分析仍然很少受到关注。本文提供了一种新颖的理论模型来计算区块大小、区块间隔等各种网络配置下的交易延迟。随后，我们通过实验验证了所提出的延迟模型，结果表明分析结果与实验结果之间的差异是低至 6.1%。我们还确定了一些性能瓶颈，并从开发人员的角度给出了见解。

1. 介绍

区块链已被视为一种新兴技术，可以提高许多应用程序的透明度、信任度和安全性，例如信息系统（Baniata、Anaqreh 和 Kertesz，2021 年；Berdik、Otoum、Schmidt、Porter 和 Jararweh，n.d.）、互联网事物（Chen、Srivastava、Parizi、Aloqaily 和 Al Ridhawi，2020；Sun 等人，2020b；Zhao、Chen、Liu、Baker 和 Zhang，2020）和医疗保健系统（Zheng、Xie、Dai、Chen 和 Wang , 2018).区块链本质上是一个分布式账本，它可以在不依赖中央中介的情况下确保数据完整性（Dinh 等人，2018 年）。区块链主要可分为非许可型和许可型（Zheng, Xie, Dai, Chen, & Wang, 2017）。在比特币（Nakamoto 等人，2008 年）和以太坊（Wood 等人，2014 年）等无许可（或公共）区块链中，每个人都可以在没有任何特定身份的情况下参与共识过程。许可区块链强制执行严格的成员资格，以便只有经过身份验证的节点才能验证交易并创建区块。此外，这些许可区块链可以进一步分为联盟链和私有链（Lao et al，2020；私有区块链由单个组织控制，而联盟区块链位于公共和私有区块链之间。此外，公共区块链中使用的典型共识机制是工作量证明（PoW），它是计算密集型和非确定性的。相比之下，大多数许可区块链采用确定性共识机制，可以轻松地在经过身份验证的用户之间达成快速共识。因此，许可区块链非常适合需要以确定性方式处理大量交易的企业应用程序。

1.1.动机

尽管许可区块链已经显示出上述好处，但是将许可区块链与企业应用相结合仍然面临一个关键挑战，即延迟问题。智能交通系统、智能工业和电子医疗服务等大多数应用程序都对延迟高度敏感。因此，交易延迟是区块链系统的一个重要指标，它会对任务的 QoS 产生重大影响。然而，许可区块链当前的延迟性能与这些对延迟敏感的企业应用程序不兼容（Nguyen、Jourjon、Potop-Butucaru 和 Thai，2019）。

已做出巨大努力来研究许可区块链的延迟问题（Nasir、Qasse、Abu Talib 和 Nassif，2018 年；Pongnumkul、Siripanpornchana 和 Thajchayapong，2017 年；Thakkar、Nathan 和 Viswanathan，2018 年；Wang、Ye 和 Xu , 2019).他们中的大多数通过使用各种系统配置下的经验测量来分析延迟性能。然而，由于越来越多的配置选项和未知的约束条件，这些经验分析的成本太高，无法获得准确的结果。此外，部署许可区块链的底层网络对分析结果影响很大，因此这些结果没有可比性，缺乏通用性。必须进行理论延迟分析以提供定量模型。有了它，开发人员可以做出配置决策，以保证对延迟敏感的应用程序的延迟 QoS。

1.2.研究贡献

在本文中，我们开发了一个专注于 Fabric 区块链的延迟分析模型，Fabric 区块链是由 Linux 基金会托管的企业级开源许可区块链平台。我们论文中定义的交易延迟是从提交交易提案到将此交易提交到账本中所花费的时间。本文的主要贡献如下： • 我们将事务延迟分解为三个阶段，每个阶段涉及多个子步骤以进行细粒度分析。在每个阶段，我们指出可能影响交易延迟的配置参数。

• 我们提出了一个分析模型来计算具有单通道和多通道的Fabric 区块链中的平均交易延迟。此外，我们对 Fabric 区块链中两种典型的共识机制，即 Solo 和 PBFT 共识进行了定量延迟分析。

• 我们进行了一系列实验来评估所提出的分析模型的有效性，结果表明我们的模型预测实验结果的误差小于6.1%。

• 我们根据分析模型识别性能瓶颈，并为Fabric 区块链部署提供可行的见解。

1.3.本文结构

本文结构如下。在第 2 节中，我们简要概述了 Fabric 区块链，包括其架构、关键组件和交易流程。在第 3 节中，我们介绍了 Fabric 区块链的分析延迟模型。在第 4 节中，我们介绍了基于我们的测试平台的实验，以验证我们的理论模型并给出一些关键见解。我们在第 5 节中描述了相关工作，并在第 6 节中总结了本文。
图 1. 涉及两个组织（组织 A、组织 B）的 Fabric 区块链示例。每个组织由三个同行组成：两个提交者和一个背书者。

2. Fabric区块链概述

Fabric是由Linux基金会托管的开源许可区块链系统，由peer、orderer、client等三种不同类型的节点组成。所有节点均由会员服务提供商 (MSP) 标识，并由不同的组织拥有。此外，Fabric 区块链引入了一种新颖的架构，其中包括三阶段执行-订单-验证交易流程。图 1 显示了具有两个组织的典型 Fabric 区块链网络示例。客户端向背书策略指定的对等方发送交易提议。然后，这些节点通过调用预先安装的链代码来执行交易提议。执行后，客户端汇集足够的背书结果并向排序服务提交交易，排序服务中排序者使用可插拔的共识机制为所有交易生成总订单并产生区块。之后，使用八卦协议将块广播给所有对等方。每个对等点最终验证块内的交易并更新分类帐状态。

2.1.关键概念节点

Fabric 区块链由一组节点组成，这些节点承担三个角色之一，即客户端、对等方或排序方。客户端用于提交交易。 Peer 以哈希链的形式维护区块链分类帐，并使用键值存储记录当前状态。有两种类型的同行，背书者和提交者。 Endorser 负责执行链码来为交易提案背书。提交者只是通过验证和提交交易来更新账本状态。 Orderer 使用可插入的共识机制实现排序服务，以生成所有交易的总序列并将它们分批放入块中。

链码。智能合约是指Fabric区块链中的chaincode，用Go、Java等编程语言编写，实现应用逻辑。 Fabric 区块链中应用程序链码的两个示例分别是用于背书交易建议的背书系统链码 (ESCC) 和用于验证交易的验证系统链码 (VSCC)。

背书政策。背书策略指定了一组需要背书交易提案的节点。仅当交易已根据背书策略得到指定节点的适当背书时，交易才被标记为有效。它由集合上的单调逻辑表达式构成，如“AND”、“OR”。

账本。在 Fabric 中，账本由两部分组成：世界状态和区块链。世界状态是一个数据库，以版本化键值存储的形式保存最新的分类帐状态。区块链账本由所有节点共同维护，是一种只追加的数据结构，用哈希链记录所有的交易。

渠道。通道是由特定网络成员集合形成的逻辑结构。每个通道都允许一组同行创建一个完全独立的分类账。在 Fabric 中，希望私下进行业务交易的组织子集可以生成一个通道，从而维护一个分区分类帐。一个组织可以出于不同的目的同时加入多个频道。

2.2.交易流程

在 Fabric 区块链中，每个成功提交的交易都遵循三个阶段。首先，交易提案被执行和背书。其次，这些交易通过共识机制在排序服务中进行排序。最后，所有节点进行交易验证，防止并发冲突。接下来，我们详细介绍这三个阶段。

执行阶段。客户将交易建议发送给一组背书者以供执行。如图 2 所示，以客户身份签名的交易提议被发送到背书策略指定的一个或多个节点。每个背书人执行交易使用预安装的链代码以读取集 (RS) 和写入集 (WS) 的形式生成背书。然后，背书人以加密方式签署背书，并在提案响应中将其发回给客户。客户端从背书人那里收集到足够多的背书，并检查背书的一致性。

订购阶段。客户端产生交易并将它们广播到排序服务。交易包含交易元数据、交易有效负载、一组背书和通道 ID。排序服务不检查交易内容，只是通过可插入的共识机制为每个通道的所有交易建立共识和总排序。然后，排序服务将排序的交易批量打包成块，并通过八卦协议将块传递给对等方。

验证阶段。所有节点，包括背书者和提交者，都从排序服务接收块并对其进行解码。然后，一个区块中的所有交易都经过验证系统链代码 (VSCC)。最后，将执行多版本并发控制 (MVCC) 验证。
图 2. 执行阶段。客户将交易提案提交给背书人，背书人使用预先安装的链代码执行交易提案。然后，将包括RS、WS和一个签名(Sign A或Sign B)的背书回复给客户端。

• VSCC 验证。 VSCC 验证对一个区块内的所有交易并行进行。它根据背书政策评估交易的背书。如果不满足背书策略，则该交易被标记为无效。

• MVCC 验证。 MVCC 也称为读写冲突检查，确保在执行阶段读取或写入的密钥版本与当前账本状态相同。此 MVCC 在块内的所有事务上按顺序实现。

如果版本不匹配，交易将被标记为无效。当 MVCC 和 VSCC 验证完成时，所有对等点提交块并将它们附加到本地存储的分类帐中。同时，写入有效交易集中的所有键值对都用于更新账本状态。

3. 延迟性能建模

在本节中，我们介绍了 Fabric 区块链的理论延迟分析。我们首先介绍了我们分析中使用的系统模型，然后提出了完全按照执行-订单-验证交易流程的单通道 Fabric 的详细延迟计算。最后，将讨论多通道 Fabric 的延迟分析。

3.1.系统模型

将充分考虑具有 Solo 或 PBFT 共识机制的 Fabric 区块链系统。我们假设交易由 M 个客户端生成并在 Fabric 网络中广播。 Fabric 网络由 K 个组织组成，每个组织有 N 个节点。新交易的到达遵循泊松点过程，到达率为 λ。每笔交易的数据包大小为 α 比特，一个签名的大小为 γ 比特。每笔交易需要根据背书策略在Ne个背书者上执行，一次背书的包大小为β比特。

此外，我们定义区块链网络的瓶颈链路带宽为ℬbps，平均传播延迟为𝒟。所有节点的等候室都被认为是无限的。此外，节点被定义为在 FIFO 基础上为事务提供服务，而每个节点的服务时间服从均值为 μ 的指数分布。表 1 提供了本文中使用的符号摘要。

Fabric 区块链参数 λ 平均交易到达率 K 组织数量 M 客户端数量 N 每个组织中的节点数量 L 网络中的通道数量 Ne 执行每笔交易所需的背书者数量 α 数据包大小交易提议 β 一个背书包大小 γ 一个签名包大小 SB 默认块大小 𝒯 默认块间隔 物理网络参数 ℬ 瓶颈链路带宽资源 𝒟 平均传播延迟

3.2.单通道结构的延迟模型

在介绍了系统模型之后，我们介绍了单通道结构区块链的延迟分析。基于 executeorder-validate 事务流程，我们将总事务延迟分为三个部分：执行阶段的延迟、排序阶段的延迟和验证阶段的延迟。下面介绍如何计算每个阶段的事务延迟。

执行阶段的延迟：如图2所示，执行阶段分为三个步骤。

1. 所有客户将交易建议发送给相应的背书人。客户端发送具有 α 位的交易提案，交易提案的传输延迟为 α/ℬ + 𝒟。

2. 背书者通过链码执行交易提案。交易提议在背书者处的执行可以建模为 M/M/1 队列，具有指数间隔时间 1/(λα) 和指数服务时间，均值为 1 /μ。交易按到达顺序进行服务，背书者的流量强度可以通过以下方式获得
   因此，每个背书者的处理延迟 Tp 可以通过使用 Little 定律获得
   
   3.背书人向客户发送背书。执行完成后，背书者将具有β位的背书发送给客户端。传输延迟为 β/ℬ + 𝒟。

执行阶段 Te 的总延迟为

订购阶段的延迟：在收集到足够的背书后，客户端将交易提案与背书组合起来，并生成发送到订购阶段的交易。排序阶段也包括三个步骤，如图 3 所示。

1. 客户端将交易发送给排序服务。交易由交易建议书、Ne背书和一个客户签名组成。因此，此步骤中的传输延迟为 (α + Neβ + γ)/ℬ + 𝒟。

2. 排序服务为所有未决交易生成一个新区块。当排序服务接收到来自不同客户端的交易时，它会将待处理的交易安排到一个明确定义的序列中，并通过可插入的共识机制将它们分批放入块中。这里，我们主要考虑两种典型的共识机制，Solo 和 PBFT。 Solo和PBFT共识机制的延迟分析如下：

(1) Solo共识的延迟分析。

Solo 共识机制通常由开发人员使用仅由单个订购者组成的 Fabric 网络进行试验。
• 在 Solo 共识的排序服务中，当以下条件之一为真时，它会为待处理的交易创建一个块：织物系统。
• 一定量的时间，定义为块间隔𝒯，自上一个块以来已经过去。

因此，将在这两种情况下分别考虑 Solo 共识过程的延迟。

条件1：交易到达率λ小，导致区块区间𝒯内交易到达数N(𝒯)达不到默认区块大小SB。在这种情况下，当 𝒯 时间过去时，排序服务将所有未决交易分批放入一个新块中。这种情况的概率 P1 可以计算如下：
图 3. 订购阶段。 Client A、Client B 和 Client C 向排序服务提出交易（分别标记为 T1、T2 和 T3）。然后排序服务将它们分批放入具有总订单的块中。这个新块通过八卦协议发送给所有对等点。

这种情况下每笔交易的平均等待时间ta为：

条件 2：交易到达率 λ 足够大，在区块间隔 𝒯 内，交易数可以超过 SB。在这种情况下，当待处理交易的数量达到 SB 时，排序服务将 SB 待处理交易分批放入一个新块中。这种情况的概率是 P2 = 1 ¶ P1。

交易到达区间{T1, T2, …, TSB¶ 1}服从负指数分布，所以SB交易总等待时间Tsum为

每笔交易的平均等待时间为 tb = Tsum/SB。

结合这两个条件，平均等待时间Twait为

然后，交易将由排序服务进行批处理，排序服务也可以建模为 M/M/1 排队系统。根据 Litter 定律，总处理时间计算如下：

Solo 共识过程中的总延迟为

2）PBFT 共识的延迟分析

在具有 PBFT 共识的排序服务中，它运行一个三阶段协议来获得对一个块的共识。这些阶段包括准备阶段、准备阶段和提交阶段。在准备阶段，领导者将交易放在一起，并以未验证块的形式将它们广播到共识网络中的副本。当领导者收到一定数量的待处理交易（定义为默认块大小 SB）或自上一个块以来已经过去一定时间（定义为块间隔𝒯）时，领导者将块作为 PRE-PREPARE 消息转发. preprepare 阶段的延迟与 TSolo 相同。而领导者交付未验证区块所需的时间可以表示为 thop = b(α +Neβ +γ)/ℬ + 𝒟，其中 b = max{SB, λ𝒯 } 是交易数量这个未验证的块。

在准备阶段，每个副本在收到未验证的块后验证块内容。副本中的块验证也可以建模为 M/M/1 队列，具有指数间隔时间，平均值为 1/λj，指数服务时间平均值为 1/μj。事务按到达顺序服务，事务在副本上花费的总时间由下式给出

然后，副本将经过验证的块作为 PREPARE 消息发送给其他副本。同样，传递消息的时间仍然很短。最后，副本在收到 2f + 1 个与本地 PRE-PREPARE 消息匹配的 PREPARE 消息后，向所有其他副本发送 COMMIT 消息。同时，消息传递的时间延迟是 thop。因此，PBFT 共识机制 TPBFT 的总延迟计算为

3. 排序服务将新区块发送给所有节点。生成新块后，排序服务使用八卦协议将附加有其签名的块广播给所有对等方。该区块包含 b = max{SB, λ𝒯 } 交易，传输延迟为 b(α + Neβ + 2γ)/ℬ + 𝒟。

因此，排序阶段的总延迟是

验证阶段的延迟：每个节点独立验证一个块内的所有交易。该阶段的延迟包括 VSCC 验证和 MVCC 验证的处理延迟。验证阶段的总处理延迟 Tv 可以计算为 X。

3.3.多通道结构的延迟模型
在本节中，我们将讨论具有多通道的 Fabric 区块链中的延迟。在多通道 Fabric 网络中，通道可以由多个不同的排序服务托管，并且通道策略在排序阶段与其他通道保持分离。因此，单通道 Fabric 的排序阶段有类似的延迟。随着通道数量的增加，执行和验证阶段的延迟会因 CPU 争用而增加。

假设在Fabric网络中有L(L2)个通道均匀分布在K个组织中，每个组织加入L′个通道，可以计算为

与单通道Fabric相比，随着通道数量的增加，多通道中每个背书节点的处理延迟增加到T’p，定义为：

此外，由于属于不同通道的 L ′ /N 个块的并行验证和提交，验证阶段的延迟将转换为 T ′ v 如下：

4. 模型验证与分析

在本节中，我们首先进行实验测量以验证我们的延迟模型的正确性。然后，我们研究了各种可配置参数对 Fabric 区块链系统延迟的影响。最后，我们给出了一些有益于 Fabric 区块链部署的见解。

4.1.实验设置

我们构建了一个 Fabric 区块链测试平台，其中包括 2 或 4 个组织以及每个组织两个对等点。排序服务仅部署一个排序节点，即我们的实验采用 Solo 共识机制。此外，“AND”类型的背书策略用于指定每个组织至少需要一名背书人来执行交易。每个节点都作为 Docker 容器启动，然后使用 Docker Swarm 连接到 Fabric 网络中。每个节点（client、peer、orderer）对应的所有容器都运行在局域网中独立的物理服务器上。每个物理服务器有 4 个 CPU（Intel Xeon 2.2 GHz）和 12GB RAM。每台机器都运行安装了 Fabric V1.4 的 Ubuntu 16.04 LTS。所有物理服务器都连接到 1 Gbps 以太网交换机。

为了将交易工作负载生成到 Fabric 区块链中，我们使用 Hyperledger Caliper（cli，2019），这是一种性能基准工具，允许用户衡量不同区块链解决方案的性能。通过实施一组预定义的自定义用例，Caliper 生成包含许多性能指标的报告，其中包括吞吐量、延迟和资源利用率。在我们的性能实验中，Caliper 在所有客户端节点上运行，每个客户端以指定的发送速率发送受控事务工作负载。交易延迟是按交易计算的，包括从提交交易到在网络中确认该交易的时间。在实验期间，客户端提交 10,000 笔交易并监听来自同行的区块事件以检查交易确认。产生的延迟是所有事务的平均值。此外，我们通过为所有事务分配完成时间戳来对 Caliper 框架进行更改，该时间戳用于计算本文中每个阶段的延迟。

4.2.结果

在本节中，我们展示了延迟性能的评估设置和分析结果，其中包含交易到达率 λ、区块大小 SB、区块间隔 𝒯 和组织数量 K。对于本节中显示的所有结果，我们重复了三个实验试验，最终的延迟结果是这些试验的平均值。

4.2.1.交易到达率的影响

与 Kuzlu、Pipattanasomporn、Gurses 和 Rahman（2019）类似； Thakkar 等人（2018 年），我们使用 Caliper 发送到达率 λ 在这个实验中从 50tps 到 250tps 的交易。区块间隔 𝒯 为 1s，区块大小 SB 从 100 到 300 不等。参数列于表2

图 4 显示了分析延迟结果和实际模拟延迟结果作为事务到达率 λ 的函数。在整个参数范围内，分析结果与仿真结果吻合良好。我们将图4中的数据作为输入，并在表3中展示误差θ。其中，Tmeasured代表仿真结果，Tmodeled为理论分析结果。我们计算误差百分比并将其定义为 θ = (Tmeasured ¶ Tmodeled)/Tmeasured × 100%。从表 3 可以看出，我们的模型预测实验测量值的误差低于 6.1%。

此外，我们从图 4 中得出，当交易到达率 λ 低于块大小 SB 时，延迟随着交易到达率的增加而增加。例如，当到达率低于图 4（a）中的 SB = 100（即交易到达率从 50tps 到 100tps）时，延迟增加。当 SB = 200 时，在图 4(b) 中也可以看到相同的观察结果（交易到达率范围从 50tps 到 200tps），以及当 SB = 300 时图 4（c）的整个范围。原因是当在区块间隔𝒯 内到达的交易数量无法到达 SB，由于排序服务中的条件 1，将创建一个新区块。随着交易到达率的增加，排序阶段新块的生成时间增加。

相反，当 λ ≥ SB 时，延迟随着事务到达率 λ 的增加而减少。例如，当块大小 SB = 100 并且到达速率 λ 从图 4（a）中的 100tps 增加到 250tps 时，延迟从 0.65s 减少到 0.36s。当我们在图 4b 中设置 SB = 200 时，当交易到达率从 200tps 增加到 250tps 时，延迟从 0.77s 减少 14.3% 到 0.66s。这是因为区块间隔𝒯内到达的交易数量已经超过了默认的区块大小SB（3.2节中的条件2），当交易数量达到SB时，排序服务将待处理的交易分批放入新的区块中。交易到达率越高，新区块生成速度越快，每笔交易在排序阶段的等待时间越短。上述图 4 的结果也与 Thakkar et al (2018) 的实证研究一致，这进一步证明了我们模型的正确性。

4.2.2.默认块间隔的影响

图 5 显示了在四种不同的交易到达率下，延迟性能作为块间隔𝒯 的函数的分析和模拟结果：（a）50tps，（b）100tps，（c）150tps，（ d)250tps。在这组实验中，我们将 SB 的值固定为 200。

我们可以看到，对于低到达率（例如图 5(a) 中的 λ = 50tps），块仅由于条件 1 而生成（即，块间隔内到达的事务数𝒯 无法达到默认块大小SB）。因此，随着默认块间隔𝒯的增加，所有交易的等待时间都更长，导致更大的延迟。此外，从图 5（d）中，我们发现延迟不受块间隔的影响𝒯 . 这是因为交易到达率（250tps）大到超过默认区块大小（例如SB = 200），条件2（P2）在排序阶段的概率无限趋向于1。因此，延迟为几乎没有区块间隔𝒯。

4.2.3.默认块大小的影响

同样，我们也进行了不同块大小 SB 从 100 到 300 的实验，并使用四种交易到达率对分析和模拟结果进行了比较，如图 6 所示。默认块间隔𝒯在本实验设置为 1s。

毫不奇怪，图 6 中的延迟结果与图 5 中的结果完全相反。对于低到达率（例如图 6a 中的 λ = 50tps），延迟几乎不受块大小的影响。原因是块的创建只是由于块间隔𝒯，即排序阶段的概率 P1 趋于 1。因此，延迟与块大小 SB 无关。此外，对于高到达率（例如图 6d 中的 λ = 250tps），延迟随着块大小的增加而增加。

4.2.4.组织数量的影响

在Fabric中，组织数量是衡量系统可扩展性的一项指标。为了分析组织数量对延迟性能的影响，我们额外部署了一个包含 4 个组织的 Fabric 区块链网络，每个组织也包含两个节点。然后，比较了不同大小的 Fabric（即 K = 2 和 K = 4）下的仿真延迟和分析延迟。

图 7 描绘了组织数量对不同事务到达率下的延迟的影响。在这组实验中，我们设置区块大小 SB = 300，区块间隔𝒯 = 1s，交易到达率从 50tps 到 250tps 不等。从图 7 中，我们可以看到有 4 个组织的 Fabric 网络的延迟明显高于只有 2 个组织的 Fabric 网络的延迟。从我们的模型中，我们知道这种价值增加的原因有两个：首先，由于使用 And 类型的背书策略，交易需要所有组织的背书。在具有 4 个组织的 Fabric 区块链中，每笔交易都需要由更多的背书者执行，从而导致更大的处理延迟。此外，在具有 4 个组织的 Fabric 网络中，需要将更多的背书组合成交易发送到网络，导致传输延迟略高。

4.2.5 通道数的影响

在多通道Fabric网络中，通道数是衡量系统可扩展性的另一个术语。为了验证我们在第 3.3 节中提出的多通道延迟模型的准确性，我们部署了一个具有 2 个组织的多通道 Fabric 区块链网络，每个组织有 2 个对等节点。同时，我们部署 {1, 2, 4, 8} 通道。然后比较了不同通道数下的仿真时延和分析时延。

图 8 描绘了通道数对延迟的影响。在本实验中，我们设置所有通道的交易到达率λ=50tps，区块大小SB=300，区块间隔𝒯=1s。从图 8 中可以看出，随着通道数量的增加，总延迟从 63 毫秒增加到 89 毫秒，这是由于对 CPU 资源的争用。

4.3.进一步分析

在这里，基于我们的分析模型，我们研究了各种参数的联系，并为部署 Fabric 区块链提供了一些见解。

4.3.1.不同阶段的延迟

图 9 绘制了交易流中三个阶段的平均延迟，其中我们将交易到达速率设置为 50tps、150tps 和 250tps，块大小 SB = 300，块间隔𝒯 = 1s。从图 9 中，我们可以看出，排序阶段的延迟占整体交易延迟的大部分，当交易到达率为 250tps 时，渐进地达到总延迟的 0.693 0.078+0.693+0.281 ≈ 67%。发生这种情况是由于订购服务中交易的等待时间增加。

洞察一：下单服务是Fabric区块链的瓶颈，尤其是等待下单的延迟。一个潜在的优化是与分片并行处理事务，但它必须考虑冲突事务的影响。

4.3.2.排序服务中各种配置的延迟

排序服务接收来自不同客户端的背书交易，给出它们的总顺序，并根据块间隔𝒯和块大小SB为待处理交易创建一个块。我们设置 𝒯 = 1s 并估计不同交易到达率（从 10tps 到 500tps 不等）和块大小值的延迟变化。

图 10 显示了延迟结果作为交易到达率 λ 和块大小 SB 的函数的等值线图。从中我们可以看出，对于较小的交易到达率，块大小值对整体延迟性能的影响很小（小于0.5s）。但是，对于更高的交易到达率，块大小对延迟有很大的影响。原因是块是由于块大小限制而生成的。随着块大小的增加，需要更高的交易到达率才能跳过块间隔（我们模型中的条件 2）。

见解 2：为了实现较低的交易延迟，当交易到达率低于默认区块大小时，建议使用较小的区块大小。另一方面，当预期交易到达率较高时，较大的块大小更合适。

5. 相关工作

最近的许多工作都提到区块链平台的性能问题是一项有前途的研究，并从实验和理论分析中探索性能（Christidis, Gaur, & Wang, 2019; Dinh et al, 2018; Hari, Kodialam, & Lakshman, 2019；Liu、Yu、Teng、Leung 和 Song，2019；Miyamae、Honda、Tamura 和 Kawaba，2018；Wang 等人，2019）。在本节中，将讨论与 Fabric 区块链相关的性能研究。

在 Nasir 等人 (2018) 中，作者对 Fabric V0.6 和 V1.4 的执行时间、平均延迟、吞吐量和可扩展性进行了性能分析。通过实验结果，作者发现 Fabric V1.4 在各种实验情况下都优于 V0.6。 Thakkar 等人 (2018) 的作者通过为系统可配置参数（包括交易到达率、块大小、背书策略、通道数量和资源分配）分配不同的值，对 Fabric V1.0 进行了全面的性能实验。此外，还给出了配置参数的一些建议，以获得他们工作中的最大性能。在 Baliga 等人 (2018) 中，使用实验方法讨论了 Fabric V1.4 的性能和可扩展性特征。在不同的工作负载集下，作者研究了配置参数（与事务相关和与链代码相关）如何影响 Fabric 中的整体吞吐量和延迟指标。此外，Tien Tuan 等人在 Dinh 等人（2017）中提出了 BLOCKBENCH，这是第一个私有区块链系统评估框架，用于分析许可区块链系统的性能。在BLOCKBENCH中，区块链架构分为三个模块化层，即共识层、数据模型层和执行层。此外，基于两个宏观和四个微观基准工作负载，对 Fabric 与其他两个许可区块链系统（以太坊和奇偶校验）进行了深入比较。他们的实验结果表明，Fabric 区块链始终提供比其他两个系统更好的性能。结果还展示了 Fabric 区块链在处理数据处理工作负载方面的局限性，并揭示了一些瓶颈。在 Nguyen 等人 (2019) 中，作者通过改变网络层的延迟来评估 Fabric 区块链的性能。他们在两个云数据中心部署了一个 Fabric 区块链网络，并引入了高达 3.5 秒的传输延迟。实验发现，Fabric 区块链系统在延迟大于 3.5s 时会惨死，证明微小的网络延迟可能会对 Fabric 区块链性能带来巨大影响。此外，考虑到具有恶意行为的 Fabric 区块链系统，Wang（2019）的作者设计了恶意行为模式并分析了其对 Fabric 中 PBFT 共识性能的影响。从实验结果来看，Fabric V0.6 无法抵抗拒绝服务攻击，而采用执行顺序验证范式的Fabric V1.4 可以抵抗无限循环事务的攻击。

上述研究仅通过实证测量来解决 Fabric 区块链的性能分析，缺乏理论分析来提供定量框架。此外，由于巨大的配置选项和复杂的底层网络环境，这些经验结果无法比较。面对这些挑战，许多先前的工作都讨论了理论性能分析。 Sukhwani、Martínez、Chang、Trivedi 和 Rindos (2017) 中的 Harish 等人提出了一个基于随机奖励网 (SRN) 的理论模型来计算 PBFT 共识过程的平均完成时间（Sousa、Bessani 和 Vukolic，2018）在织物中。使用此模型，可以估算各种配置参数下的性能指标。该理论模型计算了 PBFT 共识期间的平均延迟，并给出了 Fabric 区块链中一些潜在的性能瓶颈。但是，没有给出模型的详细解释，并且该分析模型缺乏整体延迟分析。因此，Sukhwani、Wang、Trivedi 和 Rindos (2018) 提出了扩展工作，作者通过解析数值解 (SPNP) 并使用广义Yuan、Zheng、Xiong、Zhang 和 Lei (2020) 中的随机 Petri 网 (GSPN) 方法。这种基于 SRN 的理论模型确实可以估计 Fabric V1.0 区块链的综合延迟性能，但它无法计算特定交易到达率下的延迟，也没有考虑各个节点的任何排队延迟。因此，迫切需要考虑各种约束的理论模型来有效地分析 Fabric 区块链的性能。

6. 结论

本文提出了一个理论分析框架来研究 Fabric 区块链系统的延迟性能。我们完全按照 Fabric V1.4 中的执行顺序验证事务处理规范研究了延迟性能模型。为了验证这些理论模型的有效性，我们进行了一系列实验，结果表明我们的模型可以高精度地预测平均事务延迟。此外，基于理论模型，我们获得了一些定量结果，并得出了一些对开发人员有价值的高层次见解。

将来，我们打算将我们的研究扩展到对无效交易和恶意节点的存在的分析。此外，在我们的分析模型中，假设节点之间的通信是完美的，没有任何延迟约束。然而，考虑到不稳定的信道质量、干扰、有限的资源和各种网络拓扑，我们计划研究通信对整体性能区块链系统的影响。