PeerDAS and a 48 blob target in 2025

This post kicks off a multi-part series on PeerDAS. Over the coming weeks we’ll publish performance deep dives for every major consensus layer /execution layer (el/cl) client pair, surfacing how each stack performs in preparation for the upcoming Fusaka upgrade.

The Ethereum Foundation recently outlined its priorities for the next 12 months: scale L1, scale blobs, and improve UX. This matters because rollups, Ethereum's primary scaling solution, depend on Ethereum for data availability. With more than $37B secured on rollups, our next phase of scale hinges on abundant, low cost blobspace to sustain user activity. This is where PeerDAS comes in, enabling Ethereum to process eight times more data without sacrificing security or decentralization.

Today, Ethereum nodes handle blob data availability by downloading all blob data included in each block - currently up to 6 blobs - and custodying it for 4,096 epochs (~18 days). While this ensures strong data availability guarantees, it imposes clear scalability limits: more blobs mean more storage, which demands increasingly powerful nodes. PeerDAS (EIP-7594) marks a step in the direction of danksharding, a fundamental shift in how Ethereum handles data: rather than downloading all blob data, nodes will shard the responsibility for blob custody.

By building on existing infrastructure and bandwidth requirements with battle-tested networking components, PeerDAS enables Ethereum to scale to at least 48 blob target per block, unlocking an 8x increase in blob capacity and raising throughput from ~220 to ~3,500 UOPS (user operations per second) without compromising Ethereum’s security guarantees. This means lower costs, better user experience, and a stronger ecosystem. Additionally, increased L2 activity would translate into more overall fees on L1, bolstering Ethereum’s security model by boosting validator revenues and reinforcing network security.

Simply put, scaling L2 via PeerDAS strengthens Ethereum's L1.

In this article, we'll explore how PeerDAS works and how it impacts different ecosystem stakeholders - from node operators and rollups to app developers and users. We'll also share how OP Labs is collaborating with Sunnyside Labs, Base, and Soneium to accelerate the launch of PeerDAS in the upcoming Fusaka upgrade, targeted for later this year.

What do nodes do today?

With Pectra now live, each block has a blob target of 6 and blob limit of 9. Each blob can hold up to 128KB of data. When considering only the blob data payload (excluding additional data such as kzg_commitment or kzg_proof), since all nodes custody all blobs, all nodes will be required to store 128 kB x 6 = 768 kB of data per block.

How does PeerDAS change things?

In this section, we'll discuss how PeerDAS works at a high level. For a deeper look into the technical architecture, we highly recommend this post. Manu’s PeerDAS from scratch makes for an excellent read too!  

With PeerDAS, the blob size is doubled using erasure coding, i.e. we split blobs into 64 columns and perform erasure coding to extend to 128 columns. Each full node downloads and verifies a small, randomly assigned portion of the data. At a network level (at time of writing, that’s more than 9,600 validating full nodes). This provides a very high degree of certainty that the full dataset is available. By sampling rather than fully downloading blobs, Ethereum can achieve an eightfold boost in blob capacity without increasing node storage and bandwidth requirements.

Most validating nodes will be required to custody and serve 8 columns (more on this later). Considering only the blob data payload (excluding other data such as kzg_commitment or kzg_proof), we can define the following:

• Each node custodies 8 data columns
• 48 blobs per block target 
• Each cell holds 2 kB of data

This means all validating nodes will be required to store 8 x 48 x 2 kB = 768 kB of blob data per block (which you’ll notice is the same as the current storage requirements at 6 blobs/block!)

By distributing responsibility across the network and relying on sampling over full custody, Ethereum scales efficiently without sacrificing decentralization or security.

How does this impact different stakeholders?

Both the execution and consensus layer clients will see updates to support PeerDAS. These include changes to blob gossiping, subnet sampling, validator custodying and cell validation logic. 

Node operators: Instead of seeing entire blobs being fetched, your nodes will subscribe to gossip subnets for assigned data slices and respond to sampling requests from peers. You’ll configure custody parameters and deploy updated software, but the day‑to‑day hardware requirements remain within your existing capacity. Higher blob throughput will also result in higher fee payouts (more blobs means more blob gas and commitment transactions, which means more fees/revenues for the validator operators).

A few things to note:

• Non validating nodes will handle at least 4 data columns
• Nodes with at least one attached validator handle a minimum of 8 data columns
• For each additional 32 ETH staked, nodes store an extra data column
• Nodes staking ≥ 1,824 ETH (57 validators) handle at least 64 columns, enabling reconstruction of the whole set
• Nodes staking ≥ 3,872 ETH (121 validators) must handle all 128 columns and are called supernodes

Solo stakers: PeerDAS ensures that solo staking remains accessible, enabling solo stakers to secure Ethereum using affordable home setups or cloud VMs. Your nodes will only download a fraction of each blob’s data, performing light proof checks, thus keeping CPU and bandwidth requirements within the current recommendations. 

Rollups: Rollups immediately benefit from PeerDAS. At a 48-blob target, rollups gain nearly 3,300 UOPS worth of additional data availability capacity. This allows rollups to increase gas throughput, reduce fees for their users, and confidently explore newer, more gas intensive applications.

End users and app developers: Lower data availability costs directly translate to reduced fees for end users and an improved user experience. App developers can count on higher gas throughput in their rollups, resulting in faster and more responsive decentralized applications.

Scaling Ethereum, together

Optimism remains deeply committed to Ethereum’s long term success. Reaching the 48 blob target is not a given, but teams across the ecosystem have been working hard towards it. Over the coming weeks, we plan to publish detailed insights from Sunnyside Labs' PeerDAS devnets, showcasing performance benchmarks, progress, and key challenges as we approach the ambitious 48 blob target.

Stay tuned - together, we’re taking Ethereum to everyone.

We’re hiring! If you're passionate about scaling Ethereum, advancing the Superchain, and building open, decentralized infrastructure for the world, check out our open roles. We'd love to hear from you.