Den här veckans uppgradering av MegaETH-testnätet fixade en svårfångad prestandabugg som hade orsakat att miniblock-tiden kontinuerligt ökade mellan omstarter av sequencer. Så här ligger det till. Det är en berättelse om vår filosofi – mät och bygg sedan. Om man nyligen besökte MegaETH:s prestandapanel kan man se att miniblocktiden hade ökat under veckan som ledde fram till den 3 juni. Faktum är att en sådan trend skulle börja direkt efter varje omstart av sequencer sedan lanseringen av det offentliga testnätet. Tidigare innebar de frekventa uppgraderingarna av sequencern att miniblocktiden inte skulle öka med någon märkbar mängd innan den uppåtgående trenden återställdes. De senaste uppgraderingarna hade dock inte krävt omstarter av sequencer, och trenden fortsatte i veckor. Den 3 juni nådde miniblocktiden nästan 100 ms. Med sequencer-omstarter som blir ännu mindre sannolika i framtiden tack vare heta säkerhetskopior, är det dags att eliminera buggen en gång för alla. Eftersom vi rutinmässigt samlar in massor av telemetridata för testnätet började teamet snabbt gräva. Den första upptäckten var att ökningen av miniblocktiden accelererade över tid – inte bara ökade miniblocktiden, den ökade snabbare och snabbare. Vanligtvis skulle ett sådant symptom innebära att arbetet med att bygga varje miniblock ökade superlinjärt i takt med att fler miniblock byggdes. Vi sköt dock ner hypotesen efter en del mätningar och beräkningar. Vi byggde miniblockpipelinen så att den var nästan helt asynkron till EVM för att uppnå godtyckligt låg miniblocktid. Detta innebär att oavsett hur mycket tid det tar att bygga ett miniblock, kommer EVM att utföra transaktioner under hela tiden. Således skulle den längre byggtiden för miniblock leda till ett högre antal transaktioner per miniblock, men vi observerade inte det. Problemet kan alltså inte vara att bygga miniblock. En noggrann undersökning av koden bekräftar denna slutsats – ingen del i miniblocksbyggprocessen har superlinjär komplexitet. Teamet utökade sökandet och den verkliga gärningsmannen dök snabbt upp. Tiden det tog att begå EVM-block hade ökat; Dessutom var incheckningstiden helt linjär till antalet EVM-block som producerats sedan den senaste omstarten. När du begår EVM-block uppdateras EVM-miljön, t.ex. blockhöjd, så EVM måste pausa och kan inte utföra transaktioner, vilket innebär att det inte heller finns några miniblock. Det finns ett fast intervall på 1 sekund mellan EVM-blocken. Inom 1-sekundersbudgeten leder en linjärt ökande åtagandetid till en linjärt minskande varaktighet för att köra transaktioner, vilket i sin tur leder till ett linjärt minskande antal miniblock som produceras. Om vi tar dess reciproka får vi den genomsnittliga miniblocktiden, som är omvänt proportionell i tid. Det är exakt den funktionsform som vi såg på prestandainstrumentpanelen. Matematiken stämde in. Vid den tidpunkten visste vi exakt vad vi skulle leta efter: någon procedur vars arbetsbelastning ökar linjärt över tid i den specifika del av koden som hanterar att begå EVM-block. Resten av arbetet var okomplicerat. Teamet tryckte på uppgraderingen den här veckan och miniblocktiden har inte smugit sig på. Så, vad var lärdomen? Jag tycker att det återigen visade kraften när ingenjörskonst styrs av noggranna mätningar och första principer. Teamet arbetar med de andra uppgraderingarna med samma filosofi. Håll ögonen öppna!