测量区块链网络性能的关键指标有哪些?

返回列表

TPS每秒交易次数

对于很多人来说,分布式系统中的TPS是一个非常模棱两可的指标。

TPS测量来自分布式数据库,它们通常使用标准化的交易类型或集合(例如一定数量的INSERT、UPDATE、DELETE以及常量SELECT数量)执行,并针对特定集群或单独的计算机进行配置。

此类“综合”指标无法反映所讨论的数据库或区块链的真实性能,因为此类系统中的交易处理时间可能会有所不同。面向一致性的数据库(请参阅“ CAP定理”)只有在从其他节点收到足够数量的确认后才提交事务,这一过程很慢。

面向可用性的数据库将交易简单地写入磁盘就认为该交易成功。它们立即提供了更新的数据,并且速度非常快(尽管此交易将来可能会回滚)。

如果交易仅更新一个数据单元,则TPS将更高。如果交易更新许多数据单元(行,索引,文件),它们将相互阻塞。

因此,我们一方面看不到Oracle、MSSQL、PostgreSQL的“TPS竞争”,另一方面也看不到MongoDB、Redis、Tarantool之间的“ TPS竞争”,它们的内部机制和任务相差很大。

从我们的角度来看,“测量区块链TPS”意味着进行全方位的性能测量:

1、在可重复条件下;

2、具有接近实际数量的区块验证器;

3、使用各种类型的交易:

  • 研究的区块链的典型特征(例如,主要加密货币的转账)

  • 加载存储子系统(每笔交易都有相当大的变化)

  • 加载网络带宽(大型交易规模)

  • CPU加载(大规模密码转换或计算)

要谈论“每秒交易次数”,您需要描述所有网络条件、参数和基准测试逻辑。在区块链中,将交易应用于某些内部数据库并不意味着共识会接受它。

在PoW共识中,交易永远不会完成。如果一台机器上的某个区块中包含一笔交易,这并不意味着该交易将被整个网络接受(例如,如果另一分叉获胜)。

如果区块链具有确保最终性的其他算法(例如EOS、以太坊2.0,使用GRANDPA最终性共识的波卡平行链),则处理时间可以视为节点“看到”交易和下一个最终确定的区块的时间。

这种“ TPS”非常有用,但很少见,因为它们低于预期。


与区块链相关的具体指标

本地TPS

测量处理的交易数和最大/平均/最小处理时间(在本地节点上)非常方便,因为执行这些操作的功能通常在代码中表示。交易处理时间等于更新状态数据库所需的时间。

例如,在“乐观态度”的区块链中,处理过的交易可能已经过验证,但未被共识所接受。

在这种情况下,节点会将更新后的数据发送到客户端(假设不会有任何链分叉)。这个指标不是很准确:如果选择另一个分叉链作为主链,有关被回滚交易的统计信息也必须被回滚。在测试中,这通常被忽略。

“我们的区块链昨天获得了8,000 tps”。由于这些数字易于测量,因此通常可以在简短的项目报告中找到,仅一个运行的节点和一个加载脚本就足够了。在这种情况下,不存在会减慢网络共识速度的网络延迟。

任何区块链交易的结果都是几次原子存储写入。例如,比特币支付交易涉及删除几个旧的UTXO(删除)并添加新的UTXO(插入)。在以太坊中,一个小的智能合约代码被执行,几个键值对被更新。

原子存储写入是查找存储子系统瓶颈并区分底层逻辑和内部逻辑问题的极佳度量。区块链节点可以用几种编程语言实现——这更可靠。例如,以太坊节点有Rust和Go实现。在测试网络性能时,请记住这一点。

本地生产的区块数量

这个简单的指标显示了某个验证器产生的区块数,它取决于共识,对于评估单个验证者网络的“有用性”至关重要。由于验证者在每个区块上都能赚钱,因此他们会确保机器的稳定运行和安全。

您可以确定哪个验证者候选人最有资格,最受保护并准备在具有真实用户资产的公共网络中工作。度量值可以公开检查——只需下载区块链并计算块数即可。

最终性和最后不可逆的区块

最终性确保区块链中包含的所有交易直到最终确定的区块都不会回滚或被另一个区块儿链分叉替代,这是权益共识机制网络防范双重支出攻击并为用户确认加密货币交易的一种方式。

当存在一个可以最终确定包含该交易的链的区块时,而不是当节点简单地接受交易时,用户就将交易视为最终交易。

要最终确认一个区块,验证者必须在p2p网络中接收该区块,并相互交换签名。此处检查区块链的真实速度,因为交易最终性时刻对用户而言最重要。

最终性算法也有所不同,相交并与主要共识相结合(以太坊中的Casper,EOS中的最后不可逆区块和Parity Polkadot中的GRANDPA及其修改,例如MixBytes RANDPA)。

对于并非每个区块都已最后的网络,有用的一个度量是最新的已完成块和当前的最新区块之间的延迟,这个数字表明有多少验证者在就正确的链达成共识方面落后了。

如果差距很大,那么最终性算法需要额外的分析和优化。

P2P层

点对点子系统(区块链网络的中间层)通常被忽略,验证者之间的区块交付和交易的模糊延时都是它造成的。

当验证器的数量很少时,它们将被本地化,对等列表是经过硬编码的,并且一切正常且快速。但是就像验证器在那里一样,节点在地理上分布并且模拟丢包情况,我们正面临着严重的“ tps”故障。

例如,当使用额外的最终性算法测试EOS共识时,将验证器的数量增加到80-100台,分布在四大洲,对确定性的影响很小。

同时,增加的数据包丢失会严重影响最终性,这证明需要额外的p2p层配置,以更好地抵抗网络数据包丢失(而不是高延迟)。

不幸的是,存在许多不同的设置和因素,只有基准测试才能使我们了解所需的验证器数量,并获得相当舒适的区块链速度。

p2p子系统配置在文档中很清楚,例如、查看[libp2p]、[Kademlia]协议或[BitTorrent]。

重要的p2p指标可以是:

  • 进出流量

  • 与其他对等方成功/失败连接的数量

  • 返回了先前缓存的数据块多少次,以及进一步转发请求以找到所需块的次数(高速缓存命中/未命中模拟)。例如,访问数据时遗漏数大意味着仅少数节点有被请求的数据,并且它们没有时间将它们分发给每个人。接收/发送的p2p通信量可以用来标识处理网络配置或信道问题的节点。


区块链节点的系统指标

大量资料中描述了区块链节点的标准系统指标,因此我们将做简要介绍,它们有助于发现逻辑瓶颈和错误。

中央处理器

CPU显示处理器执行多少次计算。如果CPU负载很高——节点正在使用逻辑或FPU(几乎从未在区块链中使用过)积极地进行计算。

发生后一种情况的原因是,例如,由于节点正在检查电子签名,使用强大的密码处理交易或进行复杂的计算。

可以将CPU划分为更多指标,以指出代码瓶颈。例如,系统时间(花费在内核代码上的时间)、用户时间(花费在用户进程上的时间)和io(等待来自慢速外部设备(磁盘/网络)的I / O),等等。

内存

现代区块链使用键值数据库(LevelDB,RocksDB),这些数据库不断在其内存中存储“热”数据。任何加载的服务都会遭受由于错误或针对节点代码的针对性攻击而导致的内存泄漏。

如果内存消耗正在增加或急剧增加,则很可能是由于状态数据库密钥数量大,事务队列大或不同节点子系统之间的消息量增加所致。内存不足表明区块数据限制或最大事务复杂性可能增加。

响应网络客户端的完整节点依赖于文件缓存指标。当客户端访问状态数据库和事务日志的各个部分时,磁盘上的旧块可能会出现并替换新的块。反过来,这减慢了客户端的响应速度。

网络

主要的网络指标是流量(以字节为单位),发送和接收的网络数据包数,数据包丢失率。这些指标经常被低估,因为区块链尚不能以1 Gbit / sec的速度处理交易。

目前,一些区块链项目允许用户共享其WiFi或提供用于存储和发送文件或消息的服务。测试此类网络时,网络接口流量的数量和质量变得极为重要,因为拥挤的网络通道会影响计算机上的所有其他服务。

存储

磁盘子系统是所有服务中最慢的组件,通常会导致严重的性能问题。过多的日志记录,意外的备份,不便的读/写模式,庞大的区块链流量——所有这些都可能导致节点速度显著下降或对硬件的过度需求。

使用磁盘的区块链事务日志操作模式类似于使用预写式日志(WAL)的不同的DBMS。从技术上讲,事务日志可以视为状态数据库的预写式日志。

因此,这些存储指标很重要,因为它们可以识别现代键值数据库中的瓶颈。读/写IOPS数,最大/最小/平均延迟以及许多其他有助于优化磁盘操作的指标。


结  论

综上所述,我们可以将指标分组为:

  • 区块链节点指标(产生的块数,已处理的事务数,处理时间,完成时间等)

  • p2p子系统指标(命中/未命中请求的数量,活跃对等体的数量,p2p流量的数量和结构等)

  • 系统节点指标(CPU,内存,存储,网络等)

每个组都很重要,因为可能存在子系统错误,限制了其他组件的操作,即便是很少的验证器速度减慢,也会严重影响整个网络。

共识算法和最终性算法中,最棘手的错误是由于大量的交易流或共识参数变化而出现的。它们的分析需要可重现的测试条件和复杂的负载方案。