The last few week I've not shared many updates about @ethrex_client, our @class_lambda @ethereum L1 execution client and ZK L2 stack. Please follow @ethrex_client to learn more about everything we are doing. In the L1 we are already successfully running Ethereum testnets and in the L2 we are running testnets for the identity and DeFi applications we are building for and with partners. I honestly believe we are close to having the simplest codebase and stack to mantain, upgrade and modify in Ethereum. We wouldn't have been able to reach this point without checking the code of @NethermindEth and @go_ethereum With my partners @rj_aligned, @fran_aligned from @alignedlayer and @SantiDiPaolo, @AguuMg from @PolFinance_ we are about to release one of the first whitepapers about a RWA L2s that will be powered by Ethrex and @alignedlayer. We got many more coming but I'm particularly excited by this one since it will bridge a very interesting usecase from TradFi and DeFi. We got as advisors and partners some of the strongest teams in the industry. I'm eager to share more about this project. Updates L1 We've been working on many fronts. We have improved the observability with Grafana, removed unused features to simplify the codebase and added support for `engine_getBlobsV1` endpoint. Changelog: feat(l1): `engine_getBlobsV1` request endpoint (#3636) chore(l1): remove redb support (#4103) refactor(l1): remove unnecessary usizes from blockchain crate (#4110) fix(l1): removed unnecesary state clone (#4117) fix(l1): use proper docker image to spin up localnets. (#4131) chore(l1): add block time to grafana dashboard. (#4112) fix(l1): subtract DB read times from block execution. (#4051) chore(l1): metric improvements. (#4118) chore(levm): improve organization of new levm test runner (#3958) L2 In line with our minimalist approach, we removed a significant amount of code from unused L2 databases. We continue to simplify the codebase and eliminate dead code. Additionally, the CI was stabilized after fixing a bug related to gas prices. We are benchmarking the L2 on two fronts: - L2 network maintenance cost: We are fine-tuning L2 parameters by simulating various scenarios with different transaction workloads and network configurations. The goal is to determine the approximate maintenance commission cost per transaction that users must bear for the network to achieve self-sustainability. - Isolated block proof of execution generation benchmarks: Using the ethrex-replay tool, we are proving blocks from Hoodi, Sepolia, and Mainnet to identify potential bugs in the codebase and measure our prover's performance. On the ethrex-replay side, the tool is stable enough, and we have infrastructure set up to periodically replay public networks' block executions and proofs. We are now addressing bugs that emerged during these runs. Some bugs stem from logical errors in ethrex, while others are related to memory usage. The former are mostly resolved, and we are making significant progress on the latter. We've also started looking at @ziskvm and @0xLita ZKVMs for potential short-term integration. We already support @RiscZero and @SuccinctLabs. This week, we merged a PR that stabilizes ethrex-replay, enabling us to identify and resolve two bugs in ethrex. These fixes have also been merged. The first bug involved an edge case in our ecrecover precompile, where a specific input caused execution to fail due to a gas mismatch. After thorough investigation, we traced the issue to the official SP1-patched secp256k1 library. We resolved it by migrating to SP1-patched k256 library. The second bug stemmed from an incorrect assumption about the bit length of a usize type in part of the codebase. To prevent similar issues, we conducted a comprehensive review of the codebase and submitted multiple PRs to restrict usize usage to two specific cases: indexing and scenarios constrained by an API or library. Additionally, we are adding support to run the EF test suites, including blockchain and state tests, with SP1 to enhance our testing coverage and ensure robustness across different execution scenarios. With these bugs addressed, the issues no longer occur. We are successfully replaying new Hoodi and Sepolia blocks, and Mainnet block executions improved significantly, with the SP1 execution success rate rising from 1/10 to 6/10. This progress clears the path to tackle our remaining challenges with recent block replays: out-of-memory errors during block execution in the SP1 zkVM and performance issues in execution and proving. To address these, we've set up the tool's crate for memory profiling using the Jemalloc crate. We're also working on supporting the replay of historical blocks. An MVP for this feature is in a draft PR and performs well with ethrex, reth, and geth clients but encounters issues with nethermind clients. Before releasing the first version, we aim to optimize RPC requests to ensure accurate block data downloads, even when using free RPC providers, for the majority of blocks. DevEx Improvements: - We fixed our binary builds to no longer require CUDA as a default dependency on certain operating systems and architectures. This fix is included in the latest release. - A PR has been submitted to update ethrex's version in rex, ensuring compatibility with the latest changes in ethrex L2. - We've begun developing a new tab for the ethrex L2 monitor in development environments. This tab will display developer-relevant information, such as a list of rich accounts and the addresses of L1 and L2 contracts. Changelog: - refactor(l2): replaced usize state diff constants. - reature(l1,l2): configured ethrex-replay for memory profiling. - refactor(l1): removed unnecessary usize usage in the blockchain crate (related to the bug fix). - feature(l1,l2): added new commands to the execution witness. - fix(levm): addressed issues related to 32-bit architecture (related to the bug fix). - refactor(levm): updated ecrecover implementation to use k256 instead of secp256k1 (related to the bug fix). - ci(l1,l2): separated GPU builds and adopted the x86-64-v2 target. Performance This week we continued our focus on the cpu consumption and benchmarks. Regarding CPU consumption, we identified 2 different cases, one where block building is present and another one where it's not. We are prioritizing the ones without block building given that they are present always and impact other efforts (like snap sync). As far as we investigated it's completely related to p2p. We will continue our efforts on this front With respect to benchmarks, after our last week enhancement of the modexp performance we focused on some detected improvements, like codecopy and related operations as well as signextend, mulmod and addmod. We'll continue our focus on both the CPU consumption and the performance of test that we identified as next steps for possible improvements, like eth transfers and other levm opcodes.