rewrite this title Protocol Update 002 – Scale Blobs | Ethereum Foundation Blog

Following up from Protocol Update 001, we’d like to introduce our approach to blob scaling. The L1 serves as a robust foundation for L2 systems to scale Ethereum, and a necessary component of secure L2 solutions is data availability provided by the L1. Data availability ensures that updates L2s make back to the L1 can be verified by anyone. Blobs are the unit of data availability in the protocol today, so scaling the blob count per block is a key requirement to usher in a wave of L2 adoption for use cases like real-time payments, DeFi, social media, gaming, and AI/agentic applications.

Our work is structured as a series of incremental changes to Ethereum’s blob architecture. To accelerate our rate of scaling, we are expanding from a “fork-centric” philosophy to also ship incremental optimizations in non-breaking ways as they become ready. Thus, we have the following projects tied to both network upgrades, but also the periods in between (“interfork”).

TL;DR

Fusaka introduces PeerDAS, a new data architecture that allows blob scaling beyond today’s throughput levels from 6 blobs/block up to 48 blobs/blockBlob Parameter Only (BPO) forks gradually increase mainnet blob count, bolstered by incremental peer-to-peer bandwidth optimizationsAdvanced networking techniques planned for Glamsterdam iterate on the PeerDAS design to scale even furtherMempool sharding preserves Ethereum’s values as data continues to scaleResearch into the next generation of DAS unlocks an evolution in secure DA scaling

PeerDAS in Fusaka

The first milestone is the delivery of PeerDAS in the upcoming Fusaka network upgrade. PeerDAS introduces data availability sampling (DAS), where an individual node only downloads a subset of the blob data in a given block. Together with randomized sampling per node, computational load is bounded, even as the total blob count increases. As nodes no longer need to download all the blobs in a block, we can raise the blob count without a commensurate increase in node requirements.

Fusaka is expected later this year with implementations in all Ethereum clients. Extensive testing has been performed on development networks (“devnets”) including non-finality scenarios and adversarial “data withholding” conditions. At this point in the R&D process, we continue to harden existing devnets and plan deployment to testnets and mainnet. Barnabas Busa is leading the charge here to ensure smooth progression through the final stages of the upgrade pipeline.

PeerDAS v1.x

We have two prongs of non-consensus changes in our strategy to progressively scale blobs in between the Fusaka and Glamsterdam upgrades: BPOs and bandwidth optimizations. These are additive as better bandwidth utilization lets us leverage resources towards higher throughput.

BPO

PeerDAS introduced in Fusaka sets the stage for a theoretical increase of 8x from the throughput of Ethereum today (i.e. ~64 KB/s to ~512 KB/s). Rather than immediately jump to this theoretical max at the time of Fusaka deployment, core developers have elected for a more gradual increase via “blob parameter only” hard forks. This mechanism lets core developers program automatic increases in blob capacity over time, keeping us on a continuous growth trajectory. Once programmed, BPOs don’t require any manual intervention to activate. In between steps, we’ll monitor the network and react to scaling bottlenecks that may only present themselves on mainnet, paving the way for the next increase. Barnabas Busa along with others on the EF PandaOps team work closely with the client teams to distill the correct schedule to achieve the 8x scaling from today.

Bandwidth optimizations

There’s a lot we can do to more efficiently use bandwidth on the network. Raúl Kripalani along with Marco Munizaga are leading efforts on this network engineering work. A particularly promising optimization is the introduction of “cell-level messaging” which allows nodes to more intelligently query for parts of the samples introduced in PeerDAS. This change reduces redundant communication on the network, and the bandwidth savings can, in turn, be dedicated to the safe provisioning of even more blob capacity. No consensus or execution protocol changes are needed to unlock this milestone, so they can be shipped interfork before Glamsterdam next year.

PeerDAS v2

This project refers to the next generation of the PeerDAS design that affords even more scale while capitalizing on the bandwidth savings realized from pipelining introduced by EIP-7732 (scheduled for inclusion in Glamsterdam). There are further refinements to cell-level messaging and data reconstruction techniques that let nodes more flexibly sample individual parts of blobs so that the core idea of DAS can be expressed in full. These gains, along with the pipelining benefits that allow for more efficient utilization of the time between blocks, set us up to scale beyond the limits of imminent PeerDAS designs. There are many moving pieces, and exact numbers need to be calibrated to both performance of implementations and mainnet analysis as the blob count is actually scaled in a production setting, but this work should give us the final multiples on DA throughput before needing to seek alternative designs.

This batch of updates will go into the Glamsterdam upgrade expected in the middle of 2026. Alex Stokes and Raúl Kripalani are coordinating the R&D here to ensure we can keep scaling blob throughput.

Blobpool scaling

While the benefits of scaling are clear, we must do so while preserving Ethereum’s core values. One of these directly relevant to blob scaling is censorship resistance. The mempool serves as a decentralized network for blob inclusion and directly provides censorship resistance in the face of a centralized builder network producing most blocks on Ethereum. While instances of censorship have improved over time, it is tantamount to the scaling strategy to also ensure the blob mempool scales with it.

Csaba Kiraly is leading work here so we can maintain this critical resource. Current implementations support near-term blob throughput with vigorous research into the best ways to scale the mempool as we get to higher levels unlocked with Fusaka and beyond.

Future of DA

Beyond future iterations of PeerDAS, we have a variety of research directions to keep scaling DA while retaining the security properties of Ethereum that make it unique. Proposals generally fall under the moniker FullDAS with several flavors under active investigation. A key component of these proposals all involve innovations in peer-to-peer networking that allow for a highly diverse set of participants to shard an increasing number of samples while remaining fault tolerant to adversarial actors. Work such as Robust Distributed Arrays formalizes this notion. Other considerations include low-latency inclusion, censorship resistance, and evolutions of the blob fee market to make it easier to get blobs onchain.

Research here is stewarded by Francesco D’Amato and is very active – reach out if you’d like to collaborate!