Gossipsub 消息传播延迟 - 网络
- 以太坊中文
- 发布于 2024-07-06 11:27
- 阅读 23
本文是 ProbeLab 团队对以太坊 P2P 网络中 Gossipsub 性能的研究报告，重点分析了 Gossipsub 的消息传播延迟，即消息传递到网络中所有节点所需的时间。研究结果表明，98% 的消息在 4 秒内到达，Lodestar 客户端的消息到达时间相对较慢，位于网络核心区域的节点接收消息更快，但消息大小与到达时间没有明显相关性。
概要和 TL;DR
ProbeLab 团队 ( probelab.io) 正在对 Ethereum 的 P2P 网络中 Gossipsub 的性能进行研究。继我们之前关于 Ethereum 节点消息传播带宽消耗 的帖子之后，在这篇文章中，我们调查 Gossipsub 的消息传播延迟，即消息传递到网络中所有节点所需的时间。该研究的目标是识别消耗最大网络带宽份额的协议组件。该研究由 @cortze 和 @yiannisbot 共同撰写。
为了进行这项研究，我们构建了一个名为 Hermes 的工具，它充当 GossipSub 监听器和示踪器 ( GitHub - probe-lab/hermes: A Gossipsub listener and tracer.)。Hermes 订阅所有相关的 pubsub 主题并跟踪所有协议交互。
研究描述： 消息传播和到达时间是区块链网络的敏感指标。我们假设消息将“尽可能快地”到达每个节点，但在某些情况下，仅仅因为网络核心实现了快速消息传递时间，并不意味着消息传播到整个网络是及时完成的。
在 Ethereum 的特殊情况下，由于消息传递的截止时间非常严格，因此确保消息在 4 秒窗口内到达对于降低分叉的可能性至关重要。
在本研究中，我们将近似整个网络的平均消息传播延迟。
TL;DR: 尽管只有 3 天的相对较短的数据集，但我们可以高度确信地观察到：
- 98% 的消息在 4 秒标记之前到达。
- Lodestar 似乎是在消息到达时间方面最慢的客户端，尽管这可能与在特定实现中跟踪到达的时间有关。
- 位于或靠近网络核心的节点（NA 或 EU）在更快地接收消息方面确实具有某些优势。尽管跟踪到的位置没有显示任何令人担忧的行为，但值得指出的是，额外的地理中心化可能会进一步加剧差异。
结果
本报告中的结果来自 EF 的 Xatu 公共数据集。我们从 beacon_api_eth_v2_beacon_block 表中获取了 3 天的数据（从 6 月 14 日到 16 日）。
Slot 内的到达 CDF 时间
该研究首先计算所有块在其所属的 slot 内的到达时间。该计算基于 slot 编号和自创世以来的时间完成，因为每个 slot 持续 12 秒：
time_within_slot = arrival_time - (genesis_time + (slot * 12))
此测量至关重要，因为任何超过 4 秒标记的块到达都可能在网络的某些部分产生分叉（因为它可能开始接收非提议块的证明）。
在第一个图中，我们观察到 98% 的块在 4 秒标记内到达，仅剩下 2% 的块超过了它。
\
CDF-propagation-latency1000×600 26.3 KB
这些数据来自以太坊基金会控制下的哨兵节点。这些节点包括每个位置的所有主要客户端实现，如下表所示：
| 大洲 | 国家 | 客户端 |
|---|---|---|
| 欧盟 | FI | lighthouse |
| lodestar | ||
| nimbus | ||
| prysm | ||
| teku | ||
| 北美 | US | lighthouse |
| lodestar | ||
| nimbus | ||
| prysm | ||
| teku | ||
| 大洋洲 | AU | lighthouse |
| lodestar | ||
| nimbus | ||
| prysm | ||
| teku |
当比较不同哨兵节点的到达时间时（下图），我们确实看到了它们之间的一些细微差异。Lodestar 的例外情况引起了我们的注意，因为它的分布中有一个不太均匀的尾部。但是，其余客户端遵循相似的趋势，99% 的消息在最初的 4 秒内到达。
由于此数据是从标准的 event streamer Beacon API 收集的，因此很难解释每个客户端实现中的差异，因为不仅 libp2p 代码库是用不同的语言编写的，而且消息到达的时间戳也可能在消息验证逻辑的不同时刻。
\
gossipsub_arrival_times_within_slot_by_agent_on_mainnet_beacon_block1000×600 46.4 KB
我们预计会看到来自不同地理位置的不同到达时间，因为网络地理分布似乎集中在欧洲和北美国家（链接到分布）。下图显示，尽管国家或大陆之间确实存在差异，但这些差异很小，所有 CDF 分布都显示 98-99% 的块到达在 4 秒标记内完成。
\
gossipsub_arrival_times_within_slot_on_by_country_mainnet_beacon_block1000×600 37.5 KB
\
gossipsub_arrival_times_within_slot_on_by_continent_mainnet_beacon_block1000×600 37.8 KB
到达时间
先前的 CDF 显示几乎所有块到达都发生在预期的时间范围内。但是，这些图未显示异常值，因为 CDF 对突然的网络扰动不敏感。
因此，以下图显示了 4 个 epoch（1536 秒）的时间窗口内的 maximum、median、mean 和 minimum 块到达时间。
我们没有发现 minimum、mean 和 median 分布在 3 天期间内有很大的变化。但是，我们确实看到最大到达时间变化很大。我们可以观察到到达时间从 4 秒到几乎 12 秒不等，几乎超过了整个 slot 持续时间。
\
msg-arrival-overall1000×600 74.6 KB
有趣的是，在比较不同客户端实现的平均到达时间时，存在差异。Lodestar 似乎是最后一个在网格中接收消息的客户端，并且呈现出相当高的方差，而 Teku 似乎是第一个接收消息的客户端，其次是 Prysm。
\
msg-arrival-by-agent1000×600 137 KB
按大陆划分的到达时间分布也观察到类似的模式。正如我们可以预料的那样，欧洲节点比北美和大洋洲节点更快地接收消息。尽管差异不显着，但 0.6 秒仍然使到达保持在安全范围内。但是，这仍然表明在延迟较低的地区（或者换句话说，在网络核心周围）定位节点存在一些延迟激励（但是，反过来，这将导致更多的地理中心化）。
\
msg-arrival-by-continent1000×600 96.4 KB
到达时间与消息大小之间的相关性
当尝试将我们的发现与之前 ethresear.ch 博客文章 中描述的专门调查此问题的文章相关联时，我们尚未能够看到大小与区块到达时间之间的任何主要相关性。尽管三天内实现的块大小分布并不完全具有代表性，但下图显示，大多数块保持在 50KB 到 150KB 的范围内，并且具有相似的 1 到 3 秒的到达时间。
\
msg-arrival-vs-size600×600 63.4 KB
结论和要点
尽管只有 3.5 小时的相对较短的数据集，但我们可以高度自信地观察到：
- 98% 的消息在 4 秒标记之前到达。
- Lodestar 似乎是在消息到达时间方面最慢的客户端，尽管这可能与在特定实现中跟踪到达的时间有关。
- 位于或靠近网络核心的节点（NA 或 EU）在更快地接收消息方面确实具有某些优势。尽管跟踪到的位置没有显示任何令人担忧的行为，但值得指出的是，额外的地理中心化可能会进一步加剧差异。
有关更多详细信息和 Ethereum 的 discv5 DHT 网络的每周网络健康报告，请访问 probelab.io。
- 原文链接： ethresear.ch/t/gossipsub...
- 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～
