L'aggiornamento di questa settimana al testnet MegaETH ha risolto un bug di prestazioni sfuggente che aveva causato un continuo aumento del tempo di miniblock tra i riavvii del sequencer. Ecco la storia. È una storia sulla nostra filosofia: misurare, poi costruire. Se si fosse visitato recentemente il dashboard delle prestazioni di MegaETH, si sarebbe potuto notare che il tempo di miniblock era aumentato durante la settimana che precedeva il 3 giugno. In realtà, tale tendenza sarebbe iniziata subito dopo ogni riavvio del sequencer sin dal lancio del testnet pubblico. In precedenza, i frequenti aggiornamenti al sequencer significavano che il tempo di miniblock non aumentava di alcuna quantità percepibile prima che la tendenza al rialzo venisse ripristinata. Tuttavia, gli aggiornamenti recenti non avevano richiesto riavvii del sequencer, e la tendenza è continuata per settimane. Il 3 giugno, il tempo di miniblock ha quasi raggiunto i 100 ms. Con i riavvii del sequencer che diventano sempre meno probabili in futuro grazie ai backup a caldo, è tempo di eliminare il bug una volta per tutte. Poiché raccogliamo regolarmente molti dati di telemetria per il testnet, il team ha rapidamente iniziato a scavare. La prima scoperta è stata che l'aumento del tempo di miniblock accelerava nel tempo: non solo il tempo di miniblock aumentava, ma aumentava sempre più velocemente. Di solito, tale sintomo implicherebbe che il lavoro coinvolto nella costruzione di ogni miniblock aumentasse in modo superlineare man mano che venivano costruiti più miniblock. Tuttavia, abbiamo scartato l'ipotesi dopo alcune misurazioni e calcoli. Abbiamo costruito la pipeline di miniblock per essere quasi completamente asincrona rispetto all'EVM in modo da ottenere tempi di miniblock arbitrariamente bassi. Ciò significa che, qualunque sia il tempo necessario per costruire un miniblock, l'EVM eseguirà transazioni durante tutto il tempo. Pertanto, un tempo di costruzione del miniblock più lungo porterebbe a un numero maggiore di transazioni per miniblock, ma non abbiamo osservato ciò. Quindi, il problema non può essere nella costruzione dei miniblock. Un'attenta esaminazione del codice conferma questa conclusione: nessuna parte del processo di costruzione del miniblock ha complessità superlineare. Il team ha ampliato la ricerca e il vero colpevole è emerso rapidamente. Il tempo necessario per confermare i blocchi EVM era aumentato; inoltre, il tempo di conferma era perfettamente lineare rispetto al numero di blocchi EVM prodotti dall'ultimo riavvio. Quando si confermano i blocchi EVM, l'ambiente EVM, come l'altezza del blocco, viene aggiornato, quindi l'EVM deve fermarsi e non può eseguire transazioni, il che significa niente miniblock. C'è un intervallo fisso di 1 secondo tra i blocchi EVM. All'interno del budget di 1 secondo, un tempo di conferma che aumenta linearmente porta a una durata di esecuzione delle transazioni che diminuisce linearmente, il che a sua volta porta a un numero di miniblock prodotti che diminuisce linearmente. Se prendiamo il suo reciproco, otteniamo il tempo medio di miniblock, che è inversamente proporzionale nel tempo. È esattamente la forma della funzione che abbiamo visto sul dashboard delle prestazioni. I calcoli sono stati confermati. A quel punto, sapevamo esattamente cosa cercare: qualche procedura il cui carico di lavoro aumenta linearmente nel tempo nella parte particolare del codice che gestisce la conferma dei blocchi EVM. Il resto del lavoro è stato semplice. Il team ha spinto l'aggiornamento questa settimana e il tempo di miniblock non è aumentato. Quindi, qual è stata la lezione? Penso che abbia dimostrato ancora una volta il potere quando l'ingegneria è guidata da misurazioni accurate e principi fondamentali. Il team sta lavorando su altri aggiornamenti con la stessa filosofia. Rimanete sintonizzati!