Home / News / technologie

Proto-Danksharding (EIP-4844): Understanding Data Blobs — An In-Depth Learning Guide for the US Web3 Market

NOUTITA NEWSROOM·15 OCT. 2026 À 20:01 (UTC+1)·6 MIN READ

PARALLEL EVM & ZK

TECHNOLOGIE

noutita.com#TECHNOLOGIE

In Brief (TL;DR)

A rigorous, field-ready guide to Proto-Danksharding, data blobs, and the blob-fee market. We unpack theory, practice, and competing viewpoints with citations from primary sources (EIP-4844, Ethereum.org, Etherscan, L2Beat, and leading research).

# Proto-Danksharding (EIP-4844): Understanding Data Blobs

An in-depth guide to how Ethereum’s Proto-Danksharding introduces blob data, how the blob-fee market works, and what this means for Layer-2 rollups in the US market. This piece follows a structured, source-backed exploration designed for engineers, builders, and policy/market observers tracking Web3 scaling in the US.

Proto-Danksharding is an incremental step toward true data sharding. It introduces a new blob-based data channel to blocks, enabling cheaper data posting for rollups while keeping data available for verification. The design is forward-compatible with future sharding, including data-availability sampling (DAS) as a long-term scalability ingredient.

> Key idea: blobs are not executed by the EVM, but their commitments are verifiable and the data is kept available for a finite window. This underpins cheaper rollup data posting today while laying groundwork for future sharding.

> — EIP-4844 (Proto-Danksharding) and Ethereum.org explanations. (eips.ethereum.org)

In Brief (TL;DR)

EIP-4844, also known as Proto-Danksharding, introduces blob-carrying transactions that post large data blobs (up to 128 KB per blob) to Ethereum for a short, finite window. These blobs are not accessible to the EVM but are verifiable via cryptographic commitments. (eips.ethereum.org)

Blobs live on the beacon chain for an initial period; current targets set a retention window of about 18 days, after which the raw blob data can be pruned while the commitments remain on-chain for verification. (ethereum.org)

The initial blob capacity is modest by design (target ~3 blobs per block, max ~6 blobs per block), with a separate blob gas market that adjusts fees independently from the traditional gas market. (eips.ethereum.org)

For practitioners, the blob data model decouples data availability from execution, enabling cheaper data posting for Layer-2 rollups and paving the way for later data-sharding mechanisms. (ethereum.org)

The economics are debated: some research predicts meaningful efficiency gains for rollups, while other studies highlight potential impacts on consensus security and network delays under certain workload patterns. Both sides are rooted in formal models and early post-implementation data. (arxiv.org)

1. Theoretical Foundations & Invariants

A. Proto-Danksharding defines a new data channel, not a full data sharding upgrade

Proto-Danksharding adds a new transaction type for blob-carrying transactions. Each blob carries data that is not executed by the EVM but whose commitment is verifiable. This design is intended to be forwards-compatible with full sharding, which would later introduce a broader data-availability model. (eips.ethereum.org)

The core mechanism uses KZG polynomial commitments to prove data integrity and availability without requiring nodes to fetch every blob. This is central to enabling data availability checks while keeping the data footprint manageable for validators. (ethereum.org)

In the execution layer, blob data is not directly visible to the EVM; instead, validity relies on commitments, proofs, and the blob’s sidecars. This separation of concerns is intended to deliver scaling relief without overburdening execution clients. (eips.ethereum.org)

The concept of sidecars (blob data carried separately from the block body) is designed to decouple data availability from block execution, enabling a more flexible data-availability model for the future. Validators attest to data availability, while execution-layer verification checks blob-related commitments. (eips.ethereum.org)

Quote-worthy summary from the spec:

Blob transactions introduce a new type of data payload that is not accessed by the EVM but is nonetheless verifiable via commitments; this is a stepping stone toward full data sharding. "Beacons block body references blobs, sidecars carry the data, and data availability sampling may replace blob downloads in the future." (eips.ethereum.org)

B. Data availability is decoupled from execution, with a fixed retention horizon

Blobs are stored on the beacon chain to ensure availability, but they do not live forever; their on-chain transparency is time-bound, enabling cheaper blob data relative to calldata. The initial retention horizon is about 18 days (4096 epochs). (ethereum.org)

The system uses a data-availability sidecar approach, where the commitments for the blobs remain verifiable on-chain even after the raw blob data is pruned. This provides a durable integrity backbone while containing long-term state growth. (eips.ethereum.org)

Quote:

The data in blobs is ephemerally stored and pruned after a defined window, while the commitments continue to enable verification. This design balances data availability with hardware feasibility for validators. 18 days is the first community-acknowledged retention horizon. (ethereum.org)

C. Blob size, throughput, and the initial throttle (3 blobs/slot target; 6 max)

The protocol defines a two-tier throughput target for blobs per block: a target of 3 blobs per block (0.375 MB) and a hard maximum of 6 blobs per block (0.75 MB). This conservative starting point helps manage network load while operators validate the system. (eips.ethereum.org)

A blob is sized to 128 KB (bytes per blob set to 128 KB). Each blob carries a cryptographic commitment that can be checked against the blob data via a KZG precompile. (info.etherscan.com)

There is a separate blob gas market that operates independently from the main gas market. Blob base fees adjust according to blob usage relative to the target, using a mechanism analogous to EIP-1559’s base-fee dynamics. (info.etherscan.com)

D. Data integrity, verification, and the KZG commitment stack

Blob data is summarized by a KZG commitment; rollups post a versioned hash to bind the blob data to the block’s validity. Verifiers use a precompile to check that the commitment matches the blob data, ensuring data integrity without exposing raw blob payloads to the EVM. (ethereum.org)

The rule set includes cryptographic helpers, type aliases, and a dedicated blob precompile path to verify polynomial evaluations on committed blob data. This is the cryptographic backbone of blob verification. (eips.ethereum.org)

2. Step-by-Step Tutorial (Practice)

A. Prerequisites & Security

Foundational knowledge: you should understand calldata vs blob data, the two-layer data vs execution separation, and how rollups leverage Ethereum’s data availability. See the EIP-4844 spec and Ethereum.org explainer for a formal basis. (eips.ethereum.org)

Cryptographic prerequisites: familiarity with KZG commitments, versioned hashes, and precompiles. The EIP-4844 spec outlines the commitment scheme and the related precompiles. (eips.ethereum.org)

Data availability horizon: be aware that blob data is retained for a finite window (~18 days) and then pruned, with the commitments remaining as a verifiable record. This is central to blob economics and system security. (ethereum.org)

Market dynamics: the blob fee market is separate from L1 calldata gas and is designed to balance blob usage against capacity. This separation is a deliberate design choice to decouple blob pricing from traditional gas markets. (info.etherscan.com)

B. Executing the Steps

Note: This is a high-level, educational guide. Implementing real blob transactions requires a running client and tooling that support EIP-4844 (Proto-Danksharding), which was introduced with Dencun and matured in subsequent upgrades. See EIP-4844 and Ethereum.org for official specifications and current tooling guidance. (eips.ethereum.org)

Step 1 — Understand the data-path discipline and the blob lifecycle

Read the EIP-4844 specification to understand the blob format, the BLOB_TX_TYPE transaction type, and how blob_versioned_hashes tie to blob data through KZG commitments. The spec provides the canonical definitions and parameters you’ll rely on when constructing or validating blob transactions. (eips.ethereum.org)

Study how the blob sidecars are propagated via the beacon chain and how data availability is confirmed without requiring every node to store the full blob payload. This is the core of the “sidecar” design. (eips.ethereum.org)

Step 2 — Map blob capacity to Rollup posting strategies

Use the initial capacity bounds (target 3 blobs per block, max 6 blobs per block) to reason about data posting schedules. This is the washpoint used by early experiments and policy analyses to model backlog and latency. (eips.ethereum.org)

Explore the blob-fee market dynamics: blob base fees adjust based on excess blob gas, analogous to how EIP-1559 adjusts base gas price based on gas usage. Understanding this helps you model how a given rollup might optimize blob posting versus main-chain calldata posting in a given period. (info.etherscan.com)

Step 3 — Build a minimal “blob posting” mental model (not production code)

Create a mental model of a single block: a block has a target of 3 blobs; if a rollup posts 3 blobs, blob base fee stays steady; if it posts 6 blobs, blob base fee increases; if fewer blobs post, the fee decreases. The EIP describes the exponential adjustment mechanism. (eips.ethereum.org)

Consider the retention window: the data must be available to provers for a window of approximately 18 days; after that, the data can be pruned from the consensus node, while commitments persist on-chain. That retention horizon shapes long-term data strategy for rollups. (ethereum.org)

Step 4 — Read about the economics and counterpoints

For a rigorous economic model of blob posting vs. main-market posting, review the “EIP-4844 Economics and Rollup Strategies” paper. It formulates a continuous-time model and derives when blob posting is optimal, including sharing rules among rollups. (arxiv.org)

To understand potential downsides, consult the delay analysis and empirical studies on data availability, consensus time, and fork risks post-4844. These works provide a cautionary lens on scaling promises and real-world effects. (arxiv.org)

Step 5 — Observe real-world signals on blob usage and pricing

L2BEAT’s Ethereum project page shows the blob-enabled data path as part of Ethereum’s data layer and how blob usage translates into day-to-day throughput and costs. This provides a practical yardstick for market observers. (l2beat.com)

Etherscan’s blob explainer offers concrete numbers: blob size, per-blob capacity, per-block blob limits, and the fact that blob data costs are separate from calldata, including the basic pricing formula. This is useful for analysts tracking US-based DeFi, gaming, or social apps scaling through L2s. (info.etherscan.com)

Step 6 — Prepare for the future: data sampling and sharding

The proto-danksharding approach anticipates future data-availability sampling (DAS) as a replacement for full blob downloads. It’s important to monitor community discussions and core-spec updates as the ecosystem matures—from early blobs to full sharding. (eips.ethereum.org)

C. Quick recap of the core numbers you should remember

Blob data payload per blob: up to 128 KB (blob payload). (info.etherscan.com)

Per-block blob capacity (initial): target 3 blobs, max 6 blobs. (eips.ethereum.org)

Blob data retention: ~18 days (4096 epochs). (ethereum.org)

Blob gas market: independent from main calldata, with a base-fee mechanism that moves up or down based on usage relative to target. (info.etherscan.com)

The Cancun-Deneb (Dencun) upgrade that introduced proto-danksharding went live in March 2024; page updates on Ethereum.org confirm ongoing governance and roadmap details through 2026. (ethereum.org)

D. Editorial stance: two credible viewpoints in the literature

Pro-scaling: Blob posting significantly reduces L2 data costs, enabling cheaper rollup data posting and enabling a more rollup-centric scaling path. Empirical and modeling work suggests meaningful efficiency gains in the blob market and data-availability optimization for L2s. See the blob economics paper and subsequent empirical analyses. (arxiv.org)

Caution on security and dynamics: Some studies find that blob data can affect synchronization and consensus metrics (e.g., longer receive times in slots with data, potential for fork-rate changes). While these do not negate the scaling benefits, they highlight the need for careful parameter tuning and monitoring. (arxiv.org)

E. What this means for the US Web3 market today

The blob model is a pragmatic, near-term scaling lever for Layer-2 ecosystems operating in the United States, where user demand for low-cost, high-throughput transactions remains high (DeFi, gaming, social apps). Blob data provides a cheaper data-availability channel for L2s until full data sharding becomes a reality. The separation of blob data pricing from the main gas market helps insulate L2s from spikes in L1 gas prices, potentially improving user experiences. The official docs and independent analyses consistently frame proto-danksharding as an important incremental step rather than a final answer. (ethereum.org)

F. Citations and further reading

EIP-4844: Shard Blob Transactions (spec and parameters, including TARGET_BLOB_GAS_PER_BLOCK, MAX_BLOB_GAS_PER_BLOCK, and GAS_PER_BLOB). https://eips.ethereum.org/EIPS/eip-4844. (eips.ethereum.org)

Danksharding (Ethereum.org): Proto-Danksharding overview, blob lifecycle, and the 18-day retention rule. https://ethereum.org/roadmap/danksharding. Updated June 2026. (ethereum.org)

Ethereum.org: Data availability and blob data posting for rollups; blob sidecars and DAS roadmap. https://ethereum.org/developers/docs/data-availability. (ethereum.org)

Etherscan Blob explainer: blob size, per-block blob limits, and blob pricing mechanics. https://etherscan.io/tx/0x9c426d5b88... (Blob explainer page) or the blob explainer article. (info.etherscan.com)

L2BEAT: Data-path and blob usage on Ethereum; blob as a DA layer. https://l2beat.com/projects/ethereum. (l2beat.com)

EIP-4844 Economics and Rollup Strategies (arXiv): economic modeling of blob posting vs main market posting. https://arxiv.org/abs/2310.01155. (arxiv.org)

Delay Analysis of EIP-4844 (arXiv): queueing model and latency insights. https://arxiv.org/abs/2409.11043. (arxiv.org)

Impact of EIP-4844 on Ethereum (arXiv): consensus security, data size dynamics, and blob markets; empirical study. https://arxiv.org/abs/2405.03183. (arxiv.org)

Blob data and Dencun upgrade notes (Ethereum Foundation blog and related updates): protocol-priorities and Blobs. https://blog.ethereum.org/2026/02/18/protocol-priorities-update-2026 and related Fusaka blob updates. (blog.ethereum.org)

Meta-note for practitioners in the US market: Proto-Danksharding is an essential, near-term scaling lever for rollups, with a transparent, two-market pricing dynamic (mainnet gas vs blob gas) and explicit data-availability guarantees. As the ecosystem matures toward data sampling and, eventually, full data sharding, watching how blob utilization evolves—especially in major US-facing Layer-2 ecosystems—will be a critical signal for dApp developers, exchanges, and infrastructure providers. The literature remains nuanced: clear scaling benefits are paired with observable effects on synchronization and network dynamics, which means ongoing monitoring and adaptive tooling will be crucial going forward. (ethereum.org)

Note on dates and updates

Cancun-Deneb (Dencun) went live on Mainnet in March 2024. This upgrade introduced proto-danksharding and blob transactions. See the Danksharding page for the live date and context. (ethereum.org)

Page data and governance updates continue through 2026; the Ethereum.org page shows a page last updated in 2026, reflecting ongoing work on data availability and sharding. (ethereum.org)

"In practice, Proto-Danksharding is a measured, incremental step toward a data-centric scaling future. It brings cheaper data posting today for rollups, while preserving a path to full sharding when the ecosystem is ready."

— Synthesis from EIP-4844, Ethereum.org, and independent research. (eips.ethereum.org)