大区块、Blob与重组 - 分片

大区块、Blobs 和 Reorgs

随着 EIP-4844 的上线，以太坊实际上通过为 Rollup 提供专用空间将其数据发布到 L1，从而提高了其事务吞吐量。

Blobs 现在是区块大小的主要贡献者，而平均信标区块大小（不包括 Blobs）从大约 125 KB 降至大约 9 KB。

在下图中，可以看到 Blobs 对以太坊数据吞吐量的影响：

\ block_content_over_time700×400 16.7 KB

这种吞吐量的增加预计会将某些“较弱”的验证者推向极限。 因此，我们想要回答这个问题：“Blobs 是否会导致 Reorgs？如果是，影响有多大？”

对于以下分析，我依赖于一个节点来实时解析数据（链头），并检查最终被 Reorg 的区块的内容。

以下分析考虑的最早数据点是插槽 8,992,385（2024 年 5 月 3 日），这为我们提供了大约 4 周的数据。

在此时间跨度内，我们总共观察到 487 次 Reorgs 和总共约 184,000 个插槽。

Snappy 压缩区块

首先，让我们比较一下已 Reorg 的区块的 Snappy 压缩区块大小与进入规范链的区块的 Snappy 压缩区块大小。

特别是，我们感兴趣的是，已 Reorg 的区块是否平均大于未 Reorg 的区块。

在这种情况下，我们将 Reorg 称为各自的提议者提出的有效区块，但最终被连续的提议者孤立。

\ boxplot21200×400 18.7 KB

根据上图，我们无法看到 Reorg 和未 Reorg 区块的中值区块大小存在显着差异。 关注 75\% 分位数和定义为 Q_{75} \times 1.5\ IQRQ75×1.5IQR 的上须，我们确实看到 Reorg 的区块大于未 Reorg 的区块。 这是预期的（更大的区块会导致更大的困难），但是，正如之前关于区块大小的分析中所见，4844 上线后，影响有所减少。

Blobs

接下来，让我们看看 Blobs。 随着 EIP-4844 的上线，大多数 RollUp 都从使用 calldata 切换到使用 Blobs，从而将大部分已发布的数据从 EL 有效负载转移到 Blobs。

\ boxplot31200×400 13.5 KB

根据上面的箱线图，我们可以看到大多数 reorged 区块包含 6 个 blobs。 看到具有 6 个 blobs 的区块发生更多 reorgs 是可以预期的，因为这些区块大约是 pre-4844 平均区块大小的 7 倍。

当可视化每个区块的 blobs 数量上的 reorged 区块百分比时，同样的模式也很明显。

\ reorgrate_over_blobs800×350 11.9 KB

比较具有 0 个和 6 个 blobs 的 reorged 区块的百分比，我们可以看到发生 reorg 的可能性是 3 倍以上。

在这种情况下，重要的是检查每个区块的 blobs 分布情况。 每个区块 0 个或 6 个 blobs 的“极端”情况可能会严重影响 blobs 对 reorgs 的影响。

\ blobs_per_block_ist1300×500 15.4 KB

如上面的直方图所示，该直方图显示了 2024 年 5 月每个区块的 blobs 分布，大多数区块包含 0 个或 6 个 blobs。

回归分析

为了量化 blobs 对 reorgs 的影响，我们可以应用一个简单的 Logistic 回归。

除了 (1) 未压缩的区块大小、(2) snappy 压缩的区块大小、(3) 每个区块使用的 Gas 量和 (4) 交易数量以及 (5) 每个区块的 blobs 数量之外，我们还将不同的 CL 客户端作为虚拟变量放入回归模型中。

所有因变量都经过 Z-score 缩放，并且 Lighthouse 客户端是截距的一部分。

\ logit745×398 21 KB

查看截距（const），当所有其他预测变量都处于其平均值时，发生 reorg 的基线对数几率表明发生 reorg 的基线概率非常低。

将其转化为数字，根据经验，2024 年 5 月大约有 0.27\% 的区块被 reorg。

接下来，让我们关注因变量，将 p \le 0.01p≤0.01 视为显着结果。

Blobs、size_compressed 和 nr_txs 对发生 reorg 的概率有显着影响。

• 每个额外的 blob 和 size_compressed 中的每个额外的字节都会增加发生 reorg 的概率。
• 与 Lighthouse 客户端相比，size、gas_used 和其他客户端变量（Nimbus、Prysm）没有显着影响。

对于 blobs 每增加一个标准差 (=2.33=2.33)，区块被 reorg 的对数几率增加 1.25821.2582。

在所有因变量都处于其平均值的情况下，发生 reorg 的基线概率约为 0.27\%。 这意味着 blobs 增加一个标准差 (=2.33=2.33) 会导致发生 reorg 的概率从大约 0.27\% 增加到 0.93\%，表示增加了大约 0.67 个百分点。

客户端

值得注意的是，reorg 的数量通常非常低，对于 Lodestar 和 Teku 等“少数”客户端来说甚至更低。 因此，一些玩弄时间游戏的 Lodestar 或 Teku 用户可能已经影响了这一结果。

因此，以下结果必须持保留态度。

对于 Lodestar 客户端：

• 使用 Lodestar 客户端时，发生 reorg 的对数几率增加 0.98140.9814。
• 这对应于大约 2.6672.667 的优势比，表明使用 Lodestar 客户端时，发生 reorg 的几率高出约 166.7\%。
• 发生 reorg 的基线概率约为 0.27\%。 使用 Lodestar 客户端时，此概率增加到大约 0.45\%，增加了大约 0.178 个百分点。

对于 Teku 客户端：

• 使用 Teku 客户端时，发生 reorg 的对数几率增加 0.56290.5629。
• 这对应于大约 1.7561.756 的优势比，表明使用 Teku 客户端时，发生 reorg 的几率高出约 75.6\%。
• 发生 reorg 的基线概率约为 0.27\%。 使用 Teku 客户端时，此概率增加到大约 0.3\%，增加了大约 0.027 个百分点。

对于 Nimbus 和 Prysm 客户端，与 Lighthouse 相比，我们没有看到对 reorgs 的显着影响。

接下来

• 呼吁重现：请重现我的分析。 处理大量数据可能会很麻烦。 处理在区块被 reorg 后从链中消失的数据甚至更麻烦。 因此，请将此视为深入研究“blobs 与 reorgs”主题的初步尝试。

• 更多数据：4844 仍然很年轻，我计划在几个月后重现此分析，以使用更多数据验证结果。

• 筛选客户端错误：客户端中的一个小错误会显着影响结果。 同样适用于玩 **时间游戏、诚实的 reorg 策略和 EL 客户端的验证者。

• Relay 和 Builder 怎么样: 检查为什么我们经常看到 0 个或 6 个 blobs，即极端情况，以及在这些情况下 builder 和 relay 的行为是什么。

• 检查 blobs 的使用效率以及多个实体之间 共享 blob 空间 是否可以提高效率。

• Blobs、Reorgs 和 MEV-Boost 的作用

• 插槽包含率和 Blob 市场组合学

• 关于单人质押、本地区块构建和 blobs

• 为 Pectra 增强 Blob 吞吐量

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