rewrite this title Protocol Update 001 – Scale L1 | Ethereum Foundation Blog

In June, we introduced Protocol, reorganizing the Ethereum Foundation’s research & development teams to better align on our current strategic goals, Scale L1, Scale Blobs, and Improve UX without compromising on our commitment to Ethereum’s security and hardness.

Over the coming weeks, we’ll publish updates on each work stream, covering their ongoing progress, new initiatives, open questions and opportunities for collaboration. We start today with Scale L1 — expect follow-ups about Scale Blobs and Improve UX soon!

TL;DR

Marius van der Wijden joined Ansgar Dietrichs and Tim Beiko to co-lead Scale L1Mainnet’s gas limit increased to 45M post-Berlinterop, a first step on the road to 100M gas and beyond All major execution layer clients shipped Pre-Merge History Expiry, significantly reducing node disk usageBlock-Level Access Lists (BALs) are being considered as a headliner for GlamsterdamCompute & state benchmarking initiatives are underway to better manage EVM resource pricing and performance bottlenecksThe path to zkEVM real-time proving is becoming more concrete, with the prototyping of a ZK-based attester client underwayWe are still hiring a Performance Engineering Lead: applications close Aug 10

Geth-ing Serious About L1 Scaling

Scaling Ethereum requires reconciling ambitious designs with engineering pragmatism. To help us achieve this, we’ve appointed Marius van der Wijden as co-lead for Scale L1 alongside Ansgar Dietrichs and Tim Beiko.

Marius’s extensive engineering experience on Geth combined with his commitment to protocol security make him a perfect fit to align our scaling strategy with Ethereum’s constraints.

Together, Ansgar, Marius and Tim have defined a set of key initiatives that will enable us to Scale L1 as quickly as possible. 

Towards a 100M Mainnet Gas Limit

Our immediate goal is safely scaling Ethereum’s mainnet gas limit to 100M per block. Parithosh Jayanthi, closely supported by Nethermind’s PerfNet team, is leading our work getting through each incremental increase.

At the recent Berlinterop event, client teams significantly improved their worst-case performance benchmarks, enabling the recent increase to 45M gas — a first step on the path toward 100M gas and beyond!

Additionally, client hardening has become an integral part of the 100M Gas initiative. The Pectra upgrade rollout highlighted several issues caused by network instability. It is paramount to ensure clients remain robust as throughput increases, even if the network temporarily loses finality.

History Expiry

The History Expiry project, led by Matt Garnett, reduces Ethereum nodes’ historical data footprint. The recent deployment of Partial History Expiry removed pre-Merge historical data, saving full nodes approximately 300–500 GB of disk space. This ensures they can run comfortably with a 2TB disk.

Building on this, we’re now developing Rolling History Expiry, which will continuously prune historical data beyond a fixed retention period. This will keep nodes’ storage needs manageable, even as Ethereum scales.

Block-Level Access Lists

Block-Level Access Lists (BALs), championed by Toni Wahrstaetter, are emerging as a leading candidate for inclusion in the Glamsterdam upgrade. BALs provide several critical benefits:

Enable parallel transaction execution within blocks.Facilitate parallel computation of state roots, significantly speeding up block processing.Allow preloading of required state at the start of block execution, optimizing disk access patterns.Improve overall node sync efficiency, benefiting new and archival nodes.

These improvements collectively enhance Ethereum’s capacity to reliably handle higher gas limits and faster block processing.

Benchmarking & Pricing

An ongoing challenge in scaling Ethereum is aligning the gas costs of EVM operations with their computational overhead. The performance of worst-case edge cases currently limits network throughput.

By improving benchmarking infrastructure and repricing operations that can’t be optimized by clients, we can make block execution times more consistent. If we close the gap between the worst and average case blocks, we can then raise the gas limit commensurately.

Ansgar Dietrichs leads efforts focused on targeted benchmarking and engineering interventions, informed directly by PerfNet’s comprehensive benchmarking, to identify and resolve compute-heavy bottlenecks. Significant progress has already been made post-Berlinterop, particularly in managing worst-case compute scenarios.

In parallel, Carlos Pérez spearheads Bloatnet: an initiative aimed at benchmarking and optimizing state performance. This involves testing node performance under conditions with state sizes double the current mainnet and gas limits reaching 100–150M, to directly inform both repricings and client optimizations.

Both of these efforts will inform Glamsterdam EIP proposals to homogenize resource costs across operations, enabling further L1 scaling.

zkEVM Attester Client

Today, Ethereum nodes execute all transactions in a block when receiving it. This is computationally expensive. To reduce this computational cost, Ethereum clients could instead verify a zk proof of the block’s execution. To enable this, proofs of the block must be produced in real time, which we are getting closer and closer to.

Kevaundray Wedderburn is leading work on a zkEVM attester client that assumes we have real time proofs and uses them to fulfill its validator duties.

Once the prototype is ready for mainnet, it will roll out as an optional verification mechanism. We expect a small group of nodes to adopt this over the next year, allowing us to build confidence in its robustness and security.

After this, Ethereum nodes can gradually transition to zk-based validation, with it eventually becoming the default. At that point, L1’s gas limit could increase substantially — even go beast mode!

RPC Performance & Hiring

As throughput increases, different node types (execution, consensus, RPC) face distinct challenges. RPC nodes specifically encounter heightened pressure as they serve extensive historical and real-time state requests.

Internally, the EF’s Geth and PandaOps teams are actively researching optimal configurations for different node types. We expect the importance of this to increase in the coming years and want to grow our expertise in this domain.

To that end, we’re actively hiring for a Performance Engineering Lead. Applications close August 10. If you’re as excited as us about scaling the L1, we’d love to hear from you!