使用devnets理解以太坊网络限制

目的

以太坊上的 Dencun 升级将 blobs 的概念引入以太坊。这些blobs代表了每个节点都需要在一定时间内存储的数据。随着关于在 Pectra 中增加 blob 的讨论，我们希望在各种极端情况下运行网络，以找出我们可能面临的潜在问题。我们认为两个重要的测试场景是在非最终性时期后的远程同步，以及资源受限节点的网络。

常规设置

• 100万验证者，516个主机（地理分布在10个区域）
• 8核/32GB内存，以确保客户端有足够的资源
• 主网客户端分布
• 健康的 blob 和交易 gossip（平均每个slot 3个blob）

实验

1. 5%的千兆节点，95%的节点具有20mbps/10mbps的下载/上传连接。
2. 80%的千兆节点，20%的节点具有100mbps/20mbps的下载/上传连接。非最终性持续约1天，然后节点重新启动以进行同步。
3. 一个扁平网络，每个节点包含100mbps/50mbps的下载/上传连接。非最终性持续约12小时，然后节点重新启动以进行同步。
4. 一个扁平网络，每个节点包含50mbps/25mbps的下载/上传连接。
5. 一个扁平网络，每个节点包含30mbps/15mbps的下载/上传连接。一些节点关闭2小时以测试同步时间。
6. 一个扁平网络，每个节点包含20mbps/10mbps的下载/上传连接。

汇总学习

• 我们对以太坊 P2P 层的心理模型可能需要一些修改，我们对具有相等低带宽节点的扁平网络的心理模型可能不适用于我们当前的 DA 设置。ProbeLabs 的分析也表明存在一个由更快和更慢节点组成的混合网络。扁平网络风格的测试可能仍然有助于理解如何在最坏情况下设计升级。
• 在非最终性时期后的远程同步时间似乎是合理的，发现的问题可能在于对等连接错误或范围请求优化。
• 客户端在 20mbps/10mbps 时的瓶颈似乎是在 slot 时间限制内获取数据以验证 DA（可能是由于对等速率限制或其他限制）。然而，在千兆链接下，DA 数据获取瓶颈似乎已得到解决。但是，节点仍然需要约 20 分钟才能同步到头部（理论上线速度下载数据需要 20 秒）。远程同步的瓶颈似乎与原始带宽无关（大多数节点的流量峰值都在 100mbps，因此它们有 10 倍的带宽余量），而是与批量验证/对等连接/速率限制/对等下载限制有关，我们可能需要在未来的测试中缩小范围。
• 即使在主要由千兆节点组成的网络中，也没有节点使用超过约 160mbps 的流量。这意味着千兆节点仍然有约 5 倍的带宽余量来提供数据。
• 在应用了 100mbps/50mbps 速率限制的网络中，所有节点都达到了 50mbps 的带宽使用率（包括上传和下载）。尽管下载带宽限制在 100mbps，但这表明从各个对等方而不是单个对等方获取数据时存在潜在瓶颈。
• 只有当我们低于 30/15mbps 的下载/上传速度时，网络才开始有意义地退化。总投票数可能仍然很高，但我们确实观察到较低的头部投票百分比。在 20mbps/10mbps 下载/上传速度的扁平网络中，退化非常明显，而网络仍然能够完成最终确定。
• 在这些压力场景中触发的批量获取、速率限制以及对等连接中的潜在错误似乎需要进行优化。
• 该 devnet 呈现了一个“干净”的 EL 状态，没有真正的 EL 负载或限制。未来潜在的实验可以尝试主网 shadowfork 以找到 EL 相关的瓶颈。对主网的估计表明，这平均会为每个批次增加约 20 秒，或者每个块增加 300 毫秒的可接受开销。

结论

• 该网络表明客户端不仅仅受到带宽的限制，相反，它们仍然可以应用一些优化来帮助提高同步和对等连接性能。这些优化可能会带来其他权衡，我们需要研究潜在的前进道路。
• 这些优化可能已经可以帮助今天的主网，并且无论我们决定将 blob 计数从当前的 3/6 限制增加多少，都是必需的。
• 在非最终性时期后的远程同步能够在合理的时间内完成，并将受益于一些优化/对等连接错误修复。
• 完成的分析不假设任何 blob 审查或时序游戏。在高波动性事件中，我们可能会看到更多的构建者审查。如果我们要增加最大值，我们可能会看到类似于[0,0,最大值,最大值,0,0,0,最大值,最大值,最大值]等的模式，这与每个 slot 的常见稳定目标 blobs 比率不同。
• 我们需要更多关于get-blobs优化已经提供的和潜在的可以提供的益处的研究
• 我们需要在更多的功能 devnets 上进行带宽限制，可能作为我们基于主网测量的堆栈的默认设置

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