Upgrade-ul de săptămâna aceasta la rețeaua de testare MegaETH a remediat o eroare de performanță evazivă care a făcut ca timpul de miniblocare să crească continuu între repornirile secvențierii. Iată povestea. Este o poveste despre filozofia noastră – măsură, apoi construiește. Dacă cineva a vizitat recent tabloul de bord de performanță al MegaETH, ar putea vedea că timpul de miniblocare a crescut în săptămâna dinaintea zilei de 3 iunie. De fapt, o astfel de tendință ar începe imediat după fiecare repornire a secvențiatorului de la lansarea rețelei de testare publice. Anterior, actualizările frecvente ale secvențiatorului însemnau că timpul miniblocului nu creștea cu nicio măsură perceptibilă înainte ca tendința ascendentă să fie resetată. Cu toate acestea, actualizările recente nu au necesitat reporniri ale secvențiatorului, iar tendința a continuat săptămâni întregi. Pe 3 iunie, timpul de miniblocare aproape a ajuns la 100 ms. Având în vedere că repornirile secvențierului devin și mai puțin probabile în viitor datorită backup-urilor fierbinți, este timpul să eliminați bug-ul o dată pentru totdeauna. Deoarece colectăm în mod obișnuit o mulțime de date de telemetrie pentru rețeaua de testare, echipa a început rapid să sape. Prima descoperire a fost că creșterea timpului de miniblocare s-a accelerat în timp – nu numai că timpul de miniblocare a crescut, dar a crescut din ce în ce mai repede. De obicei, un astfel de simptom ar implica faptul că munca implicată în construirea fiecărui minibloc a crescut superlinear pe măsură ce au fost construite mai multe miniblocuri. Cu toate acestea, am respins ipoteza după câteva măsurători și calcule. Am construit conducta minibloc pentru a fi aproape complet asincronă cu EVM, astfel încât să obținem un timp minibloc arbitrar scăzut. Aceasta înseamnă că, oricât de mult timp este necesar pentru a construi un minibloc, EVM va executa tranzacții pe tot parcursul timpului. Astfel, timpul mai lung de construcție a miniblocului ar duce la un număr mai mare de tranzacții pe minibloc, dar nu am observat acest lucru. Deci, problema nu poate fi cu construirea de miniblocuri. Examinarea atentă a codului confirmă această concluzie – nicio parte din procesul de construcție a miniblocurilor nu are complexitate superliniară. Echipa a extins căutarea, iar adevăratul vinovat a ieșit rapid la suprafață. Timpul necesar pentru a comite blocaje EVM a crescut; mai mult, timpul de angajare a fost perfect liniar cu numărul de blocuri EVM produse de la ultima repornire. La comiterea blocurilor EVM, mediul EVM, cum ar fi înălțimea blocului, este actualizat, astfel încât EVM trebuie să se întrerupă și nu poate executa tranzacții, ceea ce înseamnă nici miniblocuri. Există un interval fix de 1 secundă între blocurile EVM. În cadrul bugetului de o secundă, o creștere liniară a timpului de angajare duce la o scădere liniară a duratei tranzacțiilor, ceea ce la rândul său duce la o scădere liniară a numărului de miniblocuri produse. Dacă luăm reciprocul său, obținem timpul mediu de miniblocare, care este invers proporțional în timp. Este exact forma funcției pe care am văzut-o pe tabloul de bord de performanță. Matematica s-a verificat. În acel moment, știam exact ce să căutăm: o procedură al cărei volum de muncă crește liniar în timp în partea specifică a codului care se ocupă de comiterea blocurilor EVM. Restul muncii a fost simplă. Echipa a împins actualizarea săptămâna aceasta și timpul de miniblocare nu s-a strecurat. Deci, care a fost lecția? Cred că a arătat din nou puterea atunci când ingineria este ghidată de măsurători atente și principii de bază. Echipa lucrează la celelalte actualizări cu aceeași filozofie. Rămâneți pe fază!