本周对MegaETH测试网的升级修复了一个难以捉摸的性能bug，该bug导致在序列器重启之间，微块时间持续增加。以下是这个故事。这是一个关于我们哲学的故事——测量，然后构建。 如果最近访问MegaETH的性能仪表板，可能会看到在6月3日之前的一周内，微块时间一直在增加。实际上，这种趋势自公共测试网启动以来，每次序列器重启后都会开始。之前，频繁的序列器升级意味着微块时间在上升趋势重置之前不会增加任何可感知的量。然而，最近的升级并不需要序列器重启，这一趋势持续了数周。在6月3日，微块时间几乎达到了100毫秒。由于热备份的引入，未来序列器重启的可能性变得更小，是时候彻底消除这个bug了。 由于我们定期收集大量的遥测数据，团队迅速开始深入挖掘。第一个发现是微块时间的增加随着时间的推移而加速——微块时间不仅在增加，而且增加得越来越快。通常，这种症状意味着构建每个微块所需的工作量随着构建的微块数量的增加而超线性增加。然而，在进行一些测量和计算后，我们否定了这一假设。我们构建的微块管道几乎完全是异步的，以便实现任意低的微块时间。这意味着，无论构建微块需要多长时间，EVM在整个过程中都会执行交易。因此，较长的微块构建时间会导致每个微块的交易数量增加，但我们并没有观察到这一点。因此，问题不可能出在构建微块上。对代码的仔细检查证实了这一结论——微块构建过程中的任何部分都没有超线性复杂性。 团队扩大了搜索范围，真正的罪魁祸首很快浮出水面。提交EVM区块所需的时间一直在增加；此外，提交时间与自上次重启以来生成的EVM区块数量完全成线性关系。在提交EVM区块时，EVM环境（如区块高度）会被更新，因此EVM必须暂停，无法执行交易，这意味着也没有微块。EVM区块之间有一个固定的1秒间隔。在1秒的预算内，线性增加的提交时间导致运行交易的持续时间线性减少，这反过来又导致生成的微块数量线性减少。如果我们取其倒数，就得到了平均微块时间，这与时间成反比。这正是我们在性能仪表板上看到的函数形状。数学验证无误。 在那时，我们确切知道要寻找什么：某个在处理提交EVM区块的特定代码部分中，工作负载随时间线性增加的过程。其余的工作很简单。团队本周推出了升级，微块时间没有再上升。 那么，教训是什么？我认为这再次展示了当工程受到仔细测量和第一原则指导时的力量。团队正在以相同的哲学进行其他升级。敬请关注！