区块链网络性能的关键指标

衡量区块链性能的关键指标包括：

1）区块链节点指标（出块数、处理的交易数、处理时间、完成时间等）

2） P2P 子系统指标（命中/未命中请求数、活跃用户数、P2P 流量的数量和结构等）

3）系统节点指标（CPU、内存、存储、网络等）

当一切正常时，您通常不必担心区块链测试。我们将解释为什么最好不要搁置绩效评估，使用哪些指标并充分利用它。一起来了解一下吧。

TPS（每秒事务数）

在分布式系统的上下文中，TPS 是一个非常模糊且反复无常的指标。

TPS 指标来自分布式数据库。它们通常使用标准化的事务类型或事务集（例如，INSERT、UPDATE、DELETE 的值和 SELECT 的常量值），并针对特定的集群或单个机器进行配置。此类“综合”指标并不能反映相关数据库或区块链的真实性能，因为此类系统中的事务处理时间可能会有所不同。

面向一致性的数据库（参见“CAP定理”）只会在其他节点收到足够数量的确认后才会提交事务，非常慢。

如果一个事务被简单地写入磁盘以太经典节点数量，一个面向可用性的数据库就认为它是成功的。他们立即提供了更新的数据，而且速度非常快（尽管该事务将来可能会回滚）。

如果事务只更新一个数据单元，TPS会更高。如果一个事务更新了很多数据单元（行、索引、文件），它们会互相阻塞。 Oracle、MSSQL、PostgreSQL 和 MongoDB、Redis、Tarantool 之间没有任何“TPS 竞争”，因为它们的内部机制和任务非常不同。

在我们看来，“测量区块链 TPS”意味着进行全方位的性能测量：

1）在可重复的条件下

2）接近真实的区块验证节点数

3）使用各种类型的交易：

- 典型的区块链研究（例如主要加密货币的转移）

- 加载存储子系统（每个事务的大量更改）

- 加载网络带宽（大型事务）

- CPU 负载（大规模加密转换或计算）

要谈我们珍视的“TPS”，需要描述所有网络条件、参数和基准测试逻辑。在区块链中，将事务应用到某个内部数据库并不意味着共识会接受它。

在 PoW 共识中，交易永远不会最终确定。如果一个交易被包含在机器上的一个块中，并不意味着它被整个网络接受（例如，如果另一个分叉获胜）。

如果区块链有其他算法可以确保最终性（例如 EOS、以太坊2.0、使用 GRANDAPA 最终性共识的 Polkadot 平行链），则可以将处理时间视为一个节点“查看交易时间和下一个最终完成的区块。这样的“TPS”非常有用，但很少见，因为它们会低于预期。

“TPS”涉及很多方面。请保持怀疑并询问所有细节。

区块链特定指标

本地 TPS

处理的事务数和最大/平均/最小处理时间（在本地节点上）非常方便测量，因为执行这些操作的函数通常用代码表示。事务处理时间等于更新状态数据库所需的时间。例如，在“乐观”区块链中，已处理的交易可能已经过验证，但尚未被共识接受。在这种情况下，节点将更新的数据发送给客户端（假设没有链分叉）。

这个指标不太靠谱：如果选择另一条分叉链作为主链，那么交易数据会回滚，测得的统计数据也必须回滚。在测试中，这一点经常被忽视。

“昨天我们的区块链达到了8000tps”。这样的数字经常出现在简短的项目报告中，因为它们很容易衡量。您只需要一个正在运行的节点和一个加载脚本。在这种情况下，整个网络达成共识的速度不会因为网络延迟而减慢。

该指标反映状态数据库不受网络影响的性能。这个数字并不反映真实的网络带宽，但表明如果共识和网络足够快，它可以努力实现的极限在哪里。

任何区块链上的交易都是一些原子存储写入。例如，比特币支付交易涉及删除几个旧的 UTXO（删除）和添加新的 UTXO（插入）。在以太坊中，交易正在执行一个小型智能合约代码并更新几个键值对。

原子存储写入是查找存储子系统瓶颈和区分底层逻辑问题和内部逻辑问题的一个很好的指标。

区块链节点可以用多种编程语言实现，更可靠。例如，以太坊节点有 Rust 和 Go 实现。在测试网络性能时请记住这一点。

生成的本地块数

这个简单的指标显示了特定验证者生成的块数。它取决于共识，对于评估单个验证者网络的“有用性”至关重要。

由于验证者在每个区块上都赚钱，他们确保他们的机器稳定安全地运行。您可以确定哪个候选验证者是最合格的、最受保护的，并且可以在具有真实用户资产的公共网络中工作。 Metrics 指标可以公开查看，只需下载区块链并统计区块数即可。

最终性和最终不可逆块

Finality 确保区块链中包含的所有交易不会被回滚，也不会被另一条分叉链取代。这是 PoS 网络防止双花攻击并为用户确认加密货币交易的一种方式。

当存在可以完成包含交易的链的块时，用户可以认为交易已完成，而不是当交易仅被节点接受时。要敲定一个区块，验证者必须在 P2P 网络中接受该区块并相互交换签名。正是在这里检测到真正的区块链速度，因为交易完成的时间点对用户来说是最重要的。

确定性算法也彼此不同，相交并通过主要共识加入（阅读：以太坊中的 Casper，EOS 中的 Last Irreversible Blocks以太经典节点数量，Essence GRANDPA 中的 GRANDPA 和 ParityPolkadot 及其在 中的修改，例如 MixBytesRANDPA）。

对于并非每个区块都已最终确定的网络，一个有用的指标是最后确定的区块与当前最新区块之间的延迟。在他们就正确的链达成一致的情况下，这个延迟数字表明验证者落后了多远。如果这个差距很大，那么最终的确定性算法需要更多的分析和优化。

P2P 层

点对点子系统作为区块链网络的中间层经常被忽视。这是由于区块传递和验证它们的节点之间的交易存在模糊的延迟。

当验证器数量较少时，它们是本地化的，用户列表是硬编码的，一切都运行良好且速度非常快。但是，验证器节点在地理上分布，并且在模拟丢包时，我们面临着严重的“TPS”故障。

例如，在使用额外的确定性算法测试 EOS 共识时，将分布在四大洲的验证节点数量增加 80 到 100 个，对确定性几乎没有影响。

同时，增加的丢包验证会严重影响最终性，这证明需要额外的 P2P 层配置来更好地抵抗网络丢包（而不是高延迟）。不幸的是，有许多不同的设置和因素，只有基准测试才能让我们了解所需的验证节点数量并获得相对舒适的区块链速度。

P2P子系统的配置在文档中很清楚，例如参见[libp2p]、[Kadamlia]协议或[BitTorrent]。

重要的 P2P 指标可以是：

1）入站和出站流量

2）链接到用户成功/失败的次数

3）返回之前缓存的数据块被返回的次数，以及请求被进一步转发以找到想要的块的次数（缓存命中/未命中模拟）

例如，访问数据时的大量未命中意味着只有少数节点拥有请求的数据，并且他们没有时间将这些数据分发给每个节点。接收/发送的 P2P 流量允许识别处理网络配置或通道问题的节点。

区块链节点的系统指标

区块链节点的标准体系指标在大量源码中都有描述，下面就做一个简单的介绍。它们有助于发现逻辑瓶颈和错误。

中央处理器

CPU 显示处理器执行的计算量。如果 CPU 负载很高，则意味着节点正在使用逻辑或 FPU 进行主动计算（区块链中几乎从未使用过）。例如，后者可能是因为节点正在检查电子签名、使用强密码处理交易或进行复杂计算。

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

内存

现代区块链使用键值数据库（LevelDB、RocksDB）不断在内存中存储“热”数据。由于错误或对节点代码的攻击，任何加载的服务都会遭受内存泄漏。如果内存消耗增加或急剧增加，很可能是由于大量的状态数据库键、大的事务队列或不同节点子系统之间的消息量增加。

内存负载不足表示区块数据限制或最大事务复杂度可能增加。

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

网络

主要的网络指标是流量大小（以字节为单位）、发送和接收的网络数据包数量以及丢包率。这些指标经常被低估，因为区块链还不能以 1Gbit/s 的速度处理交易。

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

存储

磁盘子系统是所有服务中最慢的组件，通常会导致严重的性能问题。过多的日志记录、意外的备份、不方便的读/写模式、大型区块链聚合，所有这些都可能导致节点严重减速或对硬件的过度需求。

使用磁盘的区块链事务日志的操作模式类似于使用预写日志（WAL）的不同DBMS。从技术上讲，事务日志可以看作是状态数据库的 WAL。

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

结论

总的来说，我们可以将指标分为：

1）区块链节点指标（出块数、处理交易数、处理时间、完成时间等）

2）P2P 子系统指标（命中/未命中请求数、活跃用户数、P2P 流量的数量和结构等）

3）系统节点指标（CPU、内存、存储、网络等）

每个组都很重要，因为可能存在限制其他组件操作的子系统错误。即使是少量验证节点的减速也会严重影响整个网络。

在共识和终结性算法中，最棘手的错误只发生在有大的交易流或共识参数变化时。他们的分析需要可重复的测试条件和复杂的负载场景。