在前 5 次平行链拍卖后，我们监控了 Kusama 网络的稳定性。此时，网络上有 6 条平行链。
我们的关注点主要集中在 4 个关键领域：
候选项目稳定性
批准投票统计
网络连接
负载情况
我们从选择加入的验证器中采样了指标，旨在收集 Prometheus 和 Grafana 的信息，详情请见下文。
候选项目稳定性
在理想情况下，每个平行链会为每 2 个中继链生成一个块。我们可以通过将平行链上线期间产生的中继链块的数量除以该时间段产生的平行链块的数量来确定每个平行链的出块率。
下表显示了截至为止，最近区块编号 (#) 当前 6 个平行链的值。
由于所有这些平行链都由相同的验证器集保护并由随机验证器验证，所以验证器向平行链提供的服务应该没有较大的差异。
网络噪音的影响此时无需考虑，因为在过去的几天里，平行链没有足够的时间反复暴露于支持验证器的每个可能的组合中。但是噪音不能解释 Shiden 与其他平行链之间的巨大差异，这些平行链主要占据到理想值的 5% 到 10% 之间的范围。值得注意的是，Statemine 在推出的前几周经历了一段不稳定的时期，这导致它每分钟仅产生一次区块，并且当前的数据也因最初的不稳定而有所偏差。
DeFi衍生品协议Vega宣布将于9月发布第一版软件:DeFi衍生品协议Vega宣布将于9月发布第一版协议软件，独立验证节点将能够运行首个Vega网络，开启受限主网的阶段，也是三个启动阶段中的第二步。在该阶段中，公共的Vega链将上线，可以进行质押和治理。在受限主网的阶段中，将有13名验证者，之后社区可以逐渐增加验证人的数量。[2021/7/28 1:20:32]
这种差异有两种可能的解释。真正的原因可能包含以下两种：
大量平行链执行程序或数据
收集者与验证者的连接性较差
目前，给收集者和验证者产生平行链块的时间窗口非常短，这使得系统变得很脆弱并且在通信中会经历短暂的延迟。对于这两个问题，长期性的解决方案是改进平行链协议，为下一个平行链区块的创建留出更长的时间。短期性解决方案是将收集者定位在地理位置上更靠近大部分验证者节点的位置。然而，这会造成暂时的区域集中风险 —— 长期解决方案可以减轻这种风险。
批准投票
批准投票协议负责提供平行链的大部分安全性。它与 GRANDPA 最终协议紧密集成。总体而言，即随机选择节点来检查平行链区块的有效性。这一过程需要一定数量的节点来完成包含候选者的中继链块。关于有效性的争议会升级到整个验证器集，最终将导致至少一个验证器被削减。
为了对批准投票进行基准测试，我们可以观察以下几点：
验证者 GRANDPA 最终滞后意见
验证者分配的平均“部分”（理想情况下 = 0）
验证者分配和批准的数量
最终延迟
Bitget合约大数据中心：BTC合约多头保持优势，BTC震荡或持续:据Bitget合约大数据中心行情播报，截至今日11:00，Bitget交易所BTC/USDT合约过去24小时交易量高达8.2亿余美金，其中：盈利用户占比41%，多头盈利45%，空头盈利19%；亏损用户占59%，多头亏损15%，空头亏损21%。此外，Bitget正向合约当前盘口价差在0.5USDT左右，合约基差在0.2USDT左右。[2020/9/10]
上图显示的是对数比例，最大和平均块数应该落后于中继链最终确定的区块数量。每个验证者都有自己的观点，基于验证者对中继链引用的每个 parachain 块的审批状态的感知。
大多数情况下，数据会在 2 到 5 之间。但有时会跳到 50。达到 50 个区块有一个故障保护，实际情况是每隔几周就会被击中一次。
我们将提出治理解决方案，旨在 Polkadot 平行链发布之前解决这些问题。
平均部分
每个验证器在技术上都被分配来检查每个平行链块。通常只有第 0 批验证者被实际征召进行检查，并且只有在第 0 批验证者未能出现时才会出现后续的批。
上图表明，除了最终失速事件之外，第 50 和第 95 个百分位分配的部分通常为 0。
分配和批准
该图展示了验证者在网络上的分配如何转化为相应的批准投票。该数据与报告的最终延迟不一致，因为“过时”批准是那些在最终确定后变得无关紧要的批准。
大多数批准应该是及时的，因为它们是最终确定结果所必需的内容。此类别有可能被节点或 Grafana 误报。在 Rococo，相应的图表显示了分配和成功批准近乎 1:1 的映射。
网络连接
在 Kusama 上，有 900 个验证者，在每个会话中会随机选择 200 个参与平行链共识。每个当前的验证器都旨在连接到当前的验证器集以及最后 6 个会话。
许多验证器有大约 200 个连接，这是因为它们是旧验证器集的一部分。作为当前验证器集一部分的验证器应该会遇到更高连接性的峰值。我们可以看到，在很大程度上，我们在网络中检查的验证器是过度连接的，并且连接到其他 899 个验证器中的大多数。
一些验证器连接不足，并没有像应有的那样连入网络。尽管如此，没有一个验证者的连接数少于 100，因此应该向验证者分享更多的信息。
某些请求需要点对点通信，因此，所有验证器都必须通过已发布的节点地址公开访问。节点会自动执行此功能，节点运营商负责确保节点可达。
该图显示了每秒发出的块请求数，以及不同类型的失败数。这里的请求类型并不重要，关键是“拨号失败”（下图中的黄线）几乎正好是请求数量的 10%。这表明 10% 的验证者在其发布的地址上无法访问。
负载（CPU 和网络）
此图显示了验证器在内核中的 CPU 使用率。大多数验证器都在 1.5-2 核心利用率范围内。我们目前的建议是让验证器使用 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 个会话。
唯一的问题是网络遭遇的停顿。这些停顿被故障保护装置捕获，因此没有造成太大损害，相关工作人员正在调查起因，并将在平行链在 Polkadot 上启动之前提出解决方案。
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。