Das Upgrade dieser Woche für das MegaETH-Testnetz hat einen schwer fassbaren Leistungsfehler behoben, der dazu geführt hatte, dass die Miniblockzeit zwischen den Sequencer-Neustarts kontinuierlich anstieg. Hier ist die Geschichte. Es ist eine Geschichte über unsere Philosophie – messen, dann bauen. Wenn man kürzlich das Leistungs-Dashboard von MegaETH besucht hätte, könnte man gesehen haben, dass die Miniblockzeit in der Woche vor dem 3. Juni gestiegen war. Tatsächlich begann ein solcher Trend direkt nach jedem Sequencer-Neustart seit dem Start des öffentlichen Testnetzes. Zuvor bedeuteten die häufigen Upgrades des Sequencers, dass die Miniblockzeit nicht in einem wahrnehmbaren Maße anstieg, bevor der Aufwärtstrend zurückgesetzt wurde. Allerdings hatten die jüngsten Upgrades keine Sequencer-Neustarts erfordert, und der Trend setzte sich über Wochen fort. Am 3. Juni erreichte die Miniblockzeit fast 100 ms. Da Sequencer-Neustarts in Zukunft dank Hot-Backups noch unwahrscheinlicher werden, ist es an der Zeit, den Fehler ein für alle Mal zu beseitigen. Da wir routinemäßig viele Telemetriedaten für das Testnetz sammeln, begann das Team schnell zu graben. Die erste Entdeckung war, dass der Anstieg der Miniblockzeit im Laufe der Zeit beschleunigt wurde – nicht nur stieg die Miniblockzeit, sie stieg immer schneller. Normalerweise würde ein solches Symptom implizieren, dass die Arbeit, die mit dem Bau jedes Miniblocks verbunden ist, superlinear zunimmt, je mehr Miniblocks gebaut werden. Wir haben jedoch die Hypothese nach einigen Messungen und Berechnungen verworfen. Wir haben die Miniblock-Pipeline so gebaut, dass sie fast vollständig asynchron zur EVM ist, um eine beliebig niedrige Miniblockzeit zu erreichen. Das bedeutet, dass egal wie viel Zeit es braucht, um einen Miniblock zu bauen, die EVM während der gesamten Zeit Transaktionen ausführt. Daher würde eine längere Miniblock-Bauzeit zu einer höheren Anzahl von Transaktionen pro Miniblock führen, aber das haben wir nicht beobachtet. Das Problem kann also nicht beim Bau der Miniblocks liegen. Eine sorgfältige Prüfung des Codes bestätigt diese Schlussfolgerung – kein Teil des Miniblock-Bauprozesses hat superlineare Komplexität. Das Team erweiterte die Suche, und der wahre Übeltäter trat schnell zutage. Die Zeit, die benötigt wurde, um EVM-Blöcke zu committen, hatte zugenommen; darüber hinaus war die Commit-Zeit perfekt linear zur Anzahl der seit dem letzten Neustart produzierten EVM-Blöcke. Beim Commit von EVM-Blöcken wird die EVM-Umgebung wie die Blockhöhe aktualisiert, sodass die EVM pausieren muss und keine Transaktionen ausführen kann, was bedeutet, dass es auch keine Miniblocks gibt. Es gibt ein festes Intervall von 1 Sekunde zwischen EVM-Blöcken. Innerhalb des 1-Sekunden-Budgets führte eine linear steigende Commit-Zeit zu einer linear abnehmenden Dauer für die Ausführung von Transaktionen, was wiederum zu einer linear abnehmenden Anzahl von produzierten Miniblocks führte. Wenn wir den Kehrwert nehmen, erhalten wir die durchschnittliche Miniblockzeit, die zeitlich umgekehrt proportional ist. Es ist genau die Funktionsform, die wir im Leistungs-Dashboard gesehen haben. Die Mathematik stimmt. An diesem Punkt wussten wir genau, wonach wir suchen mussten: ein Verfahren, dessen Arbeitslast sich im Laufe der Zeit linear erhöht, im bestimmten Teil des Codes, der das Commit von EVM-Blöcken behandelt. Der Rest der Arbeit war unkompliziert. Das Team hat das Upgrade diese Woche veröffentlicht und die Miniblockzeit ist nicht gestiegen. Was war also die Lektion? Ich denke, sie hat erneut die Kraft gezeigt, wenn Ingenieurwesen durch sorgfältige Messungen und erste Prinzipien geleitet wird. Das Team arbeitet an den anderen Upgrades mit derselben Philosophie. Bleiben Sie dran!