ethlambda：我们如何让区块准时到达

在我们上一篇博客文章中，我们提到 devnet 5 引入了全块聚合，使得每个区块对其所有证明只需包含一个单一证明。这使得所需的带宽保持恒定，不依赖于证明的数量。然而，这会将大量聚合工作转移到提议者身上，后者很快成为瓶颈。

在这篇文章中，我们将讨论提议者到底有多慢，并展示如何在不改变底层密码学原语的情况下使其足够快。

当前状态

区块提议非常慢。构建一个空区块需要 0.4 秒，如果我们在 Slot 开始时开始构建区块，那么只剩下 0.4 秒来传播区块。仅仅添加一个证明就已经超过了这个时间间隔，需要 1.3 秒。这是一个大问题，因为延迟的区块会失去验证者的支持并被重组，从而增加网络的不稳定性。

为什么不直接增加 Slot 时间？

一个 Slot 由 5 个间隔组成，每个间隔 800 毫秒：区块提议、证明传播、聚合、安全目标计算和视图合并。

一个快速的解决方案是增加 Slot 时间和/或增加区块提议间隔的时长。然而，这会给未来带来新的问题。

Lean Ethereum 的目标之一是减少 Slot 时间，以改善区块确认时间和用户体验。如果我们现在就放弃这一点，那只是在不做任何尝试的情况下挪动目标。

那么替代方案是什么？除了优化 leanVM，我们仍然可以优化时间预算的分配方式。

区块构建预算花在了哪里

几周前，对 leanVM 的优化将聚合延迟降低了一半。我们分享了两个版本的性能比较，其中包括区块构建时间分解：

在这里我们可以看到，将单个提议者签名转换为区块证明的基础成本大约为 0.4 秒。向区块添加一个证明大约需要 0.3 秒，但大部分时间花费在证明压缩上，这需要大约 0.7 秒，几乎是区块构建时间的一半。这让我们了解了区块构建预算的去向。

第一个优化：早起的鸟儿有 Slot

区块提议时间在 Slot 开始时，这给我们的最大传播时间为 0.8 秒。然而，这并非我们可以构建区块的全部窗口。

在一个 Slot 的最后一个间隔开始时，所有验证者都将他们的“新”证明集合并到他们的“已知”集中，这称为视图合并。我们可以在此之后立即开始，这样我们就额外获得了 0.8 秒（一个间隔）来构建我们的区块。

在我们最初的比较中，这个优化让我们有整整 0.8 秒的间隔来传播我们的空区块。对于单证明区块，这仍然让我们在 Slot 开始后大约 0.5 秒发布区块，只给我们大约 0.3 秒的区块传播时间。包含更多的证明无疑会将我们推入下一个间隔，但我们仍然可以做得更好。

第二个优化：在提议期间避免证明压缩

成本分解表明，证明压缩几乎占了区块构建成本的一半。这很合理，因为它增加了第二轮递归证明聚合，第一轮是生成区块证明。如果我们能移除它，区块构建将只需一半的时间。结合之前的优化，所有单证明区块都将在 Slot 开始时立即发布。

事实证明，证明压缩对于网络的运行并不是必需的。如果我们只是选择我们能找到的覆盖范围最大的证明而不进行聚合，我们可以将提议者的聚合工作减少一半。事实上，PQ 心跳提案将让证明压缩在后台进行，只有一小部分签名处于热路径上。这个改变正是朝着这个方向发展的。

这个变化的缺点是每个区块包含的证明会更多，因为后续的区块将不得不包含现在未被聚合的证明。

第三个优化：聚合单一签名是浪费，我们不要这样做

在成本分解可视化中，乍一看似乎有问题的是空区块的基准成本。根据定义，空区块不应包含任何有用的共识信息，因此不应要求提议者做任何实际工作。然而，提议者必须对区块进行签名并将签名转换为区块证明。第一部分不需要太多时间，实际工作是将其转换为区块证明。这方面可以改进。

我们在这里提出的优化是将提议者签名移出区块证明。由于这是一个协议层面的变更，需要客户端团队之间的协调，但我们认为这是值得的。

// 之前：
struct SignedBlock {
    // 区块
    message: Block,

    // 提议者签名和所有证明签名的聚合证明
    proof: MultiMessageAggregate
}

// 之后：
struct SignedBlock { message: Block, proof: BlockProof }

struct BlockProof {
    // 原始 XMSS 签名（重用现有的定长线格式）
    proposer_signature: XmssSignature,

    // 仅针对区块体证明的多消息聚合（如果没有证明则为空字节）
    attestation_proof:  MultiMessageAggregate,
}

通过将提议者签名从聚合路径中移除，我们将需要聚合的证明数量减少了一个。这将聚合时间减少了一个证明的时间：聚合单个证明将等同于现在空区块所做的工作，2 证明区块将等同于现在单证明区块的工作，以此类推。

这个优化几乎免费地减少了聚合工作：唯一的缺点是除了约 250KB 的区块证明之外，还需要包含一个额外的 2KB 签名，并且需要以不到一毫秒的运行时成本进行验证。

结论

我们使用这三个优化运行了测试网，并进行了并排比较。作为参考，每个测试网都在一台具有 8 个核心、16 个线程和 64 GB RAM 的单服务器上运行。测试网配置包括分布在 4 个聚合委员会中的 32 个 ethlambda 节点，每个委员会有一个聚合器。

运行一个包含所有列出的优化的节点，我们可以在 Slot 开始后约 150 毫秒发布包含 2 个证明的区块，并留有足够的时间进行区块传播。这可能无法扩展到更大的验证者数量，但在这个问题变得严重之前，我们认为应该保持当前的 Slot 时间。

关注我们

加入我们的 Telegram 获取每日开发更新，在 X 上关注我们 获取公告和每周社区电话会议。

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