Tygodniowa aktualizacja testnetu MegaETH naprawiła nieuchwytny błąd wydajności, który powodował ciągły wzrost czasu miniblocków między restartami sekwencera. Oto historia. To historia o naszej filozofii – mierzyć, a potem budować. Jeśli ktoś odwiedził ostatnio pulpit wydajności MegaETH, mógłby zauważyć, że czas miniblocków wzrastał w tygodniu poprzedzającym 3 czerwca. W rzeczywistości taki trend zaczynał się tuż po każdym restarcie sekwencera od momentu uruchomienia publicznego testnetu. Wcześniejsze częste aktualizacje sekwencera oznaczały, że czas miniblocków nie wzrastał w żadnej zauważalnej ilości przed zresetowaniem trendu wzrostowego. Jednak ostatnie aktualizacje nie wymagały restartów sekwencera, a trend utrzymywał się przez tygodnie. 3 czerwca czas miniblocków prawie osiągnął 100 ms. Przy coraz mniejszych szansach na restarty sekwencera w przyszłości dzięki gorącym kopiom, nadszedł czas, aby raz na zawsze wyeliminować błąd. Ponieważ rutynowo zbieramy dużo danych telemetrycznych dla testnetu, zespół szybko zaczął badać sprawę. Pierwszym odkryciem było to, że wzrost czasu miniblocków przyspieszał w czasie – nie tylko czas miniblocków wzrastał, ale wzrastał coraz szybciej. Zwykle taki objaw sugerowałby, że praca związana z budowaniem każdego miniblocka wzrastała superliniowo w miarę budowania kolejnych miniblocków. Jednak po pewnych pomiarach i obliczeniach odrzuciliśmy tę hipotezę. Zbudowaliśmy potok miniblocków, aby był prawie całkowicie asynchroniczny w stosunku do EVM, aby osiągnąć dowolnie niski czas miniblocków. Oznacza to, że niezależnie od tego, ile czasu zajmuje budowa miniblocka, EVM będzie wykonywać transakcje przez cały ten czas. Tak więc, dłuższy czas budowy miniblocka prowadziłby do większej liczby transakcji na miniblock, ale tego nie zaobserwowaliśmy. Dlatego problem nie może dotyczyć budowy miniblocków. Dokładne zbadanie kodu potwierdza tę konkluzję – żadna część procesu budowy miniblocków nie ma superliniowej złożoności. Zespół rozszerzył poszukiwania, a prawdziwy winowajca szybko się ujawnił. Czas potrzebny na zatwierdzenie bloków EVM wzrastał; co więcej, czas zatwierdzania był idealnie liniowy w stosunku do liczby bloków EVM wyprodukowanych od ostatniego restartu. Podczas zatwierdzania bloków EVM, środowisko EVM, takie jak wysokość bloku, jest aktualizowane, więc EVM musi się zatrzymać i nie może wykonywać transakcji, co oznacza brak miniblocków. Istnieje stały 1-sekundowy interwał między blokami EVM. W ramach 1-sekundowego budżetu, liniowo rosnący czas zatwierdzania prowadził do liniowo malejącego czasu na wykonywanie transakcji, co z kolei prowadziło do liniowo malejącej liczby wyprodukowanych miniblocków. Jeśli weźmiemy jego odwrotność, otrzymujemy średni czas miniblocka, który jest odwrotnie proporcjonalny w czasie. To dokładnie kształt funkcji, który widzieliśmy na pulpicie wydajności. Matematyka się zgadzała. W tym momencie wiedzieliśmy dokładnie, czego szukać: jakiejś procedury, której obciążenie rośnie liniowo w czasie w szczególnej części kodu, która obsługuje zatwierdzanie bloków EVM. Reszta pracy była prosta. Zespół wprowadził aktualizację w tym tygodniu i czas miniblocków nie wzrósł. Więc, jaka była lekcja? Myślę, że ponownie pokazała moc, gdy inżynieria jest kierowana przez staranne pomiary i pierwsze zasady. Zespół pracuje nad innymi aktualizacjami z tą samą filozofią. Bądźcie na bieżąco!