How PeerDAS Reduces the Burden on Ethereum Nodes
The core mechanism by which PeerDAS (Peer-to-Peer Data Availability Sampling) reduces node burden is "divide and conquer": instead of requiring every node to download all blob data, it splits the data into small pieces, letting each node randomly store and verify only a tiny portion, and uses cryptography to ensure the entire dataset remains recoverable. This way, even as total data volume grows significantly, the storage and bandwidth demands of a single node stay unchanged.
The world's largest cryptocurrency exchange by trading volume,leading in security and liquidity.
New user benefit: Enjoy 20% off trading fees upon registration!
This design directly responds to a critical bottleneck in Ethereum scaling: if the method of verifying data availability does not change, every doubling of L2 transaction volume would proportionally increase the resource requirements for running a node. Eventually only a few data centers could afford to run nodes, undermining network decentralization.
Prerequisites
You have a basic understanding of Ethereum's "blob" (the temporary data type introduced with the Dencun upgrade specifically for L2 data storage).
You know that after the Pectra upgrade each block can contain up to 9 blobs, with a target of 6.
You are interested in how PeerDAS will affect regular node operators after it goes live.
Step 1: Understanding how PeerDAS redistributes tasks
Before PeerDAS, every node had to download and store all the blob data included in a block. This caused node burden to grow proportionally with the number of blobs.
PeerDAS introduces Data Availability Sampling (DAS), breaking the verification task apart:
Splitting and redundancy: A blob's data is doubled in size using erasure coding. The expanded data is then cut into 128 "columns"; only any 64 columns are needed to recover the entire blob.
Random assignment: Based on its node ID, each node is randomly assigned to store and verify a small subset of columns (typically 8 columns).
Verifying availability: A node does not need to download all the data. It simply requests a few column fragments at random from other nodes in the network and confirms their authenticity using cryptographic proofs (KZG commitments). As long as the majority of nodes can successfully sample their respective fragments, it can be confirmed with high probability that the entire dataset is complete and available.
Simply put, it's like a giant jigsaw puzzle where each person is responsible for keeping and checking just a few pieces, and by cross-checking with one another they can confirm the whole picture is complete—without anyone needing to hold every piece.
Step 2: Calculating the actual change in node burden
Through the mechanism above, PeerDAS achieves the effect of "scaling without adding burden." Below is a comparison of node storage requirements under different target blob counts:
| Network state | Target blobs per block | Node data storage (approx.) | Notes |
|---|---|---|---|
| Pectra upgrade (current) | 6 | 768 KB / block | Every node must store all blob data. |
| Fusaka + PeerDAS | 6 → 48 (gradual increase) | 768 KB / block | Each node stores only 8 columns; total storage stays the same as before the upgrade. |
| Fusaka + PeerDAS (early stage) | 14 (target for Jan 7, 2026) | ~32 GB | For a node with 1–8 validators, this is lower than the current ~100 GB requirement. |
Key takeaway: Even if the blob target rises to 48 in the future, the storage and bandwidth requirements of a single node will not multiply—they essentially stay at pre-upgrade levels. This lays the foundation for potentially reaching a target of 48 blobs (roughly 8× the current data throughput).
Step 3: Understanding the specific requirements for different roles
PeerDAS imposes differentiated requirements depending on the node type:
Regular full node (no validator): only needs to store and serve 4 data columns, plus sample an additional 4 columns. Lowest requirements.
Validator node (with staked ETH): must store at least 8 data columns. For each additional 32 ETH staked (i.e., each extra validator), one more data column is required, up to a maximum of 128 columns.
"Supernode": a node with more than 3,872 ETH staked, or one that actively enables this mode, must store all 128 data columns. Such nodes can respond to blob queries faster and help the network repair data gaps.
Common misconception
Misunderstanding "sampling" to mean the node no longer needs any data.
This is a widespread misconception. PeerDAS's "sampling" does not mean a node is completely free from handling data; it transforms the verification responsibility from storing all the data into "storing a small portion of the data + sampling other portions from the network." Nodes still bear storage and bandwidth costs—but those costs are capped at a fixed, low level and will not rise as the network scales. It trades full data replication for more efficient distributed verification.
Risk reminders
After the Fusaka upgrade, regular nodes will no longer be able to provide complete blob data: If the node you run needs to serve full blobs (for example, to support L2s), you will have to enable semi-supernode or supernode mode, which significantly increases storage and bandwidth demands.
Centralization risks of "supernodes": While reducing burden on ordinary nodes, the new mechanism gives rise to "supernodes" that store the entire dataset. If there are too few such nodes, data repair efficiency could be affected.
Fork choice attacks: In theory, an attacker could exploit uncertainty during the sampling phase to launch a "premature reorg" attack, making some validators think data is available and thereby influencing final consensus. The protocol design already accounts for this risk, and developers are tuning parameters to mitigate it.
The world's largest cryptocurrency exchange by trading volume,leading in security and liquidity.
New user benefit: Enjoy 20% off trading fees upon registration!
How to confirm PeerDAS is operating normally
Regular node operators do not need to take active steps. Once the upgrade is complete, you can verify operation as follows:
Your node client (e.g., Lighthouse, Teku) is updated to a Fusaka-compatible version and starts without errors.
Check block explorers or client logs for information related to "data columns." If you haven't enabled "supernode" mode, your node will not sync full blob data, but it will participate normally in the data availability sampling process and will not experience resource exhaustion.
