区块到达时间、家庭质押者与提高Blob数量 - 分片
- 以太坊中文
- 发布于 2024-12-04 17:57
- 阅读 23
本文分析了以太坊主网上区块和 blob 的到达时间，旨在评估增加 blob 数量对家庭质押者的影响。通过对 ethPandaOps 收集的社区数据进行分析，发现当前的网络性能可以支持将 blob 数量增加到 4/8 或 6/9，即使在考虑 EIP7623 引入的最坏情况区块大小后，仍然可行。文章强调了保持以太坊去中心化的重要性，并感谢社区成员提供的数据支持。
区块到达时间、家庭质押者和增加 Blob 数量
感谢所有无私分享数据的社区成员，使得这项分析成为可能，感谢 MigaLabs 提供的验证者实体数据，以及 ProbeLab 提供的早期版本主网带宽报告。
特别感谢 Parithosh, Toni, Mikel, Andrew, 和 Matty 在整个分析过程中提供的反馈和帮助。
TL;DR
概要
- 历史上的时间安排游戏使得预测一个安全的 Blob 数量增长变得困难
- ethPandaOps 最近开始从社区接收区块到达时间数据
- 对带宽最敏感的场景的分析表明，区块和 Blob 的到达时间都很健康
结果
- 当天真地推断这些数据并与 EIP7623 结合时，此分析支持在 EIP7691 中将 Blob 数量增加到 4/8 或 6/9。
- 这只是一个数据点，但它比之前的分析对潜在的 Blob 数量增长持更乐观的态度。
介绍
ethPandaOps 团队最近开始接收来自社区成员的数据。家庭质押者是 Ethereum 网络最有价值的资产之一，这个计划开始揭示他们如何看待网络。辅助二进制文件 与信标节点一起运行，并通过信标 API 事件流记录节点上发生的事件。这些事件被发送到 ethPandaOps 团队，然后由该团队发布数据（略有延迟和一些数据清理）。
更多信息：
该团队已经收集了大约 6 周的社区数据，现在我们有足够的数据来进行一些以前不可能进行的有趣的观察。
背景
随着 EIP4844 的到来，只有当节点接收到区块和区块中引用的 Blob 时，该区块才被认为是有效的。这个区块/Blob 捆绑包必须在 slot 中的 4 秒内被网络中的大多数节点接收，否则就有被 re-org 的风险。
复杂的运营商（以及现在的 MEV 中继）会进行区块提案时间安排游戏。这些运营商尽可能晚地提交他们的区块，以最大限度地提高他们的利润，同时最大限度地减少被 re-org 的风险。这些时间安排游戏历来模糊了区块到达时间数据。
ProbeLab 即将发布的未发布研究 表明，网络上 50% 的非云节点具有 20Mbps 的上传带宽。
问题陈述
Ethereum 的去中心化对其成功至关重要。EIP7691 旨在增加 Blob 数量，如果参数过高，可能会无意中将某些节点运营商排除在外。
我们需要：
- 确保 Blob 数量的增加对于家庭质押者来说是安全的，因为这组参与者是 Blob 数量增加的“最坏情况”，因为他们拥有的可用带宽最低。
- 确保网络有足够的数据吞吐量来支持 Layer 2 的增长。
鉴于现有的情况，我们可以对潜在的 Blob 数量增加做出一些假设：
风险最低：
与直觉相反，如果你查看区块到达数据，进行时间安排游戏的运营商似乎最有可能受到 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 在主网上的表现如何？
- 问题 2：到达时间是否随区块/Blob 捆绑包大小而变化？
- 问题 3：我们今天在主网上还能支持多少？
我们将从家庭质押者的角度回答这些问题，因为这是我们风险最高的运营商群体。
分析
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。
时间数据由 Xatu Sentry 捕获，Xatu Sentry 是一个与信标节点一起运行的辅助二进制文件，并通过信标 API 事件流记录许多事件。这些事件可以被认为是区块到达时间的最坏情况，因为记录事件需要额外的处理时间和网络开销。从分析来看，这种开销在 50-300 毫秒之间，但为了安全起见，我们保留了原始的时间数据。
每个信标节点实现以不同的顺序发出 block、head 和 blob_sidecar 事件。为了解决这个问题，我们将区块/Blob 捆绑包定义为仅在从每个信标节点记录了 slot 的所有相关事件后才“到达”。这再次是最坏情况。
问题 1
3/6 在主网上的表现如何？
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趋势线显示了到达时间的 99%、95% 和 50% 的百分位数 - 这意味着有多少百分比的区块比该线更快到达。
这些百分位趋势线回答了我们的问题：随着捆绑包大小的增加，到达时间也会增加。这表明带宽是这些参与者的主要瓶颈。
\
3530×2411 651 KB再次查看通过 MEV Relay 提供的区块，我们看到了类似的情况。
结果： 是的，到达时间随区块/Blob 捆绑包大小而变化
问题 3：
我们今天在主网上还能支持多少？
TLDR：4/8 和 6/9 都是可以实现的
要回答这个问题，我们需要检查区块有多大。在我们的时间段内，压缩信标区块大小的第 99 个百分位是 101KB。我们的 Blob 的大小固定为 128KB。
使用这些参数，我们可以叠加区块/Blob 计数：
\
3530×2411 918 KB我们可以非常天真地绘制一条趋势线，以查看何时会超过 4 秒的认证截止日期。
\
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。请注意，目前主网上的最大压缩区块大小为 1.79MB（而且我们似乎运行良好！），所以请谨慎对待此数据点。
\
1175×804 208 KB与本地构建的区块相比，MEV Relay 区块的趋势再次支持更高的 Blob 数量。
结果： 数据支持增加 Blob 数量，尤其是在同时包含 EIP7623 的情况下。4/8 或 6/9 都可以安全应用。存在更高的 Blob 数量的可能性，但我们需要先看看网络在初始增长后的表现如何。
结论
Ethereum 的去中心化是根本，家庭质押者在这其中发挥着关键作用。网络是一个微妙而复杂的系统，需要经过深思熟虑。
我们的分析表明，对于带宽有限的节点，区块到达性能超过了最初的预期。社区贡献的数据为网络的功能提供了有价值的真实世界见解，我们再次感谢那些贡献数据的人。
虽然我们天真地假设 Blob 数量和到达时间之间存在线性关系，但这是对高度复杂的分布式系统的简化视图。此外，还有一些正在进行的工作流程可能会随着时间的推移改善或恶化带宽要求。我们的分析侧重于我们现在可用的数据，基于过去六周的网络性能观察。
仅根据区块/Blob 到达指标，将 Blob 数量从（目标 3/最大 6）增加到（目标 4/最大 8）或（目标 6/最大 9）似乎是可行的。但是，这只是在决定 Blob 数量调整时要评估的众多因素之一。
- 原文链接： ethresear.ch/t/block-arr...
- 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～
