A atualização desta semana para a rede de testes MegaETH corrigiu um bug de desempenho indescritível que fazia com que o tempo de minibloqueio aumentasse continuamente entre as reinicializações do sequenciador. Aqui está a história. É uma história sobre nossa filosofia – medir e depois construir. Se alguém visitou o painel de desempenho do MegaETH recentemente, pode ver que o tempo do minibloco aumentou durante a semana que antecedeu 3 de junho. Na verdade, essa tendência começaria logo após cada reinicialização do sequenciador desde o lançamento da rede de teste pública. Anteriormente, as atualizações frequentes do sequenciador significavam que o tempo do minibloco não aumentava 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 do minibloco quase atingiu 100ms. Com as reinicializações do sequenciador se tornando ainda menos prováveis no futuro graças aos backups quentes, é hora de eliminar o bug de uma vez por todas. Como coletamos rotineiramente muitos dados de telemetria para a rede de teste, a equipe rapidamente começou a cavar. A primeira descoberta foi que o aumento no tempo de minibloqueio acelerou ao longo do tempo – não apenas o tempo de minibloqueio aumentou, mas aumentou cada vez mais rápido. Normalmente, tal sintoma implicaria que o trabalho envolvido na construção de cada minibloco aumentava superlinearmente à medida que mais miniblocos eram construídos. No entanto, derrubamos a hipótese após algumas medições e cálculos. Construímos o pipeline de minibloco para ser quase totalmente assíncrono ao EVM, de modo a atingir um tempo de minibloco arbitrariamente baixo. Isso significa que, por mais tempo que leve para construir um minibloco, o EVM executará transações durante todo o tempo. Assim, o tempo de construção de minibloco mais longo levaria a um número maior de transações por minibloco, mas não observamos isso. Portanto, o problema não pode ser com a construção de miniblocos. Um exame cuidadoso do código confirma essa conclusão - nenhuma parte do processo de construção do minibloco tem complexidade superlinear. A equipe expandiu a busca e o verdadeiro culpado rapidamente veio à tona. O tempo necessário para confirmar blocos EVM estava aumentando; além disso, o tempo de confirmação foi 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, portanto, o EVM deve pausar e não pode executar transações, o que significa que também não há miniblocos. Há um intervalo fixo de 1 segundo entre os blocos EVM. Dentro do orçamento de 1 segundo, um tempo de confirmação linearmente crescente leva a uma duração linearmente decrescente para executar transações, o que, por sua vez, leva a um número linearmente decrescente de miniblocos produzidos. Se tomarmos seu recíproco, obtemos o tempo médio do minibloco, que é inversamente proporcional no tempo. É exatamente a forma da função que vimos no painel de desempenho. A matemática deu certo. Nesse ponto, sabíamos exatamente o que procurar: algum procedimento cuja carga de trabalho aumenta linearmente ao longo do tempo na parte específica do código que lida com o commit de blocos EVM. O resto do trabalho foi direto. A equipe empurrou a atualização esta semana e o tempo de minibloqueio 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 primeiros princípios. A equipe está trabalhando nas outras atualizações com a mesma filosofia. Fique ligado!