PeerDAS¶

Introduction¶

PeerDAS (Peer Data Availability Sampling) is a key technology introduced to Ethereum through EIP-7594 in the Fusaka upgrade (December 2025), designed to significantly expand Ethereum's blob capacity by optimizing the data availability mechanism without increasing hardware requirements for validators.

PeerDAS allows nodes to verify overall data availability by downloading only a small portion of data. Through Data Availability Sampling (DAS) and erasure coding technology, the data download requirement for each node is reduced to ⅛ (potentially 1/16 or 1/32 in the future), paving the way for an eventual 8x blob capacity increase and supporting Ethereum's progression toward full Danksharding.

Core Principles¶

Data Availability Sampling (DAS)¶

Background: - The blobs introduced by EIP-4844 require all nodes to download all blob data - As blob count increases, storage and bandwidth requirements grow linearly - Home stakers struggle to afford data-center-grade hardware requirements - This limits further expansion of blob capacity

DAS Solution: - Nodes only need to download a small portion of data samples - Overall data availability is verified through random sampling - Erasure coding ensures data redundancy - The more nodes in the network, the higher the security

Column Sampling Mechanism¶

Columns vs. Rows: - Row: Complete blob data - Column: A cross-section across all blobs

Why Columns: - PeerDAS defines samples as "columns" rather than "rows" - Column sampling is more efficient than row sampling - Better distribution of data load - Optimized network transmission and storage

Sampling Parameters: - Each node samples ⅛ of the data (current parameters) - Future reduction to 1/16 or 1/32 - Increase column count by reducing sample size - Flexibly adjusted to adapt to network conditions

Technical Implementation¶

Erasure Coding¶

Reed-Solomon Erasure Coding: - Data is encoded into N blocks - Only any k blocks are needed to reconstruct the complete data - N - k blocks can be lost without affecting recovery - Provides data redundancy and fault tolerance

Applied to PeerDAS: - Blob data is expanded through erasure coding - Distributed across multiple columns - Nodes randomly select columns for sampling - Ensures data is always recoverable

Pseudo-Random Sampling¶

Randomness Guarantee: - Pseudo-random number generators are used to select sampling columns - Prevents attackers from predicting sampling patterns - The larger the network, the lower the probability of a successful attack - Follows a sublinear decline trend

Security: - Addresses data withholding attacks - Attackers cannot know in advance which nodes will sample which data - Must control the vast majority of nodes to successfully hide data - Higher network decentralization means greater security

Impact on Nodes¶

Reduced Hardware Requirements¶

Storage Requirements: - Full blob storage: 100% data - PeerDAS (⅛): Only 12.5% data - Future (1/16): Only 6.25% data - Reduction: Approximately 87.5% storage savings

Bandwidth Requirements: - Download volume reduced by 87.5% - Upload volume correspondingly reduced - Reduced network transmission pressure - Supports running nodes on residential broadband

Computation Requirements: - Verification computation significantly reduced - Only need to verify sampled columns - Reduced CPU and memory pressure - Standard hardware is sufficient

Supporting Home Staking¶

Democratizing Validation: - No data-center-grade hardware needed - Can run on ordinary laptops or NUCs - Reduced operational costs - Increased network decentralization

Incentivizing More Participation: - Lower technical barrier - Reduced operational expenses - Attracts more retail stakers - Enhances network security

Scaling Potential¶

Current vs. Future¶

EIP-4844 (Dencun): - Target: 3 blobs/block - Maximum: 6 blobs/block - Total capacity: 768 KB/block

EIP-7691 (Pectra): - Target: 6 blobs/block - Maximum: 9 blobs/block - Total capacity: 1.125 MB/block

PeerDAS (Fusaka): - Optimized data distribution mechanism - Paves the way for larger-scale scaling - Target: Support 8x capacity increase - Ultimate: Tens to hundreds of blobs per block

Path to Full Danksharding¶

Progressive Scaling Roadmap: 1. Proto-Danksharding (Dencun): Introduced the blob concept 2. Increased Blob Capacity (Pectra): 3/6 -> 6/9 3. PeerDAS (Fusaka): Optimized data distribution, reduced node burden 4. Further Blob Increases: Gradually increase blob count as PeerDAS matures 5. Full Danksharding: Target 16 MB/second data throughput

Long-Term Vision: - Hundreds of blobs per block - 16 MB/second data throughput - Fully sharded data availability layer - Support for massive L2 transaction volume

Compatibility with EIP-4844¶

Fully Backward Compatible: - PeerDAS builds on top of EIP-4844 - Does not change the fundamental blob structure - Only optimizes data distribution and sampling mechanisms - Existing L2s require no modifications

Progressive Deployment: - Can be rolled out gradually - Nodes can selectively upgrade - Does not affect normal network operation - Reduces upgrade risk

Impact on Layer 2¶

Lower Costs: - More blob capacity means more data availability - L2s can publish more transaction data - Further reduces L2 transaction fees - Increases L2 throughput

Support for More Rollups: - Larger data availability space - Supports more Rollups running simultaneously - Reduces competition between Rollups - Promotes L2 ecosystem growth

Faster Settlement: - More blob space reduces congestion - L2s can submit data more frequently - Accelerates finalization time - Improves user experience

Deployment Timeline¶

2024: EIP-7594 proposal and specification development
H1 2025: Testnet deployment and testing
December 3, 2025: Fusaka upgrade activates PeerDAS on mainnet

Technical Challenges¶

Network Protocol Optimization: - Requires efficient P2P data distribution mechanisms - Gossip protocol optimization - Reduce network latency and overhead - Ensure rapid data propagation

Security Guarantees: - Prevent data withholding attacks - Ensure sufficient data redundancy - Handle malicious nodes - Maintain network robustness

Client Implementation: - All clients need to support PeerDAS - Implement complex sampling logic - Optimize storage and retrieval - Ensure interoperability