How PeerDAS Helps Ethereum Reclaim "Data Sovereignty"

Article by: imToken

By the end of 2025, the Ethereum community quietly celebrated the conclusion of the Fusaka upgrade.

Looking back over the past year, although discussions about underlying technology upgrades have gradually faded from the market spotlight, many on-chain users have already felt a significant change: Ethereum Layer 2 solutions are becoming increasingly cheaper.

Today’s on-chain interactions, whether transfers or complex DeFi operations, often only cost a few cents in Gas fees or can be ignored altogether. Behind this, the Dencun upgrade and Blob mechanism have played a crucial role. At the same time, with the official activation of the core feature PeerDAS (Peer Data Availability Sampling) in the Fusaka upgrade, Ethereum is also bidding farewell to the era of “full data download” verification.

It can be said that, what truly determines whether Ethereum can carry large-scale applications sustainably in the long term is not just Blob itself, but more importantly, the next step represented by PeerDAS.

1. What is PeerDAS?

To understand the revolutionary significance of PeerDAS, we cannot just talk about concepts abstractly; we must first revisit a key milestone on Ethereum’s scalability journey—the Dencun upgrade in March 2024.

At that time, EIP-4844 introduced a transaction model carrying Blobs (embedding large amounts of transaction data into blobs), enabling Layer 2 solutions to move away from relying on expensive calldata storage mechanisms and instead use temporary Blob storage.

This change directly reduced the cost of Rollups to a tenth of the previous, ensuring that L2 platforms could offer cheaper and faster transactions without compromising Ethereum’s security and decentralization, allowing users to enjoy the benefits of a “low Gas fee era.”

However, while Blob is very useful, each block on the Ethereum mainnet has a hard limit on the number of Blobs it can carry (usually 3-6). The reason is very practical: physical bandwidth and disk space are limited.

In traditional verification modes, every validator—whether operated by professional institutions or ordinary home computers—must download and propagate the complete Blob data to verify its validity.

This creates a dilemma:

• If the number of Blobs increases (for scalability): data volume surges, home nodes’ bandwidth gets saturated, disks fill up, forcing them offline, which could lead to network centralization, ultimately turning into a giant chain only run by large data centers;
• If the number of Blobs is limited (for decentralization): L2 throughput is locked, unable to meet future explosive growth.

In essence, Blob is just the first step, solving the “where to store” problem. When data is small, everything works fine. But if the number of Rollups continues to grow, each submitting data at high frequency, and Blob capacity expands, then bandwidth and storage pressures on nodes will become new centralization risks.

Continuing with the traditional full download model, unable to address bandwidth constraints, Ethereum’s scalability will hit a wall. PeerDAS is the key to breaking this deadlock.

In one sentence, PeerDAS is fundamentally a new data verification architecture that breaks the ironclad rule that verification must involve full data download, allowing Blob capacity to surpass current physical throughput levels (e.g., from 6 Blobs/block to 48 or more).

2. Blob solves “where to put it,” PeerDAS solves “how to store it efficiently”

As mentioned above, Blob took the first step in scalability, solving the “where to store” problem (moving from expensive Calldata to temporary Blob space). What PeerDAS aims to solve is “how to store data more efficiently.”

Its core challenge is how to prevent physical bandwidth from being overwhelmed as data volume explodes exponentially. The idea is straightforward: based on probability and distributed cooperation, not everyone needs to store the full data, yet we can still highly likely confirm that the data truly exists.

This can be seen from the full name of PeerDAS—“Peer Data Availability Sampling Verification.”

The concept sounds obscure, but we can use a simple analogy to understand this paradigm shift. For example, traditional full verification is like a library receiving a massive 3,000-page “Encyclopedia Britannica” (Blob data). To prevent loss, every librarian (node) must make a complete copy of the book as a backup.

This means only those with enough resources (bandwidth/disk space) can be librarians, especially as the encyclopedia keeps expanding, content increasing, and ordinary people being phased out, leading to centralization.

Now, with PeerDAS sampling and techniques like Erasure Coding, it’s like tearing the book into countless fragments, encoding them mathematically, and distributing them. Each librarian no longer needs to hold the entire book—just a few randomly selected pages.

Even during verification, no one needs to present the whole book. Theoretically, if the network collectively holds any 50% of the fragments (regardless of whether they hold page 10 or page 100), we can, through mathematical algorithms, instantly reconstruct the entire book with 100% certainty.

This is the magic of PeerDAS—shifting the burden of data download from individual nodes to a collaborative network of thousands of nodes across the entire network.

scale70Source: @Maaztwts

From a purely data perspective, before the Fusaka upgrade, the number of Blobs was stuck at a single digit (3-6). With PeerDAS implementation, this upper limit is torn open, allowing the number of Blobs per block to jump from 6 to 48 or more.

When users initiate a transaction on Arbitrum or Optimism, and data is packaged and sent back to the mainnet, there’s no longer a need to broadcast the complete data to the entire network. This enables Ethereum’s scalability to leap forward without linearly increasing node costs.

Objectively, Blob + PeerDAS constitute the complete Data Availability (DA) solution. From a roadmap perspective, this is also a critical transition from Proto-Danksharding to full Danksharding on Ethereum.

3. The new on-chain normal after Fusaka

As is well known, in the past two years, third-party modular DA layers like Celestia gained significant market share due to the high cost of Ethereum’s mainnet data storage. Their narrative was based on the premise that Ethereum’s native data storage was expensive.

Now, with Blob and the latest PeerDAS, Ethereum has become both cheaper and highly secure: the cost for Layer 2 to publish data to Layer 1 has been cut in half, and Ethereum’s vast validator set far exceeds that of third-party chains in security.

Objectively, this is a blow to third-party DA solutions like Celestia, marking a reassertion of Ethereum’s sovereignty over data availability and greatly squeezing their operational space.

You might ask, these are all very low-level details—what do they have to do with wallet usage, transfers, or DeFi?

The connection is very direct. If PeerDAS is successfully implemented, it means that the data costs for Layer 2 can remain low in the long term. Rollups won’t be forced to raise fees due to DA cost rebounds, and on-chain applications can confidently design high-frequency interactions. Wallets and DApps won’t have to constantly compromise between “functionality vs. cost”…

In other words, the reason we can currently use cheap Layer 2 solutions is thanks to Blob. If we want to keep using them affordably in the future, PeerDAS is the silent contributor we rely on.

That’s why, in Ethereum’s scalability roadmap, PeerDAS, though low-profile, is always regarded as an indispensable step. Essentially, it’s the most technically elegant form in the author’s view—“beneficial yet unnoticed, its absence would be hard to sustain”—making its presence almost imperceptible.

Ultimately, PeerDAS proves that blockchain can, through clever mathematical designs (like data sampling), carry Web2-level massive data loads without excessively sacrificing decentralization.

At this point, Ethereum’s data highway is fully paved. The next question for the application layer is: what kind of vehicles will run on this road?

Let’s wait and see.