以太坊中的带宽可用性：区域差异与网络影响 - 网络
- 以太坊中文
- 发布于 2024-12-03 14:38
- 阅读 22
本文由 ProbeLab 团队发布，旨在评估以太坊网络在 Dencun 升级后，特别是引入 Blob 交易后，对于增加 Blob 数量的承受能力。通过对以太坊主网上大量节点的带宽测量，分析了不同地区、不同基础设施和不同客户端的带宽可用性，以及在不同slot时间段内的带宽变化。研究表明，当前网络状态可以合理支持将 blob 目标值/最大值从 3/6 增加到 6/9。
本研究由 ProbeLab 团队的 @cortze 和 @yiannisbot 完成 ( probelab.io)，并获得了 EF 和 PeerDAS 社区的反馈。
简介
Dencun 升级是以太坊路线图上的一个重要里程碑，它引入了 Blob 交易和 Blob sidecar（通过 EIP-4844）。本次升级包括对底层网络的重大更新，现在底层网络必须通过 GossipSub 共享每个 slot 三个 Blob sidecar 的目标值（每个 128KB），上限为六个（通常被称为 "3/6"，分别指目标和最大 Blob sidecar）。
自升级以来，当前的网络没有出现任何重大中断或最终确定困难。网络中的节点可以适应当前的 Blob 目标和最大值，Blob sidecar 在 4 秒的传播窗口内很好地在网络中传播，这可以从 ProbeLab 关于区块到达的每周报告中看到：Week 2024-47 | ProbeLab。
然而，随着 L2 对更多容量的需求增加，关于 "网络可以轻松处理的最大 "目标/最大 "Blob 数量是多少？"的问题（questions）浮出水面，尤其是对于家庭质押者而言。
本研究的动机和目标是帮助定义 在网络中还有多少额外的带宽可以支持下一次硬分叉的 Blob 目标和最大值的增加。
在这篇文章中，我们：
- 介绍我们准备的测量方法和框架，以估计网络中节点的可用上传带宽。
- 介绍我们进行的全面带宽测量研究，在该研究中，我们测量了从
2024-11-23到2024-11-28的 6 天内以太坊网络中大多数在线和可达节点的带宽可用性。
总结
- 部署在欧洲或美国的节点中，有 60% 的节点的可用带宽超过 20Mbps，而部署在澳大利亚的节点中，只有 20% 的节点可以超过 20Mbps。这与澳大利亚的线路速度可用性无关，而是因为 65% 的以太坊节点位于欧洲或美国，因此在地理上远离亚洲节点。
- Slot 的第 1 到 4 秒，即区块传播发生的时间，在带宽可用性方面明显更满载。节点在这些秒内的带宽可用性降低了 9%-13%。
- 然而，即使在 Slot 中负载更高的时段（第 1 到 4 秒），我们从 4 个不同地理区域的测量表明，节点的平均可用带宽（无论是在云基础设施还是非云基础设施中）都保持在 18 到 23 Mbps 之间。这告诉我们，仍然有空间可以承载更多的 blob，尽管这将导致在这部分负载较高的 Slot 中带宽可用性进一步降低。
- 在我们为期 6 天的测量期间，我们发现 35% 的 Slot 根本没有 blob，而 42% 的 Slot 包含 5 到 6 个 blob。鉴于当前 3/6 的目标/最大 blob 值，我们进行的 42% 的带宽测量都是在几乎达到 blob 最大容量的情况下进行的。
- 鉴于目前关于将 blob 数量从 3/6 的目标值和最大值增加到 6/9 的讨论，所提出的指标与 EthPandaOps 最近的文章（link）相符，即在当前的网络状态下，这是一个合理的增加。 网络中已经有 50% 的 Slot 达到了目标 blob 数量或以上，而 35% 的 Slot 甚至没有相关的 blob。
-
同时，我们预计节点在 Slot 的第 1 到 4 秒，尤其是在假设 Gossipsub 不可避免地在网络中传播的重复消息数量的情况下，带宽可用性方面会面临压力。因此，至关重要的是开发并将节省带宽的改进应用于 Gossipsub， 例如以下 GH 问题和 ethresear.ch 中讨论的改进，因为在不久的将来需要进一步增加 blob 数量：
测量工具和研究准备
我们构建了一个名为 net-probe 的工具，它可以：
- 从 Nebula 爬虫中提取节点信息，该爬虫每 2 小时爬取一次以太坊
discv5网络。 - 通过 Hermes 连接到爬取过程中发现的每个节点。
- 从 Hermes 连接到的每个节点下载精心选择的数据量。
在执行完整的实验之前，我们必须确定应该从每个节点提取的正确数据量，以便：i) 饱和节点的上行链路，从而找出它有多少可用带宽，但同时，ii) 避免中断节点的操作。请注意，这些是以太坊主网节点，因此我们必须谨慎行事以避免任何中断。
我们测试了以下参数：
- 范围区块 RPC 调用请求：
1、5、10、20、30和40个区块。 10次重试，RPC 请求1、5、10和20个区块。5次重试，RPC 请求30和40个区块，以避免向这些节点发送垃圾邮件。
设置 RPC 大小
下图显示了对于我们设法连接的不同 RPC 大小请求的节点，我们可以测量的带宽（x 轴），即每个 RPC 请求的区块数量。
我们从不同测试研究的比较中得出以下结论：
- 发送
1、5和10个区块的 RPC 调用会产生截然不同的结果，请求更大的 RPC 大小会显示出更多的带宽可用性。这是一个明确的指标，表明需要增加 "每个 RPC 请求的区块数量 "值，因为我们似乎没有用较小的 RPC 调用来饱和节点的带宽。 - CDF 图显示，当我们请求每个 RPC
20、30或40个区块时，带宽测量几乎没有变化，这表明此 RPC 大小似乎在 TCP 连接上产生了足够的流量来饱和节点的上行链路带宽。
[]（https://ethresear.ch/uploads/default/original/3X/d/a/dae21bab3a73aadb52152c9c34acd5d9beabee26.jpeg "image"）_
_image1000×600 65.5 KB注意：54,463 个下载的区块的平均大小为 101.30 KB 的序列化数据和 47.76 KB 的压缩数据。
设置 RPC 重试
正如预期的那样，在连续 RPC 重试后观察到的带宽可用性（y 轴）也存在一些差异（下图中的 x 轴）：
- 前 2 个 RPC 响应未充分利用 TCP 连接中的可用带宽（请参见线图的上升趋势）。
- 在第 3 个响应之后，对于大多数 RPC 大小而言，测量变得非常稳定，即趋势趋于平缓。
[]（https://ethresear.ch/uploads/default/original/3X/e/7/e75865c2122b6bb1ed9cc9b6ee5e4e343d653d3e.jpeg "image"）
image1000×600 54.7 KB- 上图给人的印象是，较大的 RPC 大小请求会导致更高的带宽可用性。
- 但是，考虑到每次 RPC 重试成功响应的比例，我们看到请求大量区块确实会对响应的成功率产生影响。例如，请求 30 或 40 个区块在第三次重试后开始失败。此外，连续请求更大的 RPC 也会导致 RPC 重试的成功率更快下降。
[]（https://ethresear.ch/uploads/default/original/3X/3/4/34bf2c9f801c30d086f1fb5ebb21eb6f0b3c86f4.jpeg "image"）
image1000×600 56.9 KB最终参数
鉴于上述观察，我们为我们的生产研究选择了以下值：
- 重试：
6个连续 RPC 请求 - RPC 大小：每次重试
20个区块 - 每次
2个节点的请求并发性 - 日期：
2024-11-23至2024-11-28 - 基础设施：来自以下区域的 AWS EC2 实例：
us-west-1- 加利福尼亚us-east-2- 弗吉尼亚eu-central-1- 法兰克福ap-southeast-1- 悉尼
- 结果统计样本：
- 我们在下面展示的结果是从
Nebula以太坊数据库中总共13,023个唯一节点在 6 天内获得的（这些日期内唯一的在线节点）。 - 我们从
9,179个节点收集了带宽测量数据，占在线和可达节点总数的 70.48%。
- 我们在下面展示的结果是从
带宽数据分析
总体带宽可用性结果
注意：该工具可以测量 3 种不同类型的带宽测量：
- 有效带宽：我们可以测量的序列化数据的字节数。
- 压缩带宽：我们可以测量的压缩数据的字节数。
- 线路带宽：在线路上共享的所有字节。
为了简单和完整起见，报告的其余部分将参考 "线路带宽"。
下图显示了我们从 net-probe 成功连接的 9,179 个唯一节点在这些 6 天内测量的平均线路带宽的 CDF。该图显示了从 net-probe 运行的每个区域体验到的带宽测量，因此该图可以按如下方式解读：
- 来自我们在美国和欧洲的
net-probe部署的带宽测量表明，40% 的网络节点以低于约 20Mbps 的速率提供区块。这也意味着剩余约 60% 的节点具有超过约 20Mbps 的上传容量。 - 同时，我们在悉尼的
net-probe部署只能以 20% 的网络节点达到 20Mbps 的上传速度（请参见ap-southeast-2区域的 y 轴上的 0.8 标记）。考虑到我们在 ProbeLab 观察到的节点地理分布显示几乎 65% 的网络节点部署在美国和欧洲，这也就不足为奇了。
[]（https://ethresear.ch/uploads/default/original/3X/8/c/8c34010b0e56c6fd15e5de5b4f9077ec1ed02050.jpeg "image"）
image1000×600 71 KB每个成功连接的 9,179 个节点的线路带宽的 CDF。请注意，该图已在 0 到 150 Mbps 范围内放大。
每个基础设施部署的带宽可用性（云与非云）
在下图中，我们展示了为不同类型的节点部署观察到的带宽，即托管在公共云基础设施上的节点与未托管在公共云基础设施上的节点。
我们观察到，与非云部署相比，在云提供商中运行的节点以更高的上传带宽速率提供区块，大约有 5Mbps 的额外可用带宽。
云部署和非云部署之间带宽可用性的这种微小差异表明，独立质押者（最有可能使用非云基础设施）正在为其节点部署投入足够的资源。
[]（https://ethresear.ch/uploads/default/original/3X/0/e/0e7f5402614db899c745b83bbc597c03005436ea.png "image"）
image1000×600 75.9 KB按节点的宿主类型（4,409 个云节点与 4,770 个非云节点）分隔的线路带宽的 CDF。
每个客户端实现的带宽可用性
通过远程节点的客户端实现比较上传带宽，下图显示了大多数客户端共享相似的分布，直到第 70 个百分位，Lodestar 除外，我们将在下面讨论它。从那时起，分布尾部的差异变得稍微明显。
我们从这项测量中得出的结论是：
- 不同客户端实现在带宽可用性方面没有重大差异。
- Lodestar 的性能似乎至少超过了其余客户端 10Mbps（在第 60 个百分位）。
- Lodestar 性能的提高很可能是由于其 80% 以上的节点位于美国或欧盟（link），正如我们之前所见，这些节点具有更高的带宽可用性。
[]（https://ethresear.ch/uploads/default/original/3X/1/a/1aaea5d67b3ff25da8630be7c51d2195bd8c3371.jpeg "image"）
image1000×600 68.9 KB按节点的客户端分隔的线路带宽的 CDF。
每个区域的带宽可用性
带宽测量以及延迟测量都受到数据生成位置的高度影响。因此，我们选择我们的 net-probe 部署来代表：以太坊节点部署最受欢迎的区域（美国和欧盟）以及地理位置最远的区域（澳大利亚）。下图提供了按大洲聚合的四个区域的节点的线路带宽的 CDF。测量表明，正如预期的那样，较远的区域呈现出较低的带宽可用性。在这种情况下，我们观察到：
- 大洋洲和非洲至少落后于其他地区 8 到 10 Mbps，提供的非常可观的 90th 百分位数低于 20 Mbps 标记。
- 亚洲和南美的节点在第 50th 和 80th 百分位数之间实现了 15 到 25 Mbps。
- 欧洲的节点与北美节点的带宽分布相匹配，直到第 40th 百分位数，之后转变为一直到 60 Mbps 的第 90th 百分位数的中位数 24 Mbps。
[]（https://ethresear.ch/uploads/default/original/3X/4/f/4f0ea9bdaf4ad9d884c90224a3f7029a326e80cb.jpeg "image"）
image1000×600 65.4 KB按节点的洲分隔的线路带宽的 CDF
每个 Slot 窗口的带宽可用性
每个以太坊 Slot 都分为不同的部分，每个部分都在 12 秒的 Slot 持续时间内分配给不同的职责。尝试将整个 Slot 时间的可用线路带宽相关联，下图显示了每个节点托管类型的每个节点在 Slot 内每秒的平均线路带宽可用性。我们观察到以下情况：
- 云托管节点具有更高的平均可用带宽，但云节点和非云节点的可用的带宽部分在整个 Slot 中都明显波动。
- 从 Slot 的第一秒到第四秒，带宽可用性明显降低，这是将区块和 blob 广播到网络的时间窗口。我们能够测量的带宽下降代表非云用户的 9.5% 到 10% 的下降，而对于位于数据中心的节点，带宽降低了 13%。
- 尽管可用带宽的平均量有所下降，但非云托管节点仍有约 19Mbps 的带宽可用，云托管节点仍有约 23Mbps 的带宽可用。这强烈表明，blob 数量目标值和最大值的小幅增加不应中断网络。
[]（https://ethresear.ch/uploads/default/original/3X/3/0/30889063c58c781c1e52ca0899a8d8fc0141ae7a.png "image"）
image1000×600 71.4 KB每个部署类型在 Slot 内随时间变化的平均线路带宽可用性。
整个 Slot 的 RPC 成功率
作为我们研究的副产品，我们捕获了我们在整个 Slot 中获得的成功 RPC 回复的数量，这些回复由我们可用的 "数据点数量 "表示。在 Slot 的第 2 秒和第 7/8 秒之间，数据点的数量（即成功的 RPC）有所下降，此时正在广播、传播和处理区块、blob 和证明。
[]（https://ethresear.ch/uploads/default/original/3X/3/9/39a6099f5247faa8a03ae8dc1823c91ffec8b77e.png "image"）
image1000×600 74.1 KB每个 Slot 秒的成功数据点的直方图。
每个区块的当前 blob 计数
从多个角度了解了节点带宽的可用性后，重要的是要了解在测量期间区块中包含了多少个 blob 交易。这方面很重要，以便评估 blob 计数增加的影响，即多少个 blob 导致了我们所看到的带宽可用性，以及有多少空间可以容纳额外的 blob。
下图显示了在 6 天的研究中，每个 Slot 中包含的 blob 数量。以下是我们的观察结果：
- 35% 的 Slot 根本没有 blob。
- 42% 的 Slot 包含 5 到 6 个 blob。
- 鉴于当前 3/6 的目标/最大 blob 值，我们进行的 42% 的带宽测量都是在几乎达到 blob 最大容量的情况下进行的。
- 假设当 blob 计数目标值和最大值增加到 6/9 时，需求将保持不变，我们可以预计在约 42% 的情况下，每个区块将有 9 个 blob，而在约 50% 的情况下，每个区块将有 6 个或更少的 blob。
鉴于以上所述，我们的看法是，我们没有看到对 11 月 28 日星期四的所有核心开发人员 CL 电话会议中讨论的当前所需的 6/9 的 blob 目标值和最大值有任何关键性的反对意见。
[]（https://ethresear.ch/uploads/default/original/3X/9/f/9f1ea004ccdd3f9c19f75bb736c01c79140efd9c.png "image"）
image1000×600 26.7 KB每个 Slot 的 blob 数量的 CDF。
结论
从这一系列广泛的测量中，我们得出以下结论：
-
至少代表了 65% 的网络（北美和欧盟的节点）的观点，我们测量到只有 30% 到 40% 的测量对等方报告的上传链接低于 20 Mbps 标记。
-
另一方面，当节点位于像悉尼这样更偏远的位置时，只有 20% 的连接超过了 20 Mbps。
-
我们需要记住，如果考虑到 80% 的区块至少实现了 2 的 snappy 压缩率，则此可用带宽实际上会翻倍。
-
部署在云基础设施中的节点似乎比非云节点至少多出 5 Mbps 的可用带宽。
-
在整个 Slot 时间内测量的带宽表明，在第 1 秒和第 4 秒之间，带宽可用性平均下降了 9% 到 13%。精准的时刻是区块加上 Blob 应该广播到网络的时间。
-
我们可以发现，在我们发送的 RPC 请求的成功率略有下降，在 Slot 的 "繁忙 "时刻，这可能会在一定程度上影响 PeerDAS 中 blob 的采样。
-
鉴于目前关于将 blob 数量从 3/6 的目标值和最大值增加到 6/9 的讨论，所提出的指标与 EthPandaOps 最近的文章（link）相符，即在当前的网络状态下，这是一个合理的增加。 网络中已经有 50% 的 Slot 达到了目标 blob 数量或以上，而 35% 的 Slot 甚至没有相关的 blob。
-
Status Update: `IDONTWANT` Message Adoption on Ethereum Mainnet
- 原文链接： ethresear.ch/t/bandwidth...
- 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～
