Deze week heeft de upgrade van het MegaETH-testnet een hardnekkige prestatiebug verholpen die ervoor zorgde dat de miniblock-tijd continu toenam tussen de herstarts van de sequencer. Hier is het verhaal. Het is een verhaal over onze filosofie – meten, dan bouwen. Als iemand recent het prestatie-dashboard van MegaETH had bezocht, zou men kunnen zien dat de miniblock-tijd was toegenomen in de week voorafgaand aan 3 juni. Eigenlijk zou zo'n trend beginnen direct na elke herstart van de sequencer sinds de lancering van het publieke testnet. Voorheen betekenden de frequente upgrades van de sequencer dat de miniblock-tijd niet met een waarneembaar bedrag zou toenemen voordat de opwaartse trend werd gereset. Echter, recente upgrades vereisten geen herstarts van de sequencer, en de trend zette zich wekenlang voort. Op 3 juni bereikte de miniblock-tijd bijna 100 ms. Met herstarts van de sequencer die in de toekomst nog minder waarschijnlijk worden dankzij hot backups, is het tijd om de bug voorgoed te elimineren. Aangezien we routinematig veel telemetriegegevens voor het testnet verzamelen, begon het team snel te graven. De eerste ontdekking was dat de toename van de miniblock-tijd in de loop van de tijd versnelde – niet alleen nam de miniblock-tijd toe, maar het nam steeds sneller toe. Gewoonlijk zou zo'n symptoom impliceren dat het werk dat betrokken is bij het bouwen van elke miniblock superlineair toenam naarmate er meer miniblocks werden gebouwd. We hebben echter de hypothese verworpen na wat meten en berekenen. We hebben de miniblock-pijplijn bijna volledig asynchroon gemaakt ten opzichte van de EVM om arbitrarily lage miniblock-tijden te bereiken. Dit betekent dat hoe lang het ook duurt om een miniblock te bouwen, de EVM gedurende die hele tijd transacties zal uitvoeren. Dus, de langere tijd voor het bouwen van miniblocks zou leiden tot een hoger aantal transacties per miniblock, maar dat hebben we niet waargenomen. Dus, het probleem kan niet liggen bij het bouwen van miniblocks. Zorgvuldige inspectie van de code bevestigt deze conclusie – geen enkel deel van het proces voor het bouwen van miniblocks heeft superlineaire complexiteit. Het team breidde de zoektocht uit, en de echte schuldige kwam snel naar voren. De tijd die nodig was om EVM-blokken te bevestigen, was toegenomen; verder was de bevestigingstijd perfect lineair aan het aantal EVM-blokken dat sinds de laatste herstart was geproduceerd. Bij het bevestigen van EVM-blokken wordt de EVM-omgeving, zoals de blokhoogte, bijgewerkt, zodat de EVM moet pauzeren en geen transacties kan uitvoeren, wat betekent dat er ook geen miniblocks zijn. Er is een vaste interval van 1 seconde tussen EVM-blokken. Binnen het budget van 1 seconde leidde een lineair toenemende bevestigingstijd tot een lineair afnemende duur om transacties uit te voeren, wat op zijn beurt leidde tot een lineair afnemend aantal geproduceerde miniblocks. Als we de omgekeerde waarde nemen, krijgen we de gemiddelde miniblock-tijd, die omgekeerd evenredig is in de tijd. Het is precies de functievorm die we op het prestatie-dashboard zagen. De wiskunde klopte. Op dat moment wisten we precies waar we naar moesten zoeken: een procedure waarvan de werklast lineair toeneemt in de specifieke code die verantwoordelijk is voor het bevestigen van EVM-blokken. De rest van het werk was eenvoudig. Het team heeft deze week de upgrade doorgevoerd en de miniblock-tijd is niet meer gestegen. Dus, wat was de les? Ik denk dat het opnieuw de kracht toonde wanneer engineering wordt geleid door zorgvuldige metingen en eerste principes. Het team werkt aan de andere upgrades met dezelfde filosofie. Blijf op de hoogte!