Sunnyside Devnet更新 - 04/08

Sunnyside Devnet 更新 - 04/08

你可以在这里找到所有已发布的报告：

Sunnyside Devnet 报告

概览

本周，我们专注于研究 CL 对 EL 的 getBlobs 可能存在的依赖性。

我们想确定当我们在 EL 端禁用 getBlobs 时，blob 吞吐量如何变化，并观察 CL 的传播效果如何。

没有 getBlobs 的 Pectra：

50 个 blobs/区块

带有 getBlobs 的 lighthouse/geth：

43 个 blobs/区块

没有 getBlobs 的 lighthouse/geth：

35 个 blobs/区块

带有 getBlobs 的 lighthouse/nethermind：

45 个 blobs/区块

从以上测试中：

没有 getBlobs，仅靠 lighthouse 处理了 35 个 blobs/区块。

具有良好的 getBlobs 命中率的网络性能更好。

没有 getBlobs 的 Pectra

使用 50 个 lighthouse-geth 节点，我们手动修改了

getBlobs

函数，使其始终返回

nil

。

在没有 getBlobs 的情况下，我们观察到 pectra devnet 可以处理大约

50 blobs/block

。

我们可以观察到，上述指标保持在合理的时间范围内，这允许在网络中进行适当的 blob/区块传播。

我们之前在 pectra devnet 上的测试表明，该网络可以毫无问题地处理多达

72 blobs/block

在具有无限带宽限制的最佳网络中，我们观察到该网络仅通过 CL 传播 blob 即可处理超过 50 个 blob，这仍然远高于当前限制。

Lighthouse/Geth

在这里，我们将比较 lighthouse-geth devnet，其中一个具有 getBlobs，另一个禁用了 getBlobs。

带有 getBlobs

ALT

使用 getBlobs，我们看到网络处理大约

43 blobs/block

。

没有 getBlobs

ALT

没有 getBlobs，我们也看到了类似的数字，大约

35 blobs/block

。

观察

带有 getBlobs

ALT

对于带有 getBlobs 的网络，节点大多显示 100% 的 getBlob 命中率，直到网络变得不稳定。

带有 getBlobs

ALT

没有 getBlobs

ALT

无论有无 getBlobs，都有类似数量的数据列侧链进行 Gossip 和验证。

带有 getBlobs

ALT

没有 getBlobs

ALT

但是，使用 getBlobs 存在更高的列处理失败率。

带有 getBlobs

ALT

没有 getBlobs

ALT

对于 getBlobs，数据列侧链 Gossip 验证运行时也更高。这似乎是由于 lighthouse 会处理/验证来自 Gossip 和 getBlobs 的数据列。这是 lighthouse 中一个已知的改进，将被合并。

带有 getBlobs

ALT

该指标也与带有 getBlobs 的 devnet 中记录的数据列处理等待时间一致。

带有 getBlobs

ALT

没有 getBlobs

ALT

没有 getBlobs，节点显示更高的

beacon_block_delay_attestable_slot_start

，表明区块变得可证明的速度较慢。当值超过 8 秒时，我们看到网络变得不稳定。使用 getBlobs，区块在 slot 时间中较早导入。

以上指标显示

getBlobs

通过从 EL 获取 blob，有助于更快地准备好区块。

带有 getBlobs 的 Lighthouse/Nethermind

在 nethermind 中，我们观察到大约 45 个 blobs/区块，直到网络变得不稳定。

在整个测试过程中，getBlob 命中率大多保持在 100%，直到网络变得不稳定。

观测

在 lighthouse-nethermind-3 中，我们观察到在网络变得不稳定之前，getBlob 命中率较低（我们尚未找出原因）。

在同一时间戳内，该特定节点显示的

beacon_block_delay_attestable_slot_start

比其他具有 100% blob 命中率的节点高约 5 倍。

这也与 lighthouse/geth 的发现一致，即 getBlobs 在可证明之前的延迟方面表现更好。

我们还类似地看到了更高数量的数据列侧链 Gossip 验证和列处理失败，就像带有 getBlobs 的 lighthouse/geth 一样。

结论

在 pectra 测试中，我们确实观察到没有 getBlobs 时，blobs/区块的数量较低。

在 lighthouse/geth 测试以及 lighthouse/nethermind 测试中，我们观察到具有更好 getBlobs 性能的网络处理了更多的 blobs/区块。

我们假设

45 blobs/block

是在出现计算瓶颈之前的最大 blob 数量。没有 getBlobs，CL 的 Gossip 可以毫无问题地处理

35 blobs/block

。

如果响应中缺少任何 blob，CL 当前会丢弃它们，并且仅使用具有 100% 命中率的 getBlobs。因此，最好了解当前主网或测试网中的平均 getBlobs 命中率。

下一步

我们的下一个行动项目是：

确定带有 getBlobs 的 lighthouse/geth 中的列处理失败原因。

使用其他 EL（如 besu / erigon / reth）以及不同的 blobpool 性能来验证以上发现。

使用其他 CL 验证上述场景，并提供到 PeerDAS 的不同时间指标中

一旦分布式 blob 发布准备就绪，量化其优于现状的性能提升。

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