A atualização desta semana na testnet MegaETH corrigiu um bug de desempenho elusivo que havia causado um aumento contínuo no tempo de miniblock entre as reinicializações do sequenciador. Aqui está a história. É uma história sobre a nossa filosofia – medir, depois construir. Se alguém visitasse o painel de desempenho do MegaETH recentemente, poderia ver que o tempo de miniblock estava aumentando durante a semana que antecedeu 3 de junho. Na verdade, tal tendência começaria logo após cada reinicialização do sequenciador desde o lançamento da testnet pública. Anteriormente, as frequentes atualizações no sequenciador significavam que o tempo de miniblock não aumentaria em nenhuma quantidade perceptível antes que a tendência ascendente fosse redefinida. No entanto, as atualizações recentes não exigiram reinicializações do sequenciador, e a tendência continuou por semanas. Em 3 de junho, o tempo de miniblock quase atingiu 100ms. Com as reinicializações do sequenciador se tornando ainda menos prováveis no futuro, graças a backups quentes, é hora de eliminar o bug de uma vez por todas. Como coletamos rotineiramente muitos dados de telemetria para a testnet, a equipe rapidamente começou a investigar. A primeira descoberta foi que o aumento no tempo de miniblock acelerou ao longo do tempo – não apenas o tempo de miniblock aumentou, mas aumentou cada vez mais rápido. Normalmente, tal sintoma implicaria que o trabalho envolvido na construção de cada miniblock aumentava de forma superlinear à medida que mais miniblocks eram construídos. No entanto, descartamos a hipótese após algumas medições e cálculos. Construímos o pipeline de miniblock para ser quase totalmente assíncrono em relação ao EVM, a fim de alcançar um tempo de miniblock arbitrariamente baixo. Isso significa que, independentemente do tempo que leva para construir um miniblock, o EVM estará executando transações durante todo esse tempo. Assim, o maior tempo de construção de miniblock levaria a um maior número de transações por miniblock, mas não observamos isso. Portanto, o problema não pode estar na construção de miniblocks. Um exame cuidadoso do código confirma essa conclusão – nenhuma parte do processo de construção de miniblocks tem complexidade superlinear. A equipe expandiu a busca, e o verdadeiro culpado rapidamente surgiu. O tempo que levou para confirmar os blocos EVM estava aumentando; além disso, o tempo de confirmação era perfeitamente linear ao número de blocos EVM produzidos desde a última reinicialização. Ao confirmar blocos EVM, o ambiente EVM, como a altura do bloco, é atualizado, então o EVM deve pausar e não pode executar transações, o que significa que não há miniblocks também. Há um intervalo fixo de 1 segundo entre os blocos EVM. Dentro do orçamento de 1 segundo, um tempo de confirmação que aumenta linearmente leva a uma duração que diminui linearmente para executar transações, o que, por sua vez, leva a um número que diminui linearmente de miniblocks produzidos. Se tomarmos seu recíproco, obtemos o tempo médio de miniblock, que é inversamente proporcional ao tempo. É exatamente a forma da função que vimos no painel de desempenho. A matemática conferiu. Nesse ponto, sabíamos exatamente o que procurar: algum procedimento cujo trabalho aumenta linearmente ao longo do tempo na parte específica do código que lida com a confirmação de blocos EVM. O resto do trabalho foi direto. A equipe lançou a atualização esta semana e o tempo de miniblock não aumentou. Então, qual foi a lição? Acho que mostrou novamente o poder quando a engenharia é guiada por medições cuidadosas e princípios fundamentais. A equipe está trabalhando em outras atualizações com a mesma filosofia. Fique atento!