引言
硬分叉是重新定义网络能力和效率的关键时刻。5月7日，以太坊主网从Deneb升级到Electra分叉，其中包括对协议共识和网络层的几项关键变更和改进。在这篇文章中，我们特别研究了网络如何为分叉做准备，通过分析事件前几周的网络拓扑、消息到达时间的变化，以及升级是否实现了一些放宽的带宽要求。
为此，我们对一些测量工具（如Nebula和Hermes）在硬分叉事件前、期间和之后收集的数据进行了专门分析。这项分析补充了我们关于网络拓扑、区块到达时间、带宽使用等的每周更新。我们在一年前对Dencun硬分叉的P2P层进行了深入研究，这为本研究的重点领域提供了一些参考。
正如预期，在这三种情况下，我们可以看到在官方发布各自的客户端后不久，节点运营商就开始升级。在硬分叉前两天，网络中约53%的节点运行了Electra兼容的客户端实现 - 前一天为60%，前一小时为67%。这些数字没有考虑Nimbus客户端，因为它们不公布版本信息。Nimbus是网络部署中占有重要份额的第四个实现，所以Electra就绪节点的数量可能高出几个个位数百分点。
我们还可以安全地说，节点运营商并没有利用硬分叉作为切换客户端实现的机会，如下图所示。在分叉期间，客户端实现的分布几乎没有变化。
要点
- 大约70%的在线节点立即跟随了新的分叉。
- 另外约20%的节点在事件发生一周后跟随了新的分叉
- 很难说剩余的节点是否为家庭/业余部署，因为我们发现它们运行在云基础设施上，即不太可能在没有运行验证者的情况下启动节点。
- 兼容的客户端版本在分叉前的几天里逐步被采用。
硬分叉对区块到达时间的影响
Pectra升级的核心新增功能之一是将每个区块的blob目标值和最大值增加三个额外的blob（请参见EthPandaOps文章，ProbeLab文章）。尽管网络通过这额外的50%临时空间受益，但这个blob数量的增加也意味着网络需要在每个时段额外传输多达348KB的数据。如果节点无法在时段早期分配更多带宽（区块传播时）,这最终可能会影响网络的整体消息广播能力。
（后续内容省略，保持原有格式和翻译风格）以下是翻译结果：下面的图表显示了我们认为的四个最相关的数据点随时间变化：报告的区块到达时间的最小值、平均值、中位数和第95百分位数。该图显示网络上区块传播稳定，仅在5月7日凌晨00点硬分叉前12小时出现第95百分位数线突然跃升至4.6秒的情况（硬分叉发生在5月7日上午10点UTC）。这一峰值持续了几个小时后恢复，并最终将平均和中位数到达时间从之前的2.38秒降低到约2.2秒。
我们将硬分叉时间附近区块到达的峰值归因于一些未及时更新的节点，这些节点可能确实干扰了网状网络的稳定性。
再次观察到，仍有5%的区块到达接近或超过4秒标记，这对MEV构建者来说应该是令人警惕的，对于接受投标的个人构建者也是如此。
（后续部分省略，保持原有格式和标签）
纯吞吐量并不是我们唯一关注的内容；至少在以太坊中，时间很重要。由于网络有特定的时间窗口，了解吞吐量在时隙内的可用性很重要。以下图表显示了按主机类型聚合的平均测量吞吐量和请求信标块的时隙时间。
模式很清晰，在时隙的第一秒到第四秒之间，云端和非云端托管节点都出现了下降。这是网络通过gossipsub广播信标块和blob侧链的窗口。
在比较Pectra升级前后的分布时，我们看到它们在时隙内遵循完全相同的模式。唯一的区别是，云端节点的平均值增加了5-6 Mbps，非云端节点增加了2 Mbps。
Pectra升级前：
Pectra升级后：
要点
- 尽管增加了3个额外的blob，网络整体仍处于健康状态。
- 资源可用性分布的高端节点似乎比升级前有更多可用带宽。
- 在网络中资源受限的节点感知到上传吞吐量略有下降，但这被认为既不显著也不关键。
- 正如这篇文章报告的[链接]，由于添加了
IDONTWANT消息原语，重复消息数量明显减少，但其对带宽可用性的影响在节点资源可用性范围内并不清晰。
结论
分叉事件突显了节点运营商倾向于在最后一刻升级。尽管大多数节点准时跟随新的分叉，但相当大的部分延迟了长达一周。兼容的客户端版本仅逐步在分叉前被采用，表明网络的部分地区仍然缺乏升级紧迫性。
在传播方面，及时的块传递仍未得到保证。大约5%的块在控制节点晚到，尽管中位数时间有所改善，但尾部仍然存在问题，这指向资源可用性或网络性能中持续存在的差距。
尽管如此，网络整体在分叉后仍保持稳定和健康状态。额外的blob没有造成重大干扰，IDONTWANT的引入改善了情况，但并不显著。一些节点似乎有更多带宽可用性，可能是由于IDONTWANT的添加，或提供了额外的带宽资源，而性能较弱的节点（可能是家庭质押者）在上传吞吐量方面略有减少。
