以太坊节点消息传播带宽消耗 - 网络

总结 & TL;DR

ProbeLab 团队 ( probelab.io) 正在对以太坊 P2P 网络中 Gossipsub 的性能进行研究。 紧随我们之前关于以太坊 Gossipsub 网络中重复消息数量的帖子，在本帖中，我们调查了 GossipSub 级别的带宽消耗，即消息传播的带宽消耗。该研究的目标是识别消耗最大网络带宽份额的协议组件。该研究由 @cortze 和 @yiannisbot 共同撰写。

为了进行这项研究，我们构建了一个名为 Hermes 的工具，它充当 GossipSub 的监听器和追踪器 ( GitHub - probe-lab/hermes: A Gossipsub listener and tracer.)。 Hermes 订阅所有相关的 pubsub 主题并追踪所有协议交互。 此处报告的结果来自 3.5 小时的追踪。

研究描述： p2p 系统的分布式特性使得它们在计算、延迟和带宽消耗方面通常效率较低。 这是由于节点之间需要额外的交互来组织 p2p 网络，而没有中央机构在对等方之间进行桥接。 因此，处理对等点或内容发现、内容共享和消息广播等过程通常会成为挑战或瓶颈。

以太坊在这方面没有什么不同。 消息传播占据了以太坊网络中节点使用的大部分网络带宽。 本研究调查了 GossipSub 级别的带宽消耗。 目标是确定消耗最大网络带宽份额的协议组件。

TL;DR： 尽管我们的 Hermes 节点的配置在这种情况下并不代表以太坊网络中的标准节点，但 GossipSub 的带宽消耗数据验证了仍有很大的优化空间。

我们观察到，很大一部分带宽用于 SENT_IHAVE 消息（占总带宽的 23.4%，占总出站带宽的 30%）和 RECV_IHAVE 消息（占总带宽的 10%，占总入站带宽的 42%）。

最重要的是，这些发现验证了我们之前关于“Gossipsub gossip 机制的有效性”研究中提出的改进建议：Gossip IWANT/IHAVE Effectiveness in Ethereum's Gossipsusb network

考虑到一个节点不仅会收到重复的消息，还会生成重复的消息给其他节点，我们强烈建议推动 GossipSub1.2 计划，因为它将有效地消除接收或生成重复消息上浪费的带宽，这相当于总带宽的约 42%。

带宽消耗结果

注意：本研究中显示的带宽使用情况仅限于：

• Holesky 网络
• GossipSub RPC 调用
• 以下 GossipSub 主题：
  • beacon_block
  • beacon_aggregate_and_proof
  • sync_commmittee_contribution_and_proof
  • attester_slashing
  • proposer_slashing
  • voluntary_exit \* (检查 Hermes 问题 → Broadcasting of invalid `voluntary_exit` messages to mesh peers · Issue #24 · probe-lab/hermes · GitHub)
  • bls_to_execution_change
• SENT_IHAVE 和 RECV_IHAVE RPC 调用的带宽是根据每个 topic 字符串和其中的 msg_ids 的字节数计算得出的。

NetIn vs NetOut

该研究首先概述了发送与接收带宽消耗的比率。 下图显示，在 Hermes 节点上，大部分带宽来自我们发送给连接对等方的数据。

总出站带宽大约是入站带宽的 3 到 4 倍。 请注意，Hermes 与标准节点的不同之处在于，它保持了更多的对等连接（大约 250 个对等方）。 这显然对带宽使用有重大影响。 也就是说，虽然这些数字不能代表普通节点的绝对带宽使用量，但百分比分配仍然代表普通节点的带宽使用量。

缩小范围，我们观察到出站流量的比率为 700-800 KB/s，入站流量的比率为 200 KB/s。

\ bandwidth-in-out2000×1200 167 KB

基于每个事件类型的带宽

GossipSub 发送多种类型的消息，具有不同的目的。 从控制消息以保持网格稳定到纯消息或 gossip 的 IHAVE / IWANT 消息，以确保主机没有错过任何消息。 这些消息类型中的每一种都需要发送 RPC 调用，从而增加了发送和接收的网络流量总量。

以下图表隔离了每个事件的带宽。 第一个图表显示了原始 KB/s 随时间的变化，第二个图表显示了每个事件在总聚合中的百分比。

\ bandwidth-by-event2000×1200 241 KB

\ bandwidth-ratio-by-event2000×1200 115 KB

百分比表

| Event | % of total BW | % of Received BW | % of Sent BW |
| --- | --- | --- | --- |
| RECV_GRAFT | 0.000367 | 0.001565 | ———————— |
| RECV_IHAVE | 9.974349 | 42.537746 | ———————— |
| RECV_IWANT | 2.368042 | 10.099021 | ———————— |
| RECV_MSG  (duplicated) | 7.347250 | 31.333920 | ———————— |
| RECV_MSG | 3.640691 | 15.526507 | ———————— |
| RECV_PRUNE | 0.002973 | 0.012678 | ———————— |
| RECV_SUBS | 0.114559 | 0.488562 | ———————— |
| SENT_GRAFT | 0.002863 | ———————— | 0.003740 |
| SENT_IHAVE | 23.404913 | ———————— | 30.573967 |
| SENT_IWANT | 0.094569 | ———————— | 0.123536 |
| SENT_MSG | 53.049257 | ———————— | 69.298539 |
| SENT_PRUNE | 0.000164 | ———————— | 0.000214 |
| SENT_SUBS | 0.000003 | ———————— | 0.000004 |

从上面的图表中，我们可以观察到：

• SENT_MSG 事件是消耗最多网络流量的事件，占总网络流量的 53%，占总发送流量的 69%。

它在 500 到 700 KB/s 之间呈尖峰振荡，并且显然是消耗最多带宽的事件。

很难定义所有这些已发送消息在远程端产生的重复消息的比率。 但是，我们可以假设它会遵循与 RECV_MSG 类似的模式（每 1 个原始字节有 2 个重复字节）。

• 令人惊讶的是，就消耗的带宽而言，SENT_IHAVE 事件紧随 SENT_MSG 之后，占总带宽的 23.4%，占总出站带宽的 30%。 有趣的是，订阅消息频率高的主题（即使它们的大小很小）确实会对我们用于发送这些 IHAVE 消息的带宽产生影响。

每个 IHAVE 限制为 5,000 个消息 ID； 但是，如果消息 ID 为 40 字节，则每次心跳（以太坊的情况下为 0.7 秒）仍最多可累积 200KB 的消息 ID。

• RECV_IHAVES 占总带宽的 10%，占总入站带宽的 42%，入站网络带宽要求为 100KB/s。
• 以上两点表明，IHAVE 消息的总带宽远非可以忽略不计，几乎达到了 400KB/s，消耗了总出站带宽的 23% 和总入站带宽的 40% 以上。
• RECV_MSG 事件保持在第四位，占总消耗带宽的 11%，其中只有 3.6% 属于唯一的或原始消息，其余 7.3% 属于重复项。 就整体入站带宽而言，它们分别代表原始和重复接收消息的 15% 和 31%。
• 在较低的比率下，整个 RECV_IWANT 消息列表保持在较低的总带宽使用量的 2.3% 以内，这代表了总接收字节的 10%。

与实时节点的比较

为了验证之前从 Hermes 的 GossipSub 模块中获取的测量结果，我们将带宽使用率与标准运行的以太坊节点进行了比较：

• 家庭设置中的本地 Prysm 节点 (Holesky) 报告的平均接收网络流量为 386KB/s，发送网络流量为 580KB/s。

虽然数字可能略有不同，但这些测量结果考虑了 Beacon 节点 docker 容器的全部流量，其中包括：

• 对等点发现
• 按范围或根请求/响应，如 beacon_blocs 或 blobs

MigaLabs 公共仪表板 在 monitor.eth 上显示的带宽使用量略高于我们测量的带宽使用量。 但是，尚不清楚该测量是否包括执行层。 报告的带宽报告显示平均入站 290KB/s 和出站 1.2MB/s，尽管它不包含许多数据点（每小时 5 个点），并且变化非常明显。

\ migalabs2000×1218 124 KB

结论与要点

尽管我们的 Hermes 节点的配置在这种情况下并不代表以太坊网络中的标准节点，但 GossipSub 的带宽消耗数据验证了仍有很大的优化空间。

我们观察到很大一部分带宽用于 SENT_IHAVE （占总带宽的 23.4%，占总出站带宽的 30%） 和 RECV_IHAVE （占总带宽的 10%，占总入站带宽的 42%）。

最重要的是，这些发现验证了我们之前关于“Gossipsub gossip 机制的有效性”研究中提出的改进建议：Gossip IWANT/IHAVE Effectiveness in Ethereum's Gossipsusb network

考虑到一个节点不仅会收到重复的消息，还会生成重复的消息给其他节点，我们强烈建议推动 GossipSub1.2 计划，因为它将有效地消除接收或生成重复消息上浪费的带宽，这相当于总带宽的约 42%。

即使目前，以太坊网络中主机的网络带宽使用量（大约入站 300 KB/s 和出站 1.1 MB/s，包括 EL）仍然只占 平均家庭 带宽可用性的一小部分，根据地区的不同，带宽可用性在 8MB/s 到 26MB/s 之间变化。

有关以太坊 discv5 DHT 网络的更多详细信息和每周网络健康报告，请访问 probelab.io。

• Gossipsub 消息传播延迟
• Hermes：以太坊 Gossipsub 网络的监控轻节点
• 家庭质押带宽研究在哪里？

• 原文链接： ethresear.ch/t/ethereum-...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～