Kusama首批平行链网络稳定性报告：总体平稳，唯一问题在于停顿

我们的监控集中在 4 个关键领域：

• 出块稳定性

• 批准投票统计

• 网络连接

• 网络加载

我们从选择加入的验证人中进行了采样，以通过 Prometheus 和 Grafana 两个监测性能的工具来收集信息，如下图所示。

在理想情况下，协议的当前迭代中，每个平行链为每 2 个中继链块生成一个块。我们可以通过将平行链上线期间产生的中继链块的数量除以该时间段产生的平行链块的数量来确定每个平行链的出块率。

下表显示了截至最近的区块编号 (#) 的 6 个当前平行链的值。

由于所有这些平行链都由相同的验证人集保护并由随机验证人验证，所以验证人向平行链提供的服务应该没有重大差异。

网络噪音的影响此时不值得考虑，因为在过去的几天里，平行链没有足够的时间反复暴露于支持验证人的所有可能组合。但是噪音当然不能解释 Shiden（还有 Khala，在较小程度上）与其他平行链之间的巨大差异，这些平行链主要占据理想值的 5% 到 10% 之间的范围。值得注意的是，Statemine 在推出的前几周经历了一段艰难的时期，这导致它每分钟仅产生一次区块，并且当前的数据因最初的问题而有所偏差。

这种差异有两种可能的解释。真正的原因可能是两者之一或两种都有：

1. 繁重的平行链执行或数据

2. 收集人与验证人的连接性较差

目前，提供给收集人和验证人产生平行链块的时间窗口非常短，这使得系统脆弱并且在通信中经历短暂的延迟。对于这两个问题，长期的解决方案是改进平行链协议，为下一个平行链区块的创建留出更长的时间。一个短期的解决方案是将收集人的地理位置更靠近大部分验证人节点的位置。然而，这会造成暂时的区域集中风险 —— 长期解决方案可以减轻这种风险。

批准投票协议负责提供平行链的大部分安全性。它与 GRANDPA 的最终性协议紧密集成。粗略地说，节点被随机选择来检查平行链区块的有效性。需要一定数量的节点来完成包含候选者的中继链块，并且宣布他们打算检查但不跟进的“未出现”将被自动替换。关于有效性的争议升级到整个验证人集，导致至少一个验证人被 Slash 惩罚。

为了对批准投票进行基准测试，我们可以观察到以下几点：

• 验证人的 GRANDPA 最终性滞后意见

• 验证人分配的平均“ 部分（tranche）”（理想情况下 = 0）

• 验证人分配和批准的数量

最终延迟

上图显示了对数标度（logarithmic scale），应该落后于中继链最终确定性的区块数量的最大和平均意见。每个验证人都有自己的意见，基于验证人对中继链引用的每个平行链块的批准状态的看法。

大多数情况下，这是在 2 到 5 之间。然而，它偶尔会跳到 50。这些事件有点令人震惊 —— 50 块有一个故障保护，很明显，每隔几周就会被击中一次。

目前正在调查这些最终失速事件。我们将提出治理解决方案，以在 Polkadot 平行链发布之前解决这个问题。

平均Tranche

每个验证人在技术上都被分配来检查每个平行链块。唯一的问题是什么时候 —— 通常只有第 0 批验证人被实际征召进行检查，并且只有在第 0 批验证人未能出现时才会出现后续的一批。

上图表明，除了最终失速事件外，第 50 和第 95 个百分位数分配的部分通常为 0。

分配和批准

该图展示了验证人在网络上的分配如何转化为相应的批准投票。我们可以看到所有分配都被转换为批准，尽管其中大多数报告为过时。该数据与报告的最终延迟不一致，因为“过时”批准是那些在最终确定后变得无关紧要的批准。

几乎根据定义，大多数批准不应该是陈旧的，因为它们首先是最终确定所必需的。此类别有可能被节点或 Grafana（一个性能监测工具）误报。在 Rococo，相应的图表显示了分配和成功批准的近乎 1:1 的映射。

在 Kusama 上，有 900 个验证人，每个 session 中随机选择 200 个参与平行链共识。每个当前验证人都旨在连接到当前活跃验证人集中的验证人以及最后 6 个 session。

有许多验证人有大约 200 个连接，这是因为它们是旧验证人集的一部分。作为当前验证人集的一部分的验证人应该会遇到更高连接性的峰值。我们可以看到，在很大程度上，我们在网络中检查的验证人是过度连接的，并且连接到验证对等集上的其他 899 个验证人中的大多数。这对正确性没有问题，但确实为提高效率提供了机会。

一些验证人连接不足，并没有像应有的那样插入到传播网络。尽管如此，没有一个验证人的连接数少于 100，因此信息应该被验证人传播，尽管要经过更多的跳跃。

某些请求需要点对点通信，因此，所有验证人都必须可以通过已发布的节点地址公开访问。节点软件自动执行此功能，但节点运营商负责确保节点可访问。

该图显示了每秒发出的块请求数，以及不同类型的失败数。这里的请求类型并不重要，关键是“拨号失败”失败（下图中的黄线）几乎正好是请求数量的 10%。这表明 10% 的验证人在其发布的地址上无法访问。

此图显示验证人在内核中的 CPU 使用率。大多数验证人都在 1.5-2 core 利用率范围内。我们目前的建议是让验证人使用 4 核 CPU 运行，因此 CPU 利用率在预期范围内。

此图按任务显示 CPU 使用情况细分。前 3 个任务支配 CPU 使用率，降序是“libp2p-node”、“network-worker”和“grandpa-voter”任务。这些任务主要与网络相关，这表明网络利用率的优化将大大降低节点的 CPU 利用率。

节点使用的大部分用于传播的流量发生在 /polkadot/validation/1 网络协议上。这会汇总节点之间的所有信息，并占网络流量的很大一部分。该图显示，总体而言，验证人的平均网络带宽非常稳定的在 400-500KB/s 之间，“输入”带宽略大于“输出”带宽。

节点使用的大部分请求/响应带宽都在块分布协议中。有 200 个验证人和 1MB 的最大 PoV 大小，块的峰值约为 15KB。在这些平均请求/响应速率下，这意味着大约 307KB/s 的输入和 138KB/s 的输出带宽。然而，目前 PoV 非常小，因为平行链还没有接近峰值交易量。

总体来说，网络运行平稳。尽管平均对等点数和网络带宽在整个网络中看起来是一致的，但仍有一些异常节点过度连接并经受了更高级别的网络带宽。

在目前的环境下看，强大的 4 核 CPU 和 64GB 内存以及快速的互联网连接的长期推荐已经绰绰有余。当前的带宽使用似乎在 8-16Mbps 的范围内，因此一个典型的 100Mbps 数据中心连接足以维持最后 5 个。

唯一的主要问题是网络遇到的不常见的区块最终性的停顿（finality stalls）。这些停顿被故障保护装置捕获，因此没有造成太大损害，但我们正在调查根本原因，会在 Polkadot 启动平行链之前提出解决方案。

原文链接：https://polkadot.network/network-stability-report-kusama-with-parachains/

翻译：波卡第一中文社区