Die Dokumente zu realtime_sendRawTransaction und paginierten Protokollabfragen sind jetzt verfügbar. Credits gehen an @0xSami_M! Wir arbeiten an einer Überarbeitung der Dokumentationswebsite.

Bunny braucht etwas Schatten

parallele E.V.M. (Ethereum Veggie Machine)

Ich bin mir nicht so sicher. Selbst PoW basiert letztendlich auf der Annahme, dass der Gegner nicht über große Mengen physischer Infrastruktur (CPU, GPU, ASIC, SSD, Stromversorgung usw.) über längere Zeiträume kontrollieren kann, was eine wirtschaftliche Annahme ist. Sowohl PoW als auch PoS delegieren das schwierige Problem der Sybil-Minderung an Regeln, Muster und Heuristiken der Off-Chain-Welt.

RT @0xBreadguy: Schön, dass dieser Beitrag die Solana Shreds (15ms) als Vergleich zu Megas 10ms Blöcken hervorgehoben hat. Irgendwie landen wir immer wieder in dies…

Die Gespräche führten schnell zu einem optimalen Co-Design von CLOB und Kette, was durchaus erwartet wurde!!

Es gibt ein wöchentliches Ingenieurmeeting zwischen GTE und MegaETH. Wir besprechen alles, von neuen RPC-Methoden (wer möchte paginierte Abfragen?) bis hin dazu, wie Spam auf der schnellsten Blockchain betrachtet werden sollte. Ich werde ständig daran erinnert, wie talentiert, ehrgeizig und pragmatisch das Team ist. Es war mir eine große Freude, im vergangenen Jahr mit dem GTE-Team zu arbeiten, und das ist erst der Anfang! Herzlichen Glückwunsch an @GTE_XYZ !!

Pup musste 42 Stunden reisen, nur um zu uns zu kommen, und hatte Verspätung. Also fuhren wir 3 Stunden mitten in der Nacht, um die letzten 10 Stunden abzuschneiden. Willkommen zu Hause, River!

Wirklich großartige Systeme bieten benutzerfreundliche Abstraktionen für Endbenutzer, während sie die gesamte Leistung der zugrunde liegenden Mechanismen beibehalten. Cloud abstrahiert Betriebssysteme und Netzwerke zu einem riesigen Computer. Krypto abstrahiert verteilte Algorithmen und Spieltheorie zu einem wohlwollenden Verwalter. EigenCloud abstrahiert Cloud und Krypto in eine immer überprüfbare, unendlich skalierbare Computing-Plattform, auf die jeder alles auslagern kann. Herzlichen Glückwunsch an @sreeramkannan und das @eigenlayer-Team!

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!