区块到达时间、家庭质押者与增加 blob 数量 - 分片
- 以太坊中文
- 发布于 2024-11-28 14:24
- 阅读 20
本文分析了以太坊主网上区块和blob的到达时间，旨在评估增加blob数量对家庭质押者的影响。通过ethPandaOps团队收集的数据，分析表明，即使在最坏情况下，增加blob数量到4/8或6/9是可行的，特别是在同时实施EIP7623的情况下。文章强调了以太坊去中心化的重要性，并感谢社区成员提供数据支持分析。
区块到达时间、家庭质押者和增加 Blob 数量
感谢所有无私分享数据的社区成员，使得这个分析成为可能，感谢 MigaLabs 提供的验证者实体数据，以及 ProbeLab 提供的 Mainnet 带宽报告的早期版本。
特别感谢 Parithosh, Toni, Mikel, Andrew, 和 Matty 在整个分析过程中提供的反馈和帮助。
TL;DR
概要
- 从历史上看，timing games 使得预测安全的 blob 数量增加变得困难
- ethPandaOps 最近开始从社区接收区块到达时间数据
- 对带宽最敏感的场景的分析显示，区块和 blob 的到达时间是健康的
结果
- 当简单地推断这些数据并与 EIP7623 结合时，此分析支持在 EIP7691 中将 blob 数量增加到 4/8 或 6/9。
- 这只是一个数据点，但与之前的分析相比，它对潜在的 blob 数量增加持更乐观的看法。
介绍
ethPandaOps 团队最近开始从社区成员那里接收数据。家庭质押者是以太坊网络最有价值的资产之一，该计划开始让我们了解他们如何看待网络。边车二进制文件 与信标节点一起运行，并通过信标 API 事件流记录节点上发生的事件。这些事件被发送到 ethPandaOps 团队，然后该团队发布数据（有少量延迟和一些数据清理）。
更多信息：
该团队已经收集了大约 6 周的社区数据，现在我们有足够的数据来进行一些以前不可能的有趣的观察。
背景
随着 EIP4844 的到来，只有当节点收到区块和区块中引用的 blob 时，该区块才被认为是有效的。这个区块/blob 捆绑包必须在 slot 中的 4 秒内被网络上的大多数节点收到，否则就有被 re-org 的风险。
复杂的运营商（现在是 MEV-Relay）会玩 block proposal timing games。这些运营商尽可能晚地提交他们的区块，以最大化他们的利润，同时最小化他们被 re-org 的风险。这些 timing games 在历史上混淆了区块到达时间数据。
来自 ProbeLab 的未发布的即将发布的研究 表明，网络上 50% 的非云节点的上传带宽为 20Mbps。
问题陈述
以太坊的去中心化对其成功至关重要。EIP7691 旨在增加 blob 数量，如果参数过高，则存在无意中将某些节点运营商排除在其集合之外的风险。
我们需要：
- 确保 blob 数量的增加对于家庭质押者是安全的，因为这组参与者是 blob 数量增加的“最坏情况”，因为他们可用的带宽最低。
- 确保网络有足够的数据吞吐量来支持 Layer 2 的增长。
鉴于现有的情况，我们可以对潜在的 blob 数量增加做出一些假设：
风险最低：
与直觉相反，如果你查看区块到达数据，那么玩 timing games 的运营商似乎最有可能受到 blob 数量增加的影响。因为提议过晚而被 reorg 对业务不利，我们可以假设他们会相应地调整他们的区块提议时机。在这里，blob 数量的增加不太可能成为问题。
风险最高：
一个单人质押者在本地构建一个区块（没有 mev-relay），并被其他家庭质押者证明。在这种情况下：
- 提议者：
- 需要将其区块和所有 blob 发布到网络。该节点需要尽可能快地将其区块（约 100KB），然后将所有 blob（每个 128KB）发布到其所有 mesh peers。
- 在本地构建区块时，提议者没有 MEV Relay 的帮助，MEV Relay 会将区块/blob 捆绑包 gossip 给其自己的 peers。
- 证明者：
- 需要在 slot 中的 4 秒之前从 p2p 网络下载区块/blob 捆绑包。
此分析将提出以下问题：
- 问题 1：3/6 在 Mainnet 上的表现如何？
- 问题 2：到达时间是否随区块/blob 捆绑包大小而变化？
- 问题 3：我们今天在 Mainnet 上还能支持多少？
我们将从家庭质押者的角度回答这些问题，因为这是我们风险最高的运营商群体。
分析
Start: 2024-10-04T22:00:00Z
End: 2024-11-25T02:00:00Z
Blocks: 366,384
Arrival events: 75,945,392
Countries: 9 (Australia, Bulgaria, Czechia, Germany, Italy, Spain, The Netherlands, United Kingdom, United States)查看 juypter notebook here。
Timing 数据由 Xatu Sentry 捕获，Xatu Sentry 是一个与信标节点一起运行的边车二进制文件，并通过信标 API 事件流记录许多事件。这些事件可以被认为是区块到达时间的最坏情况，因为记录事件需要额外的处理时间和网络开销。从分析来看，这种开销在 50-300 毫秒之间，但为了安全起见，我们保持了 timing 数据不变。
每个信标节点实现以不同的顺序发出 block、head 和 blob_sidecar 事件。为了解决这个问题，我们定义一个区块/blob 捆绑包为“已到达”，只有在从每个信标节点记录了 slot 的所有相关事件之后。这再次是最坏情况的场景。
问题 1
3/6 在 Mainnet 上的表现如何？
TL;DR: 很好!
\
1166×804 115 KB此图表显示了区块/blob 捆绑包的可见到达时间与捆绑包的总大小的关系。当查看由单人质押者本地构建并由家庭用户看到的区块时，许多区块/blob 捆绑包在 4 秒之前被看到。
\
1166×804 118 KB我们还应该查看 MEV Relay 提供的区块，因为现实情况是，许多区块都是通过这种方式提议的。我们可以看到 min 的增加，因为此过程中涉及额外的往返，但情况仍然看起来健康！
结果： 对于我们的家庭用户来说，区块/blob 捆绑包在 4 秒的截止时间内到达。
问题 2
到达时间是否随区块/blob 捆绑包大小而变化？
TL;DR: 是的
\
3530×2411 650 KB趋势线显示了到达时间的 99th、95th 和 50th 百分位数 - 这意味着有多少百分比的区块比该线更快地到达。
这些百分位趋势线回答了我们的问题：随着捆绑包大小的增加，到达时间也会增加。这表明带宽是这些参与者的主要瓶颈。
\
3530×2411 651 KB再次查看通过 MEV Relay 提供的区块，我们看到了类似的情况。
结果： 是的，到达时间随区块/blob 捆绑包大小而变化
问题 3：
我们今天在 Mainnet 上还能支持多少？
TLDR: 4/8 和 6/9 都是可以实现的
要回答这个问题，我们需要检查区块有多大。在我们的时间段内，压缩信标区块大小的第 99 个百分位数为 101KB。我们的 blob 的大小固定为 128KB。
使用这些参数，我们可以覆盖区块/blob 计数：
\
3530×2411 918 KB我们可以非常天真地绘制一条趋势线，以查看何时会超过 4 秒的 attestation 截止时间。
\
3530×2411 1 MB此趋势线假设 blob 计数和到达时间之间存在线性关系。在此假设下，我们可以支持每个区块最多 14 个 blob，同时保持 95% 的区块/blob 捆绑包在截止时间内到达。95% 的目标为我们的测量中的 50-300 毫秒处理开销提供了余量，同时也考虑了异常值。
\
3530×2411 1020 KB当专门查看 MEV Relay 区块时，数据显示出更加乐观的前景 - 第 95 个百分位数的趋势线表明每个区块最多支持 20 个 blob。这种改进的性能可以归因于 MEV Relay 是高带宽节点，可以帮助提议者并行地在整个网络中分发区块和 blob。
EIP7623
EIP7623 将最坏情况下的压缩区块大小提高到约 720KB - 比我们平均的历史区块大 7 倍。让我们分析一下，在这种增加的区块大小下，我们是否仍然可以支持更多的 blob。
\
3530×2411 967 KB即使在 EIP7623 的绝对最坏情况区块大小下，我们仍然支持增加 blob。请注意，当前 Mainnet 上的最大压缩区块大小为 1.79MB（而且我们似乎进展顺利！），因此请谨慎对待此数据点。
\
1175×804 208 KB与本地构建的区块相比，MEV Relay 区块的趋势再次支持更高的 blob 计数。
结果： 数据支持增加 blob 计数，特别是如果同时包含 EIP7623。4/8 或 6/9 都可以安全应用。存在更高的 blob 计数的潜力，但我们需要先看看网络在初始增长时的表现如何。
结论
以太坊的去中心化是根本，家庭质押者在这张图中扮演着至关重要的角色。网络是一个微妙而复杂的系统，需要深思熟虑和审慎考虑。
我们的分析表明，带宽有限的节点的区块到达性能超过了最初的预期。社区贡献的数据为网络的性能提供了有价值的真实世界见解，我们再次感谢那些正在贡献数据的人。
虽然我们天真地假设 blob 计数和到达时间之间存在线性关系，但这只是对高度复杂分布式系统的简化看法。此外，还有一些正在进行的工作可能会随着时间的推移而改善或恶化带宽要求。我们的分析侧重于我们现在可用的数据，基于过去六周的网络性能观察。
仅根据区块/blob 到达指标，将 blob 计数从（目标 3/最大 6）增加到（目标 4/最大 8）或（目标 6/最大 9）似乎是可行的。但是，这只是在决定 blob 计数调整时要评估的众多因素之一。
- 原文链接： ethresear.ch/t/block-arr...
- 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～
