代码编织梦想

摘要

Hyperledger Fabric (HLF)是一个分布式账本平台的开源实现,用于在模块化架构中运行智能合约。在本文中,我们提出了一个使用随机奖励网(SRN)的Hyperledger Fabric v1.0+的性能模型。从我们的详细模型中,我们可以计算每个节点上的吞吐量、利用率和平均队列长度,以及节点内的关键处理阶段。为了验证我们的模型,我们在实验室中设置了一个HLF网络,并使用Hyperledger Caliper运行工作负载。从我们的分析结果中,我们发现完成背书过程的时间受到同伴数量和策略(如and())的显著影响。排序服务和账本写的性能瓶颈可以使用更大的块大小来缓解,尽管延迟会增加。对于提交对等体,事务验证检查(使用验证系统链码(VSCC))是一个耗时的步骤,但它的性能影响可以很容易地减轻,因为它可以并行化。然而,它的性能是至关重要的,因为它吸收了爆炸块到达时的冲击。我们还分析了各种假设场景,例如在管道中处理事务的对等节点,以及每个组织有多个背书者。

一 引言

根据美国国家标准与技术研究院 (NIST) [1],“区块链是以分布式方式(即没有中央存储库)实现的不可变数字分类账系统,通常没有中央权威。”区块链网络使可信方能够以可验证的方式以点对点方式发送交易,而无需可信中介。它允许各方更快地结算交易,从而加快商品和服务的流动 [2]。因此,比特币等加密货币是在区块链网络上运行的应用程序。

Hyperledger 项目是由 Linux 基金会主持的开源协作项目,旨在为企业推进区块链技术。在我们的研究中,我们专注于 Hyperledger Fabric 版本 v1.0+ [3](称为 Fabric V1 或简称为 Fabric)。它目前部署在 400 多个概念验证和生产分布式账本系统中,横跨不同行业和用例 [4]。与任何人都可以加入网络的公共区块链网络(如比特币或以太坊)相反,HLF 是一个经过许可的区块链网络,参与者可以在其中相互了解和识别但并不完全信任彼此。因此,组织可以从分布式账本技术 (DLT) 中受益,而无需加密货币 [5]。

随着 HLF 项目的发展和成熟,必须对执行不同功能的节点之间的复杂交互进行建模。此类模型提供了一个定量框架,有助于比较不同的配置并做出设计权衡决策。在本文中,我们提出了 Fabric V1 的性能模型,该模型使用随机奖励网络 (SRN) 来计算作为各种系统参数函数的各种对等方的吞吐量、利用率和平均队列长度。就像 HLF 的多个子系统是“可插拔的”一样,我们确保相应的子模型也是可插拔的
有了这个模型,我们可以提出各种假设问题,例如

  1. 随着事务到达率的增加,每个节点的吞吐量、利用率和平均队列长度如何变化?
  2. 如果节点验证管道中的交易而不是批量验证,整体系统吞吐量会增加吗?
  3. 如果每个组织有多个背书节点,我们能获得多少性能提升?

本文的研究贡献如下。

  1. Fabric V1 区块链网络的综合性能模型。对于 Fabric 独特的区块链网络架构,它捕获了每个子系统执行的关键步骤以及它们之间的交互。

  2. 系统开发人员和从业人员关心的关键假设场景分析。

  3. 使用多节点实验设置验证模型。

二 系统描述 - HYPERLEDGER FABRIC V1

Fabric V1 引入了执行-订单-验证架构 [3],这是对传统订单执行设计的根本转变,其他区块链平台也遵循这一设计,包括 HLF 的预览版(称为 v0.6)[6]。目标是将交易执行(通过智能合约 (SC))与交易排序分开。与传统的状态机复制方法 [7] 相比,该架构提供了更好的可扩展性、用于交易验证的新信任假设、对非确定性 SC 的支持以及模块化共识实现 [3]、[5]。

在这里插入图片描述
图 1. Hyperledger Fabric V1 上的交易流,有 2 个节点和运行单个通道的排序服务

在 Fabric V1 中,节点执行交易并维护分布式账本。排序者对网络中的所有交易进行排序,提出新的区块并寻求共识。订购者的集合形成订购服务。默认情况下,所有节点都是提交者,从而从排序服务中以事务块的形式接收有序的状态更新,并维护分类帐。收到新块后,对等方验证交易,提交对分类帐本地副本的更改并附加到区块链上的块上。节点可以承担背书交易的额外责任,因此称为背书人。背书者通过执行智能合约 (SC)(在 HLF 中称为链代码)并在将结果发送回客户端之前附加其加密签名(称为背书)来模拟交易。请注意,单个对等节点可以同时是背书者和提交者.

Fabric 使用版本化的键值存储 (KVS) 和账本维护所有节点的全局状态。 KVS 显示交易的最新状态,链代码可以使用 get() 操作读取该状态,状态更新由交易使用 put() 操作提出。版本号单调递增。 KVS 通过链码进行分区。分类帐是所有交易块的有序哈希链,因此提供了所有状态更改的可验证历史记录。键值存储和分类帐都由每个对等点私下更新。

在 Fabric 网络中,一部分想要私下进行业务交易的节点可以形成一个通道,从而维护键值存储和分类帐的单独分区。在我们的分析中,我们考虑单通道 Fabric 网络。

要执行交易,客户端需要来自背书策略定义的所有对等方的签名。背书策略是业务逻辑的反映,可以使用使用 AND、OR 和 k/n 的任意布尔逻辑来描述(更多细节见第 VII-A 节)。

让我们考虑图 1 中的 Fabric 网络。在此示例中,每个对等点代表一个组织(例如 Org0 和 Org1)。 Fabric V1中的交易流程描述如下

  1. 客户端发送一个交易提议(TxProposal)给由背书策略定义的节点(都运行相同的智能合约,比如 SC1),包括 clientID、payload 和 transactionID,以及客户端的加密签名交易标头。有效负载包含 chaincodeID、操作和输入参数。

  2. 每个对等点通过使用针对本地键值状态的用户输入调用相应的 SC(在本例中为 SC1)来模拟交易执行。 SC 在与对等方隔离的容器中运行。 endorser 模拟后产生 read-set 表示 SC 读取的密钥版本号,write-set 表示 SC 更新的键值对。

  3. 每个peer向客户端发送包含结果、read-set、write-set和元数据的背书消息,其中元数据包括transactionID、endorserID和endorser签名。此消息由对等方的加密签名签名。

  4. 客户端等待peer的背书,直到满足交易的背书策略并验证收到的结果一致。然后,客户端准备包含有效载荷的交易和从背书节点接收到的背书集,并将其发送到排序服务。此操作是异步的,当事务成功提交时,客户端将收到其对等方的通知。

  5. 几秒后(称为块超时)或一定数量的待处理交易(称为块大小)后,排序服务创建一个待处理交易块,按时间戳维护顺序。该块附加有基于块头的加密签名,然后广播给同一通道上的所有对等方。

  6. 当节点收到一个交易块时,它会根据其背书策略并行评估交易背书(使用验证系统链码(VSCC))。失败的标记为无效。接下来,对于每个有效交易,它执行多版本并发控制(MVCC)[8],[9](在[3]中称为读写检查),这意味着它串行验证读取集版本是否与当前匹配KVS 上的版本(假设之前的事务已提交)。交易的有效性被捕获为一个位掩码,并在块被附加到本地分类账之前附加到块。最后将所有的write-set写入本地KVS,完成状态转换。节点通知客户端交易成功或失败。

因此,Fabric V1 中的每笔交易都经历三个阶段:背书、排序和验证。

三 性能指标

在本文中,我们在 DLT 系统级别对 Fabric 的性能进行建模。 Hyperledger 性能和可扩展性工作Group1 最近发布了性能指标文档 [10] 的第一版,试图提供适用于不同 DLT 平台的清晰明了的性能指标。我们借用并完善我们的模型和分析的定义.

交易吞吐量:交易吞吐量是区块链网络在定义的时间段内提交有效交易的速率。它以每秒事务数 (tps) 表示。对于单通道 Fabric 网络,在我们的模型和实验分析中,我们都考虑在单个对等点进行测量。请注意,此处的事务对应于链代码“调用”而不是“查询”。由于仅考虑有效交易,因此吞吐量与实际吞吐量相同。

交易延迟:交易延迟是从提交交易到确认交易通过网络提交之间的时间。与比特币或以太坊等基于彩票的共识协议不同,交易终结是概率性的,Fabric 的共识过程导致确定性终结,因此定义简单。在我们的模型和分析中,我们检查单个节点的交易确认。端到端延迟包括三个延迟:背书延迟、排序延迟和提交延迟[9]。

队列长度:节点的队列长度是在该节点等待服务或正在服务的作业数。在我们的模型中,我们计算排序服务、每个背书节点和提交节点的每个处理阶段的平均队列长度。

利用率:节点的利用率是节点忙碌时间的百分比。在我们的模型中,我们计算每个背书节点的利用率和提交节点的每个处理阶段。对于多线程操作,利用率对应于所有逻辑处理器的平均利用率。

四 HYPERLEDGER FABRIC V1 的 SRN 模型

在本节中,我们使用称为随机奖励网 (SRN) [11] 的随机 Petri 网建模形式来展示我们的 Fabric 性能模型。这种形式主义允许一个简洁的规范和一个捕获区块链网络系统性能行为的底层(随机)过程的自动生成/解决方案。此外,使用 SRN 还可以让我们通过轻松添加或删除系统细节来研究不同的场景。 SRN 已经从性能角度成功地用于对不同的计算机/通信系统进行建模 [12]。我们使用随机 Petri 网包 (SPNP) [13] 求解模型。

图 2 显示了单通道 Fabric 网络的 SRN 模型,其中包含一个客户端、两个背书节点 (AND()) 和一个运行验证逻辑的节点。事务请求遵循速率为 λC 的泊松到达过程。最大限度。待处理的请求上限为 no。工作负载生成器中的线程数(在我们的例子中为 20 个)。客户端准备背书请求并将其发送给背书节点(比如节点 0 和节点 1)(转换 TPr,包括传输时间)。对等点认可交易(分别转换为 TEn0 和 TEn1)。当客户端收到来自两个对等方的响应时,客户端将已背书的交易发送到排序服务(转换 TTx),由存入 POS 的代币指示。在块大小待处理交易(由 M 表示)之后,将创建一个交易块并将其交付给提交对等方(过渡 TOS)。提交对等方首先执行 VSCC 并行验证块中的所有事务,受对等方中逻辑处理器(核心/vCPU)数量(CPUmax)的限制。然后它对所有事务串行执行 MVCC 验证(转换 TMVCC)。最后,块中的所有交易都写入分类帐的本地副本(transition TLedger)。TMVCC 和 TLedger 的转换都是在块级别捕获的。由于第 VII-B 节中讨论的原因,我们不考虑此模型中的块超时。请注意,我们隐含地假设所有交易都具有相同的复杂性并且彼此独立。总之,一个Fabric事务的三个阶段可以在SRN模型中看到。

我们从我们的模型中获取指标如下。事务阶段的吞吐量对应于相应转换的速率,使用 SPNP [14] 中的函数 rate()。例如,TL​​edger 的转换率表示系统的块吞吐量(乘以 M 以获得事务吞吐量)。事务阶段的利用率是通过使用函数 enabled() 启用 SRN 中的相应转换的概率来计算的。对于具有依赖于函数的标记率的转换(例如 TVSCC),所有逻辑处理器的平均利用率是使用奖励函数计算的。交易阶段的平均队列长度可以通过函数 mark() 通过相应阶段的令牌数获得。例如,POS 中令牌的平均数量表示订购服务的平均队列长度。
在这里插入图片描述
图 3. Hyperledger Fabric V1 网络设置

五 模型参数化的实证分析

我们使用从我们实验室的 Fabric 网络设置中收集的数据来参数化我们的模型。与第 IX-B 节中总结的研究不同,这项工作的目标不是通过对系统进行压力加载来对性能进行基准测试;相反,我们从受真实流量模式影响的 Fabric 网络中进行测量。在本节中,我们提供了所用工具的详细信息、网络设置以及我们用于数据收集和分析的方法。

A. 网络设置

部署的网络如图 3 所示。每个节点都作为 Docker 容器启动,然后使用 Docker Swarm2 连接到网络中。尽管节点和排序节点可以在物理/虚拟机上本地运行,但 Docker 容器网络是部署 Fabric 网络的推荐方法 [15]。每个组织(peer 和 ca)对应的容器运行在一个独立的物理节点(‘Org0’、‘Org1’)上。 Peers 在一个单独的容器(称为 CC)中执行链代码。与排序服务对应的所有容器都在单个物理节点(“排序服务”)中运行。它包括1个排序服务节点(OSN)、4个Kafka broker、3个ZooKeeper节点。 Hyperledger Caliper 部署在一个单独的物理节点上,具有多个与本地安装的 Fabric Node.js SDK3 交互的客户端线程。我们在此处提供了设置 Fabric 网络的详细步骤4。请注意,我们考虑的是每个组织都有一个对等点的网络,因此我们忽略了八卦协议对网络性能的影响。

Org0、Org1、Caliper对应的物理机有4个CPU(1路4核)(Intel Xeon 2.2GHz)12GB内存,运行的订单服务有16个CPU(2路4核2超线程) Intel Xeon 2.4 GHz 和 32GB 内存。每台机器都在安装了 Fabric 版本 v1.15 的 7200 rpm 硬盘驱动器上运行 Ubuntu 16.04 LTS。所有物理机都与 1 Gbps 交换机连接。所有节点都使用NTP (Network Time Protocol)服务进行同步,以便可以跨节点测量事务延迟。所有节点之间的通信都配置为使用传输层安全性 (TLS)。

为了执行工作负载,我们使用最近被批准为 Hyperledger 项目的 Hyperledger Caliper6。它是一个基准执行平台,使用户能够一致地衡量不同 DLT 平台的性能。使用此工具的一个优点是它可以处理由客户端(使用 Fabric SDK)执行的复杂工作流,包括处理来自对等方的事件通知。为了按照泊松到达过程生成流量,我们在 Caliper 中实现了一个新的速率控制功能。 Caliper 目前的一个限制是它只支持与一个 OSN 节点的交互。

B. 测试应用程序

对于我们的性能测试,我们利用 Caliper 工具提供的简单链代码并根据我们的需要对其进行扩展。此应用程序维护用户的帐户余额。它可以执行两个功能。函数“open”检查账户是否存在,如果不存在,则创建一个新账户并为其分配账户余额。因此,它对键值存储执行一次读取、一次写入操作。 “转账”功能允许将资金从一个账户转移到另一个账户。因此它执行两次读取、两次写入操作。在运行“转账”交易之前,我们运行“开放”交易几分钟。加载键值存储。 [9] 中的作者也采用了类似的方法,通过读写操作的数量来区分工作负载。对于这两个功能,输入的帐号都是随机选择的;因此连续交易之间几乎没有依赖关系;因此交易似乎永远不会失败 MVCC 验证。这样,我们就可以轻松地以高速率生成所有有效交易的工作负载7。

C. 测量

我们通过分析 caliper 输出文件、对等日志和排序日志来测量在交易生命周期中执行关键步骤所花费的时间。图 4 显示了事务序列图以及捕获时间戳的地点和对等方/排序方中日志条目的快照。我们将这些重要日志条目从 DEBUG 模式转换为 INFO 模式。为了测量每个事务生命周期阶段的平均队列长度,我们添加了额外的日志条目以捕获新事务进入和离开该阶段的时间。没有的加权时间平均值。事务/块的数量给出了该阶段的平均队列长度 [16]。我们还将时间戳分辨率提高到微秒。我们测量了块大小为 500 且 λC = 100 的设置的额外日志记录的开销,并观察到平均事务延迟仅增加 0.64%,75%ile 延迟仅增加 0.48%。我们的 Fabric 源代码更改可以在这里找到8。

D. 测量运动

我们使用20个客户端线程运行Caliper,测试持续时间为240秒,确保事务到达遵循泊松到达过程。我们修剪第一个和最后一个 20 秒。测试运行作为加速和减速阶段。为了针对不同的配置设置验证我们的模型,我们改变了三个参数:a)客户端 tx。到达率 (λC),b) 区块大小,c) 交易类型(‘open’ 和 ‘transfer’)。由于我们的硬件限制,我们无法改变用于验证对等体的 CPU 数量。我们计划在未来的工作中追求它。对于给定的块大小,我们将 λC 保持足够高,以便大多数块是由于块大小而不是超时而创建的(参考第 VII-B 节)。在每次测试运行之间重新启动所有 docker 实例。
在这里插入图片描述
E. 模型参数

我们对上述每组配置参数值执行测试运行并收集日志文件,我们从中得出所需的输出指标。根据 λC ,每次测试运行包含 7k 到 30k 笔交易,从而产生 7k 到 30k 的交易级参数值样本和 150 到 900 块区块级参数值的样本。为确保各组的参数值一致,我们执行方差分析 (ANOVA) F 检验 [17] 以查看均值是否存在统计显着差异,然后使用 Tukey 的诚实显着性检验 [17] 进行多重比较程序], [18]。因此,我们从大型数据集中导出参数值。

在我们目前的工作中,我们假设所有转换的触发时间呈指数分布。在我们未来的工作中,我们计划进行分布分析并为每个转换选择最适合的分布。由于我们的验证结果很好,我们对自己的选择充满信心。通过这种选择,潜在的随机过程是一个连续时间马尔可夫链 (CTMC),因此我们可以使用解析数值解来分析我们的模型(第七节)。

“开放”交易的参数值总结在表 I 中。由于篇幅限制,我们仅在本文中显示“开放”交易的结果。 [19] 中分享了详细的实证分析。 Transitions TMVCC 和 TLedger 在区块级别进行测量,因为在交易级别的测量值太小。在客户端处理消息的时间 (TPr) 和准备块的时间 (TOS) 也包括到对等方的传输时间。关于TOS,虽然目前基于Kafka的排序服务没有共识的概念,但未来拜占庭容错(BFT)共识协议实现时,这个转换也会包括共识时间。
在这里插入图片描述

六 整体系统分析和模型验证

让我们分析一个使用 AND() 背书策略的网络的整体系统模型(图 2),其中 CPUmax = 4 用于 VSCC 验证和各种块大小。不幸的是,底层马尔可夫模型有一个巨大的空间,我们无法使用解析-数值解来求解完整的系统模型。因此,我们采用使用 SPNP 的模拟方法。

为了验证我们的模型,我们计算了排序服务 (OS) 和节点内关键处理阶段(VSCC 验证、MVCC 验证和账本写入 (LWrite))的平均队列长度,并将其与经验结果进行比较。我们选择“平均队列长度”,因为它可以可靠地测量并提供对系统性能的直观洞察。

我们针对不同的客户到达率和不同的块大小验证了我们的结果。从图 5 中的结果,我们观察到所有测量结果(标记为 (m))与不同客户到达率下的模型结果具有可比性。其他块大小的结果也类似。因此,我们认为我们的模型经过验证。不幸的是,我们无法可靠地测量来自对等日志的背书对等点的队列长度。

然而,由于结果与其他四个测量点相匹配,我们利用了我们模型的结果。从我们的模型结果中,让我们可视化每个事务阶段的利用率和平均队列长度(图 6)随着 λC 的增加。我们还计算了客户端处理和传输到订购服务的利用率。我们发现从客户端到排序服务的传输是性能瓶颈,利用率急剧上升,其次是背书节点。排序服务/分类账写入的队列长度预计会很大,因为它在生成/提交块之前等待块大小的交易。

在我们的实验室设置中,在高客户到达率下,交易往往会超时(可能是由于排队延迟)并失败,尽管对等点或订购服务并不是特别繁忙。它还解释了背书交易到排序服务的传输时间是一个性能瓶颈。根据我们的测量,很难说延迟是由于网络传输时间还是由于排序服务的内部排队。假设这个延迟在另一个设置中不是问题(用立即转换替换 TTx),让我们计算最大值。该网络中可能的吞吐量。在我们的模型中,我们不断提高客户交易到达率,直到任何交易阶段的利用率达到 90%。我们还考虑了每个组织有多个背书者的场景。 (Enmax),使用依赖于标记的发射率进行转换 TEn0、TEn0。从图 7 中的结果中,我们看到最大值。吞吐量随着块大小的增加而显着增加,尽管平均延迟增加(未显示)。当 Enmax = 1 时,瓶颈是背书节点。当 Enmax = 4 时,瓶颈是账本写入。因此最大。如果每个组织有多个背书者,系统吞吐量会大大增加(尤其是对于更大的块大小,如 120)。
在这里插入图片描述

在这里插入图片描述

七 模型分析

在接下来的三个小节中,我们分析了每个事务阶段对应的子系统。本节中的所有分析都是使用解析数值解 (SPNP) 完成的。

A. 背书策略

客户端节点负责寻求对其提议的交易的背书,从而满足背书策略。背书策略是单调的逻辑表达式,计算结果为 TRUE 或 FALSE。例如。,背书策略 OR(Org1, Org2) 意味着来自 Org1 或 Org2 的任何对等体的背书就足够了。背书策略可以表示为 AND、OR 和 k/n 表达式的任意组合,例如 OR(Org1, Org2) AND (2/3 of Org3, Org4, Org5)。

在这里插入图片描述图 8. 通用 SRN 模型,用于捕获两个节点之间的 AND/OR 背书策略

图 2 中模型的背书部分表示 AND() 策略中的两个对等方;因此,客户端在将交易转发给订购服务之前等待双方的响应。这个模型可以很容易地扩展来表示更多节点的 AND() 策略。为了对 OR() 和 k/n() 策略建模,我们使用 SRN 中的可变基数弧(称为 viarc())从没有触发的地方刷新令牌,如图 8 中带 Z 符号的弧所示。此外,一个guard函数用于立即转换Iwait,写法类似于背书逻辑表达式。因此,通过扩展图 8 所示的网络(没有虚线部分)并插入图 2 中的整个系统网络,可以轻松捕获复杂的背书策略。

背书过程给交易增加了显着的延迟。首先,链代码在每个节点的单独 Docker 容器中执行,增加了合理的性能开销。其次,客户端需要等待多个节点的背书响应以满足背书策略。让我们分析表 II 中不同背书策略完成背书的平均时间。我们假设每个节点的背书时间呈指数分布,速率为 0.308 每毫秒。

在这里插入图片描述
在 Fabric Node SDK 的当前版本中,客户端在为排序服务准备背书消息之前等待所有背书节点的回复(或超时)。因此,我们无法使用不同的背书策略来验证我们的全系统模型。即将发布的新功能 9 将解决此限制。

B. 订购服务
在这里插入图片描述
在这里插入图片描述
排序服务从客户端接收背书交易,对它们进行排序并根据块超时或块大小创建一个事务块。给定背书交易的到达率 (λE)、块大小和块超时,我们想评估由于块大小或块超时而生成块的概率。

让我们考虑图 9 中的 SRN 模型。POS 中的代币数量代表待处理的交易。令牌存放在 PSize 或 PTimeout 中,具体取决于块是由于大小限制还是超时而创建的。由于块超时是确定性的,我们使用 Erlang 分布 [20]、[21] 对其进行近似,它显示为一个单独的网络。当至少有一个令牌就位 POS 时,立即转换 TOtrigger 被启用。我们考虑一个 5 阶段的 Erlang 分布,其中每个阶段以 5/(块超时)的速率触发。

图 10 显示了由于超时条件为超时 = 1.0 秒而创建块的概率等值线图。对于较小的块大小,即使在低到达率 (λE) 下,块也会由于大小限制而生成。随着块大小的增加,需要更高的背书交易到达率 (λE) 来跳过我们模型中的超时条件。因此,我们可以跳过额外的逻辑来解释超时条件,从而显着降低整个系统模型的大小和复杂性(图 2)。

在这里插入图片描述
C. 块验证和提交

让我们使用图 11 中的 SRN 模型分析提交节点的性能。让我们假设块到达(来自排序服务)遵循泊松到达过程,速率为 λB,每个大小为 M。限制基础马尔可夫模型的大小,我们考虑最大值。每个阶段两个块的队列长度。

让我们考虑 Fabric 设计师感兴趣的两个场景。

在这里插入图片描述

  1. 块的突发到达:让我们考虑这样一个场景,其中提交对等方面临块的突发流,由高和低平均块到达率的周期组成。为了捕获这一点,我们使用马尔可夫调制泊松过程 (MMPP) [20]、[21] 对输入到达过程进行建模。让我们考虑图 11 中块大小为 M 的扩展 SRN 模型(以虚线框显示)。当 PMMPP 中有令牌时,块以高速率(例如每秒 6 个块)到达平均时间分数µstart µstart+µstop 和低速率(比如每秒 2.25 个块)。突发模式的平均启动时间为八秒。 ( 1 µstart ) 平均持续 2 秒。( 1 µstop )。为了将模型的结果与非突发到达率进行比较,我们考虑相同的平均到达率。因此,λB = λB-high ∗ µstart µstart+µstop + λB-low ∗ µstop µstart+µstop 。

我们将以突发模式 (MMPP(1)) 开始的 MMPP 到达结果与泊松到达率 λB= 每秒 3 个块的模型的结果进行比较。从图 12 中,我们发现 Ledger 写入和 VSCC 验证阶段的利用率在前几秒内随着​​ MMPP(1) 到达而跳跃。 MVCC 检查和 Ledger 写入阶段的平均队列长度都有显着的跳跃。总体而言,VSCC 验证阶段似乎很好地吸收了突发到达的冲击。然而,账本写入阶段的利用率和平均队列长度受到的影响最大,因此从性能角度来看是至关重要的。请记住,块是按顺序从排序服务交付的。因此,我们需要确保输入队列足够大,并且提交节点可以足够快地处理块。再次重新请求块会显着降低对等点的速度。

在这里插入图片描述
2)管道模型:为了提高提交节点的性能,作者在[3]、[9]中提出了一种管道架构,其中每个交易都经过管道中的各个阶段,而不是当前的交易通过的架构块中的每个阶段。我们假设这样的系统将只有一个逻辑处理器用于 VSCC 验证。我们假设 VSCC 验证的参数值相同,参数值除以 MVCC 的块大小,LWrite。我们计算最大值。吞吐量对于各种块大小的此管道模型(图 13)。令人惊讶的是,最大。吞吐量与 CPUmax = 1 的常规模型相当。但是,MVCC 验证时的平均队列长度稍大,而账本写入时的平均队列长度更小(未显示)。其余指标具有可比性。在这里插入图片描述
让我们使用图 11 和 13 中模型的修改版本来计算交易块的延迟,通过删除转换 Tblock-arr 并考虑 PVSCC 中的 M 个初始令牌和来自转换 TLedger 的输出位置 Done。当 M 个代币存入到位 Done 时,它​​表示一个块的完成。我们计算了不同块大小的常规模型和管道模型的平均块延迟(图 14)。正如预期的那样,与 CPUmax = 1 的常规模型相比,流水线模型中的平均块延迟略有改善。随着我们在常规模型中添加更多 CPU,延迟进一步降低。

我们针对 VSCC 验证率的平均块延迟对流水线模型进行敏感性分析。我们发现最大。吞吐量结果与 VSCC 验证 CPUmax = 2、4 等的常规模型相当。总的来说,流水线架构会稍微改善块延迟,但不会改善最大值。与传统架构相比的吞吐量和其他性能指标。

八 讨论

A. 随机模型的庞大性

我们使用高级形式主义,即 SRN 来模拟 Fabric 网络的复杂交互。这种方法的缺点是生成的底层随机模型非常庞大。我们无法为全系统模型生成基础状态空间,因为它是无限的。因此我们采用了模拟方法(参考第 VI 节)。对于提交对等模型(参考第 VII-C 节),我们考虑了最大值。每个阶段两个块的队列长度。这会截断基础模型的状态空间,我们使用解析数字解决方案解决了这个问题。有趣的是,我们发现模型状态空间大小随块大小线性增加。

规模问题限制了我们回答有关 Fabric 网络可扩展性问题的能力。在我们未来的工作中,我们将考虑采用分层方法和定点迭代解决方案技术来缓解此问题 [12]。

B. 我们模型的局限性

我们模型的一个局限性是我们无法计算特定交易吞吐量的延迟。从我们的模型中,我们可以估计交易块的平均延迟(参考第 VII-C2 节)。然而,这并没有考虑到系统“加载”时各个节点的任何排队延迟。按照这些思路,该模型也无法捕获由于超时(主要是由于排队延迟)导致的事务失败。在我们未来的工作中,我们计划使用状态空间建模方法计算事务的响应时间分布,如 [22] 中所述。

C. 有效性的威胁

我们结果的有效性的一个威胁是我们没有使用定制的 VSCC。自定义 VSCC 允许用户定义额外的(业务)逻辑来验证交易。由于这是在 VSCC 验证期间完成的背书策略签名验证的补充,我们认为更高的均值参数可以轻松捕捉到这一点。请注意,[3] 中的作者使用了自定义 VSCC 而不是 [9] 中的作者。另一个威胁是我们的节点在 LAN 设置中连接,而不是在现实世界中预期的广域网 (WAN)。在我们未来的工作中,我们计划通过在 Amazon Web Services (AWS) 等云服务上运行 Fabric 来复制我们的结果。

九 相关工作

A. 区块链网络的性能建模

Decker 和 Wattenhofer [23] 提出了一个简单的模型来计算比特币网络中的陈旧块生成率,该模型考虑了比特币的块生成和块传播过程。 Gervais 等人 [24] 对基于工作量证明 (PoW) 的区块链网络的安全性和性能方面进行建模和分析。对于性能建模,他们开发了一个模拟器,模拟块挖掘和传播过程作为块间隔、块大小和块传播机制的函数。它的输出指标是陈旧块率。 Papadis 等人 [25] 为基于 PoW 的区块链网络开发了随机模型,以计算块增长率和陈旧块率作为传播延迟和计算节点的哈希能力的函数。在我们之前的工作中,我们对 Fabric v0.6 [26] 的实用拜占庭容错 (PBFT) 共识过程进行了建模和分析。由于 Fabric V1 的架构与版本 v0.6 [5] 相比有了显着发展,因此本文讨论的模型不适用于版本 v0.6。

B. Hyperledger Fabric 的性能评估

Thakkar 等人在 [9] 中广泛研究了 Hyperledger Fabric v1.0 的性能,其中他们改变了五个可调参数:块大小、背书策略、通道数、对等点的 vCPU 数,以及键值数据库(GoLevelDB 与 CouchDB)。他们的研究为 Fabric 带来了三项优化:VSCC 验证的并行化、会员服务提供商 (MSP) 的缓存以及 CouchDB 的批量读/写,所有这些都包含在 v1.1 版本中,在 [3] 和我们的工作。 [3] 介绍了 Fabric V1 的大量细节。他们使用名为 Fabcoin 的应用程序测试了 Fabric v1.1,使用的数据模型类似于比特币风格的 UTXO10。与 [3]、[9] 在云数据中心的虚拟机上运行节点不同,我们在物理机上运行节点。 Sousa 等人 [27] 将 BFTSMaRt [28] 集成为 Fabric v1.0 的排序服务,并仅针对他们在 AWS 数据中心的地理分布式设置中部署的排序服务进行性能分析。

Auh Dinh 等人 [29] 使用基于 YCSB 和 Smallbank 基准的宏观基准在 48 节点集群上对 Fabric v0.6(以及以太坊和奇偶校验)进行了性能测试。他们还开发了单独的微基准测试,以深入了解共识、数据模型和执行引擎等各个层的性能特征。

十 结论和未来的工作

在本文中,我们为一个名为 Hyperledger Fabric 的流行分布式账本平台开发了随机模型。Fabric 网络中的每笔交易都经历三个阶段:背书、排序和验证。我们详细分析了整个系统以及每个交易阶段对应的子系统。我们从运行实际工作负载的 Fabric 设置中收集数据,以参数化和验证我们的模型。我们的模型提供了一个定量框架,可帮助系统架构师根据不同的系统配置来评估性能,并做出设计权衡决策。

对于传入的块,由于提交节点并行验证事务(VSCC),如果将提交节点部署在具有大量 CPU 的系统上,则会有显着的性能提升。它可以显着减少 VSCC 验证时的队列长度,并让系统吸收块突发到达的冲击。然而,这不是提交节点的性能瓶颈,因为账本写入的利用率最高。我们还分析了两种情况:每个组织有多个背书同行。和验证器的管道架构。交易背书并行化可以显着减少背书队列长度并增加最大值。如果背书过程是性能瓶颈,系统的吞吐量。管道架构在平均块验证延迟方面提供了大约 1% 的改进,但没有提供其他性能优势。在未来的工作中,我们将考虑采用分层建模方法来克服模型生成和解决方案的庞大性。

版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://blog.csdn.net/miracleoa/article/details/130850079

fpga2016~2018,fpl2017会议论文整理(持续更新)_edward-bao的博客-爱代码爱编程_fpga会议论文

      目录                                                              FPGA2016会议论文                                         FPGA2017会议论文                                        

Scaling Hyperledger Fabric Using Pipelined Execution and Sparse Peers(提升fabric 6倍性能的文章翻译)-爱代码爱编程

本文章是记录我对hyperledger fabric pipelined    ABSTRACT 许多使用Hyperledger Fabric(允许使用的区块链平台)构建的区块链应用程序的概念证明,最近已经转化为生产。但是,由于网络使用量的稳定增长,Hyperledger Fabric提供的性能对于企业来说是至关重要的。因此,在本文中,我们研究了使用