Understanding Base expansion plan: Increasing gas target by 1Mgas/s per week in the future

Source: Base, Mirror; Compiled by: Tao Zhu, Golden Finance

One of Base’s 2024 roadmap plans is to make on-chain technology accessible to everyone at an affordable price. We are focused on providing fast, low-cost transactions on a secure, decentralized L2 to enable global participation in the on-chain economy.

We will showcase our progress in this new blog series Scaling Base, where we will share updates and our plans to get a billion people on-chain. In this issue, we will share our approach to increasing data availability capacity while looking forward to integrating PeerDAS in the upcoming Pectra upgrade.

Scaling Base since its release

Ethereum introduced EIP-4844 in March of this year - an upgrade that reduced L2 fees by 100 times by decoupling them from Ethereum mainnet fees. This separation enables the combined network to scale: if Layer 2 is congested, it can act independently to increase its target capacity and reduce transaction fees.

As a result, we’ve scaled Base’s throughput 4x since launching a year ago, increasing the gas target per block from 2.5 Mgas/s to 10 Mgas/s in order to keep fees below 1 cent as activity increases. This is only possible because of the massive effort from the Base core team and builders across the ecosystem to scale the OP Stack, Ethereum clients, and the EVM.

Next Steps: 1 Mgas/s per Week

A few months ago, we set an ambitious goal: to achieve 1 Ggas/s of capacity for Base. We knew that achieving this goal would require a lot of effort and collaboration from many teams. Taking a step back, we realized that the more predictability we could provide in the scaling process, both for our internal teams and for the broader ecosystem, the easier it would be to plan and coordinate the necessary work.

To provide this clarity, we’re changing our mindset about scaling Base: we’ll commit to continually increasing the gas target, and then work to ensure we can achieve that growth by scaling all of our key properties.

To begin, we are publicly committing to increase the base gas target by 1 Mgas/s per week starting in late September. These increases will be continually monitored and tested - if we need to change plans, we will clearly communicate our key learnings and changes. As we continue to scale the underlying infrastructure and build confidence, we will aim to increase the rate of increase (e.g. 2 Mgas/s per week) to accelerate our progress towards 1 Ggas/s.

Pectra and PeerDAS

As Base continues to scale, we hope that the Ethereum community will integrate the necessary mainnet upgrades to improve the availability of L1 data to ensure that L2 can continue to bring the next billion users on-chain.

Over the past two years, we have worked with the Ethereum core developer community to complete this task, starting with EIP-4844. This upgrade, led by the Base team, OP Labs, and Ethereum core developers, significantly reduced the cost of Base and other L2s by introducing blob space and providing a fixed amount of blob space to provide data availability.

But as demand increases, our forecasts show that the current limits will not be able to meet Base's needs over the next year. This is where PeerDAS comes into play.

PeerDAS (Peer Data Availability Sampling) is a protocol change in the upcoming Pectra hard fork that addresses this issue by increasing total blob capacity without requiring every node to download every blob. It ensures that Ethereum nodes can access all blob data while downloading only a small portion, significantly reducing network bandwidth requirements and freeing up a lot of data availability capacity.

The Base core team has been actively preparing to include PeerDAS in the Pectra upgrade:

Sponsored Business Content

• We are working with ethPandaOps to perform a network analysis of the PeerDAS development network to provide the necessary data to provide recommendations.

• We are contributing to the implementation in Prysm, which was used to drive initial analysis.

PeerDAS blob capacity

In addition to these contributions, we advocate for a substantial increase in blob capacity at the same time as PeerDAS is activated. This is critical to scaling efforts, allowing more data to be processed without overloading a single node.

Any protocol change that impacts bandwidth should naturally face developer scrutiny, as there is a risk of introducing network instability and network-related denial-of-service attacks. Due to the complexity of PeerDAS, some have advocated for its inclusion while keeping blob capacity unchanged initially. This approach would defer any increase in data availability capacity to a subsequent upgrade, which would likely be several months (if not a year) after Pectra activates in 2025.

While the final details of PeerDAS are still being discussed, we believe its architecture allows existing bandwidth-constrained stakers to participate safely. In addition, EIP-7251, also planned for Pectra, should reduce attestation and sync_committee p2p traffic, which are major consumers of node bandwidth.

Impose higher minimum prices on blob data

One argument against increasing capacity is that L1 nodes need to be fairly compensated for the compute, storage, and bandwidth required to provide data availability. When demand for blobs is below the target, the price drops to a floor of 1 wei per byte of blob data. Demand above the target capacity allows a market-based pricing mechanism to kick in, better recovering the costs incurred by L1 nodes.

We believe that addressing this issue by capping DA capacity is a step in the wrong direction; instead, we suggest a different approach that ensures a healthy market for blob space so that the network is fairly compensated while keeping it unconstrained. Some potential solutions are to increase the minimum blob fee or implement a different fee mechanism for blob data.

Raising the Target for Positive-Sum Scaling

After the release of EIP-4844, L2 transaction fees will be decoupled from Ethereum mainnet fees as long as average blob demand is below the target (currently 3 per block).

So far, we have only seen a few cases where blob demand has exceeded this target for a long time. Some may view blob demand below the target as a reason to act conservatively. However, with Base’s expansion plans and L2 demand growing, we expect demand to consistently reach or exceed capacity in the coming months. Exceeding the target will end the decoupling of transaction fees - not allowing L2s to independently increase capacity and keep fees low.

When data availability reaches target capacity, scaling becomes a zero-sum game - an increase in throughput for one L2 negatively impacts another. Our goal is to create a positive-sum scaling environment. Implementing PeerDAS and increasing the number of blobs are key steps to achieve this goal.

L2 Protocol Improvements

L1 data availability can be indirectly extended through L2 protocol improvements, which reduce the required data. The OP Stack already has innovations such as span batched data layout and Brotli compression in the Fjord upgrade, which improves Base’s data compression rate by 25%. Future enhancements include state compression and aggregatable signatures for L2 transactions and UserOps. These improvements, while helpful, are icing on the cake. Ultimately, the data availability capacity of the mainnet must grow to support a healthy scaling roadmap.

Looking Ahead

As Ethereum continues to grow, any increase in data availability capacity will eventually be absorbed by organic demand. While a market-based pricing regime for data availability is inevitable, maintaining separate fees for as long as possible will allow Ethereum to reach its full potential more quickly.