In den letzten Wochen habe ich nicht viele Updates über @ethrex_client, unseren @class_lambda @ethereum L1 Ausführungsklienten und ZK L2 Stack geteilt. Bitte folgt @ethrex_client, um mehr über alles zu erfahren, was wir tun. Im L1 betreiben wir bereits erfolgreich Ethereum-Testnets und im L2 führen wir Testnets für die Identitäts- und DeFi-Anwendungen durch, die wir für und mit Partnern entwickeln. Ich glaube ehrlich, dass wir kurz davor stehen, die einfachste Codebasis und den einfachsten Stack zu haben, um ihn zu warten, zu aktualisieren und zu modifizieren in Ethereum. Wir hätten diesen Punkt nicht erreicht, ohne den Code von @NethermindEth und @go_ethereum zu überprüfen. Mit meinen Partnern @rj_aligned, @fran_aligned von @alignedlayer und @SantiDiPaolo, @AguuMg von @PolFinance_ stehen wir kurz davor, eines der ersten Whitepapers über RWA L2s zu veröffentlichen, die von Ethrex und @alignedlayer unterstützt werden. Wir haben noch viele weitere in der Pipeline, aber ich bin besonders auf dieses hier gespannt, da es einen sehr interessanten Anwendungsfall aus TradFi und DeFi überbrücken wird. Wir haben als Berater und Partner einige der stärksten Teams in der Branche. Ich freue mich darauf, mehr über dieses Projekt zu teilen. Updates L1 Wir haben an vielen Fronten gearbeitet. Wir haben die Beobachtbarkeit mit Grafana verbessert, nicht verwendete Funktionen entfernt, um die Codebasis zu vereinfachen, und Unterstützung für den `engine_getBlobsV1` Endpunkt hinzugefügt. Changelog: feat(l1): `engine_getBlobsV1` Anforderungsendpunkt (#3636) chore(l1): entferne redb Unterstützung (#4103) refactor(l1): entferne unnötige usizes aus dem Blockchain-Crate (#4110) fix(l1): entferne unnötigen Statusklon (#4117) fix(l1): verwende das richtige Docker-Image, um Localnets zu starten. (#4131) chore(l1): füge Blockzeit zum Grafana-Dashboard hinzu. (#4112) fix(l1): ziehe DB-Lesezeiten von der Blockausführung ab. (#4051) chore(l1): Verbesserungen der Metriken. (#4118) chore(levm): verbessere die Organisation des neuen levm-Testläufers (#3958) L2 Im Einklang mit unserem minimalistischen Ansatz haben wir eine erhebliche Menge an Code aus nicht verwendeten L2-Datenbanken entfernt. Wir setzen die Vereinfachung der Codebasis fort und beseitigen toten Code. Darüber hinaus wurde die CI stabilisiert, nachdem ein Fehler im Zusammenhang mit Gaspreisen behoben wurde. Wir benchmarken das L2 auf zwei Fronten: - L2-Netzwerkwartungskosten: Wir optimieren die L2-Parameter, indem wir verschiedene Szenarien mit unterschiedlichen Transaktionslasten und Netzwerk-Konfigurationen simulieren. Das Ziel ist es, die ungefähren Wartungskosten pro Transaktion zu bestimmen, die die Benutzer tragen müssen, damit das Netzwerk selbsttragend wird. - Benchmarks zur isolierten Blockausführungsnachweisgenerierung: Mit dem ethrex-replay-Tool beweisen wir Blöcke von Hoodi, Sepolia und Mainnet, um potenzielle Fehler in der Codebasis zu identifizieren und die Leistung unseres Provers zu messen. Auf der ethrex-replay-Seite ist das Tool stabil genug, und wir haben die Infrastruktur eingerichtet, um regelmäßig die Blockausführungen und -nachweise öffentlicher Netzwerke wiederzugeben. Wir beheben jetzt Fehler, die während dieser Läufe aufgetreten sind. Einige Fehler stammen von logischen Fehlern in ethrex, während andere mit dem Speicherverbrauch zusammenhängen. Letztere sind größtenteils behoben, und wir machen erhebliche Fortschritte bei den anderen. Wir haben auch begonnen, @ziskvm und @0xLita ZKVMs für eine mögliche kurzfristige Integration zu betrachten. Wir unterstützen bereits @RiscZero und @SuccinctLabs. In dieser Woche haben wir einen PR zusammengeführt, der ethrex-replay stabilisiert, was es uns ermöglicht, zwei Fehler in ethrex zu identifizieren und zu beheben. Diese Fixes wurden ebenfalls zusammengeführt. Der erste Fehler betraf einen Randfall in unserem ecrecover Precompile, bei dem ein bestimmter Input die Ausführung aufgrund eines Gasfehlers zum Scheitern brachte. Nach gründlicher Untersuchung haben wir das Problem auf die offizielle SP1-gepatchte secp256k1-Bibliothek zurückverfolgt. Wir haben es behoben, indem wir zur SP1-gepatchten k256-Bibliothek migriert sind. Der zweite Fehler stammte von einer falschen Annahme über die Bitlänge eines usize-Typs in einem Teil der Codebasis. Um ähnliche Probleme zu vermeiden, haben wir eine umfassende Überprüfung der Codebasis durchgeführt und mehrere PRs eingereicht, um die Verwendung von usize auf zwei spezifische Fälle zu beschränken: Indizierung und Szenarien, die durch eine API oder Bibliothek eingeschränkt sind. Darüber hinaus fügen wir Unterstützung hinzu, um die EF-Test-Suiten, einschließlich Blockchain- und Zustandstests, mit SP1 auszuführen, um unsere Testabdeckung zu verbessern und die Robustheit in verschiedenen Ausführungsszenarien sicherzustellen. Mit diesen behobenen Fehlern treten die Probleme nicht mehr auf. Wir spielen erfolgreich neue Hoodi- und Sepolia-Blöcke wieder, und die Blockausführungen im Mainnet haben sich erheblich verbessert, wobei die Erfolgsquote der SP1-Ausführung von 1/10 auf 6/10 gestiegen ist. Dieser Fortschritt ebnet den Weg, um unsere verbleibenden Herausforderungen mit den aktuellen Blockwiederholungen anzugehen: Out-of-Memory-Fehler während der Blockausführung im SP1 zkVM und Leistungsprobleme bei der Ausführung und dem Beweisen. Um dies zu beheben, haben wir das Crate des Tools für die Speicherprofilierung mit dem Jemalloc-Crate eingerichtet. Wir arbeiten auch daran, die Wiederholung historischer Blöcke zu unterstützen. Ein MVP für diese Funktion befindet sich in einem Entwurf-PR und funktioniert gut mit den ethrex-, reth- und geth-Clients, hat jedoch Probleme mit den nethermind-Clients. Bevor wir die erste Version veröffentlichen, wollen wir die RPC-Anfragen optimieren, um genaue Blockdaten-Downloads sicherzustellen, selbst wenn wir kostenlose RPC-Anbieter verwenden, für die meisten Blöcke. DevEx Verbesserungen: - Wir haben unsere Binär-Bauten so angepasst, dass sie auf bestimmten Betriebssystemen und Architekturen CUDA nicht mehr als Standardabhängigkeit benötigen. Diese Korrektur ist in der neuesten Version enthalten. - Ein PR wurde eingereicht, um die Version von ethrex in rex zu aktualisieren, um die Kompatibilität mit den neuesten Änderungen in ethrex L2 sicherzustellen. - Wir haben begonnen, einen neuen Tab für den ethrex L2-Monitor in Entwicklungsumgebungen zu entwickeln. Dieser Tab wird entwicklerrelevante Informationen anzeigen, wie eine Liste von reichen Konten und die Adressen von L1- und L2-Verträgen. Changelog: - refactor(l2): ersetzte usize-Zustandsdifferenzkonstanten. - feature(l1,l2): konfiguriertes ethrex-replay für die Speicherprofilierung. - refactor(l1): entfernte unnötige usize-Nutzung im Blockchain-Crate (im Zusammenhang mit dem Bugfix). - feature(l1,l2): neue Befehle zum Ausführungszeugnis hinzugefügt. - fix(levm): Probleme im Zusammenhang mit 32-Bit-Architektur behoben (im Zusammenhang mit dem Bugfix). - refactor(levm): aktualisierte ecrecover-Implementierung, um k256 anstelle von secp256k1 zu verwenden (im Zusammenhang mit dem Bugfix). - ci(l1,l2): GPU-Bauten getrennt und das x86-64-v2-Ziel übernommen. Leistung In dieser Woche haben wir unseren Fokus auf den CPU-Verbrauch und die Benchmarks fortgesetzt. Was den CPU-Verbrauch betrifft, haben wir 2 verschiedene Fälle identifiziert, einen, in dem das Blockbuilding vorhanden ist, und einen, in dem es nicht vorhanden ist. Wir priorisieren die ohne Blockbuilding, da sie immer vorhanden sind und andere Bemühungen (wie Snap-Sync) beeinflussen. Soweit wir untersucht haben, hängt es vollständig mit p2p zusammen. Wir werden unsere Bemühungen in diesem Bereich fortsetzen. In Bezug auf die Benchmarks haben wir nach unserer letzten Woche Verbesserung der modexp-Leistung einige identifizierte Verbesserungen fokussiert, wie codecopy und verwandte Operationen sowie signextend, mulmod und addmod. Wir werden unseren Fokus sowohl auf den CPU-Verbrauch als auch auf die Leistung der Tests, die wir als nächste Schritte für mögliche Verbesserungen identifiziert haben, wie eth-Transfers und andere levm-OpCodes, fortsetzen.