What Full Danksharding Demands from Ethereum Nodes

Full Danksharding's ~1.3 MB per slot target creates a new primary constraint. Nodes must ingest, verify, and store massive data blobs, not just process transactions.\n- New Role: The Blob Sidecar becomes the critical resource, not gas.\n- Hardware Shift: Requires high-throughput NVMe SSDs and >1 Gbps network links.\n- Economic Consequence: Builders who fail to secure cheap, reliable DA lose block-building auctions.

Without enforced PBS, validators cannot feasibly construct blocks with 64 blobs. This cements the builder market as critical infrastructure.\n- Specialization: Builders (e.g., Flashbots, bloXroute) compete on MEV extraction and blob inclusion efficiency.\n- Validator Role: Reduced to block header validation, outsourcing complex construction.\n- Centralization Risk: Node ops must rely on a competitive builder market to avoid being outbid.

To prevent lazy validators, Proof-of-Custody requires each validator to cryptographically prove they downloaded and stored their assigned blob data.\n- Enforcement: Uses Custody Bits and KZG polynomial commitments.\n- Node Requirement: Mandates local blob storage for a period, increasing operational overhead.\n- Slashing Risk: Failure to generate a valid proof results in penalties, making reliable storage a security requirement.

Danksharding's core innovation is Data Availability Sampling (DAS), where nodes probabilistically verify data via random sampling. This model fails if the network lacks sufficient honest nodes to achieve statistical security.

• Critical Threshold: Requires ~1000+ nodes performing DAS to secure a 128-blob block.
• Risk: Sybil attacks or node centralization could degrade security, creating a false sense of data availability.

The peer-to-peer (P2P) network must propagate ~1.3 MB blobs to specialized builder/relay networks within a 12-second slot. This is a 10-100x increase in bandwidth demand versus today.

• Risk: Network congestion could cause proposers to miss blobs, leading to chain re-orgs and MEV extraction.
• Comparison: This is the same scaling challenge that plagues high-throughput L1s like Solana.

Proposer-Builder Separation (PBS) is mandatory for Danksharding. This concentrates block construction power in a few specialized builders with custom hardware.

• Risk: Creates a single point of censorship and MEV centralization, undermining Ethereum's credibly neutral base layer.
• Outcome: The network's liveness depends on the health of ~5-10 major builder entities like Flashbots, potentially replicating the miner centralization problems of Proof-of-Work.

To make stateless clients viable, Danksharding depends on Verkle Trees and zk-SNARKs for efficient state proofs. Verifying these proofs adds new computational overhead to all full nodes.

• Risk: A 10-100ms verification delay per block could push node hardware requirements beyond consumer-grade, reducing node count.
• Consequence: This undermines the stateless client vision, forcing reliance on centralized infrastructure providers.

Rollups like Arbitrum, Optimism, and zkSync will compete for scarce blob space in every block, creating a volatile fee market for data.

• Risk: During peak demand, L2 transaction costs could spike, negating their low-fee promise and pushing users to alternative L1s or validiums.
• Irony: The system designed to scale L2s could become their primary bottleneck and cost center.

The complexity of implementing DAS, PBS, and Verkle proofs could overwhelm smaller client teams like Nethermind or Erigon, consolidating the node software market around Geth.

• Risk: A >66% supermajority for any single client creates a systemic failure risk from a single bug, as seen in past Geth incidents.
• Outcome: Ethereum's resilience is inversely proportional to the difficulty of running a correct, diverse node.

Full Danksharding targets ~1.3 MB/s of persistent blob data. A full node today stores ~1TB; storing all blobs would require ~4 PB/year. This is untenable for decentralization.

• Impossible Storage Load: Solo stakers cannot store the full history.
• Centralization Risk: Pushes node operation to professional data centers.

Nodes no longer download full blobs. Instead, they perform random sampling of small chunks via KZG commitments and PeerDAS. A node only needs to sample ~30-50 chunks to achieve >99% statistical certainty the data is available.

• Constant Workload: Sampling load is independent of total blob size.
• Enables Light Clients: Same sampling logic powers ultra-light verification.

Without enforced PBS, a malicious block producer could create an un-sampleable block—a blob that passes initial sampling but whose full data is later withheld. Only a neutral, competitive builder market (e.g., mev-boost, SUAVE) can provide the economic security needed.

• Critical for Liveness: Prevents data withholding attacks.
• Relies on MEV Infrastructure: Builders become essential data guarantors.

EIP-4844 (Proto-Danksharding) is the training wheels. It introduces blobs and KZG but without DAS. Full Danksharding extends KZG commitments into a 2D grid, enabling efficient sampling. Your node's client (e.g., Geth, Nethermind) must support this new cryptographic primitive.

• Backwards Compatible: Builds directly on 4844's footprint.
• Client Readiness: Requires KZG library integration and PeerDAS networking.

Blobs are ephemeral, deleted by nodes after ~30 days (4096 epochs). This is a hard protocol rule to manage storage. Applications like layer-2 rollups (e.g., Arbitrum, Optimism, zkSync) must ensure their transaction data is archived elsewhere (e.g., EigenDA, Celestia, Avail) before deletion.

• New Risk Vector: L2s must architect robust data pipelines.
• Archival Market Emerges: Creates demand for decentralized storage services.

Sampling requires a new p2p sub-protocol: PeerDAS. Nodes form a topic-based mesh network to request and serve random blob chunks. This replaces simple block gossip. Expect higher peer counts and different bandwidth patterns—constant, low-volume chatter instead of bursty block transfers.

• Network Overhaul: Requires client implementation of new wire protocol.
• Robustness is Key: Network must resist eclipse attacks targeting samplers.