Scaling Ethereum to keep up with increasing demand is a challenging but necessary task. Traditional hard forks often involve significant changes, creating operational challenges for developers and the wider community. Blob-Parameter-Only (BPO) forks offer a simpler, more focused solution. By adjusting just two parameters—blob targets and limits—Ethereum can scale its data availability incrementally and more predictably.

This approach ensures solo stakers can remain part of the network while providing Layer 2 solutions with the capacity they need to keep transaction costs low. In this blog post, we will discuss how BPO forks work, their key benefits, and the framework guiding their implementation.

Overview of BPO Forks

Blob-Parameter-Only (BPO) forks are a proposed mechanism to incrementally and safely scale Ethereum’s data capacity. Unlike traditional Ethereum hard forks that implement various large-scale changes, BPO forks focus exclusively on adjusting two parameters:

  1. Blob Targets – The desired or targeted average number of data "blobs" per block.
  2. Blob Limits – The maximum allowable number of data blobs per block.

These parameters are critical for Ethereum's scalability, especially in relation to data availability (DA) for Layer 2 (L2) rollups. By focusing solely on these two parameters, BPO forks simplify the operational burden associated with hard forks, making the scaling process more predictable and manageable.

Purpose & Benefits of BPO Forks

The introduction of BPO forks aims to address Ethereum's dual challenges:

  • Ensuring that solo stakers (individual validators who are not part of larger pools) can continue participating with manageable bandwidth requirements.
  • Enabling Layer 2 rollups to process transactions at competitive costs by increasing Ethereum’s data availability.

BPO forks propose a sustainable method of scaling Ethereum's blob capacity in smaller, more regular increments rather than large, infrequent updates. This approach is designed to:

  • Reduce the operational overhead and complexity of hard forks.
  • Provide a clearer roadmap for Ethereum’s scaling trajectory.
  • Share the responsibility of scaling decisions across both Ethereum Layer 1 (L1) and Layer 2 (L2) ecosystems.

Layer 2 Data Avalability, in terms of data posted per day to L1 has grown exponentially.

Source: growthepie

The ultimate goal is to balance the needs of solo stakers and L2 rollups, creating a framework for continuous and adaptive growth in Ethereum's capacity.

Framework for BPO Forks

The framework sets out three core conditions that must be met before a BPO fork can proceed:

1. Solo Staker Minimum Bandwidth Requirements: Solo stakers are crucial to Ethereum’s decentralization. To ensure they remain viable, the framework identifies a bandwidth requirement of approximately 50 Mbps for both download and upload speeds (for those not using MEV-boost).

This bandwidth requirement ensures that solo stakers can handle the increased data demands caused by adjustments to blob targets and limits.

2. Ensuring Safety for Solo Stakers: Specifically, a proposed increase should not result in excessive block sizes that exceed solo staker bandwidth limits.

A useful framework for assessing safety involves analyzing the 30-day trailing p999 block size (i.e., the block size at the 99.9th percentile) and ensuring it remains within the solo staker bandwidth limits even after the parameter adjustment.

3. Sustained Blob Congestion: The framework requires that blobs be "sustainably congested" to justify an increase in blob capacity. This means the average blob count per block should consistently meet or exceed the blob target for at least 10 days before any parameter adjustment.

Source: Dune

Sustained congestion indicates a genuine and ongoing demand for higher blob limits, ensuring that increases are based on real-world usage patterns rather than speculative or temporary spikes.

Community Feedback

Since these forks are designed to address both technical and operational challenges, input from various stakeholders—such as developers, solo stakers, and Layer 2 (L2) teams—is critical to their design and implementation.

The community has provided several valuable suggestions to streamline the implementation and adoption of BPO forks:

  1. Efficient Testing of Blob Parameter Changes: Community members have emphasized the need for robust testing mechanisms to evaluate the safety and efficiency of proposed blob parameter increases. Testing ensures that the changes are viable for both Layer 1 (L1) and Layer 2 (L2) ecosystems.
  2. Collaborative Scaling Solutions: By sharing the operational and developmental burden across Ethereum contributors, including L1 and L2 teams, the implementation process becomes smoother and more inclusive.

The community has also voiced concerns regarding:

  • Impact on Solo Stakers: Ensuring that solo stakers are not excluded due to increased bandwidth requirements remains a primary concern.
  • Fork Cadence: Some community members advocate for more frequent BPO forks to ensure timely responses to scaling needs, while others suggest that a slower cadence allows for more thorough testing and preparation.

New Ideas Proposed

One specific technical parameter that requires attention is the BLOB_BASE_FEE_UPDATE_FRACTION. This parameter governs how the blob base fee adjusts in response to changes in blob targets and limits. If blob targets are raised, this parameter may need to be adjusted to ensure smooth and predictable changes in the blob fee market.

  • Failure to update this parameter alongside other blob changes could lead to unpredictable fee dynamics, disrupting the economic incentives for validators and L2 users.
  • Community members recommend including adjustments to this parameter in the framework for BPO forks.

Another proposed idea involves managing the blob gas limit similarly to the block gas limit. This approach would allow each block to "vote" on the blob gas limit, enabling dynamic adjustments based on network conditions and usage.

  • While this approach offers flexibility, it introduces additional complexity to the fork process and may require significant changes to the current consensus mechanism.
  • Further research and experimentation are needed to determine the feasibility of this approach.

As Ethereum scales to meet the demands of its expanding ecosystem, BPO forks will play a critical role in ensuring that the network remains efficient, inclusive, and future-ready. By addressing both technical and operational challenges, BPO forks offer a clear path forward in Ethereum’s journey toward scalability. This framework also minimizes operational overhead while ensuring Ethereum remains decentralized and accessible.

References: Blob-Parameter-Only (BPO) Forks

_____________________________________________________________________

Disclaimer: The information contained in this website is for general informational purposes only. The content provided on this website, including articles, blog posts, opinions, and analysis related to blockchain technology and cryptocurrencies, is not intended as financial or investment advice. The website and its content should not be relied upon for making financial decisions. Read full disclaimer and privacy Policy.

For Press Releases, project updates and guest posts publishing with us, email to contact@etherworld.co.

Subscribe to EtherWorld YouTube channel for ELI5 content.

Share if you like the content. Donate at avarch.eth or Gitcoin

You've something to share with the blockchain community, join us on Discord!

Follow us at Twitter, Facebook, LinkedIn, and Instagram.