带你了解区块链网络性能的关键衡量指标！

衡量区块链性能的关键指标包括：1） 区块链节点指标（生产的区块数，已处理的交易数，处理时间，完成时间等） 2） P2P子系统指标（命中/未命中请求的数量，活跃用户的数量，P2P流量的数量和结构等） 3） 系统节点指标（CPU，内存，存储，网络等）

当一切都正常时，你通常不用担心区块链测试。我们将解释为什么最好不要搁置性能评估，使用什么指标并充分利用它。让我们来一探究竟吧。

TPS（每秒交易）

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

TPS指标来自分布式数据库。它们通常使用标准化的交易类型或交易集合（例如，INSERT， UPDATE，DELETE的数值与常量SELECTs的数值），并针对特定的集群或单独的机器进行配置。这样的“综合”指标无法反应所讨论的数据库或区块链的真实性能，因为在这样的系统中，交易处理时间可能会有所不同。

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

面向可用性的数据库认为，如果交易被简单的写入磁盘，那么它就是成功的。他们立即提供了更新的数据，并且速度非常快（尽管这个交易在将来可能会回滚）。

如果交易仅更新一个数据单元，则TPS将更高。如果交易更新许多数据单元（行、索引、文件），它们将彼此阻塞。我们在Oracle，MSSQL，PostgreSQL和MongoDB，Redis，Tarantool之间看不到任何“TPS竞争”，是因为它们的内部机制和任务相差很大。

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

1）在可重复条件下

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

3）使用各种类型的交易： - 研究的区块链典型（例如，主要加密货币的transfer（）） - 加载存储子系统（每笔交易都有相当大的变化） - 加载网络带宽（大型交易） - CPU加载（大规模密码转换或计算）

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

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

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

“TPS”涉及很多事情。请保持怀疑的态度，并询问一切细节。

区块链特有的指标

本地TPS

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

这个指标不是很可靠：如果选择另一个分叉链被选为主链，那么交易数据将会回滚，而测量的统计数据也必须回滚。在测试中，这一点常常被忽略。

“昨天我们的区块链达到了8000tps”。这样的数字经常可以在简短的项目报告中看到，因为它们很容易测量。只需要一个运行节点和一个加载脚本就足够了。在这种情况下，全网达成共识的速度不会因为网络延迟而降低。

该指标反应了状态数据库在不受网络影响的情况下的性能。这个数字没有反映真实的网络带宽，而是显示了如果共识和网络足够快，那么它努力能达到的极限在哪。

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

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

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

本地区块产生的数量

这个简单的指标显示了某个特定验证节点生产的区块数量。它取决于共识，并且对于评估单个验证节点网络的“有用性”至关重要。

由于验证节点在每个区块上都能赚钱，所以他们会确保他们的机器稳定和安全地运行。你可以确定哪个验证节点候选人是最合格、最受保护的，并且准备好在具有真实用户资产的公共网络中工作。指标度量可以公开检查，只需下载区块链并计算区块数量即可。

最终确定性&最终不可逆转的区块

最终确定性确保了所有包含在区块链中的交易都不会回滚，也不会被另一个分叉链所替换。这是PoS网络防范双花攻击和为用户确认加密货币交易的一种方式。

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

最终确定性的算法互相之间也有所区别，相交，并由主要共识而结合（请阅读：以太坊中的Casper，EOS中的Last Irreversible Blocks，Essence中的GRANDPA和ParityPolkadot中的GRANDPA及其修改，例如MixBytesRANDPA）。

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

P2P层

点对点子系统作为区块链网络的中间层经常被忽略。这要归咎于区块交付和验证节点之间交易的模糊延迟。

当验证节点的数量很少时，他们是本地化的，用户列表是硬编码的，所有的一切都运行正常并且非常快速。但是，验证节点在地理上是分布的，并且模拟丢包情况，我们正面临严重的“TPS”故障。

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

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

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

重要的P2P指标可以是：

1）入站出站的流量2）链接到用户成功/失败的数量3）返回了之前缓存的数据块的次数，以及进一步转发请求以找到所需块的次数（缓存命中/未命中模拟）

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

区块链节点的系统指标

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

CPU

CPU显示处理器执行的计算量。如果CPU负载很高，表示节点正在使用逻辑或FPU（几乎从未在区块链中使用）积极地进行计算。例如，后一种情况会发生是因为节点正在检查电子签名，使用强密码处理交易或进行复杂的计算。

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

内存

现代区块链使用键值数据库（LevelDB，RocksDB），这些数据库不断在其内存中存储“热”数据。任何加载的服务都会遭受，由于错误或针对节点代码的攻击，所导致的内存泄露。如果内存消耗正在增加或急剧增加，则很有可能是由于状态数据库密钥数量大，交易队列大，或者不同节点子系统之间的消息量增加所造成的。

内存负载不足表明可能会增加区块数据限制或最大交易复杂性。

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

网络

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

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

存储

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

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

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

结论

综上所述，我们可以把指标分组成：

1）区块链节点指标（生产的区块数，已处理的交易数，处理时间，完成时间等）2）P2P子系统指标（命中/未命中请求的数量，活跃用户的数量，P2P流量的数量和结构等）3）系统节点指标（CPU，内存，存储，网络等）

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

在共识算法和最终确定性算法中，最棘手的错误只出现在大型的交易流或共识参数更改时。它们的分析需要可重复的测试条件和复杂的负载场景。