ethlambda: 我们如何实现签名聚合3倍加速

后量子 leanConsensus 测试网的 Devnet 4 通过 leanMultisig 引入了递归签名聚合。这一变化对网络有利（每个区块需要验证的证明更少），但给聚合器带来了沉重的工作负载，导致我们的节点开始错过 Slot 并在最终确认中落后。

两个改进帮助我们恢复了正常水平：将聚合移出热路径，以及收紧编译目标。聚合时间下降了约 3 倍，我们不再错过 Slot。

Devnet 4 中的递归聚合

leanConsensus 使用 leanMultisig，一种后量子签名方案。早期的 devnet 每个认证验证一个证明。Devnet 4 增加了递归聚合：聚合器将许多证明折叠成一个递归证明，验证者每个区块只验证一个证明，而不是多个。

权衡结果是：验证更便宜，聚合更昂贵。

问题

在我们的服务器上运行 4-ethlambda devnet 时，我们观察到两个症状：

• 聚合器在大多数 Slot 中错过了区块提议。
• 最终确认呈跳跃式推进。

两者都表明聚合时间超过了 Slot 本身。Grafana 显示聚合时间固定在 4 秒桶，即整个 Slot。直方图是分桶的，因此我们在日志中增加了每证明计时以读取实际值。

单个证明消耗了大部分 Slot，导致聚合器放弃它所有的其他验证者职责。如果在一个 Slot 中执行了多个聚合，问题会加剧，这可能意味着聚合器在整个 Slot 中几乎无响应。

异步聚合

聚合与驱动节点其余部分的同一任务运行，破坏了异步编程的协作并发性。当它在计算证明时，Slot tick和验证者职责都在它后面等待。

我们将聚合移到了一个后台任务（#299），并设置了 750 毫秒的软截止时间。节点调度一个证明，然后回到其他职责，当结果准备就绪时发布它。截止时间后，不会启动新作业，但已经在进行中的证明仍会完成并广播到网络。

我们的聚合器不再错过提议，最终确认曲线也平滑了。

在 ethlambda 中，聚合工作者位于 crates/blockchain/src/aggregation.rs 中，会话生命周期（启动、截止、取消、终结）由 crates/blockchain/src/lib.rs 中的 BlockChainServer actor 管理。会话 ID 用于防止过时结果，因此来自前一个 Slot 卡住的工作者不会污染当前 Slot。

将编译目标改为 x86-64-v3

来自 leanConsensus 社区的某人提到，为本机架构编译 leanMultisig 在其基准测试中提供了约 2 倍的加速。我们在 Skylake-SP devnet 服务器上进行了 400 个 Slot 的运行测试，观察到聚合时间平均减少了 2.7 倍。

-C target-cpu=native 有一个缺点：二进制文件在大多数 x86-64 机器上不再可移植。我们尝试了 x86-64-v3（#311），这是大多数 2013 年以后的 CPU（Haswell 及更新）支持的特性级别，范围足以在我们的主机上分发一个二进制文件。我们借鉴了 ethrex（我们面向生产环境的执行客户端），它 做了同样的切换。

x86-64-v3 在同一硬件上优于 native，这起初让我们感到惊讶。原因可能是 CPU 的一个特性。在 native 下，编译器会发出 AVX-512 指令，而 AVX-512 会在此类 CPU 上触发核心降频。x86-64-v3 将二进制文件限制在 AVX2，因此核心保持其全时钟频率，最终更快。不支持 AVX-512 的 CPU 不会出现这种差距。

结果

通过异步聚合和 x86-64-v3，我们的 devnet 4 运行达到了递归聚合之前相同的吞吐量，并且还获得了递归承诺中额外的验证者端节省。

ethlambda 是开源的，目前正在 devnet 4 中运行：

• ethlambda on GitHub
• leanConsensus 规范
• 在 Telegram 上加入我们
• 在 X 上关注我们

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