Slot 时间与 ePBS - 讨论缩短 slot 时间

社区（或者可能是 Paradigm，我不清楚）似乎在推动缩短 slot time。在这篇简短的笔记中，我将推测在 ePBS 下的 slot time 实际限制，以及当前机制或提议的延迟执行机制下的实际限制。

请记住，如今扩展的真正瓶颈是带宽和 blob 传播时间。无论我们做什么，都需要允许更长的时间来进行大量数据传播。Blob 验证开销很小，blob 传播时间越长，我们获得的免费 DA 就越多，从而实现扩展。

区块广播，attestation 截止时间。

在具有较大区块广播的地理位置分散的开发网络上进行的实验表明，对于高达 6MB 的区块，我们可以在不到 2 秒的时间内可靠地进行广播，对于 1MB 的区块，则可以在不到 800 毫秒的时间内可靠地进行广播。

这些表明，对于当前的共识机制，即使有更多的 blob，我们也可以在 slot 的大约 3 秒处设置 attestation 截止时间。这是因为我们可以尝试将 MEV-Boost 签名的边界推到仅一次往返，从 relayer 广播所有内容，假设区块和 blob 在 slot 的 2 秒内已完全到达，然后执行区块 CL + EL，并验证 DA。

使用 EIP-7886，我们不需要验证 EL 执行（或大部分），因此我们可以减少与执行区块相对应的处理部分。因此，实际上，我们预期可能的截止时间为 2 秒加上 CL 执行加上 EL 执行的静态部分（当使用 EIP-7886 来实现这一部分时），根据当前的执行状态，我将此时间设置为 2.2 秒，但这高于 2 秒。

EIP-7732 为我们提供了更多：我们不需要在此阶段广播 payload 或 blob，因此只需要广播信标区块，这比执行和 blob 小得多！在我们的实验中，即使在 1/2MB 的较低级别（是当前包含 payload 的完整区块的 4 倍），区块也能在 300 毫秒内完全分发！这意味着，如果我们仅在 EIP-7732 下广播共识区块，我们可以安全地假设该区块将在 1 秒内完全分发和执行（因为现在再次只需要 CL 执行）。

这只有在 ePBS 将 CL 区块的广播与 EL 和 blob 解耦时才有可能，与当前规范和 EIP-7886 相比，这使得热路径更加高效。

Payload 广播 – 聚合

当前 mainnet 上的测量结果表明，95% 的 attestation 在不到 1 秒的时间内到达节点。因此，ePBS 下的 builder 和一般的聚合器可以被迫在 attestation 截止时间后 1 秒揭示 payload 并生成聚合。根据上面的数字，对于 ePBS，这将大约是 2 秒，对于 EIP-7886，将是 3.2 秒，对于当前的共识机制，将是 4 秒。

Blob 广播

在当前的共识和 EIP-7886 中，blob 广播的瓶颈位于热路径上，blob 在 slot 的 0 秒处进行广播，并且需要通过 attestation 截止时间进行验证。

PTC observers

这仅适用于 ePBS，需要另一轮，其中涉及 payload 被 PTC 成员观察，然后将 attestation 传递到链上。这必须是对 payload 的完整广播（我们在上面计算为最坏情况下为 2 秒），再加上对这 512 个 attestation 的完整广播，实际上它们远小于 1 秒，因为它们只有几个字节，但我们将在此处保守地将它们计为 1 秒。这意味着 ePBS 在 payload 暴露时间后至少需要 3 秒，因此我预计 ePBS 的最小 slot time 大约为 5 秒。

节点还在并行执行其他任务，例如获取聚合、计算分叉选择和执行 payload，但是 ePBS 为此提供了比当前机制和 EIP-7886 更多的时间，因此我们已经在上面考虑了它们。

另一方面，EIP-7886 和当前的共识机制不需要额外的 2 秒用于广播（因为已经考虑了它们），因此我们只需要考虑聚合到达节点所需的 1 秒即可。这使得 EIP-7886 的总 slot time 约为 4.2 秒，当前共识机制约为 5 秒。

预期延迟下的推测最小值。

• Slot time：预期的总slot time，越低越好
• 区块执行：允许执行 payload 的时间，越高越好。
• DA 广播和验证：blob 在网络上传输 + 验证者检查它们是否可用的时间，越高越好。

我过于保守地为 CL 广播提供 1"，为 CL+Payload+Blob 广播提供 2"。这些数字之间的任何差异都会使表格更倾向于 ePBS。

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