我要感谢Flashbots 、 Titan和Ultrasound团队慷慨分享数据。我还要感谢ethPandaOps 团队收集了证明和区块到达数据，并提供了 Xatu 的 ClickHouse 实例访问权限。最后，非常感谢 Thomas Thiery、Anders Elowsson、Barnabé Monnot 和 Marios Ioannou 的反馈和建议。
TL;DR
该分析研究了区块和证明的到达时间，涵盖了自 2025 年 8 月初以来的 1 周以太坊时隙。它旨在评估EIP-7782的可行性，该方案提议通过将证明截止时间设置为 3 秒、将聚合截止时间设置为 4.5 秒，将时隙缩短至 6 秒。
区块通常会在接近证明截止时间时到达（95% 百分位为 3.3 秒）。然而，纯区块传播时间（定义为自中继发布区块以来经过的时间）不到 1 秒。在 Ultrasound、Flashbots 或 Titan 区块的样本中，95% 百分位约为 800 毫秒。这表明，区块传播的起始时间并非仅用于区块传播，并且当前区块传播结构中的证明时序可能存在一些滞后。
错过时隙的证明（揭示了纯传播时间）平均在4秒后831毫秒到达。子网绝对多数在830毫秒内形成，而第95个百分位则需要1962毫秒。
对于区块头源自中继的时隙，见证消息在中继发布区块后不到 4.5 秒内到达（仍然低于建议的 6 秒时隙的 4.5 秒聚合截止时间）。分布呈现双模态，模态分别约为 1.2 秒和 3 秒。这两种模态的来源是进行见证消息的实体。这可能是由于网络连接、见证策略或配置错误造成的。
验证者实体是导致证明延迟的最主要因素。一些运营商的报告总是比其他运营商晚，而一个配置错误的实体就可能严重影响结果。区块内容也很重要：更高的 Gas 使用量和更多的区块会增加延迟的几率。
介绍
本报告包含对从 12243599 到 12293998 个时段之间以太坊节点收集的区块和证明到达情况进行分析的主要结果，这大约相当于 2025 年 8 月第一周的一周时段。
本次分析的目标是对EIP-7782的可行性进行初步了解，该方案提议通过将证明截止时间缩短至 3 秒、将聚合截止时间缩短至 4.5 秒，将时隙缩短至 6 秒。
我们的分析重点关注三个不同的指标，如下图所示。
首先，我们研究区块到达时间。区块到达时间对应于信标节点首次发现区块的时间。根据区块到达时间，我们计算两个传播指标：
- 区块到达时间与中继发布区块有效载荷时间之间的毫秒数。此区块传播指标在图中以黄色表示，旨在减少计时游戏的影响。然而，由于我们仅收集了 Ultrasound、Flashbots 和 Titan 中继的数据，因此此指标仅针对部分时隙进行报告。
- 区块到达时间与时隙开始时间之间的毫秒数。由于此指标不需要中继数据，因此我们可以报告完整的时隙样本。然而，由于计时博弈和区块构建逻辑，此指标高估了实际所需的传播时间。
其次，我们分析了错过时隙的见证消息。在这些时隙中，区块有效载荷从未可用，因此我们知道验证者等到了 4 秒的截止时间才进行见证。这使我们能够通过将见证消息到达信标节点的时间减去 4 秒来计算纯见证消息的传播时间。这也就是上图中的浅蓝色部分。
第三个也是最后一个指标试图估算区块通过 P2P 层传播所需的总时间，包括执行、验证和传播证明信息。它对应图中的黄色、粉色和浅蓝色部分。与区块传播指标类似，我们计算自中继发布区块以来的证明信息到达时间，以考虑时间博弈。我们使用 Ultrasound、Flashbots 和 Titan 中继共享的发布时间，与区块传播指标相同。
数据收集
- 中继发布时间由Flashbots 、 Titan和Ultrasound团队友情提供。数据集包含自时隙开始以来，中继通过将区块有效载荷发送到信标节点来响应
/eth/v1/builder/blinded_blocks请求所经过的毫秒数。 - 区块到达时间是从Xatu 的 Beacon API 事件流表中收集的。这些表包含由ethPandaOps 团队运行的内部节点以及选择与 ethPandaOps 团队共享指标的社区节点生成的事件。一方面，纳入社区数据提供了更广泛的信标节点和地理位置池。然而，这也带来了一个缺点——由于无法验证，数据更容易出错。用于收集数据的 SQL 查询可以在
beacon_blocks.sql中找到。 - 证明到达信息是从Xatu 的共识层 P2P表中收集的。我们筛选了数据，只包含由ethPandaOps 团队管理的一组节点生成的消息，这些节点运行着 Prysm 共识客户端的一个分叉版本，该客户端旨在收集 P2P 相关数据。收集错过时隙数据的逻辑可以在
atts_missed_runner.py中找到。收集中继时隙数据的逻辑可以在atts_sample_runner.py中找到。 - 验证器 ID 和验证器实体之间的映射关系是从ethseer.io收集的。这些数据可以直接在 Xatu 的 ClickHouse 实例中使用表
ethseer_validator_entity进行查询。我们在函数get_validator_ethseer_info中实现了此查询。
区块传播
在我们数据集中的 51139 个区块中，47.6% 没有中继数据。这些区块要么由其他中继提供，要么是自建的。其余 41.3% 由 Ultrasound 发布，5.8% 由 Flashbots 发布，5.3% 由 Titan 发布。每个区块都有 109 个社区节点和 29 个内部节点的区块到达记录。节点拥有各种客户端和地理区域。
聚焦于我们拥有中继数据的时隙子集，我们可以在以下两幅图中看到自区块发布以来，按节点客户端和节点国家/地区划分的区块传播分布。箱线图用彩色框显示了三个四分位数，用延伸线显示了上下四分位数之外的变异性。点表示异常值。
不同客户端之间存在一些差异，Lodestar 和 Caplin 的传播时间略长。回想一下，Caplin 是嵌入在 Erigon 执行客户端中的共识客户端。它与其他共识客户端类似，但完全集成在执行层中。
各国的情况也各不相同，其中荷兰的分布呈现出令人惊讶的倾斜。然而，在我们的数据集中，荷兰只有 99 个观测值，而其他国家/地区的观测值则在 4.5 万到 5 万之间，因此样本可能不具代表性。在荷兰之后，澳大利亚、印度和尼日利亚的传播时间更长。
无论观察到的变化如何，大多数节点仍然能在 1 秒内收到区块。自中继发布区块以来，区块传播时间的 95% 百分位数为：Xatu 内部节点 816 毫秒，社区节点 804 毫秒。下图显示了自中继发布区块以来，区块传播时间的累积分布函数 (CDF)。
最终图表按区块头源显示了自时隙开始以来区块到达时间的分布。正如我们之前所解释的，这高估了区块传播时间，因为它还包含了区块构建和与 mev-boost 交互所花费的时间。然而，它让我们能够了解中继时隙子样本与剩余时隙的比较情况。
有趣的是，没有中继数据的时隙传播时间略短，但它们显示出更多的异常值和更大的标准差。第 95 个百分位数相当，“其他”时隙耗时 3292 毫秒，而有中继数据的时隙耗时 3337 毫秒。这表明，使用中继数据观察到的时长可能是一个合理的估计。
此外，区块到达时间如此接近证明截止时间，而实际广播时间却不到 1 秒，这表明时隙的开始时间并非仅用于区块广播。因此，当前时隙结构中的证明时序可能存在一些滞后。
区块传播和区块大小之间的关系进一步证实了这一点。我们通常认为这两个指标呈正相关。然而，它们的相关性仅为 0.004。我们还可以从下方的散点图中看到它们之间的非线性关系。
有关更多图表和分析，请参阅笔记本2.3-beacon-block-arrivals-with-relay.ipynb 。
错过时段的证明时间
我们的样本中有 207 个缺失的时隙。对于每个时隙，我们都观察来自子网 0 和 1 的证明消息。我们有三个节点在四个地区（荷兰、印度、美国和澳大利亚）监听相同的子网。下图显示了所有这些证明消息传播时间的总体分布（即，自时隙中第 4 秒标记以来证明消息到达的毫秒数）。
正如预期，大多数证明消息的传播时间不到 1 秒，平均为 831 毫秒。然而，我们确实看到分布中存在一个较大的右尾，一些证明消息的到达时间晚于 1 秒。实际上，整体 95 百分位数为 2066 毫秒。
需要注意的是，我们看到的时间可能被高估了。由于错过了一些时间槽，所有见证者都会同时发送见证，从而导致 P2P 层的活动激增。在更正常的情况下，由于验证者接收和验证区块的时间略有不同，见证的发送速度会更慢。
查看接收节点区域的相同分布（在下面的箱线图中），我们发现尽管印度和澳大利亚节点显示的时间稍长，但差异并没有实质性差异（约 100 毫秒）。
分析证明消息时，另一个重要的考虑因素是证明消息的来源，即证明者。我们使用来自ethseer.io的映射，提取了证明者的验证者实体。然后，我们绘制了每个实体的传播时间（左侧）以及到达时隙中每个 50 毫秒桶的证明消息中每个实体的权重（右侧）。
 atts-prop-entity-1 3119×2382 421 KB |  atts-prop-entity-2 3343×2381 403 KB |
我们已经看到实体之间存在显著差异。仅凭客户端配置和地理位置信息，我们无法准确找出某些实体比其他实体的证明速度慢的原因。
Kiln 就是一个值得注意的例子。在我们的数据中，他们负责处理大量在 1500 毫秒到 3250 毫秒之间到达的证明，并且他们的中位传播时间最长。看到这些结果后，我们直接联系了他们，他们发现了客户端的一个错误配置，这显著缩短了他们的传输时间。在主要样本发布两周后，我们观察了 183 个错过时隙的样本（即时隙 12344420 到 12394820 之间），我们发现整体第 95 个百分位数从 2066 毫秒下降到了 1782 毫秒。此外，我们可以在下图中看到，Kiln 在后续证明中的权重发生了显著变化。这表明，更仔细地调查那些延迟证明的实体，以尝试解决延迟的根本原因至关重要。
到目前为止，我们一直在研究样本中所有时隙和子网的数据分布。然而，另一个相关指标是子网的第 66 个百分位。换句话说，给定一个时隙和一个子网，子网何时会观察到绝大多数的证明？下图展示了我们数据中各个时隙和子网的这一指标。请注意，这里我们取的是每个证明者观察到的第一个证明（即我们使用最快的节点）。有趣的是，所有缺失时隙的所有子网都花费了不到 830 毫秒的时间达到绝大多数。平均值为 640 毫秒。
同样的分析也可以用于 95% 的百分位数。分布如下图所示。现在的平均值是 1572 毫秒，而 95% 的百分位数是 1962 毫秒。
有关更多图表和分析，请参阅笔记本2.4-committee-attestations-missed-slots.ipyn 。笔记本2.5-committee-attestations-missed-slots-v2.ipynb包含相同的分析，但使用了 2 周后错过的时间段的样本。
认证到达
在这部分分析中，我们从区块传播部分使用的中继数据所在的时隙中随机抽取了 4963 个时隙样本。其中，80.4% 的区块头来自 Ultrasound，10.9% 来自 Flashbots，8.7% 来自 Titan。下图显示了所有时隙和所有子网的证明到达时间分布（以中继发布区块以来的毫秒数计算）。
在这里，我们可以看到一个清晰的双峰分布，众数分别在 1.2 秒和 3 秒左右。这意味着存在两组证明——快速和慢速。双峰分布的来源既不是头信息源（如下图所示，不同中继之间的分布非常相似），也不是特定的时隙（正如在各个时隙级别上相同的趋势所证明的那样）。
解释这种双峰形状的原因似乎是证明的来源，即进行证明的实体。这与我们对错过的时段的观察一致。然而，这种趋势在证明到达时间方面更加明显。
 atts-time-entity-1 3125×2382 426 KB |  atts-time-entity-2 3406×2382 418 KB |
如果没有更多关于证明者的信息（例如客户端配置和地理位置），就无法确定证明消息呈现双峰形态的确切原因。不过，存在一些可能性。其一可能是网络连接。更好的位置和对等连接有望加快证明消息的速度。其二可能是验证者实体实现的证明逻辑。一些实体会快速进行证明，以确保其证明消息准时到达。另一些实体则会等到观察到其他证明消息后再进行证明，以便更好地了解应该支持哪个区块，从而提高其证明消息成为规范的可能性。最后，与 Kiln 的情况类似，一些实体可能存在配置错误或使用的客户端版本不够理想。
除了整体分布之外，我们还计算了每个子网中 95% 的证明消息。换句话说，这是给定子网中 95% 的证明消息到达所需的时间（从中继器发布区块开始计算）。下方直方图展示了该指标在每个时隙和子网中的分布情况。
平均 P95 为 3590 毫秒，而 P95 指标的第 95 个百分位数为 4217 毫秒，仍然低于 6 秒时隙提案所需的 4.5 秒标记。
有关更多图表和分析，请参阅笔记本2.6-committee-attestations-with-relay-v2.ipynb 。
影响延迟证明的因素
为了进一步了解导致证明延迟到达的因素，我们使用了相同的 4963 个中继时隙随机样本。我们将每个证明标记为延迟（如果在 4.5 秒后到达）或准时（如果在 4.5 秒前到达）。在 6 秒时隙时间内，4.5 秒的截止时间将成为聚合截止时间。延迟到达的证明占所有证明的 11.1%。为了辅助模型训练，我们进一步对占多数的类别（即准时到达的证明）进行了欠采样，以使该变量的比例达到 50:50。
然后，我们用最大似然估计(MLE) 拟合了逻辑回归模型，以预测证明是延迟还是按时。正类表示延迟证明。对于特征，我们使用了独热编码 (one-hot encoding)，其中包含证明者的实体以及一些区块信息，例如使用的 gas 值、区块数量和交易数量。使用 MLE 不仅可以估计每个特征如何影响延迟证明的对数概率（通过线性模型的系数），还可以评估这些影响的统计显著性（通过 p 值）。
下表描述了整体模型性能。
Logit Regression Results==============================================================================Dep. Variable: y No. Observations: 117835 Model: Logit Df Residuals: 117812 Method: MLE Df Model: 22 Date: Wed, 27 Aug 2025 Pseudo R-squ.: 0.2402 Time: 17 : 59 : 49 Log-Likelihood: - 62058. converged: True LL-Null: - 81677. Covariance Type : nonrobust LLR p-value: 0.000伪 R 平方表明解释力中等，而对数似然和 LLR 的 p 值表明模型拟合度具有统计显著性。现在，检查 p 值低于 5% 的特征（见下表），我们得出结论：gas 用量和 blob 数量与迟到呈正相关，而交易数量则呈负相关。虽然影响较小，但由于样本量较大，因此非常显著。
| 多变的 | 系数 | p 值 | 解释 |
|---|---|---|---|
| 区块气体使用量 | +0.1305 | <0.001 | 更高的汽油使用量会增加迟到的可能性。 |
| 区块数 | +0.0589 | <0.001 | 斑点越多，迟到的几率就越大。 |
| 区块交易计数 | -0.0243 | 0.017 | 交易越多，延迟到达的可能性就越小。 |
Gas 使用量和区块数量的影响符合预期——Gas 使用量较高的区块执行时间往往更长，而数据量较大的区块传播时间则更长。然而，与交易数量呈反比关系却出乎意料。需要注意的是，交易数量与时隙内迟到率之间的相关性相当弱（0.015）。因此，观察到的关系很可能源于与其他特征的相互作用。
至于实体特征，它们在逻辑回归中并不显著。这可能是由于模型的稀疏性和线性加性假设造成的。逻辑回归可以包含分类变量，但当类别稀少或以复杂的方式相互作用时，它们可能会遇到困难。
为了解决这个问题，我们还训练了一组基于树的模型，这些模型更适合捕捉此类非线性特征。其中表现最佳的是LightGBM分类器。它在训练集上的F1得分为0.762，准确率为0.759。
 pr_curve 1935×1735 146 KB | |
在该模型中，实体特征表现出更高的相关性，如下图所示的特征重要性排名和Shapley 值所示。为了便于解释，蜂群图右侧的红点表示该特征对延迟到达有正向影响。相反，蜂群图右侧的蓝点表示该特征对延迟到达有负向影响。例如，Stakewise 在图右侧标识了这些点，表示该实体的证明更有可能延迟而不是准时。
 shap_beeswarm 3975×3572 569 KB |
|
单独质押者似乎对延迟证明产生负面影响，也就是说，他们延迟证明的数量往往少于平均水平的验证者。除了实体之外，区块数量和 Gas 消耗量也继续显示相关，这支持了逻辑回归模型的结果。
令人惊讶的是，第 66 百分位区块到达时间与延迟到达率之间并没有显示出明显的关系。它确实具有最高的特征重要性，但 Shapley 值并没有显示出明显的趋势。查看下面的散点图，该图将此特征与时隙内的延迟到达率进行了比较，我们发现 1 秒到 3.5 秒之间的区块到达时间对时隙内的延迟证明率没有显著影响。这表明，虽然此特征与延迟证明相关，但它与延迟证明的关系是复杂且非线性的。它的影响可能是通过与其他特征（例如证明者实体）的交互来实现的。
如需更多图表和分析，请参阅model_report 。用于复制模型训练和评估的代码是late_atts_model_runner.py 。
