ethlambda：运行 1024 个验证者 devnet 的经验与教训

liumuhui 3小时前阅读数 1 #区块链

上周我们运行了一个包含 1024 个验证者的 devnet，分布在 8 个聚合子网络中。这种布局保持了网络的可扩展性，因为每个聚合器在每个时间间隔内合并 128 个签名，完全在预算之内。32 个 ethlambda 节点中的每一个都位于自己的服务器中，每个节点有 32 个验证者，是我们之抢跑的两倍。

网络在整个运行期间保持运行并持续完成最终确认，但余量比我们想要的要小。事实证明，proposer 是瓶颈，区块构建时间很高，这与我们在之前的运行中看到的情况以及我们在上一篇文章中写到的内容一致。

数据

Grafana 仪表板显示 devnet 的总体概览

九个区块中有一个被 reorg，被排除在链之外，最终确认落后于链头 24 个 slot。

图片列出了 devnet 的一些数据：被 reorg 的区块：11%，最终确认延迟：24 个 slot，区块构建时间，平均：2.5s，委员会聚合，最大：0.42s，递归聚合，平均：1.3s

在 4 秒的 slot 和 0.8 秒的时间间隔下，签名路径保持稳定：97% 的签名在其时间间隔内到达，95% 的委员会聚合按时到达，委员会聚合峰值达到 0.42 秒。

区块生产错过了其时间窗口。5% 的区块按时到达，59% 在签名传播期间到达，即验证者应该对它们进行投票的时间间隔。区块构建平均耗时 2.5 秒，递归聚合平均耗时 1.3 秒，两者都超过了各自需要在 0.8 秒内完成的时间间隔。

延迟区块解释了 reorg 的原因

我们看到的每一次 reorg 都可以追溯到 proposer 发布延迟。

验证者在 slot 的固定时间点投票，投票给他们当时能看到链头。尚未到达的区块不是链头，因此投票会投给其父区块。下一个 proposer 在父区块之上构建，因为权重在那里，无论延迟的区块多么有效，它都会被孤立。Proposer 没有违反任何规则，网络也没有丢弃任何东西：它是在决定其命运的投票之后才完成区块的。

这使得 reorg 率成为区块延迟程度的直接函数。在其时间间隔之后才完成构建的区块有 3% 的概率被 reorg，并且该概率随延迟而上升：延迟整整一个 slot，区块被 reorg 的概率为 80%。平均构建时间为 2.5 秒，只有 5% 的区块按时到达，很多提议都落在这条曲线的某个位置。59% 在签名传播期间到达的区块大多数情况下都能存活，因为它们在下一个 proposer 冻结其视图之前到达。剩下的 36% 是我们大多数 reorg 的来源，其中大约四分之一到达得足够晚，以至于下一个 proposer 会在它们之上构建。

缓慢的递归聚合解释了最终确认延迟

最终确认也因类似原因受到影响。上链的区块更少，因此验证者可以打包 attestation 的位置更少，投票累积所需的时间更长。在落后的 slot 中，证明区块合法性的 attestation（最终确认的第一步）在提议后 2 到 4 个 slot 才到达。我们预计到这一点：fork-choice 至少需要一个 slot 来确认投票，而 4 个 slot 是在同步条件下区块成为安全目标的最坏情况。

之后的 slot 是我们损失时间的地方。后续区块继续为相同的 attestation 数据包含更多签名，大约经过 11 个 slot，区块才携带足够的投票来被证明合法。两轮这样的过程占了 24 个 slot 最终确认延迟的大部分，因此交易需要将近两分钟才能完成最终确认。这比今天的信标链要好，但仍然没有达到我们想要的目标。

证明合法需要 11 个 slot 而不是 2 或 3 个的原因在于递归聚合没有跟上，而委员会聚合 95% 的按时率掩盖了这一点。委员会聚合只是第一轮。它为我们提供每个子网络一个 payload，覆盖 1024 个签名中的 128 个，并且在其时间间隔内完成，还有余量。将这 8 个 payload 转换为一个覆盖整个验证者集合的 payload 需要额外的递归轮次，这项工作平均耗时 1.3 秒，比委员会聚合到达的时间间隔还要长。聚合器将其作为一项阻塞步骤来运行，与其他职责冲突，因此当 proposer 需要时，递归结果还没有准备好。

Proposer 用现有的东西来构建。区块最终携带的 attestation 没有经过任何递归聚合轮次，每个只有单个委员会的投票量，因此每个区块携带的权重只是其可能的一小部分。所有按时产生的投票仍然需要几个 slot 才能累积成证明合法性的多数，一次一个委员会。

时间花在了哪里

区块构建平均耗时 2.5 秒，而多消息聚合（对不同投票的聚合 payload 进行聚合）几乎占了全部时间。在区块构建期间，我们跳过了同消息 payload 的递归聚合，只为每个投票保留最佳的聚合 payload，因为这会进一步减慢构建速度，因此合并来自不同 attestation 的 payload 占据了主要成本。

一种出路是直接加快多消息聚合的速度。这可以腾出足够的余量来同时对同消息 payload 进行递归聚合，从而将更多 attestation 打包到每个区块中，并缩短证明合法性的路径。

另一种是在提议时不再做所有工作。多消息聚合分为两部分：我们提前知道的 payload，例如针对前几个 slot 区块的最终确认投票，以及在提议前刚刚到达的 payload，例如当前 slot 的投票和 proposer 签名。我们可以提前聚合第一组。在 API 方面，这意味着一个流式接口：逐个添加 proof，最后将它们收集到一个区块 proof 中，或者在多消息 payload 到达时递归聚合它们。

还有一个较小的优化，我们之前写过。区块构建的一部分时间花在将 proposer 签名转换为可聚合的 payload 上。将该签名从区块 proof 中移出，放入自己的字段中，可以从聚合集中减少一个 payload，而且每个签名 1.3 KB 相对于区块 proof 的 220 KB，区块大小几乎不受影响。

聚合器的吞吐量也有帮助。目前聚合器将递归聚合作为阻塞步骤运行；将其与其他职责进行流水线处理，再加上 leanVM 的性能优化，应该能将 1.3 秒的平均时间降下来。

有效的部分

委员会聚合峰值达到 0.42 秒，我们在其时间间隔开始前最多 0.6 秒就启动聚合，因此结果落地时还有余量。如果成本保持线性，将每个子网络的验证者数量翻倍会使峰值达到 0.84 秒，超过了时间间隔本身。它仍然能按时落地，但仅仅是因为提前启动。在 2048 个验证者且子网络布局不变的情况下，签名应该继续按时到达。